All Compliance and ISO 27001 Coding Mammoth Semonto MijnLijn

How to Prepare Your Business for ISO 27001 Certification

A risk-based roadmap to get audit-ready for ISO/IEC 27001, with deliverables, pitfalls, and where Coding Mammoth helps.

Preparing for ISO 27001 certification graphic
Jelle De Laender
2 February 2026

ISO/IEC 27001 (ISO 27001) certification is not a pile of policies. It is proof that your organisation runs an Information Security Management System (ISMS) that consistently manages risk and keeps improving.

This guide walks through a practical preparation plan you can follow, whether you are a SaaS team moving upmarket or a business that needs a recognised security baseline for customers, regulators or procurement teams.

TL;DR

  • Define your finish line early: ISMS only, full certification, or phased.
  • Keep scope tight, risks explicit, and evidence collection built into daily work.
  • Your SoA must reflect real controls and evidence, not a template.
  • Run internal audits and management reviews before the certification body arrives.
  • Plan for ongoing surveillance audits and continual improvement, not a one-off sprint.

What ISO 27001 certification really checks

ISO/IEC 27001 defines the requirements for an ISMS: how you set the scope, identify risks, choose controls, operate them, measure effectiveness, and continually improve.

Certification means an independent certification body audits your ISMS and concludes it conforms to ISO/IEC 27001. You do not get certified by ISO. You get certified by a certification body (and ideally one that is accredited).

Step 0: Decide what done means (certification, or just an ISMS)

Before you build anything, clarify your finish line:

  • Implement ISO 27001 without certification: useful when you want a strong programme quickly, but certification is not required yet.
  • Certification for trust and market access: common when enterprise customers, tenders, or regulators expect it.
  • A phased approach: implement the ISMS now, certify once controls have been operating long enough to show evidence.

A small but important mindset shift: certification is an audit outcome. Your real goal is a working system that survives staffing changes, product changes, and new threats.

Step 1: Set scope and context (make it audit-friendly)

Your scope is the boundary of what is certified. Too wide and you drown. Too narrow and customers (or auditors) will challenge it.

Deliverables you should aim for:

  • ISMS scope statement (systems, locations, teams, products, exclusions)
  • Context and interested parties (customers, regulators, suppliers, internal stakeholders)
  • High-level asset inventory (information and supporting systems, not just laptops)

Practical guidance:

  • Start with the revenue-critical product or service, then expand later.
  • Document exclusions explicitly and justify them.
  • Make sure scope matches the contracts you care about. If a customer wants your production SaaS covered, do not scope only internal IT.

Step 2: Build a risk management engine you can repeat

ISO 27001 is risk-based. Auditors will look for a method that is consistent, not magical.

Deliverables:

  • Risk assessment methodology (how you identify, analyse, and evaluate risk)
  • Risk register (risks, owners, likelihood, impact, treatment decisions)
  • Risk treatment plan (what you will do, by when, and who owns it)
  • Risk acceptance rules (who can accept what level of risk)

Practical guidance:

  • Keep your risk scales simple. Low/Medium/High is fine if used consistently.
  • Assign owners who can actually change things.
  • Treat suppliers and cloud dependencies as first-class risk drivers.

Step 3: Choose controls and write a Statement of Applicability (SoA)

Annex A is a catalogue of control topics you can select from to treat risks. Your Statement of Applicability (SoA) is where you list which controls you apply, which controls you exclude, why those choices make sense, and where each control is implemented (process, policy, technical control, evidence source).

If you are transitioning from ISO 27001:2013 to ISO 27001:2022, the control set and numbering changes are significant. You may want to read our transition guide before you map controls.

Deliverables:

  • Statement of Applicability
  • Control implementation plan (what is already done vs. what needs work)

Practical guidance:

  • Avoid copy-paste SoA documents. Auditors can smell them.
  • Link controls to real evidence sources (tickets, configurations, logs, training records, supplier reviews).

Step 4: Implement controls in a way your team will actually follow

This is where most ISO programmes either become a lightweight operating system, or an expensive museum exhibit.

Focus on controls that match your risks and operating model:

  • Access control: joiner-mover-leaver, MFA, least privilege, privileged access
  • Secure delivery: change management, code review, CI/CD guardrails, separation of duties where realistic
  • Asset management: inventory, classification, acceptable use
  • Incident management: triage, escalation, post-incident reviews, learning loop
  • Supplier management: due diligence, security clauses, periodic review
  • Backup and recovery: tested restore, defined RPO/RTO, evidence of testing
  • Monitoring and logging: alerting, log retention, investigation workflows
  • Awareness and training: role-based training, not generic checkbox training

Deliverables:

  • Core policies (small set, clear ownership, reviewed on a schedule)
  • Procedures or playbooks where they reduce risk (incidents, access requests, vendor onboarding)
  • Evidence trails (tickets, screenshots, reports, meeting notes, approvals)

Practical guidance:

  • Prefer documenting what you do over doing what the template says.
  • Build evidence collection into existing tools (ticketing, version control, cloud config, HR systems).
  • If a control is manual, schedule it and assign it. Unowned controls do not survive.

Step 5: Prove it works (measurement, monitoring, and evidence hygiene)

Auditors do not certify intentions. They certify operation.

Deliverables:

  • Monitoring and measurement approach (what you measure, why, and how often)
  • Key ISMS KPIs (examples: patch SLAs, access review completion, incident response times, supplier review cadence)
  • Evidence map (for each key control: where the proof lives, who owns it, retention)

Practical guidance:

  • Choose a few meaningful metrics and make them reliable.
  • Track exceptions and corrective actions. Mature programmes show how they handle imperfect reality.

Step 6: Run an internal audit and a management review (pre-certification reality check)

Before the certification body arrives, you want to find issues yourself.

Deliverables:

  • Internal audit programme (scope, frequency, responsibilities)
  • Internal audit report(s) (findings, severity, corrective actions, deadlines)
  • Management review minutes (decisions, resourcing, priorities, improvement actions)

Practical guidance:

  • Internal audits should be independent. If the same person built the system and audits it, credibility drops.
  • Management review should drive decisions, not just record everything is fine.

Step 7: Choose a certification body and prepare for Stage 1 and Stage 2

Certification audits are typically done in two stages:

  • Stage 1: readiness and documentation review, confirms you can proceed
  • Stage 2: effectiveness review, tests implementation in practice through sampling and interviews

Practical guidance:

  • Select an accredited certification body where possible.
  • Align timing so you have enough operational evidence (not just freshly written policies).
  • Prepare a clean audit pack: scope, risk method, risk register, SoA, key policies, audit results, management review, corrective actions.

Step 8: Maintain certification (surveillance audits and continual improvement)

Certification is not a one-time event. Expect:

  • Surveillance audits (usually annually)
  • Recertification cycles (commonly every few years, depending on the scheme and certification body)

Your ISMS needs a sustainable operating rhythm:

  • Regular risk reviews
  • Supplier review cadence
  • Access reviews
  • Incident exercises
  • Internal audits
  • Management reviews
  • Continual improvement tracking

Where Coding Mammoth fits in your ISO 27001 preparation plan

Most teams do not fail ISO 27001 because they lack intelligence. They fail because they lack time, structure, and an experienced guide to prevent rework.

Coding Mammoth supports ISO 27001 programmes in three complementary ways:

1) Fractional CISO: leadership, prioritisation, and ISMS ownership

Best for: teams that need senior security leadership without hiring a full-time CISO.

A Fractional CISO helps you:

  • Set direction, risk appetite, and priorities
  • Translate ISO 27001 into an operating roadmap
  • Keep leadership reporting and accountability in place
  • Run management reviews and keep the ISMS alive after certification

Learn more: Fractional CISO services.

2) ISO 27001 Implementer: hands-on implementation that fits how you work

Best for: teams pursuing first-time certification or rebuilding a messy ISMS.

An ISO Implementer helps you:

  • Define scope and set up the risk method and risk register
  • Produce ISMS documentation and a robust SoA
  • Implement controls with your existing tooling and workflows
  • Build lightweight, audit-friendly evidence habits

Learn more: ISO 27001 Implementer services.

3) ISO 27001 Internal Auditor: independent readiness checks and internal audits

Best for: teams that want an objective view before the certification body finds surprises.

An Internal Auditor helps you:

  • Plan and execute internal audits with risk-based sampling
  • Identify gaps early and translate findings into clear corrective actions
  • Run certification readiness checks (interviews, evidence review, report quality)
  • Stay audit-ready year-round, including after certification

Learn more: ISO 27001 Internal Auditor services.

Common engagement patterns

  • We need certification fast, but done properly: Implementer to build and operationalise, then Internal Auditor for readiness, then Fractional CISO to maintain.
  • We are already implementing, but want independent assurance: Internal Auditor focused on readiness and corrective actions.
  • We are certified, but struggling to keep it running: Fractional CISO to own the operating rhythm, with targeted internal audits to keep drift under control.

If you want to talk through your situation, get in touch.

Common pitfalls (and how to avoid them)

  • Scope creep: start with what matters, expand later.
  • Policy theatre: policies must match operations and generate evidence.
  • No evidence trails: if it is not recorded, it did not happen (in audit terms).
  • Overengineering: ISO 27001 does not require heavyweight bureaucracy.
  • Supplier blind spots: your risk surface includes cloud and vendors.
  • Skipping internal audit and management review: these are not optional rituals, they are your safety net.

References and official links

ISO standards and official resources

Certification and accreditation context

Belgium-specific

Relevant blog posts