ISO 27001 Requirements: A Practical Checklist

ISO 27001 is the international standard for an information security management system, or ISMS. Certification is issued by an accredited body after an external audit, and buyers increasingly ask for it before signing, especially in Europe and among enterprise customers who need proof that a vendor manages security as an ongoing program, not a one-time project.

The standard itself is short, but the requirements are specific and the audit checks for evidence, not intentions. Below is a practical checklist of what is actually required, in the order most companies tackle it.

1. Define the scope of your ISMS

Clause 4 requires you to document which parts of the business the ISMS covers: which products, teams, locations, and systems are in scope, and which are explicitly out. A scope that is too broad slows you down and pulls in systems you do not need to certify. A scope that is too narrow raises questions from buyers who expected your core platform to be covered. Get this wrong early and you will redo months of work.

2. Get documented leadership commitment

Clause 5 requires evidence that senior management owns the ISMS, not just IT or a compliance hire. This means a signed information security policy, assigned roles and responsibilities, and management review meetings that actually happen and get minuted. Auditors ask for this evidence specifically because ISMS programs that live entirely inside one department tend to fail.

3. Run a formal risk assessment

This is the core of ISO 27001. Clause 6 requires a documented methodology for identifying information security risks, assessing their likelihood and impact, and deciding how to treat each one: accept, avoid, transfer, or mitigate with a control. The output is a risk register and a Statement of Applicability, which is the document that maps each risk to a control decision. Skipping the rigour here is the most common reason readiness stalls, because everything downstream depends on this register.

4. Set measurable security objectives

Objectives need to be specific and trackable, for example a target patch window or a maximum time to revoke access after an employee leaves, not vague statements like "improve security." Auditors will ask how you measure progress against each objective and what happens when you miss one.

5. Support the ISMS with real resources

Clause 7 covers competence, awareness, communication, and documented information. In practice this means: people responsible for security tasks are actually trained for them, staff go through security awareness training, and your policies, procedures, and records are version-controlled and kept current. A policy nobody has read since it was written is a common audit finding.

6. Operate the controls, not just write them down

Clause 8 is where operational planning and control happen. This is the clause that separates companies that have a folder of policies from companies that actually run an ISMS. You need evidence the controls are functioning: access reviews that happened on schedule, incident tickets that were worked, change requests that went through approval. Auditors sample this evidence directly.

7. Monitor, measure, and internally audit

Clause 9 requires you to track whether the ISMS is working, through metrics, internal audits, and management review. An internal audit has to happen before your certification audit, and it needs to be independent of the people who run the controls being audited. This is one of the most commonly missed requirements for companies moving fast toward a certification date.

8. Correct nonconformities and improve

Clause 10 requires a documented process for handling nonconformities, root-causing them, and tracking corrective actions to closure. Auditors expect to see this process used, not just described. A program with zero nonconformities on record for a full year usually reads as under-tested rather than flawless.

9. Select and implement Annex A controls

Annex A lists 93 controls across organizational, people, physical, and technological categories, covering things like access control, cryptography, supplier relationships, incident management, and business continuity. You do not need every control. You select the ones relevant to your risk register and document any exclusions with a justification in the Statement of Applicability. This is where most of the technical implementation work happens, and where scope creep does the most damage to a timeline.

10. Complete the certification audit in two stages

Stage 1 is a documentation review, where the auditor checks that your ISMS is designed correctly and ready for assessment. Stage 2 is the substantive audit, where the auditor tests whether the controls are actually operating as documented. Certification is valid for three years, with surveillance audits typically each year in between.

Where Canadian companies add a layer

If you handle personal information, ISO 27001 alone does not close the gap with Canadian privacy law. PIPEDA and, for Quebec-based operations or Quebec residents' data, Law 25 impose separate obligations around consent, breach notification, and data subject rights that are not covered by the standard's Annex A controls. Companies going through certification without accounting for this overlap often end up doing the privacy work twice, once for the ISMS and once to actually comply with Canadian law.

traztech runs ISO 27001 readiness engagements for Canadian companies and builds the PIPEDA and Law 25 overlap into the risk assessment and control set from the start, rather than treating it as a separate project. If you want a structured walkthrough of the implementation process, our ISO 27001 implementation guide breaks down the phases in more detail, and our compliance solutions overview covers how this fits alongside other frameworks like SOC 2.

Get a readiness assessment

If you are scoping an ISO 27001 project or trying to figure out how much work stands between where you are today and an audit-ready ISMS, talk to us. Contact traztech for a readiness conversation with Jacob Masse and the team.

Choosing a certification body, and what the quote is actually built from

Your certificate is only worth what the body behind it is worth. The thing to check is accreditation: the certification body should itself be accredited by a recognised accreditation body, such as the Standards Council of Canada, ANAB in the United States, or UKAS in the United Kingdom. Unaccredited certificates exist, they are cheaper, and enterprise procurement teams increasingly check the accreditation mark on the certificate. If a buyer rejects it, you have paid for a document that did not do the one job you bought it for.

The quote itself is priced in audit days, and audit days are driven mostly by headcount inside the scope, then adjusted for number of sites, complexity of the technology, and how many other frameworks you are certifying at the same time. A company of twenty-five people with one cloud platform and no physical data centre is a small number of days. The same company after acquiring a team in another country with its own systems is meaningfully more, because the auditor has to sample both. Ask for the day count and the rate separately, and ask how Stage 1, Stage 2 and each surveillance visit are split across the three-year cycle so you can budget the whole cycle rather than being surprised in year two.

Two other line items catch people out. Travel and expenses are usually billed at cost and can be material if your auditor is not local. And any nonconformity that requires a follow-up visit rather than a documentary close-out is billed as additional time. That is one more reason the internal audit in requirement seven is worth doing properly rather than treating it as a formality.

What Stage 1 actually finds

Stage 1 is often described as a paperwork check, which undersells it. The auditor is deciding whether it is worth their time to come back for Stage 2, and the findings are consistent enough to predict.

The most common is a scope statement that does not match reality. It names the product but not the corporate IT that supports it, or it excludes a development environment that clearly holds production data. The second is a Statement of Applicability where the justifications are copied text rather than reasoning about your business. The third is an ISMS with no evidence of having run yet: policies dated last week, a risk register with no review history, no management review minutes, and an internal audit that has not happened. Stage 1 can pass with a young ISMS, but it cannot pass with an ISMS that has never operated, because Stage 2 has nothing to sample.

The practical read is that you want at least two to three months of the ISMS actually running before Stage 2, including one management review and one internal audit. Companies that book the audit first and build backwards from the date are the ones that end up with a Stage 2 postponement, which costs both money and the buyer conversation the certificate was meant to unblock.

Writing a Statement of Applicability an auditor will accept

The Statement of Applicability is the document auditors spend the most time in, and the one most often written badly. For each of the 93 Annex A controls it needs four things: whether the control applies, why, how it is implemented in your organization, and where the evidence lives. Exclusions need a justification tied to your risk assessment, not a preference.

Some exclusions are routine and defensible. A fully remote company with no offices can exclude several physical controls, provided it has thought about home working and equipment handling instead. A company that writes no code of its own can exclude secure development controls. What does not survive is excluding a control because it would be inconvenient, or marking a control as applicable and implemented when the implementation is a policy sentence with no operating evidence behind it.

The 2022 version of Annex A brought in controls that catch out companies working from older templates, including threat intelligence, information security for use of cloud services, ICT readiness for business continuity, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding. If a consultant hands you a Statement of Applicability that does not address these, you are looking at a document built from a 2013 playbook, and the auditor will notice before your buyer does.

Risk assessment: two methods, and which one to pick

Clause 6 does not prescribe a methodology, which is why so many risk registers end up as generic lists. Two approaches work in practice. The asset-based method starts from an inventory of information assets, then identifies threats and vulnerabilities against each one. It is thorough and it is heavy, and for a company with a large estate it produces a register nobody maintains. The scenario-based method starts from realistic events, such as a compromised admin credential in the production cloud account, a laptop lost with local customer data, or a subprocessor suffering a breach, then works out which assets and controls are implicated. It produces fewer, better entries.

Whichever you pick, write the method down before you use it, including your likelihood and impact scales and your risk acceptance criteria. Auditors test whether the register was produced by the documented method, and a register with impact scores that clearly came from someone's judgement rather than a defined scale is a finding waiting to be written.

The register also needs to have moved. A risk register where every entry is dated the same week, has the same owner, and has never been re-scored tells the auditor the assessment was an event rather than a process. Re-score after any significant change and at least annually, and keep the history.

Internal audit when you are twenty-five people

Clause 9.2 requires the internal audit to be objective and impartial, which people read as requiring a separate department they do not have. It does not. Three arrangements work in a small company. Someone from a different function audits the ISMS, for example the head of finance auditing controls operated by engineering. A qualified contractor performs the audit on a fixed fee. Or two companies of similar size swap internal auditors, which is unusual but perfectly acceptable if both sides are competent.

What does not work is the person who wrote the ISMS auditing the ISMS, or the consultant who is also implementing your controls signing off on them. If we are building your ISMS we will not also be your internal auditor, and any firm that offers to do both is selling you a finding at Stage 2.

The internal audit also has to produce something. A report with no observations from a first-year ISMS is not credible. Real internal audits find that a policy was reviewed late, that two access reviews were performed by the wrong person, that the asset inventory is missing a service. Those observations feed clause 10, and a clause 10 process with entries in it is what a mature program looks like.

The three-year cycle nobody budgets for

Certification is not the finish. Surveillance audits happen in years one and two, and recertification in year three is a fuller assessment closer in effort to the original Stage 2. Each surveillance visit samples a different slice of the ISMS, and the auditor will specifically check that management reviews happened, that internal audits happened, that nonconformities from last time were closed with evidence of effectiveness, and that the risk register reflects the year's changes.

The steady-state workload for a company under a hundred people is roughly one management review per year with real inputs, one internal audit, quarterly control operation, and continuous handling of changes as they occur. Budget for the audit fees each year and for a few days of internal effort per quarter. Companies that treat the year after certification as a rest period arrive at their first surveillance visit with twelve months of nothing to show, which is a nonconformity in the clauses that matter most.

When ISO 27001 is the wrong purchase right now

If every buyer asking you for proof is American and the words in their email are SOC 2, do SOC 2 first. Certification against ISO 27001 will not satisfy a procurement process that has a SOC 2 report checkbox, and you will spend a year and a five-figure sum solving a problem nobody asked you to solve. The reverse is also true: if your pipeline is European or your buyers are large manufacturers and government-adjacent organizations, the certificate is the thing they recognise and a SOC 2 report will get polite confusion.

If you are pre-revenue with no named buyer requesting either, the honest advice is to wait. Build the underlying practices that both frameworks assume, meaning centralised identity with MFA, a real asset inventory, logging you can query, an offboarding process that runs the same way every time, and encrypted backups you have actually restored from. That work is never wasted, it costs you nothing in audit fees, and it cuts the eventual certification effort substantially.

And if you already hold a SOC 2 report, understand what carries and what does not. The technical evidence largely carries: access reviews, change management, vulnerability handling, vendor oversight. The management system does not, because SOC 2 has no equivalent of the risk methodology, Statement of Applicability, internal audit and management review requirements. Expect roughly half the work to be new, concentrated in clauses 4 through 10 rather than in Annex A. Our ISO 27001 implementation track is built around that split, and if the real problem is that nobody internally owns the program between audits, a compliance retainer is usually the cheaper fix than hiring for it.