← All posts

5 steps to Stage 1 readiness for SME ISO 27001 audit preparation

Getting audit-ready for ISO 27001 comes down to five steps done in order: define a defensible scope, run a gap analysis, remediate what fails, complete an internal audit and management review, then book Stage 1. Auditors expect at least two to three months of operating evidence for sampled controls, plus a Statement of Applicability, a risk register, and an internal audit report. Most first-time SMEs need several months from a standing start to certification.

TL;DR:

  • Focus on defining a narrow, defensible scope based on systems, teams, and regulatory boundaries to reduce evidence collection and streamline the process.
  • Conduct a thorough gap analysis at least eight to twelve weeks before the audit and score controls according to evidence readiness to prioritize remediation efforts.
  • Ensure all key documentation and evidence, including policies, risk register, SoA, audit reports, and live operating logs, are current and traceable from design to implementation.
  • Build internal audit and management review routines into ongoing operations, with clear ownership, regular monitoring, and documented corrective actions to maintain continuous compliance.
  • Automate assessment and evidence collection with dedicated tools to save time, ensure consistency, and simplify the workflow from gap analysis to certification readiness.

Table of Contents

What does an ISO 27001 audit preparation process actually involve?

Certification runs on a lifecycle, not a single exam. Understanding the stages before you start stops you from wasting evidence on the wrong thing at the wrong time.

Internal audits come first and are entirely within your control. You run these yourselves (or with a contracted auditor) against your own ISMS, checking whether controls actually operate the way your policies claim. Think of this as your dress rehearsal.

Stage 1 is a document review. The certification body checks that your Statement of Applicability, risk assessment, policies, and scope statement are coherent and complete enough to support a Stage 2 visit. Auditors are not yet checking whether controls work in practice, only whether the paperwork makes sense and whether you're ready to be assessed properly. A weak Stage 1 usually means a delayed Stage 2 booking.

Stage 2 is where operating evidence gets scrutinised. The auditor samples specific controls and asks to see proof they function day to day: access review logs, change tickets, incident records, training completion data. This is the difference between design evidence (a policy that says access is reviewed quarterly) and operating evidence (the actual screenshot showing the last three reviews happened on schedule). Auditors sample rather than check everything, but a gap in one sampled area often triggers a wider look.

Surveillance audits follow annually for the following two years, with recertification on a rolling three-year cycle. These are lighter than Stage 2 but still evidence-based, so the operating habits you build now need to survive well past the certificate date.

What auditors are actually testing across every stage:

  • Whether documented controls match what staff actually do, not just what the policy says
  • Whether evidence trails are timestamped, dated, and traceable to a specific control
  • Whether non-conformities from previous audits or internal reviews were genuinely closed
  • Whether the scope statement matches the systems and data flows actually in use
  • Whether management review and internal audit records show the ISMS is a living process, not a one-off project

Confusing internal audit with Stage 1, or assuming Stage 1 tests operating evidence, is one of the most common ways SMEs mistime their readiness work.

How do you define ISMS scope and build a Statement of Applicability?

Scope decides how much evidence you need to collect, so get it narrow and defensible before anything else. A scope that includes every system in the business multiplies your evidence burden for no certification benefit; a scope that excludes a system customers actually care about undermines the whole exercise.

Three things decide a workable scope:

  1. Systems and data flows. Map which applications, cloud environments, and third-party processors actually touch the information you're protecting, then draw the boundary around that set, not the entire IT estate.
  2. Teams and locations. Include only the business units whose work depends on the in-scope systems. A single product line or subsidiary can carry a certificate on its own, which is often the fastest route for SMEs with mixed maturity across departments.
  3. Legal and regulatory boundaries. Where GDPR, NIS2, or client contracts already draw a line around certain data or services, align your ISMS boundary to it rather than inventing a separate one, so evidence can be reused across frameworks.

Once scope is fixed, the Statement of Applicability becomes the master index for everything an auditor will ask about. For every one of the Annex A controls in ISO/IEC 27001:2022, the SoA needs three things: whether the control is included or excluded, the rationale for that decision, and a pointer to the evidence that proves it's implemented. An exclusion without a stated reason (say, "not applicable, no physical data centre operated") is one of the fastest ways to draw follow-up questions at Stage 1.

Keep SoA entries short and operational rather than descriptive essays. A one-line rationale plus a link to the relevant policy or evidence folder does more for an auditor than a paragraph of prose repeating the control text. A tight scope combined with a well-referenced SoA routinely shaves weeks off preparation, because every subsequent step, gap analysis, evidence collection, internal audit, only has to cover what's actually in scope.

How do you run a gap analysis before an iso 27001 audit?

A gap analysis is the single highest-leverage exercise in ISO 27001 audit preparation, because it tells you exactly where remediation time needs to go before you commit to an audit date. Score every control against three states: compliant (evidence exists and is current), partial (a policy exists but operating evidence is missing or stale), and non-compliant (no meaningful control activity at all).

A few concrete examples make the scoring model click:

  • Compliant: access reviews happen quarterly, are documented, and the last review is dated within the current quarter.
  • Partial: an access control policy exists and is signed off, but the last review on file is nine months old.
  • Non-compliant: no access review process exists, and nobody owns it.

Most first-time gap analyses find a large share of controls sitting in the partial category, which is exactly why the exercise matters: partial controls look fine on paper but fail the moment an auditor asks for operating evidence.

The recipe itself follows a fixed order:

  • Pull the standard and Annex A control list, ideally against a structured checklist that maps clauses to suggested evidence rather than working from memory.
  • Map each control to the specific system, policy, or process that's supposed to satisfy it.
  • Gather whatever evidence currently exists, even if incomplete, before scoring anything.
  • Score each control compliant, partial, or non-compliant using the evidence actually in hand.
  • Assign a named owner to every partial or non-compliant control, not a team or department.
  • Schedule remediation deadlines against the audit date, working backwards from Stage 1.

Timing matters more than most teams expect. Run the gap analysis eight to twelve weeks before your targeted audit date, which gives non-compliant controls enough runway to become genuinely operational rather than hastily documented. Re-check the highest-risk items again one to two weeks before the audit itself, because access lists, patch levels, and log retention drift even in well-run environments.

Pro Tip: Score honestly the first time. Marking a partial control as compliant to make the dashboard look better only delays the problem to Stage 2, where an auditor will find the gap anyway and it will read as a bigger issue for having been hidden.

Manual gap analysis across dozens of Annex A controls is where most SME teams lose the most hours, and it's also the step automated assessment tools compress most effectively, because scoring against a fixed control set is a pattern-matching task, not a judgement call.

What documentation and evidence do auditors expect to see?

Auditors want two layers of proof for every control: the design layer (the policy that says what should happen) and the operating layer (the record showing it actually happened). One without the other fails. A beautifully written access control policy with no review logs is just as weak as a review log with no policy explaining why the review happens.

Six documents form the backbone of any Stage 2 pack:

Artefact What it proves Typical evidence source
Information security policy Management commitment and control framework Signed, dated policy document
Risk assessment and register Risks identified, rated, and owned Risk register with scores, owners, review dates
Statement of Applicability Which Annex A controls apply and why SoA document linked to evidence folders
Internal audit report The ISMS was checked against its own requirements Audit plan, findings log, closure evidence
Management review minutes Leadership reviewed ISMS performance Dated minutes covering Clause 9.3 inputs/outputs
Corrective action log Non-conformities were tracked to closure Log with dates opened, actions, and closure evidence

Beyond the paper trail, auditors sample live operating evidence pulled directly from your working systems. Typical examples include:

  • Access review screenshots showing who had access, when it was reviewed, and what changed
  • MFA configuration exports proving multifactor authentication is enforced, not just recommended
  • Change management tickets showing approval before deployment, not after
  • SIEM or logging alerts demonstrating monitoring actually catches something
  • Incident tickets and closure notes, including at least one tabletop exercise or simulated incident
  • Training completion records tied to named staff, not a generic attendance sheet

The connection between the two layers is what auditors actually trace. If your access control policy states quarterly reviews, the auditor expects to open the risk register or a linked evidence folder and find four dated reviews across the last year, each with a named reviewer and a list of what was revoked. That end-to-end link, policy to evidence to outcome, is what separates a control that exists on paper from one an auditor will actually sign off. Teams that keep evidence scattered across email threads and personal drives routinely lose days at Stage 2 simply hunting for proof that already exists somewhere.

How do you run internal audits and management reviews for ISO 27001?

Internal audits exist to catch what an external auditor would catch, before it costs you a delayed certificate. Scope the internal audit sample the same way a certification body would: cover every clause from Clause 4 to Clause 10, and sample enough Annex A controls that no major control area goes unchecked for a full cycle.

A workable internal audit and management review sequence looks like this:

  1. Build an audit plan that lists which clauses and controls will be sampled, who audits them, and by what date, ideally rotating coverage so nothing goes two cycles unchecked.
  2. Run the audit and record findings against evidence actually inspected, not assumed. Every finding needs a clause reference, a description, and a severity rating.
  3. Log corrective actions for every finding, with a named owner and a target closure date, in the same corrective action log auditors will later ask to see.
  4. Verify closure with fresh evidence, not a verbal confirmation, and timestamp it so the closure date is defensible months later.
  5. Feed results into management review, which under Clause 9.3 needs to cover audit results, risk status, corrective action progress, and resourcing decisions, with dated minutes recording what leadership actually decided.

Management review minutes are one of the most under-prepared artefacts in SME certification attempts. A single paragraph confirming "management reviewed the ISMS and agreed it was fine" satisfies nobody. A usable template records the date, attendees, each Clause 9.3 input discussed (audit results, feedback, risk changes, improvement opportunities), and the specific decisions or resource commitments that followed. Auditors read management review minutes as the clearest signal of whether the ISMS is a genuine leadership priority or a compliance exercise bolted onto IT.

What should the final pre-audit checks before Stage 1 cover?

Before booking anything, assemble the Stage 1 document pack and stress-test it as if you were the auditor. The core pack rarely changes: Statement of Applicability, scope statement, risk assessment and register, the full policy set referenced in the SoA, your most recent internal audit report, and management review minutes.

  • Confirm every SoA entry has a rationale and an evidence pointer, not just a yes/no flag.
  • Check that policy version numbers and dates match what's referenced in the SoA and risk register.
  • Re-read your own internal audit findings and confirm every corrective action shows a closure date and evidence.
  • Verify the scope statement in your documents matches what you'll actually show the auditor on the day.
  • Prepare short answers for the questions Stage 1 auditors ask most: why controls were excluded, how risk ratings were decided, and who owns the ISMS day to day.

Stage 1 findings, even minor ones, are useful signals for what Stage 2 sampling will focus on. If a Stage 1 auditor flags a thin risk treatment plan, expect Stage 2 to sample that exact control area harder. Treat Stage 1 outputs as a preview, not a formality to survive.

On booking: certification bodies typically need several weeks' lead time to schedule an auditor, and independence rules mean the same consultant who helped build your ISMS generally cannot also certify it. Fees and total timelines vary by scope size and certification body across the EU, so ask for a written quote early rather than assuming a headline figure applies to your organisation.

What are the most common ISO 27001 audit findings?

Certain findings recur across almost every SME's first certification attempt, and most are fixable in days once you know to look for them.

  • Weak or missing evidence for a control that's technically in place. The control works, but nobody kept proof. Fix: start capturing screenshots, exports, and logs immediately, even retroactively where systems retain history.
  • Stale access reviews. A policy promises quarterly reviews; the last one on file is from two quarters ago. Fix: run the review this week and document it properly going forward.
  • Undocumented exceptions. A control is skipped for a legitimate business reason, but nothing records the decision or who approved it. Fix: write a one-paragraph exception record with an owner and a review date.
  • Thin risk treatment plans. Risks are listed and rated but treatment actions are vague ("monitor closely") rather than specific and owned. Fix: rewrite each treatment action with a named owner and a concrete step.
  • Training records without evidence of completion. Staff attended a session, but there's no register tying names to dates. Fix: capture a simple sign-off log for every future session.

The distinction that matters for planning is speed of fix. Access reviews, screenshots, and exception logs can be produced in days. Re-architecting a control, replacing a logging tool, or rebuilding an access model that was never role-based to begin with takes months, not weeks. If a major structural gap surfaces late, it's often better to push the audit date than rush a fix that won't survive Stage 2 scrutiny.

Where full remediation genuinely can't finish in time, document partial progress properly: a corrective action log entry showing the fix started, an interim control reducing the risk, and a realistic completion date. Auditors respond far better to an honestly tracked work-in-progress than to a control that looks finished but isn't.

How does ShieldIQCyber support ISO 27001 audit preparation?

Every step above, scope definition, gap analysis, evidence collection, and SoA maintenance, is repetitive, control-by-control work that scales badly with spreadsheets once a business has more than a handful of systems. That's the specific problem ShieldIQ's ISO 27001 platform is built to compress.

The platform runs automated assessments against the full Annex A control set, scores each one using the same compliant/partial/non-compliant logic covered earlier, and surfaces a prioritised remediation list with owners and deadlines rather than a static spreadsheet. AI-drafted policies map directly to SoA entries, and evidence, tickets, screenshots, configuration exports, gets collated against the specific control it supports, so the design-to-operating link an auditor traces manually is already built.

A typical readiness workflow moves from gap analysis, to remediation tracking with named owners, to an evidence export packaged for Stage 1 and Stage 2, all inside one dashboard rather than scattered across email threads, spreadsheets, and shared drives.

Because the same control library maps across frameworks, work done for ISO 27001 readiness often reduces the lift for GDPR, NIS2, or SOC 2 obligations running alongside it, a practical benefit for SMEs juggling more than one compliance deadline at once.

How do you train staff and build security awareness before the audit?

Auditors don't just check whether a training policy exists, they check whether staff can explain, in their own words, why a control matters. A signed policy nobody understands is a design-evidence gap waiting to be found.

Start awareness activities as soon as scope is fixed, not in the final fortnight. Run short, role-specific sessions rather than one generic company-wide briefing: developers need secure coding and change management context, customer-facing staff need data-handling and incident-reporting basics, and anyone with elevated access needs a clear walk-through of what a suspicious access request looks like.

Keep three things auditable:

  • A training calendar showing what was delivered, to whom, and when
  • Sign-off records tying named staff to specific sessions, not a generic attendance sheet
  • A short post-training check, even a five-question quiz, showing comprehension was tested, not just attendance

Phishing simulations and a single tabletop incident exercise carry disproportionate weight with auditors, because they demonstrate the ISMS extends beyond paperwork into staff behaviour. Run at least one simulated incident before Stage 2 and keep the notes: what was simulated, who responded, what worked, and what corrective action followed. That single exercise often does more to satisfy an auditor's curiosity about "real" security culture than a stack of signed policies ever will.

Who owns what during ISO 27001 audit preparation?

Certification stalls most often when responsibility is assumed rather than assigned. Every control, document, and evidence trail needs one named owner, not a department.

Typical role split for an SME:

  • An ISMS owner or compliance lead coordinates the whole programme, keeps the SoA current, and is the auditor's primary point of contact throughout.
  • IT and security staff own the technical controls (access management, logging, patching, MFA) and are the ones actually producing operating evidence.
  • Department managers own controls specific to their function, HR for onboarding and offboarding evidence, finance for segregation-of-duties controls, and are responsible for their team's training completion.
  • Leadership or the management team owns the Clause 9.3 management review, resourcing decisions, and formally accepting residual risk.
  • An internal auditor, whether a staff member or a contracted third party, owns the internal audit plan and must stay independent of the areas they audit.

Write this ownership down before the gap analysis starts, not after. A control with no named owner is, in practice, a control nobody is accountable for, and that's exactly the kind of gap that surfaces as a partial or non-compliant score. For small teams where one person wears multiple hats, that's fine, ISO 27001 doesn't require separate individuals for every role, but it does require that the overlap is documented and that audit independence is preserved wherever practical.

How do you plan communication with auditors and stakeholders?

A certification audit runs more smoothly when nobody involved is caught off guard. Build a simple communication plan covering three audiences: the certification body, internal stakeholders, and staff whose day-to-day work will be sampled.

With the certification body, confirm scope, sample areas, and logistics well ahead of the visit, and clarify who will be available on the day to answer questions for each control area. Share the Stage 1 document pack early enough that any obvious gaps surface before the visit rather than during it.

Internally, brief department managers on which of their controls are likely to be sampled and what evidence they'll need to have to hand. Nothing unsettles an audit day faster than a manager being asked for an access review they didn't know they were responsible for producing.

For staff, a short heads-up that an auditor may ask about specific processes, how to report an incident, how access requests get approved, removes the anxiety that leads to vague or contradictory answers. Auditors read hesitant, inconsistent answers from staff as a signal that a control exists on paper only.

During the audit itself, designate a single coordinator to log every question asked and every piece of evidence requested. That log becomes invaluable for Stage 2 preparation if Stage 1 surfaced any themes, and it prevents the same evidence being hunted for twice.

How do you finish risk assessment and treatment before the audit?

Risk assessment is not a one-off spreadsheet exercise completed early and forgotten. It's the document an auditor will open first, because it justifies every SoA inclusion and exclusion decision that follows.

Before the audit, confirm three things about your risk register. First, every identified risk has a current rating, using a consistent scoring method, not one that was set eighteen months ago and never revisited. Second, every risk above your organisation's accepted threshold has a treatment plan with a specific action and an owner, not a vague mitigation statement. Third, residual risk, what's left after treatment, has been formally accepted by someone with the authority to accept it, and that acceptance is dated and recorded.

Risk register linked to treatments and security controls

Auditors specifically test whether your Annex A control selection traces back to a risk. If a control is included in the SoA but no risk in the register justifies it, or a significant risk exists with no corresponding control, that's exactly the kind of traceability gap Stage 1 is designed to catch. Re-run this check as one of your final pre-audit steps: pick five risks at random and confirm each links cleanly to a treatment action, an owner, and a control in the SoA. Then pick five SoA entries and confirm the reverse, that each traces back to a risk that justifies its inclusion. Where the trail breaks in either direction, fix it before booking Stage 1, not during it.

Why tight scope and evidence discipline beat long policies

Most ISO 27001 audit preparation guides push you towards drafting exhaustive policies first. That's backwards for a small team with limited hours to spend. Scope and evidence collection deserve the bulk of your attention; policy documents are the easy part once you know exactly what needs proving.

Assign named owners early and keep every artefact operational rather than descriptive. A risk register that takes ten minutes to update stays current. A thirty-page policy nobody rereads becomes stale within a quarter, and stale documentation is precisely what gap analyses keep flagging as partial compliance.

The bigger shift worth making is treating ISO 27001 as an ongoing operating discipline rather than a one-off project with a certificate at the end. Left unattended, ad-hoc security practices accumulate into what's fairly described as security debt, fixes deferred, reviews skipped, exceptions undocumented, that eventually costs far more to unwind than it would have cost to prevent. Teams that keep internal audits and management reviews running on schedule, rather than reviving them only when a surveillance audit looms, are the ones who find recertification straightforward rather than a second scramble.

That's also where automation earns its place, not as a shortcut around rigour, but as a way to keep evidence current without dedicating a full-time role to spreadsheet maintenance. Small teams that treat compliance as a background operating habit, rather than an annual fire drill, consistently spend less total effort over a three-year cycle than teams who rebuild their evidence base from scratch every time an audit approaches.

— Matthew Lemon

Ready to move from checklist to certificate?

Everything covered here, scope definition, gap analysis, evidence collection, internal audit, Stage 1 preparation, takes real hours from a small team, and that's precisely where ShieldIQ removes the most friction compared with running it all manually across spreadsheets and shared drives. Rather than building a gap analysis from scratch, ShieldIQ runs an automated assessment against the full ISO 27001 control set, scores each control, and generates the prioritised remediation list your team would otherwise spend days assembling by hand.

ShieldIQ

The same dashboard drafts policies, maintains your Statement of Applicability, and exports evidence packaged for Stage 1 and Stage 2, so the five-step sequence in this guide becomes a workflow rather than a scramble. If your team is juggling ISO 27001 alongside GDPR or NIS2 obligations, the cross-framework control mapping means work done once counts twice.

Start with a free ISO 27001 readiness assessment to see exactly where your organisation scores today, or book a consulting session if you'd rather have hands-on support walking through gap analysis and Stage 1 preparation with your team.

Where to read more on ISO 27001 and audit readiness

The definitive reference remains the official ISO/IEC 27001:2022 standard page, which sets out the ISMS requirements and Annex A controls every audit checks against. For a working gap analysis method, the practical gap analysis guide covers scoring and timing in more depth than any single article can. Teams wanting a control-by-control evidence checklist should also review the ISO 27001 checklist built for SMEs, which pairs each Annex A control with the design and operating evidence auditors typically sample. For the technical controls that underpin much of Annex A, particularly around infrastructure and access, cloud security best practices for SMEs is a useful companion read.

Sources

Recommended