VAPT before an ISO 27001 audit

ISO 27001 does not contain a control that says "conduct a penetration test annually". This surprises people, and it leads to two opposite mistakes: assuming testing is not needed, and assuming any test satisfies the standard regardless of how it connects to the rest of the management system.

What the standard actually asks for is that technical vulnerabilities are identified, evaluated and addressed, and that the effectiveness of your controls is assessed. Testing is the most common way organisations demonstrate both. What an auditor wants to see is not the test itself but the loop around it.

What the auditor is actually assessing

An auditor looking at your testing will be trying to establish four things.

That testing is planned rather than incidental. There should be a stated approach: what gets tested, how often, on what basis that frequency was chosen, and who decides. A test conducted because a customer demanded one is evidence of a customer relationship, not of a managed process.

That the scope is justified. Why these systems and not others. The justification should trace back to your risk assessment and your asset inventory. If your risk assessment identifies a system as critical and it has never been tested, that gap is visible.

That findings entered your normal process. This is where most organisations lose marks. The report exists, the findings were real, and nothing in the corrective action process references them. Findings should appear in whatever register you use to track improvements, with owners and dates, like any other nonconformity.

That you acted, and can prove it. Remediation evidence, retest results, and for anything not fixed, a documented risk acceptance signed by someone with the authority to accept it.

The most common finding

By a wide margin: a test report with unremediated findings and no record of a decision about them.

The auditor is not troubled by the existence of vulnerabilities. Every environment has them. What generates a nonconformity is a report that identified issues eight months ago, several of which are still open, with no evidence that anyone evaluated them, assigned them, or consciously accepted the risk.

Fixing this is administrative rather than technical. Every finding needs one of three outcomes recorded: fixed and verified, scheduled with an owner and a date, or accepted with a rationale and a review date. All three are acceptable. Silence is not.

Timing it sensibly

Not the month before. A test four weeks before the audit produces findings you cannot remediate in time, which means walking into the audit with a fresh report full of open issues. That is worse than not having tested recently.

Three to six months ahead is the useful window. Long enough to fix what matters, retest, and show a closed loop. Recent enough that the auditor sees it as current.

Ongoing rather than annual is stronger. Scanning continuously, testing on significant change, and testing the whole scope periodically demonstrates a process. A single annual event demonstrates an event.

What to have ready

For the audit itself, gather:

• The current test report, and the previous one, so a trend is visible.
• The scope statement, with the reasoning that connects it to your risk assessment.
• The findings tracker, showing each finding's status, owner and date.
• Retest evidence for anything closed, or an explanation of how closure was verified.
• Risk acceptances for anything open, signed appropriately.
• The vulnerability scanning record between tests, which shows the process is continuous rather than annual.

Assemble this as a set rather than as separate documents produced on request. An auditor who has to ask four times for pieces of the same story forms a view about how managed the process is.

Where testing supports other parts of the standard

Testing evidence is useful in more places than the obvious one:

• Supplier management, where a test of an externally hosted service, or a supplier's own testing evidence, supports your assessment of them.
• Change management, where testing after significant change demonstrates that change is controlled.
• Continual improvement, where a falling count of repeat findings across successive tests is genuine evidence that the management system works.

That last one is worth constructing deliberately. Two reports showing the same categories of finding is a poor look. Two showing the second is cleaner than the first is one of the better pieces of evidence you can present.

A note on scope alignment

The scope of your certification and the scope of your testing should be recognisably related. If your certificate covers a specific service, the systems that deliver that service should be the ones tested.

A mismatch here is easy for an auditor to spot and hard to explain. Check it before commissioning the test, not after.

The short version

Testing is not a box that ISO 27001 requires you to tick. It is one of the more persuasive ways to evidence that you identify technical vulnerabilities and do something about them.

What turns a report into evidence is the loop around it: a justified scope, findings tracked in your normal process, remediation proven, and conscious decisions recorded for whatever remains. Organisations that get this right treat the test as an input to their management system. Organisations that struggle treat it as a document to produce on the day.