SaaSFort ISO/IEC 27001:2022 Annex A control 8.24 asks for rules on the effective use of cryptography, including key management, to be defined and implemented.
The word doing the work is implemented. A documented policy satisfies the first half of the control. Certification auditors sample the second half, and the gap between the two is where most nonconformities in this area come from.
The classic finding
A policy states that all data in transit is protected with TLS 1.2 or above using strong cipher suites.
The auditor picks three externally reachable services and tests them. Two match the policy. The third, a legacy API subdomain or a marketing site on a different provider, still accepts TLS 1.0.
The nonconformity is not “weak TLS on one host”. It is that the organisation had no mechanism to detect the divergence between its stated rules and its running systems. That is a management-system finding, which is more serious than a configuration finding and takes longer to close.
What that implies for evidence
The useful shift is from documents that describe intent to artefacts that record observation.
A good evidence set for the transport-layer portion of A.8.24 contains:
- A dated observation per service, not per policy. What did this endpoint actually negotiate, on what date.
- The raw material, not just a verdict. Negotiated protocol version and cipher suite, certificate issuer and key algorithm, validity window, observed headers. A verdict without its evidence cannot be re-examined when someone disputes it.
- A series rather than a snapshot. One measurement proves a moment. A sequence proves the detection mechanism the auditor is actually assessing.
- A defined scope, listing which assets are covered and which are excluded, with the reason.
The last one is where organisations lose marks unnecessarily. An external measurement covers externally reachable services. It says nothing about encryption at rest, internal service-to-service traffic, or key custody. Presenting it as though it covered A.8.24 entirely invites a correction. Presenting it as “the external transport portion, measured continuously, with key management evidenced separately” is straightforward to assess.
Where the boundary of an external scan actually sits.
What changed for this control in 2026
Three items now appear in A.8.24 discussions that did not two years ago. None is mandatory. All are reasonable questions under a control whose surrounding standard expects rules to reflect current practice.
Certificate lifetime and issuance process. With the CA/Browser Forum ceiling stepping down to 100 days in March 2027 and 47 in 2029, “how do you renew” has become a key management question rather than an operations detail. Manual renewal is a finding waiting to happen, and automation is the answer that also satisfies the agility question.
Post-quantum key agreement. Not expected to be deployed. Increasingly expected to have been considered, with the decision written down. What the question is really about.
Mail transport. A.8.24 pairs naturally with A.5.14, information transfer, and email is the transfer channel most organisations forget to encrypt at the transport layer. SPF, DKIM and DMARC do not cover it. MTA-STS is the control.
The related controls worth cross-referencing
A.8.24 rarely stands alone in an audit. The adjacent controls an auditor will pull on:
| Control | Connection |
|---|---|
| A.5.14 Information transfer | Rules for transferring information, including by email |
| A.8.20 Networks security | Transport protection at the network layer |
| A.8.9 Configuration management | Divergence between intended and actual configuration |
| A.5.21 ICT supply chain | Third-party code and its integrity |
| A.8.16 Monitoring activities | Whether divergence is detected, and how quickly |
A.8.16 is the one that connects back to the classic finding above. If you can show a dated series of external measurements with an alerting path, you are evidencing A.8.16 and A.8.9 with the same artefact you produced for A.8.24. That efficiency is the practical argument for measuring continuously rather than before each audit.
Preparing the section
- Inventory externally reachable services. Including the ones marketing set up. Certificate transparency logs are a good source of subdomains you have forgotten.
- Measure all of them, not a representative sample. Sampling is the auditor’s job, and doing it yourself first is how you avoid their sample finding the one bad host.
- Fix divergence, then update the policy to describe what is now true.
- Keep the dated outputs in the evidence repository, including the ones from before the fix. A record showing detection followed by remediation evidences the management system better than a clean snapshot does.
- Write down decisions not to act, with rationale. “We assessed post-quantum key agreement and scheduled it for Q2” is evidence. Silence is not.
Where this sits for other frameworks
The same measurement maps to NIS2 Article 21(2)(h), DORA Article 9, and, in a German context, the relevant BSI technical guideline. If you are pursuing certification while also answering NIS2 obligations, producing the transport evidence once and mapping it is materially less work than running two exercises.
The short version
A.8.24 has two halves and audits fail on the second one.
Measure what your services actually present, keep the dated raw observations, define the scope you are claiming, and document the decisions you made about controls you chose not to deploy yet.
Ready to put this into practice?
Two ways to start — pick what fits. Free Scan if you want to see your security grade in 60s with no commitment. Free 14-day Growth trial if you're ready to monitor multiple domains, export NIS2 reports, and download Deal Reports — no credit card required.
No credit card · Cancel anytime · GDPR-ready · EU-hosted