ISO 27001 Penetration Testing: Scope, Evidence and Remediation

Direct answer: ISO 27001 does not make one identical penetration-test schedule mandatory for every organisation. Penetration testing can support technical-vulnerability management and security assurance when its scope, timing and depth follow risk. Useful evidence includes authorization, rules of engagement, asset coverage, results, remediation decisions and verified retesting.

In ISO/IEC 27001:2022, penetration testing may support Annex A controls including 8.8 for management of technical vulnerabilities and 8.29 for security testing in development and acceptance. It may also test network security, secure configuration, access controls and monitoring.

This article provides AuditPrepared guidance and does not reproduce the standard. The organisation should determine testing needs through its risks, obligations, system changes and Statement of Applicability.

Know what penetration testing can prove

A penetration test attempts to demonstrate feasible attack paths under agreed conditions. It differs from automated vulnerability scanning, which identifies potential weaknesses at scale but may not prove whether they can be combined or exploited.

Penetration testing can help answer:

• Can an external or internal actor reach a protected asset?
• Can several modest weaknesses be combined into material impact?
• Do access boundaries, segmentation and monitoring behave as designed?
• Can a user exceed the privileges assigned to their role?
• Does a corrected weakness remain exploitable?

It cannot prove that no vulnerability exists. Results reflect the scope, time, techniques, access and system state tested.

The NIST SP 800-115 technical guide provides authoritative recommendations for planning and conducting security tests and assessments.

Trigger tests through risk, not habit alone

An annual test may be useful, but frequency alone is weak assurance. Define event-based triggers such as:

• a new internet-facing service;
• material architecture, identity or network change;
• major application release;
• new sensitive information or customer population;
• acquisition or migration;
• threat intelligence relevant to the technology;
• serious incident or repeated control failure;
• supplier change affecting trust boundaries; or
• contractual or regulatory requirement.

Use periodic testing to address accumulated change and event-based testing for significant new exposure. Record why the chosen timing is proportionate.

Build a scope from attack paths

Start with service and information flows rather than a list of IP addresses. Identify:

• business services and high-impact outcomes;
• internet, partner, user and administrative entry points;
• identity providers and privilege boundaries;
• applications, APIs, mobile clients and cloud resources;
• network zones and remote-access paths;
• suppliers and shared responsibilities;
• excluded assets and the reason for exclusion; and
• production constraints or sensitive operations.

Include authenticated and unauthenticated perspectives where relevant. A test of the public interface alone may miss excessive internal privilege, flawed workflows or exposed administrative functions.

Link the scope to the ISO 27001 threat and vulnerability catalogue guide so likely attack scenarios inform the test without turning the catalogue into a substitute for risk analysis.

Authorize the work precisely

Penetration activity can disrupt services, trigger monitoring and affect third parties. Obtain written authorization before testing. Rules of engagement should cover:

• systems, addresses, tenants and locations in scope;
• permitted and prohibited techniques;
• testing window and rate limits;
• treatment of production data;
• social engineering or physical activity, if any;
• stop conditions and emergency contacts;
• evidence collection, encryption and retention;
• tester access and background requirements;
• notification to hosting or managed-service providers; and
• incident-response coordination.

Confirm that the authorizer has authority over every target. Supplier or cloud terms may require advance notification even when the organisation owns the workload.

Select a method that matches the objective

Testing knowledge may be:

• external or limited knowledge: simulates an actor with little internal information;
• credentialed: examines what a legitimate or compromised user can reach; or
• collaborative: uses architecture and source information to examine controls deeply.

One method is not universally stronger. A limited-knowledge test can assess exposed attack paths, while collaborative testing may find design flaws more efficiently. Use multiple perspectives for critical services when the risk justifies it.

Define success and coverage measures before work begins. Counting findings alone can reward shallow testing. Better evidence explains tested attack paths, methods, limits and control outcomes.

Protect operations and evidence

Agree how testers will handle credentials, sensitive records, screenshots, traffic captures and proof-of-concept code. Minimize extraction of real data; demonstrate access with the least harmful evidence possible.

Use named test accounts and log the activity. Coordinate with the monitoring team without making every alert predictable. When an exercise also evaluates detection, record which participants know the schedule and how accidental escalation will be avoided.

Store reports and evidence as sensitive information. They may describe attack paths that remain useful after individual findings are fixed.

Turn findings into risk decisions

Do not accept the tester’s severity rating without business context. Evaluate:

• exploit preconditions and required access;
• asset exposure and information sensitivity;
• plausible business impact;
• attack complexity and reliability;
• existing prevention, detection and recovery measures;
• evidence of active exploitation; and
• dependency or supplier constraints.

The risk score calculator can support consistent discussion, while the organisation’s approved risk method controls prioritization and acceptance.

Every material finding should have an owner, treatment, due date and status. Options may include correction, configuration change, architectural redesign, isolation, removal, compensating monitoring or authorized risk acceptance.

Retest the outcome, not just the patch

Retesting should demonstrate that the original attack path is closed and that the correction did not create another weakness. Preserve:

• the original finding and affected assets;
• implemented change;
• retest method and date;
• result and evidence;
• residual limitations; and
• authorization to close or retain the risk.

For combined attack paths, correcting one component may be enough to block exploitation, but remaining weaknesses still need separate decisions. Connect remediation to the change-management guide.

Integrate testing with the control system

Testing is most valuable when findings influence more than one asset. Feed lessons into:

• secure engineering principles;
• application and infrastructure baselines;
• coding and review practices;
• supplier requirements;
• monitoring use cases;
• awareness for relevant roles; and
• risk and audit programmes.

A repeated class of finding is evidence of a systemic weakness even if every individual instance is eventually closed.

Preserve design and operating evidence

Design evidence

• risk-based testing policy and triggers;
• scope and authorization process;
• tester competence and independence criteria;
• rules-of-engagement requirements;
• severity and remediation method;
• evidence protection and retention; and
• exception and risk-acceptance authority.

Operating evidence

• approved scope and authorization;
• tester qualifications and conflicts review;
• activity and communication records;
• final report with scope limitations;
• finding ownership and treatment;
• change and retest evidence;
• accepted residual risk; and
• lessons applied to wider controls.

Trace a worked example

A software company prepares to release a new customer API. The scope includes the gateway, application roles, object authorization, administrative interface and logging. The payment provider is excluded because testing it requires separate authorization; the interface and the company’s own configuration remain in scope.

Credentialed testing shows that a support role can retrieve another customer’s record by changing an identifier. Monitoring records the request but does not alert. The application owner corrects object authorization, and the security team adds a use case for repeated denied access.

Retesting confirms the unauthorized request fails, ordinary support work still functions and the new monitoring rule produces a triaged alert. The finding closes with application and detection evidence, while the development team updates its reusable authorization tests.

Audit a testing programme

Select tests across different services, triggers and providers. Include a test with serious findings and one constrained by exclusions. For each sample:

1. compare scope with service risk and architecture;
2. inspect authorization and third-party permission;
3. assess tester competence and independence;
4. verify limitations are explicit;
5. trace findings to risk-based decisions;
6. inspect remediation and retest evidence;
7. evaluate overdue or accepted findings; and
8. confirm systemic lessons were considered.

Use the Annex A control lookup to identify related controls without treating the tool as a substitute for licensed requirements.

Result	Example
Pass	Scope follows risk, testing is authorized, results are owned and material corrections are independently retested.
Partial	Testing occurs regularly, but exclusions, risk decisions or retest evidence are inconsistent.
Fail	Reports are filed without remediation, targets lack authorization or material services are repeatedly omitted without justification.

Common questions

Does certification require an annual penetration test?

ISO 27001 requires the organisation to implement applicable controls based on risk; it does not impose one universal penetration-test interval for every system. Other laws or contracts may set specific frequencies.

Should production systems be tested?

Production testing can reveal realistic conditions but creates operational and data risk. Decide based on risk, authorization and safeguards. Some techniques may be limited to controlled environments.

Can a vulnerability scan replace a penetration test?

They answer different questions. Scanning provides broad identification; penetration testing can explore exploitability and combined attack paths. Use each where it adds proportionate assurance.

Make findings change the system

Penetration testing creates value only when scope reflects meaningful attack paths and results lead to controlled decisions. Authorize carefully, protect evidence, assign remediation and retest outcomes so the exercise strengthens the wider ISMS.