ISO 27001 Penetration Testing: Scope and Remediation Evidence

ISO 27001 penetration testing is useful when its results answer a risk-treatment question about the systems your organization manages. Define the information at risk, the control being evaluated, the deployment being tested and the evidence needed after remediation. Your control owner should be able to trace a finding to a remediation action and a repeatable check.

ISO/IEC 27001:2022 defines requirements for an information security management system. Its scope includes organizational processes, people and technology. A technical penetration test examines selected behavior under specified conditions; it cannot, by itself, establish conformity of the entire management system or award certification.

For a SaaS team preparing for a security review, the practical task is to connect its technical assessment to the risk process without overstating what the assessment proves. The following workflow uses a fictional tenant-isolation example and a small evidence record. These are planning recommendations, not a completed penetration test or a prescribed audit template.

Start with a risk-treatment question

A useful question names the information and the unwanted outcome: could an ordinary customer account read another tenant’s private export? That formulation identifies a confidentiality concern and an authorization boundary. It also suggests which identities, records and application functions a test needs. “Scan the website for ISO 27001” leaves those choices unresolved.

ISO/IEC 27005:2022 provides guidance for information security risk management supporting an ISMS, including assessment, treatment, communication, monitoring and review. The operational implication is to give test results a route back to a risk owner and treatment decision. A finding that ends as an isolated PDF does not complete that route.

Ask the control owner what the application is intended to prevent and where that expectation is documented. Name the service owner who can explain exceptions. In a tenant-isolation test, a deliberately shared record may be an allowed case, while a private record with the same response status may expose a defect. The tester needs the intended rule before assigning impact.

Set the assessment interval and change triggers through the organization’s own controls, risk process, contractual commitments and review requirements. Record the rationale. An automated scheduler can execute a chosen interval; its default setting is not the organization’s risk decision. Major identity, tenancy or deployment changes may warrant a different scope from a narrow fix retest.

Translate the question into an authorized test boundary

In the fictional export scenario, prepare two test tenants with harmless synthetic records, an ordinary-user account in each, and an administrative account only if the agreed workflow requires it. Identify the application and API release, export route, background job and storage handoff that belong to the assessment. Use the smallest useful boundary that still answers the risk question.

Document differences between the test environment and the deployment being reviewed. A staging test with a bypassed identity provider or a different authorization configuration cannot silently represent production behavior. The report should explain those limits. For third-party infrastructure, obtain appropriate scope authorization rather than assuming that your customer subscription permits offensive testing of the supplier.

NIST’s security testing and assessment guide connects planning, execution, analysis and mitigation. Keep the authorization and rules of engagement with the technical record. Agree permitted methods, data handling, traffic limits, stop conditions and the operational contact before running the test.

Keep the Statement of Applicability and test evidence distinct

The Statement of Applicability and the pentest report serve different purposes. The ISO/IEC 27001 Auditing Practices Group’s educational note on the SoA discusses documenting necessary controls, inclusion justifications, implementation status and exclusions. The document expressly states that it has not undergone ISO or SC 27 endorsement; use it as explanatory context alongside the applicable standard and your audit process.

For the evidence workflow here, give the organization’s control a stable identifier and link the relevant test to it. Do not rename a scanner category as a control and treat the mapping as proof of implementation. A mapping tells the reviewer where to look. The observation, scope and remediation record determine what the evidence actually supports.

One test may support only a narrow part of a control’s implementation. A successful tenant-isolation check on one export path does not establish the behavior of every API, mobile client or administrative task. Preserve the tested boundary and any related work still pending. The risk owner can then decide whether additional testing or another treatment is needed.

Build an evidence record that survives the handoff

Use one stable finding identifier from the original observation through the remediation ticket and retest. Preserve the relevant request sequence and sanitized response, the acting identity, the resource owner, test date and deployment. Separate observed behavior from potential consequences so a reviewer can challenge the impact without losing the underlying evidence.

OWASP’s reporting guidance recommends clear scope and limitations, business context for leadership, actionable details for engineers and secure handling of sensitive report contents. It also treats an assessment as a point-in-time view. Use those reporting principles to make the evidence understandable rather than exporting unreviewed tool output.

The following JSON illustrates a small organization-defined tracking record. The control code is fictional and is not an ISO Annex A identifier. Paths and tickets are illustrative references, not evidence from a real assessment. Pending states deliberately remain pending until a reviewer has checked the actual artifacts.

{
  "risk_id": "R-17",
  "organization_control": "AUTH-01",
  "finding_id": "PT-04",
  "assessed_deployment": "staging-build-42",
  "evidence_reference": "restricted/PT-04/original-observation",
  "remediation_ticket": "SEC-201",
  "replacement_deployment": null,
  "retest_status": "pending",
  "reviewer_decision": "pending"
}

Keep confidential artifacts in an access-controlled repository and reference them from the record. Do not put live credentials, customer exports or unrestricted evidence URLs into a broadly shared tracker. If evidence is redacted, retain enough context for the authorized reviewer to understand the result and state where the protected original is held.

The value of the record is continuity. If an engineer changes the export worker, a reviewer should be able to locate the affected finding and the replacement deployment without reconstructing a chat session. The schema can fit an existing ticket system; it does not require a new compliance platform.

Separate remediation, retest and risk acceptance

A deployed code change, a successful retest and an accepted residual risk are different states. Record each explicitly. In the fictional example, the developer corrects authorization in the export workflow. The retest then checks that tenant A cannot retrieve B’s private export and that A can still retrieve its own permitted export. A failure of every export request would not demonstrate a working authorization correction.

Recheck relevant variations that belong to the agreed scope: the direct API, a queued export and any sharing exception can make different access decisions. Use synthetic records and approved accounts. If the fix changes architecture or reveals another untested path, make that scope change visible rather than declaring the original finding universally resolved.

If the business accepts a remaining risk, retain the decision, owner, scope, rationale and review date through the organization’s process. Do not rewrite an unresolved technical condition as a passed test to make a report look complete. Conversely, a passed check should identify the version and conditions in which it passed rather than becoming an indefinite assurance statement.

Choose a workflow your control owner can review

When evaluating a testing product or service, ask it to demonstrate one complete evidence handoff on an owned application slice. Can the team identify untested areas, inspect the original observation, assign remediation and record the retest? Establish who operates the assessment and whether the recipient requires an independent assessor. Export format alone does not answer those questions.

For private applications, verify the access and deployment prerequisites before purchasing a larger allowance. Ask how credentials and evidence are handled, which model services receive test context, what retention applies and which private-deployment arrangements are actually offered. Confirm the current supplier terms for your configuration rather than inheriting assumptions from a public demo.

Penligent’s homepage offers a 19-page English sample pentest report with synthetic data, including scope, findings, remediation and retest structure. In its SOC 2 and ISO/IEC 27001 section, choose “Download Sample Pentest Report” and follow the sign-in or free-account step. Use it to discuss the expected evidence format with the intended recipient before evaluating the software against your own authorized scope. It is a sample delivery format, not certification or guaranteed audit acceptance.

A useful risk-treatment record is supported by an understood test: what was assessed, what was observed, what changed, what was rechecked and who reviewed the remainder. Maintain those links as the application changes. They let the next engineering or audit reviewer evaluate the evidence without guessing what a standards label on the cover was intended to mean.