ISO/IEC 27001 certification audits come in two stages: stage 1 (documentation review) and stage 2 (on-site audit). For an organisation going through it the first time, stage 1 is the one surrounded by the least information and the most anxiety. It is common to arrive on the day thinking: we wrote all the procedures — but what are they actually going to look at?
The short answer: stage 1 is not a check that your documents exist. It is not a matter of ticking files off a list. What the auditor examines is whether your risk assessment, your Statement of Applicability (SoA), and your individual procedures connect logically.
This article covers the purpose of stage 1, how the day runs, the findings that recur, and what to do between stage 1 and stage 2. For the next step, see What Stage 2 (On-Site Audit) Actually Examines.
Disclaimer: This article is general information. Audit procedure, duration, and the handling of findings vary by certification body; their published materials and your audit plan are authoritative.
What Stage 1 Is For
In one sentence, stage 1 confirms whether you are in a state to proceed to stage 2. It checks roughly three things.
- Whether the ISMS holds together as a design — scope is clear, and the line from risk evaluation to treatment decisions is coherent
- Whether the required documented information is in place — the documents the standard requires exist and are written to your organisation's reality
- Whether stage 2 can be conducted — status of internal audit and management review, site situation, and the arrangements the audit needs
The key point is that stage 1 is not a pass/fail examination. It is closer to the truth to see it as the step that determines what must be in place for stage 2. Findings are expected, and receiving them does not put certification out of reach.
For a small organisation, one to two days is the usual guide, varying with scope breadth and number of sites. It may be conducted on site or remotely, depending on the body and the circumstances.
It Is About Connection, Not Completeness
This is the heart of stage 1. The number of procedures you wrote, and how polished the templates look, are not what is evaluated. Logical connection is.
Specifically, the auditor tests whether this chain holds:
Context of the organisation and interested-party requirements
↓
Scope definition
↓
Understanding of information assets
↓
Risk assessment (identification, analysis, evaluation)
↓
Risk treatment decisions
↓
Statement of Applicability — controls included and excluded, with reasons
↓
Procedures — how the included controls are actually operated
↓
Records — evidence of operating as stated
An auditor enters this chain at some point and traces in both directions. They might pick one control marked "included" in the SoA and ask whether a corresponding procedure exists, and which risk in the assessment it is tied to. Or they might take an item rated high risk and ask how the SoA and the procedures address it.
Mismatches of these kinds become findings.
| Type of mismatch | Example |
|---|---|
| SoA versus procedures | A control marked "included" has no corresponding procedure |
| Risk assessment versus SoA | A high-rated risk has its related control excluded with no explanation |
| Exclusion reasons that do not explain | "Not applicable" with nothing showing why it is not applicable |
| Procedures versus reality | Generic template wording naming departments or systems that do not exist here |
| Scope versus documents | An activity included in scope appears nowhere in any procedure |
The last two are typical of using templates as-is. Procedures only work once translated into your own vocabulary — see Adapting Template Procedures to Your Organisation.
For the SoA itself, see Writing the Statement of Applicability; for the assessment, How to Run a Risk Assessment.
How the Day Runs
Timings vary by body and scope, but the shape is fairly consistent.
| Segment | Content | Who attends |
|---|---|---|
| Opening meeting | Confirming the audit plan, introductions, how the day will run | ISMS manager and officers; sometimes an executive |
| Scope and organisation | Business activities, organisation structure, appropriateness of scope | ISMS manager |
| Document review | Policy, risk assessment table, SoA, procedures in turn | ISMS manager and officers |
| Readiness check | Status of internal audit and management review, preparation for stage 2 | ISMS manager |
| Sites and environment | Site locations, working environment, remote working (at outline level) | ISMS officers |
| Auditor's writing time | The auditor consolidates findings | — |
| Closing meeting | Explanation of findings, what must be addressed before stage 2, scheduling | ISMS manager, officers, executives |
Documents are often requested in advance. Some bodies have you submit the main documents beforehand so the auditor arrives having read them, in which case the day is weighted toward discussion rather than reading.
What matters in that discussion is being able to explain why. Why this scope? Why exclude this control? Why these evaluation criteria? More than whether it is written down, the question is whether the organisation can narrate the reasoning behind its decisions. Conversely, documents produced externally that nobody internally can explain will show up here.
Findings That Recur
Stage 1 findings fall into recognisable patterns — all of them avoidable in advance.
1. Vague scope statement. Scope must convey clearly which organisational units, activities, sites, and systems are covered. "Activities relating to our information security" does not let a reader tell what is in and what is out.
2. Evaluation criteria that cannot be explained. The impact and likelihood scales and the risk acceptance level have no single correct setting — but the organisation needs a reason for the setting it chose.
3. Thin exclusion reasons in the SoA. There is no obligation to implement all 93 controls, and exclusion is a legitimate choice, provided the reason actually explains. "Not applicable" alone does not.
4. Internal audit and management review not yet done. Certification requires records of one completed cycle of both. If they are outstanding at stage 1, they must be completed before stage 2 — the single biggest cause of schedules slipping. See Running an Internal Audit and Conducting a Management Review.
5. Document control not functioning. Versions, approvals, and revision history unmanaged; no clear current version. Unglamorous, but the first thing visible in an audit.
6. Incomplete training records. You need records of awareness training — who, what, when. Delivered but unrecorded counts as a finding. See Designing Security Awareness Training.
After the Findings — Getting to Stage 2
Stage 1 findings divide into those raised as nonconformities and those offered as observations or opportunities for improvement. Terminology and categories differ by body, so at the closing meeting always confirm which category applies, what must be submitted, and by when.
| Step | What you do | Rough duration |
|---|---|---|
| ① Organise the findings | Tabulate them with owner, action, and deadline | Audit day to the next |
| ② Identify causes | Separate document defects, operational design gaps, and undecided judgements | A few days |
| ③ Correct | Revise documents, add operations, complete outstanding items such as internal audit | A few weeks |
| ④ Submit corrections | In the body's format, by its deadline | By the stated deadline |
| ⑤ Stage 2 | Conducted including verification of the corrections | Weeks to about a month after stage 1 |
The interval between stages is set to allow for correction. If internal audit is outstanding at stage 1, allow time to run it. Too short and corrections do not land; too long and stage 1's verification goes stale. The dates are normally agreed with the body.
Step ② is the one people skip. Fix the wording alone and the same issue returns at stage 2. A finding usually points at an unsettled decision rather than a badly worded document — treating it that way raises the quality of the response. See Writing a Corrective Action Report.
A Readiness Checklist for Stage 1
Documents
- Scope is stated at the level of organisation, activities, sites, and systems
- The information security policy is approved and communicated
- The information asset register is current
- A risk assessment table exists, and you can explain why the criteria were set as they were
- The SoA exists, and inclusion and exclusion reasons each stand on their own
- Every control marked "included" has a corresponding procedure
- No department or system names that do not exist here remain in the procedures
- Versions, approvals, and revision history are controlled
Records
- Awareness training delivered and recorded
- Internal audit completed (or a firm plan to complete it before stage 2)
- Management review completed (same)
Arrangements
- ISMS manager and officers appointed, with roles documented
- Attendees and their parts on the day are decided
- You have confirmed whether documents must be submitted in advance, and by when
Every item here is also a precondition for stage 2. Stage 1 is not a rehearsal for stage 2; it is the step that fixes stage 2's foundations.
Conclusion
- Stage 1 confirms whether you can proceed to stage 2 — it is not a pass/fail examination
- What is examined is not the presence of documents but the logical chain from risk assessment to SoA to procedures to records
- One to two days is the usual guide; some bodies take documents in advance
- On the day, the question is whether the organisation can explain the reasoning behind what it built
- Recurring findings: vague scope, unexplained evaluation criteria, thin SoA exclusion reasons, and internal audit or management review not yet done
- When findings come, start from cause, not wording — and set the gap to stage 2 with correction time in mind
Pottech leads documentation, dealings with the certification body, and the response to stage 1 as part of its ISMS certification support, with attendance on audit days available as an option — leaving your team to concentrate on deciding and explaining.
See ISMS Certification Support for scope and pricing, or contact us. For the wider picture see What Is an ISMS (ISO/IEC 27001)?, and for what hospital customers are held to, The Three-Ministry Guidelines.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
Note: audit procedure, duration, and the categorisation and handling of findings vary by body and are subject to revision. Confirm against the body's publications and your audit plan.