Preparing for an ISO audit: Stage 1 and Stage 2 mechanics for ISO 27001, 27701, and 42001

Practitioner reference for ISMS / PIMS / AIMS programme owners · 2026-05-24 · Written from twelve years running ISO certification and surveillance audits, both as auditee and as a third-party reviewer

What ISO certification actually feels like

I have been on the inside of more ISO 27001 audits than I care to count. The first thing I tell anyone going through it for the first time: it is not a single event. It is a two-stage assessment plus three years of surveillance audits, and how you handle Stage 1 substantially determines how Stage 2 goes. The audit is also significantly less adversarial than people fear, and significantly more procedural than people hope.

This guide covers the mechanics. What happens in Stage 1, what happens in Stage 2, how the surveillance cycle works, where the differences between ISO 27001, ISO 27701 (privacy information management), and ISO 42001 (AI management) matter, and what I would do if I were starting the preparation today.

If you have read my pre-audit guide already, this picks up where that one leaves off — with the specifics of the ISO family.

The certification structure

ISO certifications follow a three-year cycle:

• Year 0 — Initial certification. Stage 1 (documentation review) followed by Stage 2 (operational assessment). If you pass Stage 2 with no major nonconformities open, you get certified.
• Year 1 — Surveillance audit. Reduced scope, focused on changes, open items, and a sample of controls. Typically 2-3 days for a mid-sized organisation.
• Year 2 — Surveillance audit. Similar to Year 1 but rotates the control sample to cover what wasn't covered in Year 1.
• Year 3 — Recertification. Full Stage 2-equivalent assessment to re-issue the certificate for another three-year cycle.

Major nonconformity at any point can suspend or revoke the certificate. Minor nonconformities require a remediation plan and proof of closure, usually within 90 days. Observations are recorded for context but do not require formal response.

The audit body — the certification body, or CB — is accredited by a national accreditation body (NABCB in India, UKAS in the UK, ANAB in the US). The CB cannot also be your consultant. If your consultant is part of a firm that does certification, those are two different teams behind a Chinese wall, and you should verify that wall is real.

Stage 1: what it actually is

Stage 1 is documentation review and audit readiness assessment. It is not a controls audit. The auditor is checking whether your management system is documented, internally consistent, and ready to be operationally tested.

The output of Stage 1 is one of three things: 1. A clean readiness confirmation — Stage 2 can proceed as scheduled 2. A list of "Stage 1 findings" that you must close before Stage 2 (typically minor documentation gaps) 3. A recommendation to delay Stage 2 because the management system is not ready

Option 3 is what you want to avoid. Reasons it happens: scope is incoherent, statement of applicability (SoA) is inconsistent with the risk assessment, mandatory policies are missing, evidence of management system operation is absent (no completed internal audit, no completed management review).

What the Stage 1 auditor reviews

The mandatory artefacts they will request, for ISO 27001:

For ISO 27701 (PIMS) add:

• Privacy roles and responsibilities — controller/processor designation, DPO appointment if applicable
• Records of Processing Activities (Article 30 equivalent) — complete inventory of personal data processing
• Data Subject Rights procedures — documented and tested
• Cross-border transfer mechanisms — SCCs, adequacy decisions, transfer impact assessments

For ISO 42001 (AIMS) add:

• AI system inventory with classification (purpose, deployment context, risk level)
• Impact assessments for high-risk AI systems
• AI policy and AI governance committee structure
• AI risk management methodology — distinct from general InfoSec risk management

What goes wrong in Stage 1

Three patterns account for nearly all Stage 1 problems:

Scope drift. Your scope statement says "Bangalore office, SaaS product X." Your asset register includes the Pune development team. Your access reviews include the Delhi sales team. The auditor asks: are Pune and Delhi in scope or not? You don't have a clear answer. This single ambiguity can hold up Stage 2 indefinitely. Fix early: rewrite the scope statement with a lawyer's eye. Every entity, every geography, every system explicitly listed as in/out.

SoA-Risk Assessment misalignment. Your risk assessment identifies risks. Your SoA marks Annex A controls applicable. Should be a clear mapping. Often isn't — controls marked "applicable" without any risk they're addressing, risks identified without any control treating them. Fix: cross-reference each Annex A control to at least one identified risk; cross-reference each risk to at least one applied control.

Internal audit absence. Auditor: "Please show me your most recent internal audit report." Auditee: "We're planning to do one next month." This is a Stage 1 fail. The standard requires demonstrated ISMS operation; an internal audit is the primary evidence of that operation. Fix: schedule and complete at least one internal audit before Stage 1, even if the scope is narrow.

The window between Stage 1 and Stage 2

Typical gap is 4-12 weeks. Use it to:

1. Close all Stage 1 findings (documented evidence of closure required at Stage 2 kickoff)
2. Complete or refresh any control evidence that was thin at Stage 1
3. Run a full internal mock-Stage-2 if it wasn't done before
4. Lock change-freeze on policies (don't update policies in the gap — auditor will ask which version applies)
5. Pre-position evidence in an organised folder structure for the Stage 2 sample requests

Stage 2: what it actually is

Stage 2 is operational effectiveness assessment. The auditor walks the ISMS in action: who does what, what evidence exists, do the records support the claims.

Stage 2 takes 3-10 days depending on organisation size, scope complexity, and number of sites. For a mid-sized SaaS company with one location, expect 4 days. For a multi-site, multi-entity organisation, expect 7-8.

How a Stage 2 day actually runs

A typical day:

• 08:30 — Opening meeting (Day 1 only). Auditor presents schedule, request list, ground rules. You confirm logistics, point of contact, war-room location.
• 09:00–10:30 — First interview block. Usually with the CISO or ISMS owner. Walks through policy framework, risk assessment, treatment plan, internal audit findings.
• 10:30–11:00 — Document request break. Auditor asks for evidence to support what was discussed. You have until end-of-day to produce.
• 11:00–13:00 — Control sample walkthrough. Auditor picks 8-12 controls from the SoA, asks for evidence of operation. This is where most findings come from.
• 13:00–14:00 — Lunch. The auditor reviews documents you've sent.
• 14:00–16:00 — Site walkthrough (server room, office, data centre) AND/OR additional interview blocks (head of HR for joiner-mover-leaver, head of IT for change management, head of operations for incident response).
• 16:00–17:00 — Daily debrief. Auditor summarises observations, flags anything concerning, lists open requests for tomorrow.
• 17:00 — End of day. Auditor returns to hotel; ISMS team works late on the leftover document requests.

This repeats with rotating focus. Final day ends with the closing meeting where preliminary findings are presented.

What the Stage 2 auditor does

For each in-scope control they select, the auditor's mental model is:

1. Does the control exist on paper? (You will have policies; this is rarely the problem.)
2. Is the control actually operating? (Evidence of execution within the audit period.)
3. Is the control operating effectively? (Sample test: pick a real instance, walk it end-to-end, verify each step.)
4. Is there a feedback loop? (Metrics, exceptions, escalations, lessons learned.)

For control A.5.1 (Access control policy), they will: - Read the policy (Step 1) - Ask: "When did someone last leave? Show me their access removal evidence." (Step 2) - Walk that example end-to-end — HR ticket, ITSM ticket, system removal, manager confirmation (Step 3) - Ask: "Are there metrics on time-to-removal? Any cases where it took more than 24 hours? What was the response?" (Step 4)

If you don't have Step 4, you get an Observation. If Step 3 falls apart, you get a Minor Nonconformity. If Step 2 has no evidence of operation, you get a Major Nonconformity.

Common Stage 2 findings

The findings I see most often:

Access review evidence is rubber-stamped. Manager signs off on access list without actually reviewing it. Auditor catches this by asking: "Manager X approved User Y's continued access in March. User Y left in February. How did this happen?" The right answer involves a documented process gap and a fix. The wrong answer is a defensive explanation. The latter generates findings; the former rarely does.

Asset register is stale. New servers, cloud accounts, SaaS subscriptions not in the register. The auditor identifies this by asking finance for the IT spend and comparing line items to the asset register. Anything in the spend but not in the register is a finding.

Vendor risk assessments are missing for material vendors. The auditor pulls your major contracts list, picks two or three, asks for the risk assessment. If they don't exist or are stale (>12 months old for material vendors), finding.

Change management procedure exists; emergency changes bypass it. The auditor asks: "Show me an emergency change in the audit period." Then they ask: "What approval did it have? When was retrospective documentation completed? Was it reviewed in the next CAB meeting?" Most organisations fail one of these three.

BCP/DR test was a desktop walkthrough. Auditor asks: "What was actually disabled? What was actually failed over? Were business outcomes measured?" If the answer is "we discussed it," finding. ISO 27001:2022 Annex A.5.30 specifically requires testing.

Internal audit findings are still open from prior year. Auditor checks dates. Anything more than 6 months past target close-date with no movement is a finding on the internal audit programme effectiveness.

Major vs Minor nonconformity — what determines which

A major nonconformity is one of: - Absence of a required control or process - Systematic failure of a control to operate - A nonconformity that significantly impacts the integrity of the ISMS

A minor nonconformity is: - A control operates but with deficiencies in some instances - Documentation gaps that don't materially affect operation - Single instances of non-compliance in an otherwise functioning control

The auditor's call is significant. A reasonable auditor will classify a one-off oversight as minor and a systematic failure as major. An unreasonable auditor might escalate. If you genuinely believe a finding is misclassified, contest it — formally, in the management response, with evidence. Auditors do downgrade findings on well-argued responses.

The certification body's policy matters too. Some CBs are stricter than others. This is worth knowing during CB selection.

What's specifically different for ISO 27701

ISO 27701:2019 is being superseded by ISO/IEC 27701:2025 Ed. 2. The 2025 edition was published in October 2025; existing 2019-version certificates remain valid until their expiry, and new certifications from 2026 onwards will increasingly be against Ed. 2.

Key Stage 1 differences for 27701:

• Controller-vs-processor designation must be explicit and per-processing-activity (some organisations are controller for HR data, processor for customer data — and the auditor will ask)
• Records of Processing Activities (RoPA) must be complete and current
• Cross-border transfer mechanisms must be documented per destination jurisdiction
• DPO appointment, if required, must be documented including reporting line and independence

Key Stage 2 differences:

• Data Subject Rights procedure walkthrough — the auditor will simulate a rights request and follow it end-to-end
• Breach notification timing — the auditor will ask about your last reportable breach (if any) and inspect the notification timeline against the regulatory standard
• Consent management — for consent-based processing, evidence of granular consent and withdrawal
• Vendor processor agreements — DPAs in place for every processor, with the required Article-28-equivalent clauses (or 27701's equivalent)

The 27701 + 27001 stack. ISO 27701 is an extension of ISO 27001 — you cannot certify 27701 standalone, only as an extension to an existing or concurrent 27001. In practice, most organisations seek a combined audit. The Stage 1 + Stage 2 is unified; the auditor adds 27701-specific questions to the standard 27001 process.

What's specifically different for ISO 42001

ISO 42001:2023 (AIMS — AI Management System) is the newest ISO management system standard and the first that specifically addresses AI governance. As of 2026, the population of certified organisations is still small but growing rapidly, especially in the EU as AI Act enforcement looms.

Key Stage 1 differences for 42001:

• AI system inventory must be complete and current — including third-party AI services and embedded AI features in vendor products
• AI impact assessment methodology must be documented and applied to high-impact systems
• AI policy must address purpose limitation, accountability, transparency, and human oversight
• Roles and responsibilities for AI development, deployment, and oversight must be defined

Key Stage 2 differences:

• The auditor will sample an AI system and walk it end-to-end: business case → impact assessment → development controls → deployment controls → monitoring → incident handling
• Bias and fairness controls — evidence of testing and ongoing monitoring
• Model governance — version control, evaluation records, rollback procedures
• Third-party AI services — vendor assessments specific to AI risk (training data provenance, model evaluation, ongoing monitoring)
• Incident handling for AI-specific failure modes — hallucination, drift, prompt injection, output errors

Auditor expertise gap. Be aware: the population of auditors with deep AI expertise is small. You may end up with an auditor who is excellent on ISO process but limited on AI-specific risk. This cuts both ways — you may get easier findings on AI-specifics, but you may also have to educate the auditor through your evidence. Document your AI risks and controls in language that a competent generalist auditor can follow without prior AI background.

42001 + 27001 stacking. Like 27701, ISO 42001 builds on a security management foundation. Most organisations stack it with 27001. Some do 42001 standalone where AI governance is the primary concern but information security is handled through other means. The choice depends on what story you want your certification to tell.

The surveillance audit cycle

Years 1 and 2 are surveillance audits. They are shorter than the initial assessment (50-70% of Stage 2 duration) and the scope is reduced — the CB samples a rotating subset of controls rather than testing all of them.

What you can expect:

• A sample of controls — typically 30-40% of the SoA, rotating annually to cover all by Year 3
• All open findings from the prior audit checked for closure
• Any major changes to scope, organisation, or systems reviewed
• A check on the internal audit programme and management review records since the last external audit
• Continued evidence of management commitment (budget, headcount, executive attention)

The "drift" problem. What kills more certifications between Year 0 and Year 3 than anything else is control drift — the controls were operating well at Year 0, the team that built them moves on, the new team doesn't fully understand them, the process gradually degrades. By Year 2, the access review is rubber-stamped, the asset register is stale, the policies haven't been updated for the new cloud platform. By Year 3 recertification, you're back to a Year 0-style preparation effort because the ISMS hasn't been maintained.

The fix is operational. Schedule the maintenance: quarterly access reviews with real spot-checks, annual policy refresh, semi-annual asset register reconciliation against finance records, monthly metrics review. The standard requires "continual improvement" — that's the operational mechanism for it.

What I would do if I were starting from scratch today

If a CISO walked into my office and said "we're going for ISO 27001 certification, where do I start," here is what I would tell them:

Month 1: Scope and gap analysis. Define scope precisely. Run a gap analysis against the standard. Identify all major gaps. Estimate effort to close. Get budget approval.

Month 2-3: Foundational documents. Information Security Policy, risk assessment methodology, risk register, statement of applicability, document control procedure. These are required artefacts; they take longer than people expect because the language has to be precise.

Month 4-6: Control implementation. Address the gaps identified in the gap analysis. Prioritise by risk and by ease — quick wins first to build momentum, deeper changes in parallel.

Month 7: Internal audit programme. Set up the audit programme. Run the first internal audit. Address findings.

Month 8: Management review. First formal management review with documented inputs, outputs, decisions.

Month 9: Mock Stage 2. Bring in an external consultant or use a separate internal team to run a mock Stage 2 audit. Treat it as live. Find issues. Fix them.

Month 10: Stage 1 with the real auditor. Schedule with the chosen certification body.

Month 11-12: Close Stage 1 findings, Stage 2 with the real auditor, certificate issued.

For 27701 add 2-3 months for the privacy-specific work (RoPA, DSR procedures, cross-border mechanisms). For 42001 add 3-4 months for AI-specific work (system inventory, impact assessment methodology, AI policy framework) — this is the long lead time because most organisations don't have an AI governance baseline.

Final notes on auditor selection and the human dynamics

The certification body matters more than people think. CBs vary on:

• Auditor quality — Some CBs have strong technical auditors who add value through their feedback. Others have process auditors who tick boxes. The first type produces more findings but better long-term ISMS health.
• Process discipline — Some CBs are strict on documentation and timing; others are flexible. There is a market signal in this.
• Reputation — Some CBs are recognised as "premium" and add credibility to the certificate, especially in international procurement contexts.
• Cost — Premium CBs cost 2-3x what mid-tier CBs charge. The cost difference is real and may not be justified for early-stage companies.

Talk to peers in your industry about their experience with different CBs. The certificate is only as valuable as the audit behind it; a weak audit produces a hollow certificate that won't pass procurement scrutiny in critical deals.

The auditor as a person. ISO auditors are professionals doing a job. Some are pleasant; some are difficult. Some are highly competent; some less so. You don't get to choose your specific auditor (the CB assigns them), but you can request a different one if there's a genuine concern about competence or fit. Don't burn this option — use it once if you must, and with documented reason.

The opening and closing meetings set the tone. Have the executive sponsor attend both. Express appreciation for the auditor's time and expertise (sincerely). Be specific about what your ISMS is trying to achieve, not generic. The audit goes better when both sides understand the engagement is collaborative, not antagonistic — even though the auditor's job is to find issues and yours is to demonstrate effectiveness.

This guide draws on first-hand experience running ISO 27001 / 27701 / 42001 audits across financial services, SaaS, healthcare, and AI-first companies. Specific certification body practices vary; check with your selected CB for any deviations from this general guidance. This is not legal or regulatory advice.

ControlForge provides synthesised controls mapped across ISO 27001 (2022), ISO 27701 (2025 Ed. 2), ISO 42001, and related frameworks. The Checklist Generator can produce a pre-audit checklist for any ISO standard; the Compliance Compare tool shows how your existing ISO certification carries over to other frameworks like SOC 2, NIST CSF, or SEBI CSCRF.