ISO 27001 · ISMS implementation
An ISMS is a management system, not a document set. Most first-time builds get the ten steps right and still stumble on the same thing: running the system long enough to leave evidence.
TL;DR
An ISMS is the governance system ISO/IEC 27001:2022 requires, not a folder of policies. You build it in three moves. Satisfy Clauses 4 through 10 in full. Pick your controls from Annex A’s 93 based on a real risk assessment. Then run the system long enough to produce evidence before an auditor arrives. Most first-time builds for ISO 27001 certification take 4 to 12 months and follow the same 10-step sequence below.
Which edition this guide covers
Every reference here is to ISO/IEC 27001:2022. The transition window for the 2013 edition closed on 31 October 2025. Certificates issued against it are no longer valid. No certification body will audit against it. If you are starting today, the 2022 edition is your only option.
Sources: ISO/IEC 27001:2022 · ISO Survey 2024 · IBM Cost of a Data Breach 2026
What an ISMS is #
An Information Security Management System is a set of governance, risk management, policies, and technical controls. Together they protect the confidentiality, integrity, and availability of your information. It is not a single tool. It is not a binder of policies.
ISO/IEC 27001:2022 does not spell out how to secure your company. It defines what your management system must include. Then it requires you to make risk-based decisions: which controls to run, and how to prove they work.
That structure is why the same standard fits a 20-person SaaS company and a multinational bank. Neither gets a prescribed control list. Both work from the same seven clause groups and the same 93-control catalogue. Each builds a system sized to its own risk.
The seven clauses you cannot skip #
ISO/IEC 27001:2022 organizes its requirements into Clauses 4 through 10. Every clause applies. There is no scope to exclude one.
| Clause | What it requires | What auditors test |
|---|---|---|
| 4. Context | Scope, internal and external issues, interested parties | Whether your scope actually matches your real risk |
| 5. Leadership | Top management commitment, security policy, assigned roles | Interviews with executives, not just policy text |
| 6. Planning | Risk assessment, risk treatment, Statement of Applicability | Whether every control traces back to a named risk |
| 7. Support | Resources, competence, awareness, document control | Training records and how documents are versioned |
| 8. Operation | Running the risk treatment plan day to day | Whether controls produce evidence, not just exist |
| 9. Performance evaluation | Monitoring, internal audit, management review | Internal audit findings and how they were closed |
| 10. Improvement | Corrective action, continual improvement | Whether findings actually get fixed |
Clause 6 decides most outcomes. Every control you run has to trace back to a risk you named there. Auditors follow that chain from the Statement of Applicability back to the risk register. A control with no risk behind it becomes a finding.
Annex A: a catalogue, not a checklist #
Annex A lists 93 reference controls across four themes: organizational, people, physical, and technological. You do not implement all 93. You select the ones your risk assessment justifies. Then you document every exclusion in your Statement of Applicability with a real reason. “We are fully remote” does not clear every physical control on its own. It has to hold up against home offices, co-working space, and any data center your cloud provider uses.
| Theme | Controls | Examples |
|---|---|---|
| Organizational (A.5) | 37 | Policies, asset management, access control, supplier relationships |
| People (A.6) | 8 | Screening, training, disciplinary process |
| Physical (A.7) | 14 | Entry controls, equipment security, clear desk |
| Technological (A.8) | 34 | Access management, malware defense, secure coding, monitoring |
The 2022 revision added 11 controls that did not exist in 2013. They cover threat intelligence, cloud security, data masking, and secure coding. If your ISMS predates 2022, check these first. They are the most common gaps in a first internal audit.
The methodology: plan, do, check, act #
Plan-Do-Check-Act is a useful way to organize this work. Plan your scope and controls. Do the implementation. Check performance through audit and review. Act on what you find.
One correction is worth making here. It shows up in a lot of guides. ISO/IEC 27001:2022 does not name PDCA anywhere in its text. The 2005 edition did. The 2013 and 2022 editions dropped it, though the clause order keeps the same logic. Use PDCA as a project tool if it helps your team. No auditor will ask you to prove you followed it.
Three companion standards help while you build. ISO/IEC 27003:2017 covers implementation guidance. ISO/IEC 27004:2016 covers how to measure whether controls work. ISO/IEC 27005:2022 covers risk management method. None of the three are certifiable on their own. They support 27001. They do not replace it.
The 10-step build #
This sequence takes a first-time ISMS from a standing start to audit-ready. Each step produces a document or decision the next step depends on.
Get executive sponsorship and set governance #
Goal: a named accountable executive and a cross-functional team.
Get formal budget and resource commitment from someone senior enough to break ties. Name who owns the ISMS overall, who owns which risks, and who runs internal audit. Pull in IT, HR, legal, and operations, not just engineering. Treating this as an IT project is the most common early mistake. Security spans people and physical space as much as technology.
Define scope and context #
Goal: a written, defensible scope statement.
Document the issues that affect your ISMS and the parties who care about it. Define which systems, locations, and data sit inside scope under Clause 4.3. Keep the first pass narrow. A SaaS company certifying its core platform moves faster than one certifying every business function at once. You can widen scope in a later cycle.
Inventory and classify your assets #
Goal: an asset register with an owner on every line.
List the data, apps, infrastructure, and physical records inside your scope. Assign an owner to each item. Classify each by data sensitivity. Find the right level of detail. Listing every laptop by serial number is too granular. Listing “IT systems” means nothing in a risk assessment.
Run the risk assessment #
Goal: a risk register you can defend line by line.
Write your methodology first: how you score likelihood and impact, and where your acceptance line sits. Then find the real threats and weaknesses against your actual assets. Score each one the same way. Decide which risks need treatment. A risk assessment copied from a template will not survive an auditor asking why you scored one risk the way you did.
Build the risk treatment plan and Statement of Applicability #
Goal: the SoA and RTP, signed off by management.
For every risk above your threshold, choose a path: mitigate it, transfer it, avoid it, or accept it with a written reason. Then build the Statement of Applicability. For all 93 Annex A controls, state whether it applies, why, and where implementation stands. Weak justifications for excluded controls are a frequent finding.
Write your policies and documented information #
Goal: policies people can follow, not 200 pages nobody reads.
Draft the information security policy Clause 5.2 requires. Then write the supporting policies your Annex A selections call for: access control, change management, encryption, incident response, business continuity, supplier security, data handling. Keep each one short enough to audit. A policy statement nobody can check against evidence should not exist. Set up version control now. An unwritten change to policy is its own finding.
Run your controls in production #
Goal: controls running in production, not just designed on paper.
This step takes the most time and people. Deploy the tech controls: access management, logging, encryption, vulnerability scanning. Stand up the process controls: incident response, supplier assessments, change management. Extend physical controls to your offices or your provider’s. Start collecting evidence the day a control goes live, not the month before your audit. The usual floor is three months of operating evidence before you book a certification audit.
Train your people #
Goal: awareness that shows up in behavior, not just a completion record.
Cover the policy itself, common threats like phishing, how to report an incident, and what happens when someone breaks the rules. Repeat this through the year with refreshers and simulations. One onboarding session is not enough. Auditors look for signs of ongoing reinforcement, not a single annual completion record.
Run your internal audit and management review #
Goal: findings caught and closed before an external auditor sees them.
Clause 9.2 requires an internal audit covering every clause and every applicable control. Someone independent of the work has to run it. You cannot audit your own function. Document every finding. Open a corrective action for each one. Verify it closed. Clause 9.3 then requires a management review at least once a year, with real inputs: audit results, risk changes, and improvement ideas. Run your internal audit with the same rigor an external auditor would use. It is your best chance to catch problems first.
Run a pre-audit readiness check #
Goal: nothing the certification auditor finds that you did not already know about.
Review every clause and every applicable control one more time. Confirm your documents are current. Confirm your controls produce evidence over a long enough window. Confirm findings from your internal audit closed, or carry an active plan. Confirm your SoA still matches your risk assessment. Organize your evidence so anyone can pull up a single item in minutes. Brief the people who will sit for interviews on what to expect. From here, you book your Stage 1 and Stage 2 audits with an accredited certification body. The Standards Council of Canada accredits bodies in Canada. ANAB does the same in the United States. Both sign the IAF Multilateral Recognition Arrangement, which makes either country’s certificate count abroad.
What makes a certification stick, not just pass #
Across implementations in technology, financial services, and healthcare, the same handful of factors keep showing up on both sides of the outcome.
Sponsorship beyond a signature
An executive who attends management reviews and resolves conflicts between teams, not just one who signed the policy once.
A scope you can defend
A focused scope you can run is more credible than an ambitious one you cannot sustain.
A risk assessment grounded in reality
Real assets, real threats to your industry, and real business impact, not a template copied from the internet.
Controls you run, not just write
The gap between a written control and one that runs is the single biggest source of findings.
Evidence from day one
Waiting until a month before the audit to start collecting evidence is the most common and most avoidable failure.
An internal audit run for real
Treat it as a dress rehearsal with the same rigor an external auditor would apply, not a formality to get through.
A security culture people buy into
Controls fail when people do not understand or support them. Make reporting a concern easy and non-punitive.
Tooling that matches your team’s size
Manual evidence collection does not scale past a handful of controls. Automation earns its place here.
Treating certification as a starting point
The ISMS keeps running after you get the certificate, through steady monitoring and a yearly recheck.
Where a CaaS model fits
A named compliance manager, backed by a monitoring platform, can run these ten steps alongside your team. You are not left to interpret the standard alone. A platform that connects to Microsoft 365, Google Workspace, AWS, Azure, and GCP gathers evidence on an ongoing basis. It replaces one manual sprint before the audit. This does not shorten the minimum evidence window auditors expect. It changes who does the interpretation work along the way.
Frequently asked questions #
What are the mandatory requirements for an ISO 27001 ISMS?
Clauses 4 through 10 of ISO/IEC 27001:2022: context, leadership, planning, support, operation, performance evaluation, and improvement. You also produce a Statement of Applicability addressing all 93 Annex A controls, whether or not you select them.
How long does it take to build an ISMS and get certified?
Most small to mid-sized companies need 4 to 8 months. Larger or multi-site companies need 8 to 12 months or more. The floor comes from the minimum evidence period auditors expect: about three months. It has nothing to do with how fast you produce paperwork.
What is the difference between Clauses 4 through 10 and Annex A?
Clauses 4 through 10 define your management system: the governance and process requirements, all mandatory in full. Annex A is a reference catalogue of 93 controls. You select from it based on your own risk assessment, and document every inclusion and exclusion in your Statement of Applicability.
What is a Statement of Applicability and why does it matter so much?
It is the document that lists all 93 Annex A controls, states whether each applies to you, and justifies why. A thin justification for an exclusion is one of the most common findings in a certification audit. It signals the risk assessment behind it was not rigorous.
Is ISO 27001 built on the Plan-Do-Check-Act cycle?
Not by name, not anymore. The 2005 edition used the term PDCA. The current 2022 edition never mentions it, though the clause order keeps the same logic of planning, doing, checking, and acting. Treat PDCA as a helpful project framework, not a certification requirement.
What are the most common reasons an ISMS implementation stalls?
The two biggest: weak top management commitment, and treating certification as paperwork instead of a real change. Close behind: a superficial risk assessment, and a scope too broad to sustain. Evidence collection that starts too late to meet the minimum window is the last common cause.
Key takeaways #
- An ISMS is a governance system, not a policy binder. Clauses 4 through 10 are mandatory in full.
- Annex A’s 93 controls are a catalogue. You select and justify, you don’t implement all of them.
- ISO/IEC 27001:2022 is the only certifiable edition now that the 2013 transition window has closed.
- PDCA is a useful way to organize the work. It is not named in the current standard’s text.
- Plan for a real evidence period, about three months at the floor, before you book your audit.
- The internal audit under Clause 9.2 is your best chance to catch problems before an external auditor does.
Build your ISMS with backup, not alone #
A named compliance manager and a monitoring platform can run this 10-step process with you. From your first scope statement to ISO 27001 certification, in Canada or the United States.
