Getting technical evidence ready for ISO 27001

Most of the ISO 27001 work we are pulled into arrives late — six weeks before a certification audit, with a consultant's gap analysis in one hand and a request for "a pen test" in the other. That order of operations is expensive and produces weaker evidence than it needs to. Here is what auditors are actually looking for on the technical side, and when to produce it.

A note on scope: we are a testing provider, not a certification body. We produce technical evidence and fix findings. The certification decision belongs to an accredited body and your own advisers.

What the standard actually asks for

The 2022 revision of Annex A folded the technical controls into a shorter list, and three of them account for most of what an auditor will ask you to demonstrate:

• Management of technical vulnerabilities. You know what you run, you learn about vulnerabilities affecting it, and you act on them within defined timeframes.
• Secure development. Security is considered during development, and changes are tested before they reach production.
• Monitoring and logging. Relevant events are recorded, retained and reviewed.

Notice what is not there: the standard does not mandate an annual penetration test in so many words. What it requires is that you can show a functioning process. A test report is strong evidence of that process working — but a single report with no surrounding process satisfies nobody.

The evidence auditors ask to see

In practice the requests are consistent:

• An asset inventory that is current, and an explanation of how it stays current.
• Scan output over time, not a single run — showing that scanning is routine.
• A documented severity scale with remediation deadlines attached to each level, and evidence those deadlines are usually met.
• A sample of findings traced end to end: discovered, ticketed, fixed, verified, closed. This is the single most persuasive artefact you can present.
• Independent testing of systems that matter, with the scope stated and the retest of fixed issues attached.
• Records of exceptions — findings you accepted rather than fixed — with a named owner, a reason and a review date.

That last item causes more anxiety than it should. Auditors do not expect zero open findings. They expect open findings to be known, owned and justified. An accepted risk with a signature is evidence of a working system; an untracked one is evidence of nothing.

Sequencing it properly

The scramble happens because testing gets booked last. Reverse it:

• Six months out. Fix the inventory. Everything else depends on knowing what exists. Start routine scanning now so that by audit time you have a history rather than a snapshot.
• Four months out. Agree the severity scale and deadlines, and start running the remediation workflow in your normal ticketing system. Do not build a separate process for the audit; auditors can tell, and a parallel process will not survive the year.
• Three months out. Independent testing of the systems in scope. Early enough that findings can be fixed and retested before the audit, which converts your worst evidence into your best.
• Six weeks out. Retest. A report showing critical findings closed and verified is far more convincing than one showing them open with a promise.
• Two weeks out. Assemble the trace: pick three findings and lay out the full lifecycle with dates and ticket references.

Common ways it goes wrong

The scope of the test does not match the scope of the certification, so the test covers systems the auditor is not interested in and misses ones they are. Agree the two together.

The report is a raw tool export with two hundred informational entries and no triage. That is not evidence of a process; it is evidence of running a tool. Ask for triaged, business-ranked findings.

Findings are fixed but never verified, so there is nothing to show that the fix worked. Retesting is what closes the loop, and it should be included in the engagement rather than bought separately.

And the most common of all: the process was built for the audit and abandoned after it. The certificate lasts three years with surveillance audits along the way. A process you would run anyway is the only one that survives them.

The strongest thing you can put in front of an auditor is not a clean report. It is three findings traced from discovery to verified closure, with dates. That single artefact demonstrates every control they are trying to assess.