Who should read this: whoever will be in the room with the certification auditor, and would like to know in advance which questions have a right answer and which have only an honest one.
The certification audit is two visits with different jobs. Getting that difference wrong is the single most common reason a first certification slips, because the preparation that gets you through the first visit is not the preparation that gets you through the second.
Stage 1 asks whether the system is designed
Stage 1 is a documentation review. The auditor is establishing whether an ISMS exists on paper, whether it covers what the standard requires, and whether Stage 2 is worth scheduling. It can be done remotely, on site, or split.
What they ask for:
- The scope statement and the boundary, and whether it is defensible
- The Statement of Applicability, with a justification for every control included and every control excluded
- The risk assessment method and the risk assessment itself
- The policy set
- Evidence that the internal audit programme and management review exist as processes, not that they have run yet
- The roles, the responsibilities, and who in management owns this
What they are really checking is whether the documents describe one coherent system. A scope that says one thing, a risk assessment that covers something wider, and a Statement of Applicability that excludes controls the scope obviously needs is the classic Stage 1 failure. If the boundary is not settled, the auditor cannot establish what they are supposed to test in Stage 2, and everything stops there. That is why scope and the Statement of Applicability is worth more attention than the policy set most teams spend their time on.
Stage 1 findings are usually described as areas of concern rather than formal nonconformities, and they come with an expectation that you close them before Stage 2. Consultants are good at producing documents, so Stage 1 tends to go well. That is exactly why it is a poor predictor of Stage 2.
Stage 2 asks whether the system ran
Stage 2 is the real audit. The auditor is no longer reading what you wrote, they are testing whether it happened. They interview people, they sample records, and they follow threads.
The shape of it:
- Sampling. They pick controls and ask for evidence across a period. Not one access review, a sequence of them with dates. Not the backup policy, the last restore test and its result.
- Interviews. They ask the people named in your policies what they actually do. A policy written by somebody outside the business fails here, because the person named in it describes something different.
- Tracing. They take one thread and follow it end to end. A risk in the register, to its treatment, to the control that implements it, to the evidence that the control ran, to the review that confirmed it works.
- Clause 9 and 10. Internal audit results, management review minutes, nonconformities raised and corrective actions closed with root cause and effectiveness checks. This is where the sequencing set out in internal audit and management review either pays off or does not.
There is a general expectation that the management system has been operating for a period, typically around three months, before Stage 2, because sampling requires a history to sample. That is calendar time and it cannot be bought, which is the constraint at the centre of how long ISO 27001 really takes.
Major, minor, and the ones that are not findings
Three outcomes, and they cost very different amounts.
A major nonconformity is a systemic failure: a required element of the management system is absent, or a control has broken down in a way that undermines the system. A missing internal audit programme is major. A risk treatment plan with no owner anywhere is major. Majors block certification. You remediate, you provide evidence, and depending on severity the auditor may need to revisit. Budget weeks, not days, and possibly another visit.
A minor nonconformity is a single lapse in an otherwise working system. One access review missed in a year of them. One supplier assessment not filed. Minors do not usually block certification. You submit a corrective action plan, typically within a few weeks, and closure is verified at the next surveillance visit or on paper before the certificate issues.
Observations and opportunities for improvement are not nonconformities. They do not need corrective action. Teams routinely over-react to these, spend effort closing them, and arrive at the next audit having treated advice as instruction.
The practical point: the number of findings matters far less than their type. A Stage 2 with six minors and no majors is a good audit. One major and nothing else is a bad one.
What auditors accept, and what they do not
Three patterns come up repeatedly.
They accept a control you have decided not to implement, if the decision is documented and justified. The Statement of Applicability exists for this. What they do not accept is a control marked applicable, described in a policy, and not running.
They accept imperfect evidence generated at the time, over perfect evidence generated afterwards. A patch record with gaps that you can explain is better than a tidy retrospective spreadsheet. Auditors have seen a great many tidy retrospective spreadsheets, and file metadata is not subtle.
They accept “we know, it is in the register, here is the treatment and the date”. An open risk with an owner and a plan is a working management system. The same risk undocumented is a finding.
The instinct to hide problems is the wrong way round. Nonconformities that your own internal audit found and closed are evidence the system works. That is the thing being certified.
What actually goes wrong
In order of how often it turns up:
- Evidence does not exist for the sampling window. Controls were designed, nothing recorded them running.
- The scope was drawn badly and part of the work has to be redone.
- Policies describe a company that does not exist. Interviews expose it in minutes.
- Clause 9 is thin. Internal audit run too late, management review missing its mandatory inputs.
- Corrective actions closed without root cause or without checking the fix worked.
Every one of these is a preparation failure rather than a security failure, which is worth noticing. None of them means the company is insecure. They mean the record does not support the claim.
What happens after Stage 2
The auditor recommends certification, they do not grant it. The certification body’s own review and decision process follows, and the certificate is issued after that. Plan for that gap rather than promising a customer a certificate for the week after the audit.
The certificate then runs on a three-year cycle: surveillance in years two and three, recertification at the end. The costs of that full cycle are set out in what ISO 27001 actually costs an SME.
If you want to know what a Stage 2 would find before you book one, that is what a structured audit ahead of the programme produces: the same ranked gap list, without the certificate on the line.
The technical reality: what passing Stage 2 does not tell you
Stage 2 tests conformity, not security. That distinction is not pedantic, it is the whole gap.
The auditor samples whether a control operated as described. They do not test whether it works. A.8.8 asks you to manage technical vulnerabilities, and a monthly scan with a report satisfies it even if the critical findings in that report are eight months old. A.8.15 asks for logging, and logs written to a disk nobody queries satisfy it. A.8.16 asks for monitoring activities, and this is the widest gap of all, because a documented procedure meets the control while nothing is actually watching.
So a clean Stage 2 tells a customer that your management system runs. It does not tell them, and it was never designed to tell them, whether you would notice an intrusion. Those are different questions, and the second one is answered by tooling that produces findings continuously and lands them in the same evidence record, not by a better-prepared audit. The full version of that argument is in the Annex A controls grouped for real work, which separates the controls that record work from the controls that are work.
