The ISO 27001:2022 controls auditors keep raising after the transition
Three Annex A controls that are new in the 2022 revision keep turning into nonconformities — what auditors look for, and how to get them operational before your audit.
The transition period for ISO/IEC 27001:2022 closed on 31 October 2025, and certificates against the 2013 edition have now lapsed. With most organisations through their transition audits and into the surveillance cycle, three Annex A controls come up again and again in findings: A.8.16 (Monitoring activities), A.5.23 (Information security for use of cloud services), and A.8.28 (Secure coding).
The pattern is not random. All three are among the 11 controls that are new to the 2022 revision, so none of them existed in 2013 implementations. Each requires a documented, operating process that many organisations had never built, and each is easy to “map” to something that already exists without actually meeting the intent. That last point is where most of the trouble starts.
Why mapping isn’t implementing
During transition, a common approach was to take the 2013 Statement of Applicability, run it through the official correspondence table between the two editions, and map each new control to the nearest existing process. For the 82 controls that were merged, renamed or carried over, that works reasonably well. For the 11 new ones, it tends to produce an SoA entry that says “implemented” and points at a procedure that was written for something else.
Auditors sampling the new controls are not checking whether a row exists in your SoA. They are asking to see the process, the people who run it, and records showing it ran. A mapping exercise gives you the first, sometimes. It rarely gives you the other two.
A.8.16 Monitoring activities
A.8.16 asks that networks, systems and applications are monitored for anomalous behaviour, and that appropriate action is taken to evaluate potential information security incidents. It sits next to A.8.15 (Logging), and the two are frequently confused. Logging is about producing, protecting and retaining records of events. Monitoring is about someone, or something, actually looking at them and acting.
A frequent finding is an organisation that points to its log retention policy, or to the existence of a SIEM or a cloud provider’s alerting console, as evidence for A.8.16. Auditors commonly want more than that:
- Defined scope. Which systems are monitored, and why those ones. This should trace back to your risk assessment and asset inventory.
- A baseline and criteria. What “normal” looks like, and what thresholds or patterns trigger review. A list of alert rules with owners is a good start.
- Responsibility. Who reviews alerts, how often, and what happens out of hours, including any managed service provider’s role.
- A link to incident management. How an anomaly becomes an event assessment under A.5.25 and, where needed, an incident under A.5.26.
- Records. Evidence the review happened: tickets, review logs, triage notes, tuning decisions.
If you have the tooling but not the procedure, write the procedure against what the tooling actually does, then produce at least one review cycle’s worth of records before the audit window.
A.5.23 Information security for use of cloud services
A.5.23 asks for processes covering the acquisition, use, management and exit from cloud services, in line with your information security requirements. It extends the general supplier controls in A.5.19 to A.5.22, and it is the one that most often exposes supplier registers built for the 2013 edition.
Those registers typically record a supplier’s name, service, contract date and perhaps a criticality rating. For cloud services, auditors commonly look for evidence that you have considered:
| Area | What tends to be asked for |
|---|---|
| Selection | Security criteria applied before adopting the service, and who approved it |
| Shared responsibility | A record of which controls the provider operates and which remain yours |
| Data location | Where data is stored and processed, verified against your legal and contractual obligations |
| Assurance | How you review the provider’s assurance, such as their certifications or audit reports, and how often |
| Configuration | Who manages security settings on your side of the line, such as access, encryption and backups |
| Exit | How you would retrieve your data and leave, and what the contract says about deletion |
The shared-responsibility row is where gaps usually sit. A provider’s certification covers the provider’s side. It does not evidence your tenancy configuration, your user access reviews, or your backups. Auditors know this, and a register that treats a provider’s certificate as full coverage is an easy finding.
A.8.28 Secure coding
A.8.28 asks that secure coding principles are applied to software development. It is the narrowest of the three, and the most likely to be excluded. If you genuinely do no software development, in-house or outsourced, the exclusion can be defensible, but think carefully about what counts. Infrastructure-as-code, automation scripts, low-code workflows and customer-facing integrations written by contractors all tend to be in scope in an auditor’s eyes. Outsourced development also brings in A.8.30.
Where the control applies, the common weakness is a secure development policy with no evidence underneath it. Auditors typically look for:
- Coding standards or principles that developers can actually find and that name the risks relevant to your stack
- Evidence those principles are applied: peer review records, static analysis results, dependency scanning, or pull request checks
- Training or onboarding that covers secure coding, linked to A.6.3
- How third-party and open-source components are selected and kept up to date
- How findings from testing under A.8.29 feed back into the standards
A short standard that is visibly used beats a long one that nobody has opened since it was approved.
A workable remediation plan
If you are preparing for your next surveillance audit, or your first certification under the 2022 edition, treat these three controls as a dedicated workstream rather than part of a bulk gap-closure exercise:
- Confirm applicability honestly. Check each against your scope and risk assessment, and record a real justification for anything you exclude.
- Write the procedure against the control, not the old annex. Use the control’s purpose, and the guidance in ISO/IEC 27002:2022, as your test of whether the procedure addresses it.
- Run at least one cycle before the audit. A procedure dated last week with no records is a finding waiting to be written.
- Sample them in your internal audit. Your audit programme under clause 9.2.2 should cover them explicitly, so problems surface internally first.
- Check the other new controls while you’re there. A.5.7, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12 and A.8.23 are less often raised, but they were mapped in the same rush.
Auditors are not looking for perfection. They are looking for a demonstration that the control is operational, not merely documented.
Where StayEvident fits
StayEvident assesses each in-scope Annex A control against the documents you upload and returns a verdict with citations to the passages it relied on, so a control that has been mapped but not written up tends to show as a partial or a gap. Cloud providers can sit in the supplier register with evaluations driven by criticality. A person confirms or overrides every verdict before it counts. See AI assessments and the registers for how that works.