Not by name, as far as the control guides we read show. ISO 27001 controls 8.8 (technical vulnerabilities) and 8.29 (security testing) expect you to find vulnerabilities and test that security requirements are met. A penetration test is one way to produce that evidence. Whether it is right for you depends on your risks and your customers.
What the two controls ask
A public guide to control 8.8, management of technical vulnerabilities, says it requires companies to obtain information about vulnerabilities in their systems, evaluate exposure and define what to do about them. It notes that smaller companies may use assessment tools from time to time while larger ones may need a continuous service. The guide says documentation is recommended but not mandatory.
A guide to control 8.29, security testing in development and acceptance, says it requires a defined testing process to verify that security requirements are implemented in the software as specified. It mentions tools for automating test scripts and generating reports, and acceptance criteria for testing results.
Neither guide describes a mandatory annual penetration test. Read the standard and ask your certification body if you need certainty.
What auditors may look for
| Control | Evidence an auditor may ask about |
|---|---|
| 8.8 | Information about vulnerabilities gathered, exposure evaluated, proper actions taken |
| 8.29 | Software tested against security requirements, with results and acceptance decisions |
Scan reports, tickets, release checks and meeting notes can all serve. A penetration test report adds an outside view that some buyers like to see.
When a penetration test is worth doing
- A customer contract or questionnaire asks for one.
- You release a major feature that changes your attack surface.
- Your risk assessment names a threat that scanning does not cover well, such as business logic abuse.
- You want an independent check on a high value system.
If none apply, regular scanning plus a documented testing process may satisfy the controls. That is a judgement for your risk assessment, and you should record it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding moves from detection to decision, which is the trail control 8.8 is about.
A practical minimum
- Scan dependencies and code on every merge or on a fixed schedule.
- Record each finding with an owner, a decision and a date.
- Define severity based fix targets in a short procedure.
- Test security requirements before release and keep the results.
- Retest after fixes. For wording on evidence after a test, see retest evidence for SOC 2 and questionnaires.
Quick check
Can automated scanning alone satisfy control 8.8?
It can be a core part, together with a process for evaluating and acting on results. Confirm what your auditor expects.
Is a penetration test required for Stage 2?
The control guides we read do not make it a requirement. Customer contracts sometimes do. Check yours.
Safeguard's dependency scanning, reachability analysis and vulnerability management can provide records for these controls. Safeguard does not replace an independent penetration test where one is needed.
Sources
- ISO 27001 control 8.8, management of technical vulnerabilities
- ISO 27001 control 8.29, security testing in development and acceptance
Last reviewed: 19 October 2026.
