Does ISO 27001 Require Penetration Testing?

If your organisation is working towards ISO/IEC 27001 certification, you may have been told that you need an annual penetration test. The reality is slightly more nuanced.

ISO 27001 does not contain a simple rule stating that every organisation must commission a penetration test once a year. Instead, it requires organisations to understand their information security risks, introduce appropriate controls and demonstrate that those controls are working effectively.

For many organisations, particularly those operating internet-facing systems, cloud services, web applications or important internal networks, penetration testing is one of the most useful ways to provide that assurance.

What does ISO 27001 actually require?

ISO/IEC 27001 is the international standard for establishing, implementing, maintaining and continually improving an Information Security Management System, usually called an ISMS.

The standard is risk-based. This means an organisation should not simply work through a generic technical checklist. It must identify the risks that apply to its own systems, information, customers and operations, then decide how those risks will be treated.

A small professional services firm using Microsoft 365 will not necessarily require the same testing programme as a software company operating a customer-facing platform. Both organisations, however, must be able to explain their decisions and provide evidence that their controls are appropriate.

Which ISO 27001 controls are relevant to penetration testing?

Penetration testing can support several areas of ISO/IEC 27001, but two Annex A controls are especially relevant.

A.8.8: Management of technical vulnerabilities

This control concerns identifying technical vulnerabilities, evaluating the organisation’s exposure and taking appropriate action.

Routine vulnerability scanning can play an important part in this process. It can identify missing patches, outdated software and common configuration weaknesses across a large number of systems.

However, a vulnerability scan and a penetration test are not the same thing. A penetration test introduces skilled human analysis to investigate whether weaknesses can be exploited, combined or used to reach sensitive systems and information.

For example, a scanner might identify an exposed service or weak configuration. A penetration tester may establish whether it can be used to gain unauthorised access, obtain credentials or move further into the environment.

A.8.29: Security testing in development and acceptance

This control is particularly relevant to organisations that develop applications, APIs or other systems. Security should be tested during development and before new systems or significant changes are accepted into service.

Automated code and vulnerability scanning can contribute to that testing, but they may not identify weaknesses involving business logic, user permissions, authentication or the way several components interact. A web application or API penetration test can provide much stronger evidence in these areas.

Penetration testing may also contribute to the wider ISO 27001 requirements for risk treatment, monitoring, measurement and evaluating whether security controls remain effective.

Will an ISO 27001 auditor expect to see a penetration test?

There is no universal answer because the expectation should depend on risk, scope and the controls included in the organisation’s Statement of Applicability.

An auditor is more likely to expect evidence of penetration testing where an organisation:

• Operates internet-facing servers, firewalls or remote-access services
• Provides a web application, SaaS platform or API
• Processes sensitive personal, financial or customer information
• Uses an important Active Directory environment
• Provides cloud, technology or managed services
• Has identified system compromise as a significant risk
• Has promised customers that regular testing takes place
• Includes penetration testing within its own policies or control procedures

If penetration testing has not been performed, the organisation may need to demonstrate how it has evaluated its exposure through other measures. The decision should be supported by a credible risk assessment, not simply by stating that the standard does not explicitly demand a test.

How often should penetration testing be carried out?

ISO 27001 does not prescribe a fixed testing frequency. For many organisations, annual testing provides a sensible baseline, but the schedule should reflect the rate of change and the level of risk.

Testing should also be considered:

• Following a major infrastructure or cloud migration
• Before launching an important new application or service
• After substantial changes to an application, API or network
• Following a security incident
• When new threats materially change the organisation’s risk
• When required by a customer, tender, insurer or regulator

A relatively stable external network may be suitable for annual testing plus testing after significant changes. A software provider releasing new functionality every week may need a more frequent and development-led approach.

The important point is that the organisation can explain why its chosen frequency is proportionate.

What should the penetration test cover?

The scope should be guided by the ISMS, the risk assessment and the systems that matter to the business. Depending on the organisation, this could include:

• External infrastructure, including public IP addresses, VPNs and firewalls
• Internal infrastructure and Active Directory
• Web applications and customer portals
• APIs used by web and mobile applications
• Cloud platforms and Microsoft 365 configurations
• Wireless networks
• Mobile applications

Testing everything every year may not be necessary or affordable. A risk-based programme can rotate different areas while ensuring that the most exposed or business-critical systems receive suitable attention.

What evidence should be retained?

Commissioning a penetration test is only part of the process. An auditor will usually be more interested in what the organisation did with the results.

Useful evidence includes:

• A documented scope and authorisation for the test
• Evidence that a suitably competent provider was selected
• The final penetration-testing report
• Findings recorded within the vulnerability or risk-management process
• Agreed owners and target dates for remediation
• Evidence that corrective work was completed
• Retest results confirming that weaknesses were addressed
• Formal acceptance and approval of any remaining risk

Leaving serious findings unresolved without a documented decision is unlikely to demonstrate effective risk management. The report should feed into a managed remediation process rather than being filed away until the next audit.

Does the testing provider need to hold a particular accreditation?

ISO 27001 does not universally require the penetration-testing company to hold one specific accreditation. The organisation should, however, demonstrate that it selected a competent supplier.

Relevant considerations include recognised technical qualifications, professional registrations, appropriate insurance, secure handling of test data, a clear methodology and experience with the technology being assessed.

For most private-sector ISO 27001 projects, an NCSC CHECK provider is not mandatory. CHECK is intended for appropriately scoped testing of UK government, public-sector and critical national infrastructure systems where that assurance is required.

Penetration testing should support the ISMS, not just the audit

The strongest reason to commission a penetration test is not simply to satisfy an auditor. It is to discover weaknesses before they are found and exploited by somebody else.

A properly scoped test can show whether security controls work together in practice, distinguish genuinely exploitable weaknesses from background noise and provide clear remediation priorities. The results can then inform the risk register, improvement plan and future security investment.

ISO 27001 may not impose a blanket annual penetration-testing rule, but it does require organisations to understand and manage their risks. Where important systems could be attacked, independent penetration testing is often one of the clearest and most defensible ways to demonstrate that this is being done effectively.

How Plainsight Security can help

Plainsight Security provides independent external infrastructure, internal infrastructure and web application penetration testing for organisations working towards or maintaining ISO 27001 certification.

We agree a proportionate scope based on your environment and objectives, conduct the assessment safely and provide a clear report containing prioritised, practical remediation advice. Retesting can then confirm that identified weaknesses have been successfully addressed.

If you are unsure what should be tested, we can help define a suitable scope without turning the exercise into a larger engagement than your risks require.