NexusSec.It is one of the most common questions from businesses preparing for certification, and the honest answer is more useful than a yes or no. Here is what the standard asks for, what auditors usually want to see, and where a penetration test fits.
What the standard actually says
ISO/IEC 27001 sets the requirements for an information security management system (ISMS). It asks you to assess and treat information security risks, and its Annex A lists the controls you consider when you do. You decide which controls apply and record that in your Statement of Applicability. Nothing in the standard says "you must run a penetration test".
Two Annex A controls in the 2022 version are where testing comes in:
- 8.8 Management of technical vulnerabilities. Get information about technical vulnerabilities in the systems you use, evaluate your exposure, and take appropriate action.
- 8.29 Security testing in development and acceptance. Define and carry out security testing when new or changed systems are developed or accepted, before they go into production.
Both controls are about outcomes. The standard leaves the method to you, as long as it fits your risks and you can show that it works.
What auditors usually ask for
- A documented process: how vulnerabilities are found, rated, fixed and tracked, and who is responsible.
- Evidence that the process runs: recent scan or test results, not just a policy.
- Evidence of follow-through: findings with owners and dates, and proof that serious ones were closed, such as a retest.
- Testing tied to change: what was tested before a new application, firewall or major system went live.
An auditor will often ask when your last independent test was and what happened to its findings. Having the report and the retest to hand makes that conversation short.
Where VAPT fits
A vulnerability scan shows known weaknesses but not whether they can be exploited. A penetration test confirms which findings are real and what an attacker could reach. Together, as a VAPT, they give you evidence for 8.8, and for 8.29 when the scope includes a new application or system before it goes live. Our guide to VAPT vs vulnerability scanning explains the difference.
How often to test
The standard does not fix a frequency. Base it on risk and change: at least once a year for most businesses, and again after a significant change such as a new internet-facing application, a firewall replacement or a cloud migration. Write the frequency into your vulnerability management procedure so the auditor can check that you followed it.
Making the report useful for certification
- Agree the test scope with your ISMS scope in mind: the systems that hold or process the information you are certifying.
- Ask for findings rated by risk, with clear remediation steps, so they can go straight into your risk treatment plan.
- Keep the original report and the retest together as evidence.
- Record any decision to accept a risk instead of fixing it, with who approved it and why.
Common mistakes
- Testing a month before the audit and leaving no time to fix the findings.
- Testing systems outside the ISMS scope while missing the ones inside it.
- Treating a scanner export as a penetration test.
- Fixing findings without recording it, so there is no evidence the process works.
Our GRC and compliance work covers the wider ISMS, and the VAPT service covers the testing itself.
