1. What ISO 27001 certifies, and what it does not
ISO/IEC 27001 certifies a management system, not a server. The auditor is checking whether your organisation has a working process for identifying information security risks and doing something about them, and whether the controls you chose are actually operating. The infrastructure is evidence, not the subject.
That single sentence explains most of the friction engineering teams feel with it. SOC 2 asks whether your controls operated over a period. ISO 27001 asks whether your system for choosing and running controls exists and is followed. You can have excellent infrastructure and still fail, because nothing is written down; you can have mediocre infrastructure and pass, which is why the certificate alone is a weak signal and buyers increasingly ask what is behind it.
The current edition is ISO/IEC 27001:2022. Amendment 1, published in February 2024, added a short climate-change consideration to clauses 4.1 and 4.2: you must decide whether climate change is a relevant issue for your organisation and record that determination. The transition window from the 2013 edition closed on 31 October 2025, so any certificate still referencing the old version is no longer valid.
2. The paperwork that has no infrastructure equivalent
Four artifacts are mandatory and cannot be produced by a pipeline. Budget real calendar time for them:
- Scope statement. Which parts of the organisation, which services, which locations are inside the ISMS. A narrow scope is legitimate and cheaper; a scope that excludes the thing your customer cares about is worthless.
- Risk assessment and treatment plan. Identified risks, owners, decisions: mitigate, accept, transfer or avoid, and what you did.
- Statement of Applicability. Every control from Annex A with a yes or no and a reason. This is the document the auditor reads first.
- Internal audit and management review. Evidence that you checked yourselves and that management looked at the result before the certification body arrived.
3. The 93 controls, and which of them are infrastructure work
Annex A of the 2022 edition lists 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34). The 2013 edition had 114 across 14 domains; the content did not shrink, it was regrouped and merged.
You are not required to implement all 93. You are required to consider each one and justify what you exclude. Here is the honest split of who does the work:
| Theme | Controls | Who carries it |
|---|---|---|
| Organizational | 37 | Mostly management: policies, supplier agreements, classification, incident process. Infrastructure supplies the asset inventory and the evidence. |
| People | 8 | HR: screening, terms of employment, awareness, offboarding. Engineering only removes the access. |
| Physical | 14 | Offices and datacentres. If you are cloud-only, most of this inherits from the provider's own certification, and you evidence that inheritance. |
| Technological | 34 | This is the engineering column: access control, cryptography, logging, monitoring, backup, secure development, change management, configuration, data masking, network segregation. |
So roughly a third of the standard lands on the people who run the systems, and that third is where a certification stalls when the platform is not ready.
4. The technological controls as a backlog
Translated out of standard-speak, and stripped of anything a platform team would not want anyway:
- Access. Named identities through one identity provider, MFA everywhere, roles defined in code, privileged access separated and reviewed on a schedule you can show.
- Cryptography. TLS in transit, encryption at rest, and a written key management position: who holds keys, how they rotate, what happens when someone leaves.
- Logging and monitoring. Centralised logs with an agreed retention, clock synchronisation, alerts that reach a person, and protection of the logs themselves from the people they record.
- Backup and continuity. Backups as code, off-site copies, and restores rehearsed on a schedule. Auditors ask for the restore record, not the backup policy.
- Secure development and change. Every change through review, environments separated, secrets out of repositories, dependency and image scanning with a patch cadence that has owners and deadlines.
- Configuration and asset management. An inventory that matches reality because it is generated from the infrastructure, not typed into a spreadsheet once a year.
5. The certification cycle, in plain calendar terms
- Stage 1: a documentation review. The auditor checks that the ISMS exists on paper: scope, risk method, Statement of Applicability, internal audit, management review. Failing here is usually a paperwork failure, not a technical one.
- Stage 2: the certification audit proper. Walkthroughs of the controls you declared applicable, with evidence sampled from the running system.
- Surveillance audits in years one and two, then recertification in year three. The certificate is valid for three years and only stays valid if the system keeps running.
That last point is the one to plan for. ISO 27001 is not a one-off project with a certificate at the end; it is an annual commitment, and the cheapest way to survive it is to make the evidence a by-product of operations rather than a yearly excavation.
6. If you already have SOC 2
You are most of the way there technically, and barely started administratively. The controls overlap heavily: access, encryption, logging, backup, change management, vendor management. What SOC 2 does not give you is the management system: scope, risk treatment, Statement of Applicability, internal audit, management review.
The practical order for a team selling into both the US and Europe: build the technical controls once, run them continuously so the evidence accumulates, then present that evidence twice, in the shape each framework expects. Doing the two as separate projects means paying for the same engineering work twice. We covered the SOC 2 side in SOC 2 for Infrastructure Teams, and the EU regulatory side in NIS2 in Practice.
7. Five things that fail an audit, none of them exotic
- A Statement of Applicability that excludes controls without a reason. Exclusions are allowed; unexplained exclusions are a finding.
- An asset inventory nobody maintains. If it is a spreadsheet, it is already wrong. Generate it.
- Backups never restored. The single most common gap we find when we take over an estate.
- Access reviews that happened once, before the audit. The cycle has to be visible over the year.
- No internal audit. It is a mandatory clause, not an optional nicety, and it must happen before the certification body arrives.
8. Where we fit
DigitalCare is the engineering side of this. We implement the technological controls in your infrastructure as code, keep them enforced and monitored, and make the evidence fall out of normal operations: access reviews, restore drills, patch reports, change history with named approvers. Our agents watch posture continuously and remediation ships as pull requests your engineers review and merge.
We do not write your ISMS for you and we do not issue certificates. The scope, the risk treatment, the Statement of Applicability and the internal audit stay with you or your consultant; the certificate comes from an accredited certification body. If the gap you are staring at is the technological third of Annex A, that part is ours: see Security and Compliance Automation.
This article is engineering guidance, not certification advice. Scope, control selection and the audit outcome are determined by your auditor and certification body.
