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.