ISO/IEC 27001 is frequently misunderstood as a technology checklist. It is not. The standard certifies a management system — an ISMS: the ongoing process by which an organization identifies its information security risks, decides what to do about them, and demonstrates that those decisions are actually carried out. Firewalls and encryption appear in it, but only as outputs of that process. Understanding this reframes the readiness work: the question an auditor asks is rarely "do you have X?" and almost always "how do you know X is working?".

Scope the ISMS Deliberately

The first real decision is scope: which parts of the organization, which services, which locations and which information assets the ISMS covers. Scope too broadly and you commit to auditing every corner of the business, including ones with no customer data and no appetite for process. Scope too narrowly and the certificate becomes misleading — customers reading "ISO 27001 certified" while the service they actually use sits outside the boundary. A defensible scope follows the data: the systems that store or process the information your customers care about, plus everything with administrative reach into them. Write the scope statement early; every subsequent decision hangs off it.

Risk Assessment Is the Engine

Everything in an ISMS traces back to the risk assessment. The mechanics are straightforward: inventory your information assets, identify what could go wrong for each — loss of confidentiality, integrity or availability — and rate each risk against criteria you define for likelihood and impact. What matters is that the assessment is yours: a generic risk register copied from a template will not survive an auditor asking why ransomware scores the same for a SaaS company as for a factory.

Each risk then gets a treatment decision — mitigate it with controls, transfer it, avoid it, or accept it with sign-off from someone entitled to accept it. Those decisions feed the Statement of Applicability (SoA), the document that maps your chosen controls against the standard's reference set and justifies every inclusion and exclusion. The SoA is the single most-read document in the audit; treat it accordingly.

Annex A in the 2022 Revision

The current standard, ISO/IEC 27001:2022, restructured the reference controls into 93 controls across four themes: organizational (37 controls — policies, supplier management, incident management, legal compliance), people (8 — screening, training, disciplinary process, remote working), physical (14 — facilities, equipment, media), and technological (34 — access control, cryptography, logging, backup, secure development). The 2022 revision also added controls that map directly onto modern operations: threat intelligence, cloud service security, configuration management, data leakage prevention and web filtering among them.

Two things trip teams up here. Annex A is a reference set, not a to-do list — you implement the controls your risk assessment calls for and justify the rest as not applicable in the SoA. And most engineering organizations discover they already operate many of the technological controls; what is missing is the documented policy above them and the evidence trail beneath them.

Evidence Is a Culture, Not a Scramble

The difference between a smooth audit and a miserable one is whether evidence exists as a byproduct of normal work. Access reviews recorded in tickets. Onboarding and offboarding checklists actually ticked. Change management visible in pull requests and pipeline logs. Backup restores tested on a schedule, with the test output kept. Log retention and alerting demonstrable in your monitoring stack — the same infrastructure a SIEM system builds on serves double duty as audit evidence.

Teams that treat evidence as a quarterly collection sprint end up manufacturing screenshots the week before the audit, which auditors recognize instantly. Teams that wire evidence into their tooling — tickets, CI, IaC, identity provider exports — barely notice the request list. The second posture is also, not coincidentally, the one where the controls are actually operating.

The Audit Cycle

Certification is not a single event. The initial audit comes in two stages: Stage 1 reviews your documentation — scope, risk assessment, SoA, mandatory policies — and confirms you are ready to be audited; Stage 2 tests whether the ISMS actually operates, through interviews, sampled records and walkthroughs. A certificate is then valid for three years, with surveillance audits in each intervening year and a full recertification at the end of the cycle. Internally, the standard requires you to run your own audit program and a management review at least annually — these are not formalities, they are where an honest organization finds its own nonconformities before the external auditor does.

Budget realistic calendar time from a standing start: typically several months to build the ISMS and let it generate operating evidence, because auditors need history, not intentions.

Where We Stand

Graf Clouds operates an ISO/IEC 27001-aligned ISMS ourselves — our ISO 27001 documentation is publicly available — so the guidance above reflects practices we apply to our own operations, not theory. If you are preparing for certification and want help with scoping, risk assessment or building the technical controls and evidence pipelines behind Annex A, our SecOps solutions team supports readiness work end to end.

Tags: #ISO27001 #ISMS #Compliance #RiskAssessment #SecOps