The Statement of Applicability is the document that turns your certificate into commitments. It lists every Annex A control, says whether it applies, and explains why. An auditor works through it and asks for evidence, so anything you have marked applicable becomes a promise you need to demonstrate, and technical testing is how several of those controls get demonstrated.
The controls that testing supports
Two controls in the 2022 version of Annex A lean directly on testing. Control 8.8 covers the management of technical vulnerabilities, which is where scanning cadence, patching timescales and prioritisation live. Control 8.29 covers security testing in development and acceptance, which is where penetration testing of new and changed systems belongs. Several others are supported by the same evidence, including access control and secure configuration, since a test report shows how those controls behave under pressure rather than how they were intended to work.
What auditors actually ask to see
Expect requests for documents with dates on them. A scope statement showing what was tested, the report itself or a summary, a record of remediation with owners and completion dates, and evidence that findings were retested. Auditors from a UKAS accredited certification body are looking for a working process rather than a perfect result, so a report with findings that were fixed is far stronger evidence than a clean report nobody can explain. Bring the previous year’s report as well, since visible improvement between two reports is the strongest evidence that the process works. The gap that causes trouble is a Statement of Applicability promising annual testing next to a report dated twenty months ago.
“I sit in a lot of audit preparation meetings, and the same problem comes up: the document says testing happens annually because that sounded right when it was written, and the business tests every two years because of budget cycles. Change the document or change the practice. Auditors do not mind which, and they do mind finding the difference themselves.”
William Fieldhouse, Director, Aardwolf Security Ltd
Writing applicability statements you can defend
Keep the justification short and specific to your organisation. Where a control is excluded, say why in terms an auditor can test, such as the absence of a development function rather than a general statement about size. Where a control applies, name the evidence you will produce and where it lives. That turns audit preparation into collecting known documents instead of a scramble. It also makes the annual review meaningful, because you can see at a glance which commitments have no current evidence behind them.
Keeping the evidence current
Set the testing schedule from the Statement of Applicability rather than from last year’s invoice. If the document commits you to testing significant changes, build a trigger into your change process so a major release books a test. Regular vulnerability assessmentcovers control 8.8 continuously and produces the trend data that shows the process works. When selecting from certified penetration testing companies for this purpose, ask for reports written with an audit audience in mind, since a document that needs translation before an auditor can read it costs you time in every surveillance visit.
Frequently asked questions about ISO 27001 evidence
These questions come up in the weeks before a surveillance audit.
Does ISO 27001 require penetration testing?
It does not name it as mandatory. It requires you to manage technical vulnerabilities and to test security in development, and testing is the usual way organisations evidence both. If you claim those controls, expect to show how.
Can internal testing satisfy the auditor?
Sometimes, if it is documented and reasonably independent of the people who built the system. External reports carry more weight, particularly where the same evidence is shown to customers during due diligence.
