How to use application pentest evidence in ISO 27001 work
A pentest report needs context: scope, release, findings, remediation and retesting. Connect those records to the risks and controls in your ISMS.
The cover image is an AI-generated editorial illustration. Screens and documents are illustrative concepts.
A pentest report is one piece of evidence in an ISO 27001 programme. It becomes useful when the organisation can explain what was tested, why that scope matters and what happened to the findings.
ISO/IEC 27001 sets requirements for an information security management system, or ISMS. It does not certify a particular testing product. The suitability of a test depends on the organisation’s risks, selected controls and other obligations.
Start with the application and its boundaries
List the applications within the ISMS scope, their owners and the data they handle. Identify the boundaries a test should examine: customer separation, privileged functions, authentication, APIs and integrations.
Agree permission to test, the target environment, test accounts, permitted actions and stop conditions. Third-party systems require the owner’s authorisation. Access to a SaaS tenant does not automatically permit testing the supplier’s platform.
Document any excluded paths. An auditor or customer needs to understand the limits of the evidence as well as the findings.
Give the testing plan meaningful triggers
Set a schedule proportionate to the risks, with additional testing after significant changes. A new customer-facing API or rewritten authorisation logic may justify a fresh assessment. A retest of one corrected finding does not necessarily cover those changes.
FM’s application pentest offering uses Aikido, with FM reporting. Aikido describes exploitation validation and remediation retesting among its capabilities. Confirm the purchased scope and available automation before promising a test on every release.
Keep the evidence connected
For each assessment, retain:
- The authorised scope, test dates and application version.
- The report, including coverage limitations and findings.
- Remediation tickets with owners and decisions on residual risk.
- Retest results showing whether the relevant issues were corrected.
Store reports securely. Detailed reproduction steps and vulnerable endpoints can be sensitive.
Map the records to the applicable controls in your Statement of Applicability. Security testing during development and acceptance is relevant to Annex A 8.29; vulnerability management and outsourced development may also be relevant. A test report alone does not discharge all of those responsibilities.
Agree expectations before the audit
Ask the certification body what evidence it needs to assess your chosen controls, and check customer contracts for any specific testing requirement. An automated report can contribute evidence; acceptance is not guaranteed by the tool’s branding or a claim that the report is audit-ready.
The strongest preparation is consistency: the testing plan describes a process the organisation actually follows, and the records show how findings changed the application.
