ISO 27001 Stage 1 assesses whether your information security management system is ready for the full certification assessment. Stage 2 examines whether that system works in practice. Both belong to the initial certification process; completing Stage 1 does not make your organization certified.
The useful distinction is the depth of evidence. Stage 1 establishes readiness, while Stage 2 examines implementation and effectiveness. Treating the first as a paperwork exercise and leaving implementation until afterward creates an avoidable scheduling risk. NQA’s ISO 27001 overview describes these two assessment purposes.
This guide addresses initial organizational certification for US and UK readers using ISO/IEC 27001:2022. ISO defines an information security management system, or ISMS, as an organization-wide approach to managing information security risks through people, processes, and technology. Confirm the applicable edition and amendments in your audit agreement against ISO’s official standard listing.
Stage 1 and Stage 2 at a glance
| Question | Stage 1 | Stage 2 |
|---|---|---|
| Main purpose? | Establish readiness for full assessment. | Assess conformity and effectiveness in practice. |
| Main emphasis? | Documentation, scope, and implementation status. | Objective evidence from sampled activities and processes. |
| Typical output? | Readiness concerns and planning for Stage 2. | Audit findings supporting the certification decision. |
| Certificate immediately afterward? | No. | Only following a positive certification decision. |
The distinction is reflected in NQA’s published certification process. Ask your own certification body how it records Stage 1 concerns and determines whether you can proceed.
Preparing for Stage 1: make the system understandable
Organize your preparation around one question: can someone outside the company understand what your ISMS covers and how you manage its risks? A practical document index can point to your scope, security policies, risk assessment, risk treatment plan, Statement of Applicability, and evidence of internal review. Confirm the actual submission list with your auditor.
The Statement of Applicability explains the necessary controls, why they are included, whether they are implemented, and the justification for excluding Annex A controls. Use it as a connection between risk decisions and implementation, rather than maintaining it as an isolated spreadsheet.
For your own readiness review, try tracing one significant risk through the system. Who owns it? What treatment was selected? Which document explains the approach? Where can someone find evidence that the treatment exists? Any broken link gives your team a concrete preparation task.
Also check whether your proposed scope describes the business accurately. For example, if a cloud service depends on a support team and an external hosting provider, ask how those relationships appear in the scope and risk assessment. A short scope statement is useful only when its boundaries are understandable.
Preparing for Stage 2: connect commitments to records
Build an evidence index that links each relevant process to its owner, supporting records, and record location. The following examples are preparation suggestions, not a universal auditor request list or a requirement to adopt these exact control frequencies.
| Process | Illustrative evidence to organize |
|---|---|
| Removing employee access | A departure record linked to account-disablement records. |
| Reviewing access rights | A completed review showing decisions and resulting changes. |
| Recovering information | A restoration exercise with results and follow-up actions. |
| Managing suppliers | A supplier assessment linked to approval and unresolved risks. |
| Security awareness | Training records and the handling of missed training. |
Prefer records with enough context to explain what happened: dates, the relevant system, the responsible person, and any resulting action. An unlabeled screenshot can create more questions than it answers. Keep original records available and agree on a secure method for sharing sensitive evidence.
A hypothetical access-review example
Suppose a SaaS company says that service owners review privileged access every quarter. For preparation, it collects the policy, the latest review, the list of accounts considered, and tickets showing the removal of unnecessary permissions.
If the review identified an unnecessary administrator account but nobody removed it or documented an approved exception, the team has found a gap between its decision and its action. Updating the policy alone would not resolve that gap. The useful next step is to complete the action, understand the delay, and check whether other reviews have the same problem.
How much time should separate the audits?
Separate three dates in your project plan: when the ISMS began operating, when Stage 1 occurs, and when Stage 2 occurs. A requirement for operating history is not automatically a requirement to wait that same period after Stage 1.
For example, NQA publishes a minimum of three months of operation, together with management review and a full internal-audit cycle, for its initial certification process. Treat that as NQA’s published requirement, not proof of a universal three-month interval between stages.
Before committing to a customer deadline, ask your certification body to confirm the required operating history, the acceptable interval between audits, and how unresolved readiness concerns affect scheduling. Also ask whether quoted audit days mean elapsed days or total auditor-days, and whether follow-up work is included.
A useful planning allowance includes time to resolve concerns, produce evidence of the changes, and complete the certification decision. Avoid treating the last scheduled audit day as a guaranteed certificate-issue date.
What happens when the auditor finds a problem?
A nonconformity is a failure to meet a requirement. NQA explains that major nonconformities require corrective action and verification before certification can be issued. Its process also specifically requires sufficient evidence that internal ISMS audits and management reviews are implemented, effective, and maintained. Check your certification body’s rules for classifications, deadlines, and follow-up evidence. See NQA’s explanation of findings and certification decisions.
For your response, keep the immediate fix separate from the action intended to prevent recurrence. In the access-review example, removing an account fixes the immediate issue. Changing how review decisions become tracked work addresses why the removal was missed. Preserve evidence of both and identify who will check the result.
Ask for clarification if you do not understand which requirement a finding concerns. A precise understanding of the finding is more useful than producing a large bundle of unrelated screenshots.
What you can tell customers after each stage
After Stage 1, describe the milestone accurately: “We have completed Stage 1 of our initial certification audit.” Add a planned Stage 2 date only if it has been agreed. Avoid presenting a readiness milestone as an issued certificate.
After certification, use the actual standard reference and certified scope. ISO develops standards but does not issue certificates; an external certification body performs that role. ISO also recommends checking the provider’s accreditation. ISO’s certification guidance explains this distinction.
Before booking Stage 2, bring together the Stage 1 report, your action tracker, and the evidence index. Ask each process owner to demonstrate one complete example, from the documented commitment through to the recorded outcome. That exercise gives you a practical basis for discussing readiness with your certification body.
Related Security and Audit Preparation Guides
Vendor Security Questionnaire Template for SaaS Risk Assessments
Active Directory Security Audit: Reviewing Privileged Access and Ownership
How to Answer Customer Security Questionnaires with Supporting Evidence
SaaS Acceptable Use Policy Template: Align Policies with Actual Workflows
SOC 2 Type 1 vs Type 2: Understanding a Different Assurance Framework