ISO 27001/20000 Audit Stages, One by One: What Each Stage Reviews

The four stages at a glance

Start with the whole picture. This table is worth printing and pinning where the system owner sits — not as a process diagram, but as a checklist of "what I should be able to produce at this stage".

1. Stage 1 audit (documentation and readiness): whether the system is ready

What is reviewed

Stage 1 is the audit of documentation and readiness, and its function is to decide whether the audit can move on site. It usually does not aim at exhaustive evidence but confirms four things: whether the system documentation is in shape (policy, objectives, manual, procedures, work instructions and record forms, with versions and approvals complete); whether the scope and sites are stated clearly (which business the certification scope covers, which departments and locations); whether the core professional activities have already happened (on the 27001 side, risk assessment and treatment plan, statement of applicability; on the 20000 side, service catalogue, SLAs and traces of service desk operation); and whether one round of internal audit and management review has been carried out, with inputs, outputs and corrective action.

So a Stage 1 that does not go through is usually not about missing documents but about missing key records, or a risk assessment that was never finished. A missing document is a writing problem and can be fixed with a new version; a missing record is a running problem and cannot be produced afterwards — it means nobody did the thing at the time. That is also why, when Stage 1 is sent back, what actually has to move is the schedule, not the paperwork.

Who takes part

The system owner leads; the management representative or the executive in charge is present; the heads of key functions such as IT, security, service desk, HR and procurement are on call. A consultant can help you sort things out while preparing, but the audit itself is answered by people inside the company — consulting and certification are two separate roles, and this boundary is not one to test.

The group does not need to be large; what matters is that the people in the room can answer three questions: who approved this document, when was this record produced, and who made this decision. Answering "our consultant wrote that" marks the item as empty.

How to organize the evidence

• Documents: one controlled document list carrying version, effective date and approver, so that it is visible which version is in use. Where the two systems are built together, separate the shared skeleton (manual, document control, internal audit, management review) from the discipline-specific documents (risk assessment procedure and SoA for 27001; service catalogue and SLA management for 20000).
• Records: internal audit plan, checklists, nonconformity reports with correction and verification, management review inputs, outputs and minutes; risk assessment report, treatment plan and SoA; service catalogue, SLA texts and sample tickets. The value of a record lies in its date, not in its volume.
• Interviews: Stage 1 questions are largely "who is responsible, how often is it done, when was the last time". If one of those three cannot be answered with a specific time, the item struggles to stand.
• Site: Stage 1 usually does not go into a deep walkround, but it looks at the office area, the server room and access control to judge whether the declared sites correspond to reality.

Common return reasons and nonconformities

• Not enough running time, records covering only a short stretch. The system has to have been running for 3 months before an application is accepted — that is a hard threshold, and one or two months of records do not demonstrate a full round.
• Risk assessment not finished, or finished with nothing after it. The driving logic of 27001 is risk: assets and threats identified, but no treatment plan, no SoA and no owners, and the chain breaks at Stage 1.
• Internal audit and management review not done, or done with zero findings. An internal audit record stating "no nonconformities, no issues" invites more questions than one that lists three — a system that has just been built and has no problems only shows the audit was not taken seriously.
• Scope written too wide. If the certification scope covers business that is not performed, sites that are not controlled, or branches with no staff, Stage 1 will ask for it to be narrowed; and once the scope changes, the documents and records behind it change too.

2. Stage 2 audit (on-site, effectiveness): whether it is really being done

What is reviewed

Stage 2 is the audit of the site and of implementation effectiveness. In one sentence: take the documents seen at Stage 1 and check them on site. Check what? Whether processes follow the documents, whether controls are in place, whether records can support that the thing really happened, and whether objectives are actually measured and used.

The two standards take different evidence routes. 27001 follows asset — risk — control — record: pick a few items from the asset inventory and see what treatment was chosen, which control it lands on, and whether there is evidence of execution (access approval, backup verification, log review, incident handling). 20000 follows service — ticket — SLA — improvement: pick a service from the catalogue and see its SLA commitments, whether tickets run from acceptance to closure, whether the monthly report carries statistics, and whether a miss produced improvement action. The 20000 side also looks closely at tools: whether the data in the service desk and the ITSM tool is real operating data rather than demonstration data.

The common failure at Stage 2 is not "not done" but "done twice": one set prepared for the audit and another running day to day. The document says changes need approval, but in practice a message in a chat group is enough; the policy says suppliers are reviewed every quarter, but no meeting has been held for a year. This kind of inconsistency is hard to hide on site, because the auditor only has to put the document and the system screen side by side.

Who takes part

Top management attends the opening and the closing, and speaks about investment and decisions; department heads take the interviews for their own areas; the people from sampled projects must be present — whoever did the work answers for it; service desk and operations duty staff, HR (training and employment) and procurement (suppliers and outsourcing) are present as needed.

A practical reminder: do not let the system owner take every question. When someone answers on behalf of others too often, the audit team turns to "does the person who actually does it know", and the person on site often cannot reproduce the wording in the document. Letting people describe their own actions in their own words is far more credible than reciting the policy.

How to organize the evidence

• Documents: the documents used on site must be the current version and must match the controlled list. Auditors pick up forms from desks at random to see whether they are the version on the list — often overlooked, and easy to lose points on.
• Records: file by business chain, not by department. One incident from acceptance, grading, handling and recovery to closure — four records kept together; one change from request, assessment, approval and implementation to rollback plan — the same bundle. Records filed by department take a long time to assemble into a chain on site, and a chain that cannot be assembled counts as absent.
• Interviews: the person doing the work can state time, object and result. "We generally do it as required" is empty; "which device raised an alert last month, who handled it, how long recovery took" is evidence.
• Site: server room, workstations, the duty desk, monitoring and ticketing screens. Ask for the system to be opened rather than only printed output; printouts can be arranged, timestamps in the system cannot.

Common return reasons and nonconformities

• Two ways of working, one in the document and one on site. The policy requires approval, in practice it is decided verbally; the process defines grading, in practice everything takes the same path. This is a large share of Stage 2 findings.
• Records break at the closure step. A nonconformity is raised, correction is done, but there is no verification and closure; a risk treatment plan lists measures with no evidence of execution. Present at the start, absent at the end, which is the same as not closed.
• Tools bought but not used, or used but not logged. The ITSM tool exists, but dispatch still happens in a chat group; on the 27001 side there is a log platform and nobody watches the alerts. The 20000 side is easily caught here, because service desk data is its core evidence.
• Objectives set but not measured. The policy names objectives; ask how much of this month's target was met and there is no answer; or the objectives have not changed in three years and are met every year, which shows nothing about the system working.
• Multi-site declaration with some sites leaving no trace. Several locations are listed in scope, and one of them has no system documents, no records, and nobody who knew an audit was taking place.

3. Surveillance audit (annual): whether it has been kept up

What is reviewed

A surveillance audit is not Stage 2 done again; it looks at continued conformity and change management. The lines are fixed: whether the previous audit's nonconformities are closed and verified; whether changes within the scope during the year have been brought into the system (business adjustment, relocation, reorganisation, replacement of a core system, outsourcing of operations); whether internal audit and management review were carried out this year; whether objectives are measured and how they were met; and whether key records are continuous — the year's security incidents, service tickets, changes, training and supplier evaluations should form an unbroken line.

Sampling in a surveillance audit is more focused: last time's findings, the parts that changed this year, and the higher-risk business within scope carry more weight. That also means the places where a nonconformity was raised last year will probably be looked at again this year.

Who takes part

The system owner is responsible; the departments that changed during the year must have someone present (system replaced, site moved, business line added, outsourcer changed); the owner of the previous nonconformity must be able to explain how the correction was made and who verified it. Top management need not attend throughout, but someone must be able to explain the conclusions of the management review.

There is a practical issue here: in many companies the team disperses once the certificate is issued, and someone is found at short notice for the annual audit. People changing is not the problem — a handover that left no trace is. If the current holder cannot explain why the previous one decided as they did, the audit will question whether the system is still understood.

How to organize the evidence

• Documents: documents changed during the year need version change records and distribution traces. A document untouched for a year is not necessarily a problem, but "why it did not need changing" has to be explainable.
• Records: the year's internal audits and management reviews, incidents and changes, training, supplier evaluations, and the correction and verification of the previous nonconformities. Continuity matters more than completeness: missing two of twelve months is harder to explain than a simplified record covering the whole year.
• Interviews: the core question is "what changed this year and how did the system follow". "Nothing changed" usually does not hold in a company whose business is running normally.
• Site: focus on areas that changed and on last time's findings; the whole company does not need walking again, but a newly added site within scope must be visitable.

Common return reasons and nonconformities

• Stopping when the certificate arrives. Nothing is accumulated day to day and a batch of records is produced before the annual audit; dates, handwriting and content do not agree, and the more that is added the more visible it becomes.
• Last time's nonconformity was corrected only on paper. The clause in the document changed, the practice on site did not; or the correction was made with no evidence of verification and closure. This comes up frequently in surveillance audits.
• Changes not brought into the system. A core system replaced, an office moved, a business line added, operations outsourced as a whole — risk not reassessed, scope not updated, documents not revised.
• Internal audit and management review copied from last year. The same issue list every year and the same improvement actions every year show that both activities have become formalities.
• A gap in records that cannot be explained. Some months have no incident or ticket records at all, with no statement that business stopped and no explanation of why the data is missing.

4. Recertification (before the 3-year certificate expires): what three years produced

What is reviewed

Recertification is not a renewal; it looks at the whole thing again on the logic of initial certification, with the focus moved from "whether it exists" to "how it stands after three years". It looks at four things: whether the system is still suitable (the business changed — did the system follow); whether the objectives were met across three years and whether they were adjusted; whether improvement has left traces — not "no problems", but "problems were found, solved and verified"; whether the certification scope is still accurate (is the business written three years ago still being done); and whether every finding from the surveillance audits has been closed.

The usual failure in recertification is time: not a lack of capability, but too late a start. The certificate is valid for 3 years and recertification has to be completed before expiry; if it is not, the certificate lapses and initial certification has to be repeated. And repeating it means going through Stage 1 and Stage 2 again, with the three years of records no longer connecting.

Who takes part

Top management must be present, and what they have to speak about is which decisions the system changed over three years — what was invested, what was stopped, which risk review changed a business arrangement. The system team links the three years of records; every department within scope has to prepare, because the coverage of recertification returns to the scale of initial certification, not the sampling scale of a surveillance audit.

How to organize the evidence

• Documents: current versions plus three years of version history. It should be visible that the documents are live documents that have been revised, not frozen since the version signed three years ago.
• Records: three years of internal audit and management review, the surveillance audit reports and corrections, trends in objective achievement, trends in incidents and changes, training and supplier evaluation. A three-year comparison table is worth building so the trend speaks for itself.
• Interviews: ask management about investment and trade-offs over three years, and ask the delivery level how the practice of three years ago differs from now. When both levels describe the same change, the improvement is real.
• Site: coverage close to initial certification, focusing on what was added or changed over the three years: new systems, new sites, new business, new outsourcing arrangements.

Common return reasons and nonconformities

• Three years of material assembled just before expiry. With gaps in the intervening years and no evidence of continuous operation, initial certification has to be repeated.
• The scope has drifted from the actual business. The business has moved on and the scope still names what was done three years ago; or the reverse — new business delivered in practice but never brought into scope.
• Improvement cannot be described in concrete terms. Asked "what changed over three years, why, and what came of it", the answer is only "we have kept improving". Improvement needs an object, an action and a result.
• Nonconformities from the last surveillance audit still open. This is one of the firmer points in recertification, because it also shows that the surveillance step failed.

5. Where the two standards differ: 27001 looks at information security, 20000 at service management

The skeleton of the four stages is the same, because both standards belong to the ISO management system family and share the PDCA and documented-information structure. But within the same stage the direction of the evidence differs. This matters especially in a dual-system project: the audits are arranged separately and the conclusions are independent, so one set of material cannot be prepared for two certificates.

One sentence to separate them: 27001 evidence points to "information did not go wrong, and these are the controls that were working"; 20000 evidence points to "service did not stop, and these are the processes that were working". The first is concerned with assets, threats, vulnerabilities and controls; the second with the service catalogue, SLAs and incident management.

What can be merged should also be stated clearly: document and record control, internal audit, management review, competence and training, and supplier and outsourcing management — these five blocks can be done once, with one skeleton carrying two sets of professional content. But the risk assessment and SoA, the implementation of security controls, the service catalogue and SLAs, and the service desk and ITSM tools must each be done separately. The audits themselves cannot be merged into one either: two certificates and two sets of certification rules, and whether they can be coordinated in one period with one audit team has to be confirmed with the certification body. This is set out further in ISO 27001 + 20000 dual certification: where the saving lies.

6. Timeline: from kick-off to certificate to recertification

Put the four stages back on one line and the order looks like this. Note that on this line the time is not taken by the audit itself but by the running and record accumulation before it.

A few places where scheduling goes wrong:

• Treating the audit as the starting point. The audit is a check, not a build. Every action that decides the outcome (risk assessment, internal audit, management review, records) is completed before the audit; on the day you can explain, not catch up.
• Treating the running period as buffer. Three months of running is an acceptance condition, and it is the stretch usually compressed when the schedule is worked backwards — the result is thin records or a returned application.
• Treating the two systems as one audit. Two certificates are arranged separately, so the internal plan has to prepare for two rounds rather than staffing for "two certificates in one go".
• Treating the annual audit as a temporary project. Surveillance happens every year; with internal audit, management review and archiving on a fixed rhythm, the annual audit becomes a matter of collecting the material once.
• Treating recertification as a renewal fee. Its coverage returns to the scale of initial certification, and starting only a short time ahead is usually too late.

7. Action list: align by stage, do not prepare four times

The list below is arranged by stage. The point is to tick in sections: while the Stage 1 boxes are not all ticked, do not rush into preparing the Stage 2 on-site answers; and the surveillance boxes should start being ticked on the day the certificate arrives.

• ⬜Fix the scope: write in one sentence the business, departments and sites the certification scope covers, and confirm that each of them has people, records and traces of the system
• ⬜Fix the people: who is the system owner, the management representative, the interface for each key function; and who maintains it after certification — write it down
• ⬜Stage 1 self-check: is the document list controlled, is risk assessment and treatment complete, has one round of internal audit and management review been run with nonconformities raised
• ⬜Stage 1 self-check: on the 27001 side, whether every SoA line carries a conclusion; on the 20000 side, whether the service catalogue and SLAs are measurable and whether the service desk has operating data
• ⬜Stage 2 self-check: take two business chains and retell each from initiation to closure from the material alone, with no verbal filling of gaps
• ⬜Stage 2 self-check: have the people who actually do the work (not the system owner) describe their process and compare it with the document
• ⬜Stage 2 self-check: confirm that the forms used on site, the system screens and the record versions match the controlled list
• ⬜Surveillance: keep a change register recording five kinds of change — business, site, organisation, system, outsourcing — as they happen
• ⬜Surveillance: track the previous nonconformities separately through to "verified closure", not stopping at "corrected"
• ⬜Recertification: build a three-year trend table (objectives, incidents, nonconformities, risk treatment) so that improvement is visible
• ⬜Recertification: confirm ahead of time whether the scope is still accurate; if the business has changed, change the scope first and then discuss scheduling
• ⬜Throughout: all dates, sites and the audit sequence follow the certification body's arrangements; leave room in the internal plan for explanation and adjustment

Taken this far, the four stages come down to one sentence in four tenses: Stage 1 is the future tense (are you ready), Stage 2 is the present continuous (are you doing it), surveillance is the present perfect continuous (have you been doing it), and recertification is the past three years (has it got better after all that). Different tenses mean different things to bring. Once it is clear what each stage is asking, preparation will not be done four times, and effort will not be spent at the wrong stage.

▍Not sure which stage you should be preparing for? Leave a comment with "audit stage self-check" and I will send you a checklist split across the four stages.