Implementing Cryptography & Physical Security

These two Annex A themes pair well in implementation terms: both are areas where organizations frequently claim a control exists ("we use encryption," "we have physical security") without ever building the specific, documented practice an auditor can actually verify — exactly the gap Foundation's control 8.24 and Physical theme lessons warned about.

The key management lifecycle

A cryptography control isn't satisfied by "we use encryption somewhere" — it requires a defined lifecycle for the keys themselves:

Generation   → Keys created using an approved method and
                sufficient randomness (not weak/predictable sources)
Distribution → Keys reach only the systems/people that need them,
                never over an unencrypted channel
Storage      → Keys are never stored alongside the data they
                protect, ideally in a dedicated key management
                system or hardware security module (HSM)
Rotation     → Keys are replaced on a defined schedule, or
                immediately upon suspected compromise
Revocation   → A compromised or retired key can be invalidated
                before its scheduled rotation
Destruction  → Retired keys are securely destroyed, not just
                deleted from a file listing

A common implementation gap: an organization encrypts data at rest and in transit (genuinely good technical practice) but has never documented who can access the encryption keys themselves, how often they rotate, or what happens if a key is suspected compromised. Strong encryption protecting data that anyone with database access can also decrypt (because the key sits right next to the data) provides much less real protection than it appears to.

Selecting algorithms without guessing

Implementers shouldn't invent cryptographic choices from scratch. A defensible cryptography policy references current, recognized guidance (e.g., NIST publications, or a national cryptography authority's recommendations) rather than a developer's personal preference or an outdated tutorial. Two practical principles:

• Avoid deprecated algorithms and modes once a recognized body has flagged them as weak (e.g., older hash functions known to have practical collision attacks) — "it still technically works" is not the same as "it's still acceptable."
• Prefer well-reviewed, standard implementations over custom cryptographic code — implementing your own encryption algorithm, even competently, is a well-known anti-pattern in the security field, since subtle implementation flaws in cryptography are extremely difficult to detect through normal testing.

Physical security: matching effort to your actual footprint

Foundation's Physical controls lesson introduced the shared responsibility model. Implementation means actually deciding, concretely, what applies:

• Fully cloud-hosted, remote-first organization: most physical perimeter/entry/environmental controls transfer to the cloud provider. Implementation work here is mostly about collecting and filing the provider's certification evidence (Foundation, lesson 9) and addressing what never transfers — securing employee laptops (encryption, screen lock policies), secure disposal of any physical media, and clear desk practices for remote workers' home offices.
• Organization with a physical office: implementation additionally requires real measures — badge access with logging, a visitor sign-in/escort process, equipment placement away from public view or environmental risk (e.g., not near a water source), and a documented process for secure disposal of retired office equipment.

Writing the SoA transfer entry properly

Foundation's SoA lesson established what a defensible entry looks like. Applied here: it's not enough to write "physical security: handled by cloud provider." A properly implemented entry names the specific provider, references the actual certification (with a certificate number or renewal date if available), and states when this evidence was last reviewed — turning an assumption into something the organization has actually verified and can produce during a Stage 2 audit.