ISO 27001 Stage 1 vs Stage 2: Audit Evidence & Checklist

One of the most common misunderstandings I see around ISO 27001 certification is the idea that Stage 1 and Stage 2 are basically the same audit, just split into two appointments.

They are not.

The two stages have different purposes, different levels of depth, and, most importantly, different expectations regarding evidence. If you prepare for Stage 1 as though it were Stage 2, you may waste time producing operational records nobody is ready to examine yet. If you prepare for Stage 2 as though it were Stage 1, the result can be much more painful: beautifully written documents with very little proof that your information security management system actually works.

In this article, I want to explain what an ISO 27001 auditor is typically looking for at each stage, what counts as useful ISO 27001 audit evidence, and how to avoid the classic “we have a policy for that” trap.

The simplest way to understand Stage 1 and Stage 2

I usually explain the difference like this:

Stage 1 asks: “Is your ISMS designed and ready to be audited?”

Stage 2 asks: “Is your ISMS actually working in practice?”

That distinction sounds simple, but it changes the entire evidence strategy.

During an ISO 27001 Stage 1 audit, the certification body is mainly assessing whether your Information Security Management System has been established sufficiently to proceed to the main certification audit. The auditor wants to understand the scope, your risk assessment approach, the structure of your controls, and whether the core management system requirements are in place.

During an ISO 27001 Stage 2 audit, the auditor goes much deeper. They test implementation, effectiveness, consistency, and operational evidence across the organization.

Think of Stage 1 as checking the architectural drawings before construction inspection. Stage 2 is when someone walks through the building, opens the fire doors, tests the alarms, and asks employees whether they know what to do when something goes wrong.

What evidence is expected during an ISO 27001 Stage 1 audit?

Stage 1 is largely about readiness and system design.

The auditor is not simply checking whether you have downloaded a collection of ISO templates and changed the company name. They want to see that the ISMS reflects your actual business, risks, technologies, locations, suppliers, and security priorities.

Typical evidence reviewed during Stage 1 may include:

the defined ISMS scope;
information security policy and relevant supporting policies;
identification of interested parties and applicable requirements;
your information security risk assessment methodology;
completed risk assessment results;
risk treatment plan;
Statement of Applicability;
information security objectives;
evidence of roles, responsibilities, and governance;
internal audit arrangements and, depending on timing, completed internal audit evidence;
management review records;
documented processes required by your ISMS;
evidence that applicable legal, regulatory, contractual, and customer requirements have been considered.

The important word here is coherence.

The auditor wants the pieces to make sense together.

For example, if your scope says that a SaaS platform hosted in AWS is covered by the ISMS, the risk assessment should reflect cloud-related risks. Those risks should influence the controls selected in the Statement of Applicability. Your policies and operating processes should then support those controls.

If the documents tell five different stories, Stage 1 will expose that quickly.

What the auditor is really testing at Stage 1

The ISO 27001 Stage 1 audit is often described as a “documentation review,” but that description can be misleading.

Yes, documentation is important. But the auditor is also evaluating whether the organization appears ready for Stage 2.

They are effectively asking questions such as:

Is the scope realistic and clearly defined?
Has the organization understood its information security risks?
Is the Statement of Applicability logically connected to the risk assessment?
Are mandatory management system processes established?
Does leadership appear involved?
Has the organization performed enough of the ISMS cycle to demonstrate readiness?
Are there obvious gaps that would make Stage 2 premature?

This is why a company with impressive policies can still struggle.

ISO 27001 is not a writing competition.

A 40-page access control policy will not compensate for an unclear risk treatment process or a management review that never happened.

If you are still at the beginning of implementation, I recommend reading my practical guide on how to really get started with ISO 27001 without hating information security. It explains how to approach the standard as a management system rather than a documentation exercise.

What evidence is expected during an ISO 27001 Stage 2 audit?

Stage 2 is where the conversation changes from “show me how the system is designed” to “show me that you are doing what you say.”

This is where ISO 27001 audit evidence becomes much more operational.

The auditor will normally sample records across different processes and controls. They may interview employees, review system settings, inspect tickets, examine logs, trace incidents, and compare documented procedures with actual practice.

Examples of evidence you may be asked to provide include:

user access requests and approval records;
onboarding and offboarding records;
periodic access reviews;
security awareness and training records;
incident tickets and incident response records;
vulnerability management records;
patching evidence;
backup monitoring and restore-test results;
supplier assessments;
security clauses in relevant supplier agreements;
change management tickets;
asset inventories;
risk treatment actions and status updates;
internal audit findings and corrective actions;
management review outputs;
security monitoring records;
business continuity or disaster recovery test results;
evidence supporting selected Annex A controls.

And this is only a sample.

The exact evidence depends on your scope, risk profile, control selection, technology stack, and business model.

A financial technology company, a software development business, a hospital supplier, and a small professional services firm may all implement ISO 27001 very differently.

That is completely acceptable.

ISO 27001 does not require every organization to operate identical controls. It requires you to manage information security risks systematically and demonstrate that the controls you claim to have implemented are actually working.

Documents are not enough at Stage 2

This is probably the single most important point in this article.

During the ISO 27001 Stage 2 audit, a policy proves very little by itself.

Imagine your policy says:

User access is reviewed every six months.

The auditor may then ask:

“When was the last review performed?”

At that moment, the useful evidence is not the policy. It is the actual access review record.

If your incident management procedure says that security incidents are categorized, investigated, and closed with documented actions, the auditor may select a real incident and ask to see the complete trail.

If your supplier security process says critical vendors are assessed annually, the auditor may ask for several supplier assessments.

That is why I tell organizations to prepare evidence by asking one simple question:

“If an auditor asked me to prove this happened, what record would I show?”

That question is far more useful than asking whether you have enough policies.

Stage 1 vs Stage 2: a practical comparison

Here is a simplified way to look at the difference.

Area	Stage 1	Stage 2
Main objective	Assess readiness	Assess implementation and effectiveness
Primary focus	ISMS design and documentation	Operational execution
Risk assessment	Methodology and completed results	Evidence risks are treated and monitored
Statement of Applicability	Logical control selection	Evidence selected controls operate
Policies	Reviewed for adequacy	Compared with actual practice
Interviews	Usually limited	Common across departments
Operational records	Sampled selectively	Examined in much greater depth
Internal audit	Readiness and completion checked	Findings, corrections, and effectiveness reviewed
Management review	Evidence that it occurred	Evidence decisions and actions are meaningful
Technical controls	High-level understanding	Practical sampling and verification

The easiest mistake is to treat this table as a rigid checklist.

It is not.

Certification audits use sampling. The auditor will not check every employee, every laptop, every supplier, or every access request. But the samples they choose need to demonstrate that the system is consistently implemented.

The ISO 27001 certification checklist I would use before Stage 1

Before an ISO 27001 Stage 1 audit, I would want the organization to be able to answer “yes” to the following questions.

Your ISMS should have a clearly defined scope, documented risk assessment and treatment approach, completed Statement of Applicability, relevant policies, measurable objectives, assigned responsibilities, and evidence of key management system activities.

I would also check whether the organization can clearly explain how these elements connect to one another.

For example:

Can you explain why each control in the Statement of Applicability is included or excluded?
Can you trace major risks to specific treatment actions?
Can management explain its information security objectives?
Can employees responsible for the ISMS explain their roles?
Have internal audit and management review activities been performed appropriately?
Are obvious legal, contractual, customer, and regulatory requirements accounted for?

If these basics are not stable, rushing into Stage 1 rarely saves time.

It usually creates a list of issues that must be corrected before Stage 2 anyway.

The ISO 27001 certification checklist I would use before Stage 2

Before Stage 2, I would shift the focus almost entirely toward implementation evidence.

Do not only review documents. Walk through actual processes.

Pick samples.

Choose three recent employees and test onboarding. Choose three former employees and test offboarding. Select several privileged accounts. Check a vulnerability report. Follow one security incident from identification through closure. Review a supplier assessment. Examine an access review. Look at a backup restore test.

This kind of preparation exposes gaps that document reviews miss.

A practical pre-audit review should confirm that:

procedures are actually followed;
records are retained;
responsibilities are understood;
control operation is consistent;
deviations are detected;
corrective actions are documented;
security objectives are monitored;
management receives meaningful information;
risks and treatment actions are updated when circumstances change.

The goal is not to create artificial evidence for the audit.

The goal is to verify that your ISMS leaves a natural trail of evidence because people are actually using it.

That is a major difference.

What does “objective evidence” mean to an ISO 27001 auditor?

Auditors use the concept of objective evidence constantly.

In practical terms, objective evidence is information that can support a conclusion rather than relying solely on someone saying, “Yes, we do that.”

Strong evidence might include a ticket, system log, signed record, meeting minutes, report, configuration screenshot, approval workflow, training record, assessment result, or documented review.

An interview can also provide evidence, but auditors typically triangulate.

For example, an employee may explain the onboarding process. The auditor might then review an onboarding ticket, verify that access was approved, and compare the process against your documented procedure.

When the interview, record, and documented process all agree, confidence increases.

When they contradict each other, questions start.

Common Stage 1 problems

The most frequent Stage 1 issues I see are not exotic technical failures.

They are structural.

Organizations often struggle because their scope is vague, their risk methodology does not match their actual risk register, the Statement of Applicability feels disconnected from the business, or management system activities have been completed only superficially.

Another common issue is copy-paste documentation.

You can usually spot it quickly.

A company uses Microsoft 365, AWS, Jira, and GitHub, but its policies repeatedly refer to “server room access,” removable media registers, and fax machines that do not exist.

This creates unnecessary audit questions and makes the ISMS look less credible.

Your documents do not need to sound complicated.

They need to sound like your company.

Common Stage 2 problems

Stage 2 failures tend to be more operational.

The organization may have a correct process, but implementation is inconsistent.

For example, ten employees were onboarded correctly, but two were given access without documented approval. Supplier reviews exist, but only for new suppliers. Vulnerability scans are performed, but there is no clear evidence that critical findings are tracked to closure.

These inconsistencies matter because the auditor is not only checking whether a control exists.

They are checking whether it is reliably applied.

I often see this when companies grow quickly. The ISMS was designed when the organization had 20 people, but six months later there are 80 employees across several countries and the original workflows no longer match reality.

ISO 27001 requires the system to evolve with the organization.

Geography also influences what customers expect

The ISO 27001 standard is international, but the commercial context around certification varies considerably.

A software company selling to enterprise customers in the UK may face different procurement expectations from one working primarily with buyers in Estonia, Ukraine, the US, or the Middle East.

Some customers ask only for a valid certificate. Others want the Statement of Applicability, penetration testing evidence, privacy documentation, detailed supplier controls, or answers to large security questionnaires.

I explored this topic in more detail in my article on differences in customer expectations regarding ISO 27001 in Estonia, Ukraine, and the UK.

This is worth understanding because certification is rarely the final objective.

For most organizations, the real objective is market access, stronger customer trust, reduced security risk, or smoother enterprise sales.

The certificate is evidence that a management system exists. Your customers may still expect much more.

Should you build an “audit evidence folder”?

Yes, but with one warning.

I often recommend creating a structured evidence library before certification, particularly for distributed companies.

It can save enormous amounts of time during the audit.

You might organize evidence around key ISMS processes and applicable controls, with links to current records rather than dozens of downloaded files.

For example, your evidence library could point the auditor toward access reviews, training records, internal audit documentation, supplier assessments, vulnerability reports, management review minutes, security objectives, and incident records.

But do not turn this into an artificial “audit museum.”

The evidence should come from normal operational systems whenever possible.

If your team uses Jira, ServiceNow, Microsoft 365, GitHub, AWS, Azure, Google Workspace, or another platform to operate controls, it is often better to demonstrate real evidence there than to manually export everything into PDFs purely for certification.

An experienced ISO 27001 auditor usually prefers real operational evidence over carefully staged documentation.

Final advice: prepare for the auditor’s next question

Good audit preparation is not about memorizing answers.

It is about understanding the chain of evidence.

If you show a risk, expect the auditor to ask how it is treated.

If you show a control, expect them to ask for implementation evidence.

If you show a procedure, expect them to select a sample.

If you show a nonconformity, expect them to ask what corrective action was taken.

If you show an objective, expect them to ask how performance is measured.

Once you understand that logic, ISO 27001 audits become much less mysterious.

The difference between the ISO 27001 Stage 1 audit and the ISO 27001 Stage 2 audit is ultimately the difference between design and demonstrated operation.

Stage 1 proves that your ISMS is ready.

Stage 2 proves that your organization is actually living it.

And that is exactly what certification is supposed to demonstrate.

Need help preparing for your ISO 27001 audit?

If you are preparing for Stage 1 or Stage 2 and want an independent review before the certification auditor arrives, I can help you identify evidence gaps, test your ISMS against likely audit trails, and focus your team on the issues that actually matter.

The goal is not to “pass an audit at any cost.” It is to build an ISMS that is credible to auditors, practical for your team, and valuable to customers across the EU, UK, US, Middle East, and other international markets.

Contact me through proskurnya.com to discuss your ISO 27001 certification preparation, gap assessment, or audit readiness review.