Stage 1 is often described as a documentation review — and that description is both accurate and misleading. It is accurate in that the auditor's primary activity is reviewing your ISMS documentation against ISO 27001 requirements. It is misleading in that experienced auditors do not simply check whether documents exist. They read documents critically, looking for internal coherence, plausibility, and the signals that distinguish a genuine management system from a documentation exercise assembled for the purpose of passing the audit.
Understanding what auditors are actually looking for in Stage 1 — not just what they are supposed to check, but what they scrutinize, what triggers further investigation, and what immediately signals a system built for compliance rather than for security — is the key to preparing a Stage 1 package that passes confidently rather than scraping through with a list of findings to address.
This article covers the complete Stage 1 process: the relationship between Stage 1 and Stage 2, the documentation package you need to prepare, what auditors are testing when they read each document, how to respond to the findings that come back, and how to navigate the path from Stage 1 completion to Stage 2 readiness.
Stage 1 and Stage 2: The Two-Phase Certification Audit
ISO 27001 certification is a two-stage audit process, each with a distinct purpose. Stage 1 assesses readiness — is the ISMS adequately designed and documented? Stage 2 assesses implementation — is the ISMS operational and effective? Understanding the boundary between them prevents the common mistake of treating Stage 1 as a lower-stakes rehearsal for Stage 2.
STAGE 1 Documentation Review Auditor reviews your ISMS documentation to determine whether your management system is adequately designed and ready for Stage 2. Timing: Typically 4–8 weeks before Stage 2 Duration: 1–2 auditor days (usually remote) Output: Stage 1 report with findings — organization must address before Stage 2 can proceed | STAGE 2 On-Site Assessment Auditor verifies that the ISMS is fully implemented, operational, and effective — not just documented. Evidence of operation is tested. Timing: 4–12 weeks after Stage 1 findings addressed Duration: 2–5 auditor days (on-site or remote for small scopes) Output: Certification decision — certificate issued if conformant, or nonconformities raised requiring resolution |
The gateway between Stage 1 and Stage 2 is finding resolution. Major nonconformities found in Stage 1 must be resolved before the CB will schedule Stage 2. Minor nonconformities must be addressed (or have a credible resolution plan in place) before Stage 2 proceeds. Stage 2 then verifies that the design confirmed in Stage 1 is actually working in practice — with operational evidence, not documentation.
| WHAT STAGE 1 IS NOT | Stage 1 is not a practice run for Stage 2. Findings from Stage 1 are formal audit findings that must be documented, responded to, and tracked through to closure. Organizations that treat Stage 1 findings as informal feedback and do not respond formally — or that address findings superficially rather than substantively — carry those findings into Stage 2 as unresolved issues. The Stage 2 auditor will be aware of Stage 1 findings and will test whether they were genuinely resolved. |
The Stage 1 Documentation Package
The Stage 1 documentation package is typically submitted to the CB 2–4 weeks before the Stage 1 audit date. It is the primary source the auditor uses to assess ISMS design adequacy. The package should be organized, complete, and internally coherent — not a collection of individually adequate documents that do not tell a consistent story together.
The table below maps the required and recommended documents, the specific clauses they satisfy, their ISO 27001 requirement status, why auditors scrutinize each document particularly, and the quality benchmark that distinguishes conforming from non-conforming submissions:
| Document | Clause | ISO req. | Why auditors scrutinize it | Quality benchmark |
| ISMS Scope Statement | 4.3 | Explicit | Auditors read this first — it defines the boundary for every other assessment. Must be specific about what is included and excluded. Vague or mismatched scope is the most common Stage 1 finding. | Specific named services, systems, and locations. Explicit exclusions with rationale. Consistent with the risk register assets and SoA control selection. |
| Information Security Policy | 5.2 | Explicit | Top-level governance document. Auditors verify CEO signature, risk appetite statement, regulatory references (UU PDP, POJK as applicable), and commitment to continual improvement. | CEO-signed. Dated. References specific Indonesian regulations by number. Contains risk appetite statement. Commitment to IS objectives. Review schedule stated. |
| Risk Assessment Results | 6.1.2 / 8.2 | Explicit | Auditors review the risk register to assess whether the methodology was applied consistently and whether the risk landscape is plausible. Implausibly low scores or missing major risks are Stage 1 findings. | All risks scored consistently per documented methodology. Risk owners assigned. Scores plausible for the sector and threat environment. Linked to SoA control selections. |
| Statement of Applicability (SoA) | 6.1.3 | Explicit | The SoA is often the most scrutinized Stage 1 document. Auditors check that all 93 controls are addressed, exclusions are justified, and implementation status reflects reality. | All 93 controls listed. Exclusions have specific, defensible justifications. Implementation status is current (not 'planned' for controls already deployed). Cross-references to risk register entries. |
| Risk Treatment Plan | 6.1.3 | Explicit | Auditors assess whether there is a credible plan to implement identified controls. Plans that show 100% completion status raise suspicion; plans with no progress evidence signal implementation has not started. | Specific actions, named owners, target dates. Implementation status reflects actual progress. Controls not yet complete show current status, not planned status. |
| IS Objectives Register | 6.2 | Explicit | Auditors verify that objectives are specific, measurable, and consistent with the IS policy. Generic objectives ('improve security') are a finding; specific objectives ('achieve <5% phishing click rate by Q4 2026') are conforming. | SMART objectives. Each objective has an action plan, responsible owner, and measurement approach. Consistent with IS Policy commitments. |
| Risk Assessment Methodology Document | 6.1.2 | Required | Auditors verify that a documented methodology exists and that the risk register results are consistent with it. Inconsistencies between the methodology and the register are Stage 1 findings. | Defines likelihood and impact scales with precise definitions. Specifies risk scoring formula. Describes asset categorization and threat identification approach. References threat library. |
| Information Security Policy Suite | 5.1 / Annex A 5.1 | Required | Supporting policies demonstrate that domain-level controls have been designed into the ISMS. Auditors check that each applicable Annex A domain has a corresponding policy. | All applicable control domains covered. Policies are approved (not draft). Version-controlled. Regulatory references current. Scope matches ISMS scope statement. |
| Competence Records (ISMS roles) | 7.2 | Explicit | Auditors verify that ISMS role holders have documented competence evidence. This is tested by sampling — 'we have the records but they are in HR' is not an acceptable Stage 1 response. | Records available for ISMS Manager, internal auditors, and key role holders. Current (within last 12 months for qualifications). Linked to the roles and responsibilities document. |
| Internal Audit Program and Reports | 9.2 | Explicit | Stage 1 auditors want evidence the internal audit program is established and operational — not just planned. At minimum, the program document and one completed audit report should exist. | Documented program with schedule. At least one completed audit report with findings classified by major/minor NC and observation. Corrective action register entries for any NCs found. |
| Management Review Record | 9.3 | Explicit | One of the most frequently missing Stage 1 documents. Auditors verify that top management has reviewed the ISMS at planned intervals. If no review has occurred, this is a major Stage 1 finding. | Minutes covering all 8 Clause 9.3.2 inputs. Dated. Attendees including CEO/executive sponsor listed. Documented decisions on improvement, changes, and resources. |
| Corrective Action Register | 10.2 | Explicit | Demonstrates that the improvement process is operational. An empty CAR register at Stage 1 suggests either (a) the ISMS has been operating perfectly (implausible for first-cycle) or (b) the corrective action process is not functioning. | Entries for nonconformities from internal audit and any other sources. Root cause documented. Actions specific. Closure evidence where applicable. |
| Package assembly warning: The most common Stage 1 package failure is submitting documents in draft status. Draft policies, unsigned risk registers, and unapproved SoA entries tell the auditor that the management system has not been finalized for operation. Every document in the Stage 1 package must be in 'Approved' status with a version number, approval date, and named approver. A single draft document in the package does not fail the audit — but multiple drafts signal that the ISMS is still under construction, which will generate multiple Stage 1 findings. |
What Auditors Are Actually Testing
Experienced Stage 1 auditors do not read ISMS documents in isolation. They read them against each other — testing for internal coherence, plausibility, and the signals that distinguish genuine management systems from compliance artifacts. The table below maps what auditors are actually assessing when they read your Stage 1 package:
| What auditors assess | The test being applied | Red flag signal auditors act on |
| ISMS Scope coherence | Do the scope statement, risk register assets, SoA applicability decisions, and IS Policy all tell the same story about what is inside and outside the ISMS? Inconsistencies — a system mentioned in the risk register but excluded from the SoA, or a regulatory body listed in interested parties but not reflected in the policy — signal a management system built from disconnected documents. | Scope statement mentions 'payment processing platform'. Risk register includes only website hosting assets. SoA excludes all payment security controls. Auditor concludes scope was defined narrowly for convenience, not for risk coverage. |
| Risk assessment plausibility | Are the risks plausible for a financial services/technology organization in Indonesia in 2026? A fintech with zero HIGH or CRITICAL risks, or a payment processor with no risks related to credential compromise or API abuse, will prompt deep probing of the methodology and scoring calibration. | A fintech handling 50,000 customer transactions daily has no risk scored above MEDIUM. Auditor questions whether the likelihood scale was calibrated appropriately or whether scores were managed to minimize treatment obligations. |
| SoA justification quality | Are the exclusion justifications specific and defensible, or generic? 'Not applicable' for a control without explanation, or 'out of scope' without reference to what specifically makes it inapplicable, will generate a clarification request or finding. | A.7.4 (Physical security monitoring) is excluded with justification 'Not applicable — fully remote organization'. A.8.28 (Secure coding) is excluded with justification 'Not applicable'. The first is defensible; the second requires explanation — does the organization develop no software? |
| IS Policy leadership signal | Does the policy genuinely reflect top management commitment, or was it produced by the security team and signed minimally? Auditors look for: specific risk appetite statement (not just 'we take security seriously'), regulatory commitments that match the actual regulatory environment, and a review date that has not expired. | IS Policy signed by CISO rather than CEO. Risk appetite section reads: 'We are committed to managing security risks appropriately.' No regulatory references beyond 'applicable laws and regulations'. Auditor notes Clause 5.2 leadership gap. |
| Objectives measurability | Are the IS objectives specific enough to be measured? Objectives like 'improve our security posture' or 'maintain ISO 27001 certification' are not objectives — they are outcomes. Conforming objectives have a specific target, a measurement method, and a target date. | IS Objectives Register lists: '1. Maintain certification. 2. Improve security awareness. 3. Reduce incidents.' None have measurable targets, responsible owners, or action plans. This is a Clause 6.2 finding. |
| Internal audit program genuineness | Does the internal audit program show evidence of genuine execution — specific findings, evidence-based conclusions, classified nonconformities — or does it read like a documentation exercise that found everything satisfactory? | Internal audit report covering all clauses 4–10 produces zero findings across all areas. Six supporting policies are described as 'reviewed and found compliant' with no evidence of sampling or testing. Auditor concludes audit was not conducted with genuine rigor. |
The coherence test is the most revealing: pick up the scope statement and the risk register and ask whether they describe the same organization. Pick up the IS Policy and the IS Objectives and ask whether the objectives operationalize the policy's commitments. Pick up the SoA and the risk register and trace three control applicability decisions back to specific risks. If these connections are present and consistent, the ISMS is coherent. If they are missing or inconsistent, Stage 1 findings are coming.
Common Stage 1 Findings and How to Respond
Stage 1 findings are not failures — they are the mechanism through which the certification process ensures that the ISMS is adequately designed before moving to Stage 2 implementation testing. Receiving Stage 1 findings is normal for first-cycle certifications. How you respond to them determines whether they become obstacles or accelerators.
The table below maps the six most common Stage 1 finding types — with real examples, severity classification, recommended response approach, and timeline guidance:
| Finding type | Example | Severity | Recommended response | Timeline |
| Documentation gap | Management review minutes do not exist — no evidence that any management review has been conducted. | Major if no review has occurred at all; minor if a review occurred but was not documented. | Conduct the management review immediately. Produce documented minutes covering all 8 Clause 9.3.2 inputs. Provide minutes to CB within the agreed response window. If management review was conducted but undocumented, produce a retrospective record dated to the actual review date (not backdated to a date it did not occur — this is document fraud). | Typically must be resolved before Stage 2 is scheduled. Major gaps may require CB confirmation that they are satisfied before Stage 2 proceeds. |
| Scope inconsistency | Scope statement references the 'customer mobile application' but the risk register contains no assets related to mobile, and the SoA excludes all mobile security controls. | Minor nonconformity | Reconcile scope, risk register, and SoA. Either: (a) add mobile application assets to the risk register and update SoA applicability decisions, or (b) amend the scope statement to remove the mobile application with justified rationale. Update all three documents consistently and resubmit. | Must be resolved before Stage 2. Provide revised documents with a brief response letter explaining the changes made. |
| SoA exclusion insufficiently justified | A.8.28 (Secure coding) excluded with justification 'Not applicable'. Organization develops a customer-facing payment API in-house. | Minor nonconformity | Either make A.8.28 applicable (with implementation status and supporting evidence) or provide a specific, defensible exclusion justification. 'Not applicable — no software development in scope' is defensible if true. 'Not applicable' alone is not. | Must be addressed before Stage 2. A revised SoA with corrected applicability decision and justification is sufficient. |
| IS objectives not measurable | IS Objectives Register lists 'Improve security awareness' with no target, no measurement method, no owner, and no action plan. | Minor nonconformity | Rewrite each objective to include: specific target (e.g. 'achieve <5% phishing click rate'), measurement method (quarterly phishing simulation), responsible owner (CISO), and target date (Q3 2026). Update the objectives register and resubmit. | Must be addressed before Stage 2 — auditors will verify that the revised objectives register is in place during Stage 2. |
| Risk assessment lacks plausibility | All 47 identified risks scored MEDIUM or below. No HIGH or CRITICAL risks for a payment processor handling 100,000+ transactions daily. | Observation at Stage 1; may be escalated to a finding if auditor determines the methodology was not applied credibly. | Review the risk register with the auditor's concern in mind. If the scoring is defensible, prepare a written rationale for the risk appetite and likelihood calibration. If scores were inadvertently compressed, recalibrate and update — accepting that some risks will move to HIGH/CRITICAL and require treatment plans. | Auditor may accept a written response at Stage 1. Stage 2 will test the risk register more deeply — a risk register that is corrected only superficially to pass Stage 1 will fail Stage 2. |
| Observation / improvement opportunity | The IS Policy review schedule states 'annual' but the document does not identify who initiates the review or by what process. | Observation | Acknowledge the observation. Update the policy to include the specific review process (e.g. 'the document owner initiates review no less than 30 days before the review date, presenting a redraft for CEO approval within 15 business days'). Not mandatory to address, but addressing it demonstrates responsiveness and improves the policy. | No mandatory deadline — but good practice to address before Stage 2. |
| Response letter discipline: When responding to Stage 1 findings, the response letter format matters. A well-structured response for each finding includes: (1) Acknowledgment of the finding and the specific clause it relates to. (2) Root cause analysis — why did this gap exist? (3) Corrective action taken — what was changed. (4) Evidence attached — revised documents, new records, updated registers. (5) Confirmation that the action addresses the finding's root cause, not just its surface symptom. CBs that receive vague responses ('we have updated our documentation') typically request more information — adding weeks to the Stage 1 resolution process. |
Stage 1 Readiness Self-Assessment
Before submitting the Stage 1 documentation package, conduct a self-assessment against the checklist below. Every unchecked item represents either a gap that will generate a Stage 1 finding or a document quality issue that will create auditor uncertainty. Address all gaps before submission — not after the Stage 1 report arrives:
| Documentation completeness |
☐ ISMS Scope Statement — finalized, approved, specific inclusions and exclusions stated ☐ Information Security Policy — CEO signature, dated, regulatory references by article number, risk appetite stated ☐ Risk Assessment Results — all risks scored, methodology applied consistently, risk owners assigned ☐ Statement of Applicability — all 93 controls addressed, exclusions justified specifically, implementation status current ☐ Risk Treatment Plan — specific actions, named owners, target dates, progress tracked ☐ IS Objectives Register — SMART objectives with measurement method, owner, and target date ☐ Risk Assessment Methodology — documented, approved, consistent with risk register results ☐ Supporting policy suite — Access Control, Incident Management, Data Classification, Supplier Security, Cryptography, BCP/DR — all approved |
| Governance evidence |
☐ Management review minutes — at least one completed review with all 8 Clause 9.3.2 inputs, CEO attendance, documented decisions ☐ Internal audit program — documented program and at least one completed audit report with classified findings ☐ Corrective action register — entries exist with root cause analysis and action status ☐ Competence records — ISMS role holders have current evidence on file and accessible |
| Document quality |
☐ All documents are version-controlled with approval date, version number, review date ☐ Document register is current — all submitted documents appear in register at matching version ☐ No documents still in 'DRAFT' status are included in the Stage 1 package ☐ Cross-references between documents are consistent — scope statement matches SoA matches risk register |
| Coherence check |
☐ Risk register assets are consistent with the ISMS scope statement ☐ SoA control applicability decisions can be traced to risk register entries or external obligations ☐ IS Policy regulatory references match the actual regulatory environment (UU PDP, POJK, PBI as applicable) ☐ IS Objectives are consistent with IS Policy commitments and risk treatment priorities ☐ Risk scores are plausible — HIGH/CRITICAL risks exist for a regulated financial services or technology organization |
| The coherence dry run: One of the most valuable pre-Stage 1 activities is a coherence dry run — having a team member who was not involved in writing the ISMS documentation read it as an auditor would, asking the coherence questions listed in this article. What assets are in scope? Are they in the risk register? Are their associated controls in the SoA? Are the SoA exclusions defensible? A team member with fresh eyes will find inconsistencies that the authors have normalized through familiarity. |
The Stage 1 to Stage 2 Pathway
The path from Stage 1 completion to Stage 2 readiness is a structured sequence of finding resolution and preparation steps. Organizations that manage this transition deliberately — with a clear response plan, evidence of changes, and formal CB confirmation before scheduling Stage 2 — avoid the wasted time and rescheduling costs that come from proceeding to Stage 2 before Stage 1 issues are genuinely closed:
| # | Step | What it involves |
| 1 | Receive Stage 1 Report | The CB issues a formal Stage 1 report within 5–10 business days of the audit. The report classifies findings as major nonconformities, minor nonconformities, or observations. Read it carefully — each finding must be addressed before Stage 2 can proceed. |
| 2 | Categorize and Prioritize Findings | Major NCs are the highest priority — Stage 2 cannot be scheduled until the CB is satisfied these are resolved. Minor NCs must also be resolved (or have a clear resolution plan) before Stage 2. Observations are discretionary but should be considered. |
| 3 | Develop Response Plan | For each finding, identify: what needs to change, who will change it, and by when. The response plan should close all major and minor NCs within the CB's allowed response window (typically 30–90 days depending on the CB and severity). |
| 4 | Implement and Document Changes | Make the required changes to documents, processes, or governance structures. Produce evidence of the change — revised documents, management review minutes, updated SoA entries. Do not simply describe what you have done; provide the actual corrected artifacts. |
| 5 | Submit Formal Response | Submit a formal written response to the CB for each finding, describing: what the finding was, what root cause was identified, what corrective action was taken, and attaching evidence of the change. The CB reviews responses and confirms whether findings are closed. |
| 6 | Confirm Stage 2 Date | Once the CB confirms Stage 1 findings are resolved (or has an acceptable resolution plan for lower-severity items), confirm the Stage 2 audit date. Typically 4–12 weeks after Stage 1 finding closure, depending on CB availability and implementation readiness. |
| 7 | Prepare for Stage 2 | Use the time between Stage 1 resolution and Stage 2 to complete any control implementation still in progress, organize evidence into an accessible library, brief management and staff on the audit process, and conduct a final pre-Stage 2 evidence dry run. |
The typical elapsed time from Stage 1 report to Stage 2 readiness is 6–16 weeks — depending on the number and severity of Stage 1 findings and the organization's capacity to address them. Major documentation gaps (missing management review, absent risk assessment) take longer to address than quality issues (improving SoA justifications). Planning the Stage 2 date with a 12-week post-Stage 1 buffer is a conservative and generally sound approach for first-cycle implementations.
Preparing the Evidence for Stage 2
Stage 1 is about documentation adequacy. Stage 2 is about operational reality. The period between Stage 1 resolution and Stage 2 is the last opportunity to complete control implementation, organize evidence into an accessible library, and brief the management and staff who will be interviewed during Stage 2. Three specific preparation activities matter most:
Evidence library organization
The Stage 2 auditor will ask for evidence of control operation — not just documentation of control design. Organize all evidence by Annex A control and by clause, in a format that allows you to navigate to specific evidence within seconds during the audit. An auditor who waits 20 minutes for evidence to be found will conclude that evidence collection is not systematic — which is itself a finding signal.
Management briefing
The Stage 2 auditor will interview management — including the CEO or executive sponsor. Brief top management on what to expect: what questions they will be asked, what the ISMS objectives are, what the top risks are, and what significant changes have occurred since implementation began. Management who cannot articulate the organization's top risks or IS objectives without consulting notes signal to auditors that leadership engagement with the ISMS is nominal rather than genuine.
Staff interview preparation
Stage 2 auditors also interview non-ISMS staff to test awareness levels. Brief relevant staff (not just ISMS team members) on the IS Policy obligations, how to report incidents, and their role in security. Do not script their answers — auditors can identify rehearsed responses immediately. Ensure staff can answer naturally from genuine understanding, not from a briefed script.
| On the importance of not coaching staff to give specific answers: Auditors are experienced in distinguishing natural responses from coached ones. 'We received security awareness training and know to report suspicious emails to the IT helpdesk' sounds rehearsed. 'I try to be careful with emails — there was a phishing simulation a few months ago and I'm more suspicious now' sounds genuine. The latter produces more confidence in the organization's security culture than any number of trained responses. Brief for understanding, not for scripted answers. |
What Passes and What Fails: The Stage 1 Outcome
A Stage 1 that produces no major nonconformities and a small number of minor nonconformities is a typical and successful outcome for a well-prepared first-cycle ISMS. It is not a sign of failure — it is evidence that the auditor engaged rigorously with your documentation and found areas to improve, which is the purpose of the audit.
A Stage 1 that produces multiple major nonconformities — particularly missing management review, absent risk assessment, or a non-existent SoA — signals that the ISMS was not ready for Stage 1. In this case, the right decision is not to rush responses and proceed to Stage 2 as quickly as possible, but to take the time needed to genuinely address the gaps, even if it means delaying Stage 2 by several months.
The certificate at the end of this process is a three-year commitment from the certification body that your ISMS meets ISO 27001 requirements. It is only worth having if it reflects a genuine management system. Stage 1 is the process that ensures it does.