ISO 27001 stage 1 and stage 2 audit: what the certification audit really tests
Certification is two audits with a gap between them, and people prepare for the wrong one. The effort goes into documentation, which is Stage 1, and the thing that decides the outcome is whether controls demonstrably operated over a period, which is Stage 2.
The iso 27001 stage 1 and stage 2 audit sequence exists precisely to separate those questions. Stage 1 asks whether you have built a management system. Stage 2 asks whether it runs.
What the iso 27001 stage 1 and stage 2 audit each examine
Stage 1 is documentation and readiness, usually half a day to a day for a small company, often remote. The auditor reads your ISMS and forms a view on whether Stage 2 is worth scheduling.
They will want the scope statement, the risk assessment method and register, the Statement of Applicability, the risk treatment plan, the policy set, the internal audit report and the management review minutes. They will check internal consistency between those, which is why traceability between the register and the SoA matters more than the quality of any single document.
The output is a report, and typically some findings to close before Stage 2. That is normal. Stage 1 producing no findings at all is unusual enough to be surprising.
Stage 2 is operation and evidence. Longer, usually on site or over several sessions, and it samples. The auditor picks controls, asks how they work, and asks to see that they did work across the period. Not that they could work. That they did.
What evidence means in practice
This is the distinction that decides Stage 2, and it is worth being concrete because "evidence" sounds vaguer than it is.
A screenshot of a Conditional Access policy shows the control exists. It does not show it operated. What operated looks like: the policy, plus the sign-in logs demonstrating enforcement across the period, plus the record of the change that created it, plus the review that confirmed it still fits.
For access reviews, the evidence is not the access list. It is a dated record saying who reviewed it, what they decided, what was removed, and what was retained with a justification. Four lines and a date, as covered in the evidence automation note.
The pattern generalises. Evidence has a date, a person, and an outcome. Anything missing one of the three is a document rather than evidence, and the auditor will say so.
The corollary that catches people: evidence cannot be produced retrospectively. An access review you performed in February without recording it did not happen as far as Stage 2 is concerned, and the honest answer is to say so rather than to write it up now and date it February.
The period being sampled
Stage 2 samples the period since the ISMS started operating, which for a first certification is usually the preceding three to six months.
That has a scheduling consequence people miss. If your ISMS started operating in March and Stage 2 is in June, the auditor samples March to June, which includes the months when you were still implementing. So the controls need to have been running, and generating records, before you felt ready.
The practical instruction: start capturing evidence in month one of the project, not in the month before the audit. Monthly exports beginning early cost nothing and are the difference between a sample that shows a system operating and a sample that shows a system switched on last week.
The interviews
Stage 2 includes talking to people who are not you, and this is where small companies are strongest and most nervous.
The auditor asks a developer what they would do if they lost a laptop, or how they get access to production, or who they report a suspicious email to. They are testing whether the control operates rather than whether the person has read the policy. Roughly right and confident passes. "I think there is a policy somewhere" does not, and that is why policies people actually read matter more than comprehensive ones.
Where you run the ISMS alone, expect to be interviewed at length yourself, and expect questions designed to test whether the system depends entirely on you. It does, and saying so plainly is better than pretending otherwise. Key person dependency belongs in your risk register as an honest entry, and having it there turns an awkward question into evidence that you assessed your own situation accurately.
Minor and major nonconformity
Two classifications, and the difference is consequence.
A minor nonconformity is a single lapse in an otherwise functioning control. One review missed in a year of reviews. A record incomplete. You submit a corrective action plan with root cause, correction and preventive action, and certification proceeds once accepted. Minors are ordinary.
A major nonconformity is a control absent, a systemic failure, or a lapse significant enough to cast doubt on the management system. No internal audit at all. A required document missing. A control described in the SoA that has never operated. A major blocks certification until it is closed and verified, which usually means another visit.
There is also an observation or opportunity for improvement, which is not a nonconformity and does not require action, though ignoring the same observation two years running invites a finding.
The useful thing to know: a corrective action plan is judged on root cause. "We forgot" is not a root cause, and "we have now done it" is not preventive action. "The review had no owner and no calendar entry; both are now assigned to a named role with a recurring reminder" is what closes a finding first time.
Getting through it
Three things that help more than extra documentation.
An evidence index. One page mapping each applicable control to where its evidence lives. Auditors work faster with it, and faster audits go better because there is more time for the substantive questions.
Honesty about gaps. If a control started operating in April rather than January, say so and show April onward. An auditor who finds a gap you did not mention starts checking everything else.
Do not over-answer. Answer the question asked. Volunteering adjacent detail opens sampling in areas nobody was going to look at, which is a self-inflicted extension of the audit.
The ISO 27001 standard sets out the requirements the auditor is testing against, and the book covers the two audits in detail including the questions that came up.
Questions
How long is the gap between Stage 1 and Stage 2?
Typically a few weeks to a few months, depending on what Stage 1 found and how long the operating period needs to be. The certification body proposes it. If Stage 1 raised findings, the gap has to be long enough to close them and generate evidence that the correction is working.
Can I fail Stage 2?
You can be issued a major nonconformity that blocks certification until closed, which is not the same as failing permanently. The more common outcome is certification with some minors and a corrective action plan.
What if a control has only been operating for a month?
Say so. A short operating period may produce a minor rather than a major, depending on the control and the reason. Concealing it produces a worse outcome than declaring it, because a discovered omission changes how the rest of the audit is conducted.
Does the auditor need access to our systems?
Usually they ask you to demonstrate on screen rather than being granted access. Expect to share your screen and navigate to the evidence while they watch, which is why knowing where everything is matters more than having it all printed.
Who should be available on the day?
Whoever owns risks, whoever approves policies, and a sample of ordinary staff. For a company of forty that is typically a director, whoever leads engineering, and two or three others. Warn them in advance what to expect, without coaching them on answers, because coached answers are recognisable and counterproductive.