Annex A — Technological Controls (8.1-8.34)

At 34 controls, Technological is the second-largest Annex A theme — and the one most likely to overlap with what a technical audience already intuitively half-knows from hands-on security work. The challenge here isn't unfamiliarity; it's precisely naming which control governs a given technical practice, and not conflating closely related ones.

The 7 clusters

Two controls everyone conflates: 8.15 vs. 8.16

8.15 (Logging) is about generating and retaining event records — what gets logged, for how long, and how logs are protected from tampering. 8.16 (Monitoring activities) is about actively watching those logs (and other signals) for anomalies, and reacting. An organization can have excellent logging (8.15) and still fail 8.16 completely if nobody — human or automated — is ever actually looking at what's being logged. This exact gap (extensive logs, zero active monitoring) is one of the most common real-world findings in mature-looking organizations, and a frequent Foundation exam trap.

Why 8.31 underpins several other controls

8.31 (Separation of development, test and production environments) might look like a narrow, single-item control, but weakness here tends to cause failures elsewhere: if test data isn't separated from production (connecting to 8.33, test information), if changes aren't properly gated between environments (connecting to 8.32, change management), and if developers have production access they shouldn't (connecting back to 8.2, privileged access), you get compounding risk from what looks like one narrow gap. Auditors who find a weak 8.31 often look harder at these adjacent controls specifically because of this pattern.

Testing vs. monitoring — another easy mix-up

8.29 (Security testing in development and acceptance) is a planned, proactive activity done before release — SAST/DAST scans, code review, penetration testing on a pre-production build. 8.16 (Monitoring) is ongoing observation of a system that's already live. A vulnerability found by 8.29 before release is exactly the kind of finding a mature SDLC catches early and cheaply; the same vulnerability found via 8.16 monitoring after release, in production, is a much more expensive and higher-risk discovery.

Cryptography (8.24) — policy, not just implementation

8.24 isn't satisfied merely by "we use encryption somewhere." It expects a documented approach: which algorithms and key lengths are acceptable, how keys are generated, stored, rotated, and destroyed, and when encryption is required versus optional. An organization that encrypts data in transit but has no defined key management practice, or no policy on encryption at rest, has a real but easy-to-miss 8.24 gap — using cryptography and having a cryptography control are two different things.

Outsourced development (8.30) — the SDLC's own supplier control

8.30 is the Technological theme's counterpart to the Organizational theme's supplier controls (5.19-5.23, from an earlier lesson) — but specifically for outsourced software development. If a contractor writes code that ends up in production, the organization is still accountable for that code meeting its own secure development requirements (8.25-8.29), not just for the contract terms themselves.