First timers most often stumble on ISO 27001 by scoping too wide, copying a template risk assessment, treating the Statement of Applicability as a formality, skipping the internal audit and management review, and building the system for the auditor rather than for the business. Each is easy to avoid if you know it is coming.
Quick background
ISO/IEC 27001:2022 asks you to run an information security management system (ISMS). The management clauses are 4 to 10: context, leadership, planning, support, operation, performance evaluation and improvement. Annex A lists 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34). ISO's own pages blocked our fetch and the standard is paid, so this guide uses the widely published structure and avoids quoting the text. Check clause detail with your certification body.
Mistake 1: scope too wide or too vague
A scope that says "the whole company" means every laptop, vendor and office is auditable. A scope that is vague means the auditor decides for you. Write a precise statement: products, locations, systems, people and exclusions with reasons. Start with what customers actually ask about.
Mistake 2: a template risk assessment
Copying a risk register full of generic threats gives you something that does not match how you work. Auditors ask you to explain a rating. Define your method (scales, criteria, acceptance level), list your real assets, and assess those. Keep the register small enough that you will maintain it.
Mistake 3: the Statement of Applicability as a spreadsheet exercise
The SoA lists each Annex A control, whether it applies, why, and whether it is implemented. Teams tick "yes" everywhere or "not applicable" without a reason. Tie each entry to the risk treatment and to a real artifact. Excluding a control is fine if you can justify it.
Mistake 4: policies nobody follows
Ten polished policies with no owner become nonconformities at the first audit. Fewer, shorter policies that match practice are safer. Give each an owner, an approval date and a review date.
Mistake 5: no internal audit, no management review
Clauses 9.2 and 9.3 require an internal audit and a management review. Teams save them for last or do them as a formality. Run the internal audit before the certification audit, by someone independent of the area audited, and hold a management review with real inputs and recorded decisions.
Mistake 6: forgetting evidence over time
A certification audit looks for operation, not just design. Controls like access reviews, backup tests and training must have records. If a control starts the week before the audit, the records will show it.
Mistake 7: owning it alone
An ISMS owned by one person fails when that person is busy. Spread control ownership across engineering, IT, HR and legal, and keep leadership involved. Leadership commitment is a requirement, not decoration.
Mistake 8: corrective actions that never close
Nonconformities and improvement ideas need owners, dates and closure evidence. Keep a log and review it monthly.
What a healthy first cycle looks like
Scope is written and approved. The risk method is documented and applied. The SoA is linked to risks. Policies are few and followed. Internal audit and management review have happened. The corrective action log shows items opened and closed. Then you ask a certification body to audit.
What to do
- Write a precise scope with exclusions.
- Define a risk method and assess your real assets.
- Build the SoA from the risk treatment, with a reason for every entry.
- Cut policies to those you will follow, with owners and review dates.
- Run an internal audit and a management review before the external audit.
- Start recurring controls early enough to build a record.
- Share ownership across functions.
- Track corrective actions to closure.
Quick check
How many controls are in ISO 27001:2022 Annex A?
93 controls in four themes: organizational, people, physical and technological.
Do I have to implement every Annex A control?
No. The Statement of Applicability records which controls apply, with a justification for each exclusion.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. That helps with the mistake that bites hardest, missing records over time.
Technical evidence comes from your real code and dependencies, through scans, SBOMs and reachability, not only policies, so your secure development and vulnerability controls have proof behind them. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. ISO 27001 certification is awarded by an independent certification body. Safeguard helps prepare and keep evidence ready, and does not certify you.
See it at /demos/framework-mapping.
Want to see it on your own stack? Book a call.
Sources
- ISO/IEC 27001 (page blocked to our fetch, check directly)
- NIST CSF 2.0 (CSWP 29), for mapping outcomes
Last reviewed: 18 October 2026.
