Who should read this: the person who has just opened Annex A of ISO 27001, counted 93 controls, and is trying to work out where on earth to start.
The standard groups those 93 into four themes: organisational (37), people (8), physical (14) and technological (34). That grouping is useful for an auditor filing findings. It is close to useless as a work plan, because it tells you nothing about who does the work, how long it takes, or what has to start first.
Here is a different grouping. Same 93 controls, sorted by how a real project moves.
Group 1: things you already do, you just cannot prove it
The largest group, and the reason the number 93 is less frightening than it looks.
You already onboard people. You already remove access when they leave, mostly. You already take backups. You already restrict who can reach production. You probably already lock the office. A meaningful share of Annex A is asking you to write down what already happens and keep a record of it happening.
The work here is not building anything. It is turning habits into records: a joiner and leaver checklist with dates on it, an access list with a review signature, a backup job with a test result attached.
Start here, because it is fast and it makes the rest feel possible. Two weeks of unglamorous documentation typically clears twenty or more controls.
The trap: writing a policy that describes an idealised company. If your leaver process is that someone messages the CTO, write that down and improve it, rather than describing an HR workflow you do not have.
Group 2: decisions only you can make
Small in number, and they gate everything else.
Who owns security. What risk you accept and at what level it gets signed off. What is in scope. Which supplier relationships matter. What your classification scheme is. Whether you will run a formal secure development process this year or not.
These are not tasks that can be delegated to a consultant or generated by a tool. They are decisions, and every project that stalls stalls because a decision stayed open for three months while people wrote documents around it.
If you want these framed and answered in a couple of weeks rather than a couple of quarters, that is exactly what an independent vCISO Security Audit produces. The Statement of Applicability is where these decisions get recorded, which is why that document deserves your attention before the control work starts.
Group 3: the evidence generators, start these in week one
This is the group people get wrong, and the mistake is expensive.
Access reviews. Log collection and review. Vulnerability scanning and patching records. Supplier reviews. Management review. Internal audit. Backup restore tests.
These controls are not judged on whether they exist. They are judged on whether they have been running for months. An auditor expects to see a history, typically several months of it, and there is no way to manufacture that history retroactively. You cannot compress this group by working harder in month eight.
So the rule is simple and it is the single most useful thing in this article: turn on the evidence generators in week one, before the policies are finished and before the risk assessment is complete. A quarterly access review that has run twice badly beats one that has run once perfectly the week before the audit.
Group 4: the engineering work
For a software company this is where the real effort sits, and it is concentrated in the technological theme.
Secure development lifecycle. Configuration management. Separation of development, test and production. Change management. Secure coding. Data masking in non-production environments. Cryptography and key handling. Monitoring.
Three of these were new in the 2022 edition, along with threat intelligence, cloud services security, information deletion, data leakage prevention, web filtering, physical security monitoring, and ICT readiness for business continuity. Eleven new controls in total, and they are the ones with no legacy template answer to copy, which is why they are where most Statements of Applicability go vague.
Budget real engineering weeks for this group. It is the part that cannot be solved by writing a document, and it competes directly with your product roadmap.
Group 5: the supplier long tail
Supplier controls look like four or five items in Annex A. In practice they are the group with the longest calendar time, because the work depends on other people answering you.
Your vendor list is longer than you think. Somebody has to inventory it, classify which suppliers matter, get security information from the ones that do, record the assessment, and set up a review cycle. Every step involves waiting on a third party.
Start this early for the same reason as group 3: the constraint is elapsed time, not effort. The same problem shows up under other regimes, which we covered in supply chain security and vendor risk, and the overlap means the work counts twice if you are also in NIS2 scope.
Group 6: the ones you will mark not applicable
If you are cloud-only with no server room, a good part of the 14 physical controls does not apply to you in the way the standard imagines. If you write no software, the development controls are handled through your supplier controls instead.
Marking a control not applicable is legitimate and expected. Marking it not applicable with a justification that collapses under one follow-up question is where audits go wrong, and that is covered in detail in the scope and Statement of Applicability article.
A better lens than the four themes
One genuinely useful thing the 2022 edition added, which almost nobody uses: every control now carries five attributes. Control type (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts (identify, protect, detect, respond, recover), operational capabilities, and security domains.
Those attributes let you slice Annex A by question rather than by filing cabinet. “Show me every detective control” is a far more useful view than “show me the physical theme”, especially when you are trying to work out whether you can actually notice an incident. A control library that carries the attributes and the cross-framework mapping turns that from a spreadsheet exercise into a filter.
What this means for sequencing
If you are starting from a normal, unmanaged position:
- Week one: switch on the evidence generators (group 3) and start the supplier inventory (group 5).
- Weeks one to three: make the decisions (group 2) and write the Statement of Applicability.
- Weeks two to six: document what you already do (group 1).
- Months two to five: the engineering work (group 4), which runs alongside everything else.
- Throughout: the evidence keeps accumulating, which is the point.
Notice that groups 3 and 5 start first even though they finish last. That is the whole trick. How those months add up in practice, and which part of the calendar you cannot compress at all, is covered in how long ISO 27001 really takes. For the wider picture of what a first certification involves at a company with no security function, start with ISO 27001 for a company without a security team, and on the budget question, is €50k for ISO 27001 worth it. The full route is on our ISO 27001 solutions page.
The technical reality: a control tells you to do a thing, not how well
Here is what Annex A leaves open, and it is structural rather than accidental.
Almost every control is written as an outcome to be achieved, not a standard to be met. That is deliberate, because the standard has to fit a three-person startup and a bank. The consequence is that the bar is set by your own Statement of Applicability and by what your auditor accepts, not by what an attacker would need to get past.
Concretely, within the letter of the controls:
- Access control is satisfied by a documented process and a periodic review. It does not require that multi-factor authentication is enforced rather than merely available, and the legacy login path everyone actually uses is where that difference lives.
- Logging and monitoring is satisfied by collecting and retaining logs. Detection is a separate question, and a log nobody reads is a storage cost, not a control.
- Backup is satisfied by backups running and being tested. Testing that the job reported success is not the same as restoring a system end to end under time pressure, and only one of those tells you whether you can recover.
- Vulnerability management is satisfied by a documented patch cycle. If you documented quarterly, quarterly is the bar you will be measured against, and a critical remote vulnerability sitting in production for eleven weeks is inside your own policy.
- Supplier security is satisfied by an assessment on file. Whether the supplier actually does what the questionnaire says is not tested by anything in Annex A.
None of that makes the standard useless. It makes it a floor. The useful move is to run two passes over Annex A: once asking “does this satisfy the control”, which is what gets you certified, and once asking “would this stop someone”, which is what gets you secure. Where the two answers diverge, write the divergence down. That list is short, it is uncomfortable, and it is worth more than the certificate.
