ISO 27001 and penetration tests: what the standard actually wants

Among the Annex A controls you will find none called a penetration test. The annex requires the management of technical vulnerabilities, security testing in development and acceptance, and an independent review of information security: objectives, not a specific act. Penetration testing appears only in the implementation guidance of ISO/IEC 27002:2022, as one of the possible ways to meet those controls.

In practice this means the test is the most direct evidence that the controls work, which is why auditors ask for it even though Annex A doesn’t name it.

The distinction is worth holding on to, because it changes the argument at the audit. You are not demonstrating that you performed a prescribed act. You are demonstrating that a control you set yourselves was verified independently and in live operation. A company that brings a scanner output instead of a test usually runs aground right here.

Certification is also granted to the management system, not to a single application. The auditor therefore doesn’t examine the severity of one finding but whether the company has a process that catches findings, evaluates them, and carries them through to a fix.

In practice a penetration test is used as evidence for four areas of Annex A controls: the management of technical vulnerabilities, security testing in development and acceptance, secure development, and the independent review of information security. We name the controls in words, because the codes have changed between revisions of the standard.

The last row is the touchiest one for internal teams. Your own IT department can run a scan, but that doesn’t document the independence of the review, because it is checking the result of its own work.

An auditor typically doesn’t read the whole report. They look in it for six things that together show the test was real and that something followed from it. A report that has findings but shows no remediation is technically fine but won’t hold up at the audit.

• Scope: what exactly was tested, naming the applications, IP ranges, or environments.
• The date of the test and the version of the tested system.
• The methodology that was followed, and who performed the test.
• A list of findings with severity and a description of impact.
• Evidence of the fix for findings you decided to remediate.
• A retest with its own date and a status for every fixed finding.

For findings you decided not to fix, the auditor wants to see a risk acceptance signed by the responsible person. Silence about a finding is worse than knowingly accepting it.

No fixed interval follows from the standard. The company sets the interval itself in its risk analysis, and the auditor then checks that it keeps to it. Among certified companies an annual cycle plus a test after any major change has become the norm, because it lines up with surveillance audits. Anyone who also falls under Act No. 264/2025 Coll., on Cybersecurity (the Czech Cybersecurity Act), has it differently: there the interval is set by regulation.

Watch out for reasoning backwards. If you write half-yearly testing into your documentation because it sounds thorough, the auditor will check half-yearly testing. An interval you don’t keep is worse than a longer one you do.

ISO 27001 certification and the obligations under the Czech Cybersecurity Act overlap technically, not formally. One well-run test can serve both, because both rest on verifying that controls work in live operation. It doesn’t count automatically, though.

The difference is in who sets the rules. With certification you set the scope and the frequency yourself and the auditor checks that you keep to them. Under the Act the requirements come from a regulation, including the interval and the records. What Act No. 264/2025 Coll. (in Czech) asks for and which regime you fall into is covered by our guide to NIS2 and the Czech Cybersecurity Act for companies.

Ordering a test as the first step makes no sense. First you need to know what is in the scope of the management system, because that is what decides what will be tested. The order of steps worth keeping before certification looks like this.

• Define the scope of the management system and list the assets that fall inside it.
• Run a risk analysis and derive from it which controls you will put in place.
• Plan the test for the assets with the highest risk, not for all of them.
• Leave time for fixes and a retest before the certification audit, not after it.

We help with defining the scope and tying it to the risk analysis as part of security consulting. The verification itself then runs as a penetration test of applications and infrastructure, whose deliverable can be attached to the documentation unchanged.