Where testing lands in the standard
The controls in the Annex include technical vulnerability management, secure development, and testing in the development lifecycle. None of them says "commission an annual penetration test".
What an auditor looks for is the loop: how vulnerabilities are identified, how they are assessed, who decides what gets fixed, what happened to the last set, and whether that is documented. A penetration test report is an input to that loop. On its own it is not the control.
The management system is the thing being certified
This is the most common misread of ISO 27001. Certification is of your management system, so an auditor's attention goes to records, decisions and review, not to a clean test result.
A company with a modest number of open findings and a documented, working remediation process is in a stronger position than a company with a spotless report and no record of how it got there. The second one cannot show the system works.
Risk assessment decides the scope
ISO 27001 is risk-driven: your risk assessment determines which controls apply and how far they go. So the scope of a test should fall out of your risk assessment rather than being chosen first.
If your risk assessment identifies the customer-facing application as your highest exposure and you test an internal tool instead, the test is not wrong but it is not responsive to your own documented risk. Auditors notice that gap.
Using a test report as ISO 27001 evidence
For the report to be useful evidence it has to connect to your process, which means a few specific things about the deliverable.
- It is dated, and the date falls inside the period under audit
- The scope is stated, and matches what your risk assessment identified
- Findings are ranked, so your risk treatment decisions have something to reference
- Remediation steps are included, so closing a finding is traceable to an action
- A retest exists, so a closed finding is evidenced rather than asserted