ISO 27001 is the framework your company needs when you are selling outside the US, or when a large customer runs it themselves and wants you to meet the same bar. It is more process-oriented than SOC 2, more prescriptive in places than HIPAA, and the certification lasts three years with annual surveillance audits in between.
This guide is for executives whose companies are preparing for a first-time certification, or recertifying after three years. Written in plain language, with a focus on what actually matters in practice.
What ISO 27001 actually is
ISO 27001 is an international standard for Information Security Management Systems, which is a formal name for "the system your company uses to run its security program." You build an ISMS, you document it, and you invite an accredited certification body to audit it. They review your documentation in a Stage 1 audit, then come on-site or remote for a Stage 2 audit where they watch your controls operate.
The deliverable is a certificate, issued for three years, with two interim surveillance audits to confirm you are still following the program. Recertification at the end of the three-year cycle is a full audit again.
The 2022 revision of the standard moved access controls from Annex A.9 to parts of Annex A.5 and Annex A.8. The numbers changed, the substance did not. For most of this guide I am going to avoid the exact paragraph numbers and talk about what the requirements ask for.
Where access controls live in the standard
Six areas do most of the work on the access side. I am going to describe each one in plain language.
A formal access control policy
Not a wiki page. An actual document, approved by your leadership team, with a version number and a review cadence. This is the anchor every auditor starts from, and they will follow the policy into your systems to verify that what you claim matches what you do.
User registration and removal
Everyone has their own identity. New hires get access through a documented process with approvals. People who leave or change roles lose their access through a documented process within a defined window. Substantively this is the same expectation as SOC 2, but ISO puts more weight on the paper trail than SOC 2 does.
Privileged access as a separate discipline
This is where ISO diverges from the looser US frameworks. Privileged access has its own requirements. Separate approval workflow, separate accounts for elevated work, logging that is distinct from general access logging, and a review cadence that is more frequent than regular user reviews. If you are treating privileged access as "regular access with more permissions," you are going to have findings.
Access reviews with assigned ownership
Similar to SOC 2 user access reviews, but ISO is explicit that someone has to own each asset and each access population. Your review artifact has to name the reviewer, the criteria they used, and the resulting changes.
Secure authentication
Password policy, multi-factor where warranted, credential storage, lockout behavior, and secure credential distribution. Modern authentication is assumed, but the auditor expects to see that you considered your options and documented the decision you made.
Restriction on source code and utility programs
This one tends to surprise teams. Source code access is a distinct control. So is access to utility programs, which is the auditor's term for admin tools like database consoles, configuration management, and infrastructure automation. Both require documented restrictions with evidence of who can reach them and why.
The ISMS requirements outside Annex A
Access controls are only part of the picture. ISO 27001 certification also requires a running ISMS, which means three practices that executives need to know about.
Management review. Your leadership team formally reviews the program on a schedule, looking at incidents, risk treatment progress, audit findings, and resource needs. The meeting minutes are an audit artifact.
Continual improvement. Findings from audits and incidents have to feed back into the program. An auditor who sees a finding from last year that nobody acted on will likely find it again this year, and that becomes a nonconformity of a different kind.
Statement of Applicability. The master document that lists every control in Annex A, notes which ones you applied, which you excluded, and why. Auditors read this as a description of your program, and they test your claims against reality.
Where organizations commonly fail
Four patterns show up often.
Generic policies that have no connection to how the company actually operates. Written once at certification time, never updated, no mention of the applications or tooling that actually run the controls. Stage 2 auditors sit next to an administrator and watch them provision an account. If what they see does not match the policy, the policy has to be rewritten or the process has to change.
Privileged access blended with normal access. Platform engineers with standing root access in production. Database administrators who log into their work laptop with a credential that can drop tables. Fails the requirement for privileged access to have its own discipline.
Source code access wide open. In many engineering organizations, every engineer can read every repository. ISO expects access to be restricted by need, logged, and reviewed. That does not mean you have to silo your teams. It does mean there has to be a deliberate decision about who can read what, with approval.
Statement of Applicability that claims more than the company does. If your SoA says you enforce multi-factor on all privileged access, and a Stage 2 auditor finds an administrator account without it, the gap between the SoA and reality becomes a major nonconformity.
The executive playbook
Start with the risk register, not the Annex
Do not walk through the standard list of controls and try to implement each one. Build a risk register first. Identify your actual assets, your actual threats, your actual vulnerabilities. From that, the applicable controls emerge. The Statement of Applicability becomes a description of decisions you made, rather than a ritualistic checklist.
Anchor your policy to what your tooling actually does
If your policy says access is reviewed quarterly, and your governance tool runs a review quarterly with an audit log, those statements stay aligned because they describe the same thing. When you write policies that describe the automation, and you automate the thing the policy describes, you never end up in the gap between paper and practice.
Separate identities for privileged work
Every human with elevated access gets two identities. A daily driver for email, calendar, and normal work. A privileged identity that is only used when elevated access is required. The privileged identity has its own multi-factor, its own approval workflow, and its own log stream. Standing privilege goes away. Everything privileged is requested, time-boxed, and recorded.
Bring source code under the same governance
Your code hosting platform goes behind single sign-on with automated provisioning. Team membership flows from identity provider groups. Branch protection and code owner review on anything sensitive. Access reviews that include repositories, not just SaaS applications.
Put admin tools under the same regime
Database consoles, cloud provider consoles, infrastructure automation, and observability tools all count as "utility programs" for ISO purposes. Each one goes behind single sign-on. Each one has a defined role population. Each one produces logs that feed the same review cadence as everything else.
Assign owners for every review
For every system in scope, there is a named owner responsible for access reviews. Reviews happen on a schedule, results get recorded, and changes flow back through the normal provisioning workflow. The auditor asks for the review log and the resulting change tickets, and the paper trail is intact.
What Stage 2 actually feels like
A Stage 2 audit runs for a few days, on-site or remote, and looks more like an interview-plus-observation session than a document review. Auditors will ask to see a new hire get provisioned. They will ask to see a terminated employee get deprovisioned. They will ask for the last access review and sample it. They will pick systems and test the controls directly.
Organizations that have done the work above make Stage 2 feel like a guided tour. Organizations that have not, make it feel like an interrogation. The difference is whether your controls produce evidence as they operate, or whether evidence has to be assembled under pressure.
Where to go from here
If you are preparing for a first-time ISO 27001 certification, the Governance Buildout engagement covers the ISMS components around access, builds the Statement of Applicability from your actual environment, and instruments the controls so Stage 2 evidence is already in place before the auditor shows up. If you are certified but concerned about surveillance audit findings, the Hardening Sprint targets the Annex controls that most often produce nonconformities in years two and three.