← Back to blog

ISO 27001 Penetration Testing: What Auditors Expect

NIMR Security Team
ISO 27001compliancepenetration testingVAPT

ISO 27001 does not have a checkbox that says "penetration test once a year." In practice, however, a properly scoped VAPT is the evidence most certification audits expect when evaluating whether your technical controls actually work. This post covers what the standard requires and how to scope testing that satisfies both auditors and your security team.

What ISO 27001 actually requires

Two parts of ISO 27001:2022 drive penetration testing:

  • Annex A control 8.8 (management of technical vulnerabilities) requires vulnerabilities to be obtained, evaluated, and acted on.
  • Clause 9.1 requires the organization to monitor, measure, and evaluate the effectiveness of its controls.

Penetration testing is how most organizations demonstrate that the controls protecting their systems hold up under attack-like conditions. ISO 27002's guidance for control 8.8 explicitly mentions testing, including penetration testing, as part of vulnerability management. Auditors also look for testing evidence under controls covering secure development, change management, and operations.

The standard does not mandate annual testing by name. Scope and frequency are risk-based, which means you get to decide, and you need to be able to justify your decision.

Scoping a VAPT that satisfies the control

  • Align scope with the ISMS. Test the systems declared in scope for certification: internet-facing applications, APIs, network perimeter, and anything processing personal data.
  • Choose a risk-based frequency. At minimum, test annually. Add testing after significant changes, new product launches, or infrastructure migrations.
  • Combine scans with pentests. Monthly or quarterly vulnerability scans satisfy the continuous obligation under control 8.8; an annual penetration test provides the depth clause 9.1 expects.
  • Document everything. Scope, dates, testers, methodology, findings, and remediation decisions. Documentation is what the auditor reviews.

What auditors look for in the evidence

  • A defined testing policy or process that states what is tested and how often.
  • Records of each engagement: scope, dates, testers, and methodology.
  • A findings register linked to the ISMS risk assessment, with treatment decisions for each finding.
  • Evidence of remediation and retest, not just a report with open items.
  • Records showing tester independence from the teams that built the systems.
  • A retained copy of each report with the risk treatment decisions attached.
  • Proof that results fed back into the risk assessment and improvement process.

Auditors rarely want to read every finding. They want to see the loop closed: identified, assessed, treated, verified.

How testing fits the certification timeline

Certification typically runs through a stage 1 audit (documentation review) and a stage 2 audit (on-site effectiveness check). Testing evidence matters at both. Stage 1 verifies the process exists: a policy that defines scope, frequency, and responsibility. Stage 2 checks execution: records showing the tests happened, findings were assessed, and fixes were verified.

Plan the first penetration test before stage 2, not after. Auditors will ask what happened with the results, and a test performed a few weeks before the audit, with remediation and retest already documented, is far stronger evidence than a report dated after the audit raised issues.

After certification, treat testing as recurring. Renewal audits expect the cycle to continue: scan, test, treat, retest.

Beyond ISO: NIST and GDPR

If you also answer to NIST frameworks or GDPR, the testing requirement shows up again. The NIST CSF identifies vulnerability management and penetration testing under its Protect and Detect functions, and GDPR Article 32 requires appropriate technical and organizational measures to ensure the security of processing, including regular testing of their effectiveness. The good news is that one well-documented testing program with a clear risk-based scope satisfies all three. Map the same evidence to each framework instead of running separate engagements.

Common mistakes

  • Treating a vulnerability scan as a penetration test. Auditors and assessors can tell, and the gap shows up when they ask what was manually tested.
  • No retest. Findings stay open or "fixed" without verification, and the evidence trail ends.
  • Testing out-of-scope systems. Results that do not map to the ISMS statement of applicability are hard to present as control evidence.
  • Orphaned findings. Vulnerabilities that never reach the risk register disappear from the audit trail.

Takeaways

  • Map pentest scope to the systems in your ISMS statement of applicability.
  • Run scans continuously; test in depth annually and after significant changes.
  • Close the loop: findings to risk treatment to retest to evidence.
  • Get a report format your auditor accepts: scope, methodology, findings, and remediation.

NIMR's penetration testing and VAPT services are aligned with ISO 27001, NIST, and GDPR controls, and our reporting maps every finding back to the control it affects. Request an assessment or review our penetration testing cost guidance before budgeting.