ISO 27001 certification runs as two separate audits with different purposes, different evidence requirements and different failure modes. Stage 1 checks whether your information security management system (ISMS) is designed correctly on paper. Stage 2 checks whether it actually operates the way the paperwork says it does. Teams that treat these as one continuous review, or that assume Stage 1 approval means Stage 2 is a formality, routinely lose weeks to remediation cycles they did not budget for. This is what the auditor looks at in each stage, what typically goes wrong, and where vulnerability management specifically gets tested.
What the Certification Body Reviews at Stage 1
Stage 1 is a documentation and readiness review, usually conducted on site or remotely over one day for a mid-sized organization. The auditor is not yet sampling operational evidence in depth. They are confirming that the ISMS, as designed, could plausibly pass Stage 2, and that it is worth scheduling the resource-intensive second visit.
Three things get the closest scrutiny:
- ISMS scope statement. The auditor checks that the scope boundary is unambiguous: which business units, physical sites, systems and third-party dependencies are included or explicitly excluded, and whether the justification for any exclusion holds up under ISO/IEC 27001:2022 clause 4.3. A scope that says “all IT systems” without naming environments, cloud accounts or data flows is a common finding.
- Core documentation set. This includes the information security policy, risk assessment methodology, risk treatment plan, internal audit programme, management review records and the risk register itself. The auditor is checking internal consistency, not depth: does the risk methodology described in the document match the risk register’s actual columns and scoring scale?
- Statement of Applicability (SoA). Every one of the 93 controls across the four Annex A themes (organizational, people, physical, technological) must be marked applicable or not applicable, with a stated justification and, for applicable controls, a reference to the implementation. Auditors flag SoAs where justifications are copy-pasted boilerplate (“not applicable because we do not use this technology”) without evidence that the exclusion was actually assessed.
Stage 1 also confirms basic mechanics: that a management review has actually taken place, that at least one internal audit cycle has been completed against the ISMS, and that corrective actions from that internal audit have an owner and a due date. Certification bodies will not schedule Stage 2 until these exist, because Stage 2 needs a functioning management system to sample.
Typical Stage 1 Findings and the Gap Window Before Stage 2
Stage 1 findings are almost never “major nonconformities” in the formal sense, because Stage 1 is not yet testing operating effectiveness. Instead you get observations and minor gaps that need closing before the auditor will proceed. The most frequent ones, in rough order of frequency:
- SoA justifications that do not reference a specific policy, procedure or technical control by name.
- Risk treatment plans with no target date or owner on individual treatment actions.
- Asset inventory that does not match the stated ISMS scope, most often because cloud resources, SaaS tools or shadow IT were not captured.
- Internal audit reports with no evidence of follow-up on prior findings.
- Missing or outdated records of legal, regulatory and contractual requirements applicable to the scope.
The gap between Stage 1 and Stage 2 is typically two to twelve weeks, set by mutual agreement with the certification body rather than by the standard itself. Use this window deliberately: it exists so control owners can close Stage 1 observations, run at least one more operational cycle (a scan, a patch cycle, an access review) so Stage 2 has fresh evidence to sample, and rehearse the interview process described later in this article. Certification bodies will push Stage 2 out further, sometimes by months, if the Stage 1 report lists more than a handful of open items, so closing them fast protects your original target date more than anything else in the process.
Stage 2 Mechanics: Sampling, Interviews, Walkthroughs and Record Inspection
Stage 2 is where the ISMS gets tested against real operations, and it is scaled to the size and risk profile of the organization rather than fixed at a set number of days. A single-site company with under 100 employees might see two auditor-days; a multi-site organization with regulated data typically sees four to six. The auditor’s toolkit has four components:
| Method | What it checks | Typical output |
|---|---|---|
| Interviews | Whether control owners can explain their own process without reading from a script | Observations on awareness gaps |
| Walkthroughs | Whether the documented process matches what actually happens on screen | Evidence of process deviation |
| Record inspection | Whether logs, tickets and approvals exist for a sampled period | Minor or major nonconformities |
| Technical sampling | Whether a subset of systems in scope actually reflects configured controls | Direct evidence for specific Annex A controls |
Sampling is statistical, not exhaustive. If you run patch management across 400 endpoints, the auditor will not review 400 tickets. They will pull a sample, commonly 5 to 15 records depending on population size and the auditor’s own sampling plan, and trace each one from trigger to closure. A single broken record in that sample does not automatically fail the audit, but a pattern (three of ten samples missing an approval step, for instance) becomes a nonconformity because it suggests the control is not consistently applied, which is exactly what clause 9.1 (monitoring, measurement, analysis and evaluation) and clause 10.2 (nonconformity and corrective action) exist to catch.
Nonconformities come in two grades. A minor nonconformity means the control exists and generally works but has an isolated lapse; you get a corrective action plan and remain on track for certification, usually with evidence submitted within 90 days. A major nonconformity means the control is absent, has systematically failed, or the failure creates a direct risk to the ISMS objective; this typically requires a follow-up on-site visit before certification can be granted, adding weeks to months and a second audit fee.
How Vulnerability Management Surfaces Differently in Each Stage
Annex A control 8.8, management of technical vulnerabilities, is one of the clearest examples of how the same control gets tested completely differently across the two stages, and it is worth walking through because it illustrates the general pattern for every technical control.
At Stage 1, the auditor is reading, not testing. They want to see a documented vulnerability management procedure that states scanning scope, scanning frequency, a severity classification scheme (commonly mapped to CVSS bands), and remediation SLAs by severity, for example 15 days for critical, 30 for high, 90 for medium. They cross-check that this procedure is referenced correctly in the SoA against control 8.8, and that the asset inventory referenced by the procedure matches the ISMS scope defined earlier. A procedure that references “all production servers” while the asset inventory only tracks on-premise hosts, with cloud workloads absent, is a Stage 1 gap that will resurface as a Stage 2 nonconformity if left unfixed.
At Stage 2, the auditor pulls evidence. Expect a request for the last two to four scan cycles, a sample of open and closed findings pulled from the vulnerability lifecycle tracking system, and a trace of individual tickets from discovery date through triage, assignment, remediation and closure. The specific question the auditor is testing is whether closure is verified or merely claimed. A ticket marked “resolved” because a patch was deployed is weaker evidence than one that shows the finding was scanned again and confirmed absent. Platforms that automate this phase, such as SITEY, re-test the specific finding after a patch or configuration change instead of closing the ticket on a deployment confirmation alone, which produces exactly the kind of closure evidence an ISO 27001 auditor is trained to ask for.
Two other things get checked at Stage 2 that rarely come up at Stage 1: risk acceptance records for vulnerabilities that were not remediated within SLA (these need a named approver and a documented rationale, not just a status field left open), and whether the scanning coverage claimed in the procedure actually matches technical reality, which the auditor may verify by asking to see a current asset count against the last scan’s target count.
Timeline, Cost Drivers and the Most Common Causes of Delay
For a first-time certification, a realistic timeline from kickoff to certificate issuance is four to nine months: one to three months building or maturing the ISMS, one to two months of internal audit and management review before Stage 1, the Stage 1 to Stage 2 gap of two to twelve weeks discussed above, and two to six weeks after Stage 2 for the certification body’s technical review and decision.
Cost is driven primarily by scope size and audit duration rather than by the certification body chosen. The main variables are:
- Number of employees and locations in scope, which sets the base auditor-day estimate under IAF MD 5.
- Number of significant risks and applicable controls, since a larger applicable control set in the SoA means more sampling.
- Whether a major nonconformity forces a follow-up visit, which is typically billed as an additional audit day plus travel.
- Ongoing surveillance audits in years one and two, and recertification in year three, which are smaller in scope but recurring costs to budget for beyond the initial certificate.
The most common cause of schedule slip is not a failed audit but a Stage 2 that gets rescheduled because Stage 1 findings were not actually closed, only acknowledged. A close second is control owners who can produce the required document but cannot explain the process behind it when interviewed, which converts what should have been a clean record check into a deeper walkthrough that eats the auditor’s available time and pushes other samples to a follow-up call.
Preparing Control Owners for Auditor Interviews
Interviews fail for predictable reasons, and all of them are avoidable with a week of preparation rather than a rewrite of the ISMS.
- Rehearse the process, not the policy document. An auditor asking “walk me through what happens when a critical vulnerability is found” wants to see the control owner open the actual ticketing system and narrate a real example, not recite the SLA table from the procedure.
- Know your own numbers. Control owners should be able to state, without looking it up, roughly how many open findings exist above SLA, how many risk acceptances are currently active, and when the last scan or review cycle ran. Auditors treat a confident “I don’t know, let me check” far better than a guessed number that turns out to be wrong.
- Align on terminology in advance. If your patch management process and your vulnerability management procedure use different severity labels for the same finding, sort that out before the audit, not during it. Terminology mismatches read as process gaps even when the underlying control is sound.
- Bring the evidence trail, not just the conclusion. For any control likely to be sampled, have the ticket, the approval, the scan result and the closure evidence ready to pull up together rather than scattered across three systems. Auditors sample faster, and more favorably, when the chain is easy to follow. This is one area where the tooling matters directly: a system like SITEY that keeps discovery, triage, remediation and retest in one linked record removes the reconstruction work that otherwise falls on the control owner the night before the interview.
- Do a dry run with whoever owns internal audit. A 30-minute mock interview per control owner, focused on the questions above, catches most of the gaps that would otherwise surface for the first time in front of the certification body.
None of this replaces having the control actually work. But a functioning control presented badly can still generate a nonconformity, and a marginal control presented with clear, traceable evidence sometimes survives as an observation instead. Preparation changes which side of that line you land on.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.