ISO 27001 Pentesting: Is It Required in the UK?

ISO/IEC 27001:2022 does not say that every organisation must buy the same annual penetration test. It requires a risk-based information security management system (ISMS), appropriate risk treatment and evaluation of whether the organisation's controls work.

For many internet-facing, sensitive or business-critical systems, penetration testing is a sensible way to produce that assurance. Whether it is necessary—and how often—depends on the ISMS scope, risk assessment, selected controls, contractual requirements and the system itself.

The ISO overview of ISO/IEC 27001 is the authoritative starting point. Your certification body and auditor should confirm expectations for your certification scope.

Why the answer is risk-based

ISO 27001 is a management-system standard, not a single technical checklist. An organisation is expected to:

• Define its ISMS boundary.
• Understand interested parties and requirements.
• Identify and evaluate information-security risks.
• Select and operate proportionate treatments.
• Monitor, measure and review the system.
• Correct problems and continually improve.

The 2022 edition's Annex A contains 93 reference controls. Technical vulnerability management, secure development, security testing and independent review may all be relevant to a penetration-testing decision, but applicability depends on the organisation's risks and chosen treatment.

Do not copy references from an ISO 27001:2013 article into a 2022 Statement of Applicability. The control structure changed between editions.

When penetration testing is likely to be appropriate

A risk owner should seriously consider testing where the scope includes:

• Internet-facing applications or APIs.
• Systems processing sensitive or regulated information.
• Privileged administration interfaces.
• Complex roles, tenant isolation or workflow authorisation.
• Cloud identity and configuration with material blast radius.
• External or internal network paths to critical assets.
• A major product launch, migration or architecture change.
• A customer contract that requires independent testing.
• Recurring weaknesses or a recent security incident.

A stable, isolated, low-impact system may justify a different assurance method or less frequent testing. Record the reasoning; “we have always done it annually” is not a risk assessment.

What a useful test contributes

Evidence of control effectiveness

Policies and screenshots show design and configuration. A penetration test asks whether a skilled attacker can bypass those controls within an authorised scope.

Validation of technical vulnerabilities

Automated scanning identifies potential known weaknesses. Human testing can reproduce exploitability, explore business logic and combine conditions into an attack path.

Prioritised remediation

A verified finding links a technical condition to an affected asset, prerequisites, evidence, impact and a proportionate fix. That supports risk treatment more directly than an untriaged list of tool alerts.

Independent challenge

An external team can test assumptions that internal teams have normalised. Independence does not eliminate the need for context: product owners and engineers should still support scope and debrief.

Choose the right scope

The test scope should trace back to the risk assessment and system boundaries.

Web applications and APIs

Include relevant roles, workflows, authentication, integrations and environments—not just URLs. Coordinate web and API testing where the frontend depends on exposed backend services.

Cloud

A cloud penetration test may cover identity, privilege paths, configuration and selected services. Define accounts, subscriptions, regions, responsibilities and provider testing rules.

Networks and identity

Network testing may examine external exposure, internal segmentation and directory attack paths. State whether the assessment begins outside, from a standard user position or from an assumed breach.

Mobile

A mobile application test should account for app builds, local storage, platform behaviour, certificate handling and backend APIs.

Evidence to retain for the ISMS

Keep more than the final PDF:

1. The risk or assurance reason for commissioning the test.
2. Approved proposal, scope and rules of engagement.
3. Asset owner and accountable business contact.
4. Tester or provider selection rationale and relevant competence.
5. Dates, methodology and limitations.
6. Original findings and severity rationale.
7. Finding owners and remediation decisions.
8. Accepted-risk records where applicable.
9. Retest evidence and final status.
10. Lessons that changed standards, training, architecture or development practice.

This creates a traceable line from identified risk to assurance, action and improvement.

How often should testing happen?

Use an annual test as a possible baseline, not an automatic answer. Increase or trigger testing when:

• Critical systems change frequently.
• New authentication or authorisation logic is introduced.
• A cloud or network boundary changes.
• Sensitive workflows or integrations launch.
• A contract names a testing interval.
• Previous findings suggest systemic weakness.
• An incident changes the risk picture.

Our guide to penetration-testing frequency provides a practical scheduling model.

Pentestly's delivery model

Pentestly combines bespoke AI testing agents with an in-house human testing team. AI assists exploration and repeatable coverage; testers retain control of authorised actions, reproduce suspected issues, assess context and approve every reported finding.

Clients can follow the engagement, discuss findings, assign remediation work and request retesting through the portal. Reports state scope and limitations so they can support an assurance programme without overstating what the test proves.

Common audit and testing mistakes

• Claiming ISO 27001 requires exactly one annual pentest for everyone.
• Referring to obsolete 2013 control numbers without checking the certification version.
• Testing a convenient system rather than the critical ISMS risk.
• Omitting roles, APIs or cloud identity from scope.
• Treating scanner output as a completed penetration test.
• Closing a finding without evidence or retesting.
• Filing the report away without feeding lessons into the ISMS.
• Saying the penetration test “certifies” compliance.

FAQs

Does ISO 27001 require penetration testing?

ISO 27001:2022 does not prescribe one universal penetration test or annual frequency for every organisation. The organisation must assess risk, select appropriate controls and evaluate whether security controls are effective. Penetration testing is often a proportionate way to provide technical assurance for exposed or critical systems.

How often should penetration testing be performed for ISO 27001?

Set the interval through risk assessment, system criticality, change frequency, contractual commitments and previous findings. Many organisations use an annual baseline and add tests after material changes, but that is an operating choice rather than one blanket ISO 27001 rule.

What penetration-testing evidence may support an ISO 27001 audit?

Useful evidence can include the risk rationale, approved scope and rules of engagement, tester competence, final report, finding ownership, remediation records, accepted-risk decisions, retest results and evidence that recurring root causes feed into improvement work.

Does a clean report prove compliance?

No. A penetration test covers an agreed scope during a defined period and has limitations. ISO 27001 evaluates the wider management system and applicable controls. A test is one evidence source within that programme.

If an audit, customer commitment or material release is driving your deadline, speak to Pentestly about the appropriate scope and reporting timeline.