ISO 27001 Annex A in a cloud-native company: which controls are already done
A company running entirely on managed cloud services already satisfies a large part of Annex A without knowing it. The work is evidencing that, and finding the dozen controls that genuinely need building.
The first reaction to ISO 27001:2022 in a twenty-person company running on AWS is that the 93 Annex A controls describe a different kind of organisation — one with a server room, a badge reader and a documented visitor log.
Some of it does. But a cloud-native company usually satisfies more of Annex A than it thinks, and the gap is concentrated in a small number of places. Knowing which is the difference between a three-month certification and a nine-month one.
What the cloud already gives you, with evidence
The 2022 revision reorganised the old 114 controls into four themes: organisational, people, physical and technological. The physical theme is where the cloud does most of the work.
Controls 7.1 through 7.14 — physical perimeter, entry controls, securing offices, equipment siting, cabling security, secure disposal — apply to the data centre. If your production runs entirely in a hyperscaler, you inherit these, and the evidence is the provider's own certification. Download the ISO 27001 certificate and the SOC 2 report from Artifact, Service Trust Portal or the equivalent, record which controls you consider inherited, and keep the currency of those documents on a review schedule.
Be precise about the boundary, because auditors are. You inherit the data centre. You do not inherit your office, your laptops or the disposal of the developer machine that had a copy of the production database on it in 2023. Controls 7.7 (clear desk), 7.9 (off-premises equipment) and 7.10 (storage media) still land on you.
Several technological controls are also mostly configuration you already have: 8.13 backup, 8.14 redundancy, 8.20 network security, 8.21 network services security, 8.22 segregation. The evidence is Terraform code and a restore test, which is a better artefact than a policy document anyway.
The controls that need real work
In our experience the gap concentrates in about a dozen places:
5.7 Threat intelligence is new in 2022 and catches people out. It does not require a subscription product. A documented routine — who reads which vendor advisories and CISA bulletins, how a relevant one becomes a ticket, with a few months of examples — satisfies it.
5.15, 5.16, 5.18 Access control, identity and access rights. The controls are ordinary; the evidence is what hurts. You need joiner/mover/leaver records and periodic access reviews with an artefact showing who reviewed what and what changed. An organisation with a graph of who can reach what has an easier time here than one with a spreadsheet.
5.23 Information security for cloud services is the control that explicitly names your situation: how cloud services are selected, what the shared responsibility split is per service, and what happens on exit. Most companies have never written the exit part down.
5.30 ICT readiness for business continuity. A restore that has actually been performed and timed, with the result recorded. Not a backup policy — a test.
8.8 Management of technical vulnerabilities and 8.28 Secure coding are where scanning tooling meets evidence. Having the scanner is not the control; the control is the triage process, the timeframes by severity, and proof they are met.
8.16 Monitoring activities. Logs collected, retained and actually alerted on. This is the control that most often reveals that alerts go to a channel nobody reads.
8.32 Change management and 8.31 Separation of environments. Usually already true through pull requests and separate accounts, but nobody has written down that the pull request approval is the change control record. Say so explicitly; it saves an argument.
The part that is not Annex A at all
Clauses 4 to 10 of the standard — the management system itself — are what actually fail audits. Annex A is a catalogue of controls you select from; the clauses are mandatory.
That means: defined scope, a risk assessment methodology and an actual risk register, a Statement of Applicability, security objectives with measurements, internal audit, and management review with minutes. The internal audit and the management review are the two most commonly missing, and neither can be manufactured retroactively — the certification body will look for dated records.
A realistic sequence
Scope first, narrowly and defensibly. Then the risk assessment, because the SoA has to follow from it rather than being written first and justified later. Then close the dozen control gaps. Then run the system for three months so there is evidence of it operating — access reviews performed, incidents logged, changes approved. Then internal audit, then management review, then Stage 1.
The three months of operation is the step people try to skip and cannot. An auditor can look at a policy written last week and see it was written last week.
The organisations that find this easy are the ones that treat the control as something the platform does and the evidence as something the platform emits. If you are generating evidence by hand, you will generate it once, for the audit, and then stop — which is precisely what the surveillance audit a year later is designed to find.