Penetration Testing for ISO 27001: Evidence for Annex A 8.8 and 8.29

Plenty of UK organisations go into their first ISO/IEC 27001 audit unsure whether they need a penetration test at all. The standard never says "pentest", so some teams skip it, and others buy the largest test they can afford and hope it covers everything. Neither approach is ideal. This resource explains which 2022 controls a penetration test supports, how to scope one for a UK certification audit and how to decide how often to repeat it.

What the two controls actually ask for

Annex A 8.8 is about knowing which technical vulnerabilities affect your systems, judging how exposed you are and taking suitable action in good time. It covers the full cycle: identify, evaluate, treat and confirm. Patch management and scanning sit here, but so does any activity that reveals weaknesses a scanner would not report.

Annex A 8.29 asks you to define and carry out security testing during development and before systems or significant changes are accepted into live use. For software teams this means security checks in the release process. For organisations that buy systems, it means testing new platforms before go-live rather than after.

Neither control prescribes a method. That flexibility is deliberate: the standard expects your risk assessment to drive the choice. Your auditor will look for a method that fits your risks, carried out as your own policy describes, with results that feed back into action.

How a penetration test supports Annex A 8.8

Scanners find known issues in software versions and settings. A penetration test adds the weaknesses that only a person can confirm: broken access control between users, flawed business logic, risky combinations of minor issues, and identity paths in Active Directory or the cloud. For 8.8, the test shows three things an auditor cares about:

• Identification beyond the obvious. Your vulnerability process reaches past automated tooling into the weaknesses that matter most.
• Evaluation. Each finding has a severity, an explanation of impact and a link to the affected asset, so you can show how you judged exposure.
• Treatment and confirmation. Fixes are tracked to completion and a retest proves they worked. Accepted risks are recorded with a reason and an owner.

The last point is where many organisations fall short. A report with open findings and no record of what happened next shows that you identified problems, not that you managed them.

How testing supports Annex A 8.29

For 8.29, timing matters as much as content. A test run just before a major release, or before a new system goes live, is direct evidence of security testing at acceptance. Teams that release often can combine automated checks in the pipeline with manual testing of significant features, through a continuous pentesting arrangement or targeted tests tied to milestones.

Keep the paper trail simple: the change or release, the test that covered it, the findings, and the decision to accept the system into live use once critical issues were dealt with. A secure code review can add evidence for in-house development, because it shows checks happening before code ships.

Scoping a test for a UK certification audit

Start from your ISMS scope statement and risk assessment rather than from a list of every server. The aim is a test that covers the assets carrying the highest risk inside the certified scope, with a written reason for what is in and out.

1. List the systems inside the ISMS scope that handle the information you are protecting: customer-facing applications, APIs, cloud accounts, identity services and remote access.
2. Rank them by risk using the same method as your risk assessment, so the test plan and the risk register agree with each other.
3. Choose test types to match. A SaaS company might pick a web application and API test plus a cloud review. An office-based firm might prioritise external and Active Directory testing.
4. Allow time for fixes before the audit. Schedule testing several weeks ahead, so critical and high findings can be fixed and retested before the auditor arrives.
5. Record the rationale. A short note explaining why these systems were chosen answers the most likely audit question before it is asked.

Before any testing begins, make sure someone with the authority to approve it signs written authorisation. In the UK this keeps the work clearly within the Computer Misuse Act 1990, and auditors sometimes ask to see it. Our guide to scoping a penetration test covers the wider worksheet.

How often to test

The standard leaves frequency to you, so the answer has to come from your risk assessment. In practice, most UK organisations settle on an annual test of their highest-risk systems plus a test after significant change, such as a new customer platform, a cloud migration or a rebuilt login flow. Write that rule into your policy, define what counts as significant, and follow it. An auditor is far more comfortable with a modest cadence you keep than an ambitious one you miss. The pentest frequency resource sets out a tiered approach.

What auditors tend to check in the report

Auditors are not usually security testers, so they look for clear signs of a controlled process rather than technical depth alone:

• Dates, scope and method stated plainly, and matching what your policy says should be tested.
• Findings rated consistently, for example with CVSS 4.0, and adjusted for business context.
• Evidence that someone owns each finding and a target date for fixing it.
• A retest or other verification showing fixes worked, plus recorded reasons for any accepted risk.
• Results fed into management review or the risk register, not filed and forgotten.

Common mistakes

• Testing outside the certified scope while leaving in-scope systems untested.
• Booking the test too late, so the auditor sees a fresh report full of open findings.
• Relying only on automated scans to evidence a control that is meant to catch serious weaknesses.
• No retest, leaving no proof that treatment worked.
• Assuming the provider's credentials matter more than the evidence. We don't claim ISO 27001 certification ourselves; what matters to your audit is a sound method and a clear record.

Where ISO 27001 overlaps other UK duties

One well-planned test can serve several purposes. UK GDPR Article 32 expects a process for regularly testing and evaluating security measures that protect personal data. If you take card payments, PCI DSS v4.0.1 Requirement 11.4 adds annual internal and external tests and segmentation checks. Plan the scope once, label each finding with the requirement it supports, and keep a single remediation record that every assessor can follow. Our compliance pentesting service is built around that approach.

Frequently asked questions

Preparing for certification or a surveillance audit? Estimate the work with the cost calculator or ask for a fixed GBP proposal.