This is a guest article by Miriam Mindt, Information Security Expert at Kertos. Kertos supports companies in their compliance, covering ISO 27001, GDPR, EU AI Act, NIS2, and more. The views and audit interpretations are the author's own – nonconformity grading always depends on your certification body and auditor.

The Stage 2 audit is where documentation stops being enough. Here’s the part of it that lands on whoever runs your systems.

First things first: ISO 27001 is not just an IT project. That belief is common and also expensive: certification produces work for HR, operations, marketing through information classification and labelling, and for every employee through training and awareness. IT certainly owns a slice of it, but not the whole thing.

This article is about that slice. It covers nine things a company’s IT function is likely to have to show during the Stage 2 audit, what a good answer looks like, and how each one usually falls short. It is deliberately not the whole audit.

What Stage 1 and Stage 2 actually check

Stage 1 is a readiness check and it’s mostly documentation. The auditor reviews the organization’s context and core documents: the scope statement, the information security policy, the risk assessment, the risk treatment plan, the Statement of Applicability, and whatever else is relevant. If they’re satisfied, they recommend you move on. If they find something major, you get time to remediate it before Stage 2.

That means spot checks of specific systems, interviews with your team if the auditor is on site, and evidence drawn from wherever the work actually happens. Not only your device management tool and identity provider, but repositories, vendor and employment contracts, monitoring and SIEM systems, and ticketing.

The failure that repeats most often is not a missing system, but a document standing in for a practice.

A general misconception for many customers or auditees is that it’s enough to have a policy in place instead of evidence that you are actually living the process that you’re documenting in your policy.

Kertos covers the rest of the certification process in more detail in the “Ask a Compliance Expert“ series.

1. The asset inventory, starting with primary assets

What gets asked: not the device list first. Auditors are more likely to start with primary assets, which are more abstract: business processes such as software development or hiring, and information assets such as employee or customer data. Then how those connect to the supporting assets that process them, and who is responsible for each.

A good answer: primary assets named and owned, supporting assets mapped to them, and for vendors, how each one was selected and how it gets reviewed.

How it falls short: an inventory that is only a list of laptops. Offline vendors and unmapped relationships between systems and the information they hold are a likelier source of findings than a device that drifted off the list.

Annex A 5.9, 5.10

2. The endpoint baseline, all of it

What gets asked: for user endpoints, five things get checked together, not one at a time: hard disk encryption, screen lock, a password manager, and antivirus.

A good answer: continuous monitoring or mobile device management that reports the current state of all four across every endpoint.

How it falls short: treating any one of the four as the whole endpoint story, or reporting coverage with exceptions. A gap in endpoint protection is not a nuance to explain, it is usually a minor nonconformity.

Annex A 8.1, 8.24, 8.7, 5.17, 8.19

3. A configuration baseline, across more than laptops

What gets asked: what a correctly configured system looks like here, and how you detect the ones that deviate. Annex A 8.9 covers configurations of hardware, software, services, and networks, so cloud and network configuration are inside it.

A good answer: documented baselines, monitoring that surfaces deviations, and review. Declarative configuration, for example via Terraform, can be a type of perfectly good evidence.

How it falls short: the baseline exists only in the mind of whoever sets up machines, and nothing covers cloud or network configuration at all.

Annex A 8.9

4. The access list, and the review of it

What gets asked: who has access to a given system, with what privileges, granted when and by whom. Then when that list was last reviewed.

A good answer: both. The list is evidence in its own right and needs to carry accounts, privileges, and the grant history. The review adds the thing the list cannot show on its own, which is deviation from the intended state, for example access that no longer matches someone’s role or group.

How it falls short: an accurate current list with no review behind it, or a review that confirms the list rather than testing it against role-based access.

Annex A 5.15, 5.16, 5.18

5. One onboarding and one offboarding, walked through

What gets asked: usually a spot check of one recent joiner and one recent leaver. How access and privileges were granted, how they were revoked, and how assets came back.

A good answer: the same sequence for everyone, visible in whatever systems you use, including for the person who left on good terms and the one who did not. Precise timestamps are rarely the point.

How it falls short: someone who left a year ago still has an active account in a system nobody remembered. A single miss in a process that otherwise works is a minor nonconformity. The major category is different in kind: no process at all, or one that fails systematically.

Annex A 5.11, 5.18, 6.5

{{cta}}

6. Vulnerability management, including your own code

What gets asked: how a vulnerability travels from disclosure to being fixed, everywhere it applies. That includes employee devices, and it also includes the software you build, in production and in staging.

A good answer: a stated timeframe by severity, evidence that it is being met, and the automation that makes it possible. Dependency scanning in your repositories counts and is often the strongest part of the answer.

How it falls short: automatic updates are switched on for laptops and nobody can say what happens to a vulnerable dependency in the product.

Annex A 8.8

7. A backup that has been restore-tested

What gets asked: what is backed up, how often, and when something was last restored from it.

A good answer: a dated restore test with a recorded result. A single mailbox or one folder is enough if it is documented, because the point is that the restore path has been exercised. The same evidence supports ICT readiness for business continuity.

How it falls short: backups have run nightly for three years and nobody has ever tested one. The backup job reports success either way, so your own monitoring will not tell you.

Annex A 8.13, 5.30

8. Cloud services across their whole lifecycle, including the exit

What gets asked: Annex A 5.23 covers acquisition, use, management, and exit from cloud services. The exit half is the half companies forget.

A good answer: a register of the services that process company data, with an owner each, and a documented migration or exit path for the ones that matter. What happens to the data, how it is retrieved, how long that takes.

How it falls short: a register that lists only what IT provisioned, and no exit strategy for anything. The absent exit plan is what actually costs companies here.

Annex A 5.23

9. Incident response you have practiced

What gets asked: how an incident is detected, assessed, escalated, and resolved, and what you changed afterward.

A good answer: runbooks for the incident types you can realistically expect, records of real incidents handled through them, and a tabletop exercise you have actually run. Incident management is one of the systems whose complete absence is a major nonconformity, so this is worth more attention than it usually gets.

How it falls short: a policy describing an incident process that has never been tested, and no record of a real incident being handled under it.

Annex A 5.24, 5.25, 5.26, 5.27

The nine at a glance

What happens if something is missing

Not every gap carries the same weight.

A major nonconformity is a control that is not implemented at all, or one failing systematically. No risk management. No incident management. Something simply not in place. A minor nonconformity is a lapse inside a system that does work: incident management exists, and one incident was not recorded properly. A lapse in a working control stays minor; it does not escalate into a major one through repetition.

A major nonconformity can cost you the audit, but it does not arrive without warning. It gets flagged at Stage 1, or in your own internal audit, and you usually get the chance to remediate. In Mindt’s words, “it’s not that easy to fail the certification completely, but it’s also not impossible.”

What the nine have in common

None of them are satisfied by a document. Each asks whether something is running, and whether you can show it running.

That makes preparation less of an exercise than teams expect. If the systems are working, there is often nothing to prepare: the audit is a walkthrough of dashboards, repositories, and ticketing, with the auditor asking questions as you go. The useful check beforehand is not “have we written this down” but “if someone asked to see this operating, could we show them, today, in the system where it happens.” If you want that check across the whole program rather than just the IT side, Kertos published an ISO 27001 starter kit listing the evidence to capture at each phase.

If your IT is run by an external provider, some of the responsibility genuinely moves with it, and controls can be scoped accordingly. What does not move is the certificate, which belongs to your company. The practical version of this list is to work through the nine with your provider and establish which they can evidence, which you evidence, and what the scope statement says about the rest.

That conversation is also a useful test of the provider. A provider running your IT on a modern platform can show you the asset inventory, the endpoint state, the access list, and the last completed offboarding in a live dashboard. One that has to go and compile it for you will have to do the same thing again during the audit, with an auditor watching.

{{cta}}

Three things that sit outside IT but land on the same people

Your internal audit needs someone independent and qualified. Clause 9.2 requires an auditor who is competent to audit an ISO 27001 ISMS and was not involved in building yours. In a 40-person company, this is genuinely hard because whoever has the expertise is usually the person who implemented it.

It also buys a second opinion on your processes and your risk register, which is worth having on its own.

A narrow scope is not the safe option. Teams draw the ISMS scope tightly to keep the work down, and worry a buyer’s security team will hold it against them. The buyer is usually the smaller problem. The bigger one is internal: a narrow scope creates interfaces and exclusions you then have to manage. If one development team is in scope and another is not, and people move between them, the person arriving from the out-of-scope team has not accepted the same policies or completed the same training. Running all of that, in Mindt’s phrase, “can be more work in a way” than putting the whole process in scope from the start.

The certificate runs three years, with surveillance audits in years one and two. Those primarily check previous findings and what you did about them, and they look for continual improvement, which is what clause 10 of the standard is about. They remain audits, so other things can be checked too. If nobody has touched the ISMS for a year, it shows. The full sequence, from scope through Stage 1 and Stage 2 to the surveillance audits, is laid out in Kertos’s complete guide to ISO 27001 certification.