ISO 27001 Pen Testing Controls and What Auditors Examine

ISO 27001 pen testing proves that security controls work. The standard’s requirements make an exploit-backed test the most defensible evidence path. The decisive proof is the closed loop from finding to risk register, treatment, remediation, retest, and management review.

Why ISO 27001 never says "penetration test" yet auditors expect one anyway

The short answer to “does ISO 27001 require a pen test” is technically no, practically yes. ISO 27001 deliberately defines outcomes rather than prescribing the method for achieving them. Clause 9.1 requires an organization to evaluate whether its controls operate effectively, so showing that a control exists is not enough.

At Stage 2, auditors therefore ask how the organization established that its technical controls withstand attack. A patch report shows that maintenance happened. It does not establish whether an attacker can still reach sensitive information through another weakness or a chain of weaknesses. Auditors rely on industry practice where the standard leaves the method open, so they usually expect a documented penetration test.

The three controls that make pen testing the most defensible evidence path

Annex A 8.8, Management of technical vulnerabilities, requires timely identification, evaluation, and remediation of vulnerabilities in systems in use. Information can come from CVE feeds and vendor advisories, but also from active scanning and penetration testing. A policy is not proof of execution. Timestamped test reports and remediation records show that work took place, and annual penetration testing is widely accepted as the least that should be done for production systems that handle sensitive information, with more testing after significant changes.

Annex A 8.29, Security testing in development and acceptance, moves the obligation into the software delivery process. It requires established testing programmes and criteria, with acceptance tests planned, documented, and executed. Its guidance explicitly calls for penetration tests to identify weak coding and design. For software-producing organizations, application and API tests and pipeline security gates address this requirement before deployment, rather than leaving security validation to an annual production test.

Clause 9.1, Monitoring, measurement, analysis, and evaluation, asks whether those controls perform as intended, an effectiveness test teams often overlook. A scoped penetration test with findings and remediation evidence answers it more directly than implementation records alone. Clause 10.2, continual improvement, adds the expectation that the information security management system, or ISMS, learns from the results.

The Statement of Applicability, or SoA, determines which Annex A controls apply. An auditor is likely to question a decision to exclude 8.8 or 8.29 without a strong reason. The transition deadline for the 2022 revision has also passed, so evidence and risk registers still using 2013 control numbers signal a stale evidence trail.

Why vulnerability scanning cannot close the evidence gap these controls create

Vulnerability scanning identifies known CVEs and misconfigurations through automated detection. It does not prove exploitation, link weaknesses into attack paths, or test business logic as it would face an attack. A penetration test attempts exploitation and shows how a weakness affects the specific business.

When preparing for an audit, this difference matters most if the ISMS policy promises annual penetration testing by a qualified third party. The auditor holds the organization to that wording. Scanner output cannot demonstrate that the promised test occurred, regardless of how many vulnerabilities it lists. Acceptance of scans in place of penetration testing reflects auditor leniency.

Scans still support the monitoring programme, with quarterly scanning for standard systems and monthly scanning for internet-facing systems. The test report must then show its work through reproduction steps and proof-of-concept evidence. A report that merely lists suspected weaknesses leaves the same central question unanswered, because an unreproducible assertion does not prove that a control failed.

What whitebox access changes about coverage and audit credibility

Black-box testing gives the tester public target details and rules of engagement, so the tester can check external exposure and ways to gain an initial foothold. Discovery consumes time that could otherwise go into deeper testing. Authenticated workflows and their business-logic flaws remain largely out of view. That makes black-box testing a strong answer to one question, but not a complete assessment of a SaaS environment.

Grey-box testing adds user accounts, API documentation, and some details about the architecture. It exposes role separation, tenant isolation, and business logic to realistic attack attempts. These are central risks for SaaS products. Grey-box testing is therefore the dominant choice for compliance evidence, balancing authenticated depth with a scope an auditor can evaluate.

Whitebox testing adds source code, architecture diagrams, configurations, credentials, and build context. This supports code-to-runtime validation and reveals paths that external testing cannot reach, including hardcoded secrets, insecure deserialization in internal services, and server-side request forgery, or SSRF, paths to cloud metadata endpoints. Access changes what the tester can establish. For an ISMS covering both SaaS and cloud infrastructure, whitebox access provides the most defensible basis for broad coverage.

Even so, each method answers different questions and leaves blind spots the others can address. The choice follows the ISMS boundary and risk treatment priorities. If the SoA includes a customer portal and an internal HR system, a deep portal test still leaves the HR system unassessed.

The six-item evidence set auditors request at Stage 2

Clause 7.5 requires documented information, and the Stage 2 evidence set turns that obligation into six concrete checks. The first is methodology and tester identity. Formal certification evidence calls for a tester independent of whoever built the system, with a description of manual testing. Alignment with a recognized standard such as OWASP ASVS gives the auditor a basis for assessing coverage.

The second check is findings with severity ratings and risk evaluation. CVSS scores provide a severity framework, but each finding also needs evaluation in the organization’s environment. A score alone lacks the business context. Without that context, the report does not clearly explain how the finding belongs in the risk register.

The third check is proof of exploitation. Screenshots, reproduction steps, and working exploit evidence substantiate the finding and justify its severity. Assertions are not a substitute for demonstrated results. Without proof-of-concept evidence, the auditor cannot assess the report as evidence of active testing.

The fourth check is remediation evidence with named owners and deadlines. Each finding needs a recommendation mapped to the relevant Annex A control, an owner, and a target date under a severity-based service-level agreement, or SLA. Completion dates and ticket references record what was done. Open critical or high-severity findings without documented remediation timelines expose the organization to a nonconformity.

The fifth check is retest evidence that confirms the fixes work. A completed ticket is not that confirmation. Retest closure documentation distinguishes a deployed change from a verified fix, while an old report with unresolved critical findings records that the organization knew about the risk without demonstrating action.

The sixth check is management review records that show the results reached leadership. Engineering activity alone does not demonstrate organizational learning. Auditors also expect a testing schedule in the vulnerability management procedure. Even well-executed ad hoc tests leave a management-system gap when no documented programme governs when testing happens.

How findings must feed back into the ISMS risk register and risk treatment plan

A good test can still leave a broken evidence trail. The common failure is filing the report without formally bringing its findings into the ISMS, creating an evidence gap that is visible at a surveillance audit. Discovery is only the starting point here. Each finding that has been proven and given a severity rating must go into the risk register with the relevant 2022 Annex A control identifier.

The risk treatment plan then records whether the organization will accept, remediate, transfer, or avoid the risk, with an owner and SLA deadline. Where remediation is chosen, the evidence must follow the fix through retesting and closure, with results reaching management review. A missing or wrong mapping can itself produce a nonconformity because the ISMS cannot demonstrate the relationship between the risk and its controls.

That traceability need not become a sprawling paperwork exercise. A single compliance mapping page showing which findings evidence which controls answers the question in nearly every audit. The SoA must also show any control gaps found. If testing exposes a relevant control previously marked not applicable, leaving that exclusion unchanged creates a discrepancy in the management system.

The documented programme should include an annual full penetration test, quarterly vulnerability assessments or monthly scans for internet-facing systems, and targeted retesting after significant changes. Those changes include a new application, a major release, an infrastructure migration, or a security incident. Testing needs to precede Stage 2 by enough time for remediation and retesting. The compliance artifact is not the penetration test report but the closed evidence loop.

What a test scoped for a SaaS-plus-cloud ISMS actually needs to cover

The ISMS boundary determines the assessment programme’s coverage. If the SoA includes the SaaS application, cloud infrastructure, and corporate network, all three need periodic assessment. A portal-only engagement cannot stand for the whole environment. Rotating scope by year is acceptable where a reasonable programme covers the full boundary, but omitted systems cannot simply disappear from the evidence trail.

At the application and API layer, Annex A 8.29 makes pre-production testing directly relevant to services handling personal or sensitive data. Authenticated grey-box or whitebox testing reliably exposes business-logic flaws, authentication weaknesses, broken access control, and tenant isolation failures. Internal call chains also need enough context to assess. In cloud-native microservices, SSRF can expose cloud metadata endpoints, making an apparently local application weakness a path into infrastructure.

At the cloud layer, the tester also needs to check IAM policies, S3 bucket permissions, security group rules, and exposed internal services. Annex A 8.8 addresses these configuration-level vulnerabilities. Whitebox access makes otherwise hidden attack paths assessable. Reading infrastructure-as-code lets the tester see configurations that external scanning cannot reach, including paths an attacker could use after gaining initial access.

The development pipeline and source code complete the scope. Hardcoded API keys or database credentials can provide direct infrastructure access without a complex exploit chain. TruffleHog or Gitleaks can help with pre-commit and CI/CD secrets scanning, and a secrets manager can give applications their credentials through runtime secret injection.

Annex A 8.25, secure development lifecycle, requires findings to feed back into how software is developed, so continuous pull-request scanning is a way to act on that requirement between annual tests. A whitebox engagement covering these layers can consolidate technical findings into one report, with control tags, a compliance mapping page, and retest closure documentation. That reduces duplicate reporting without shrinking the assessment boundary.

How ISO 27001 evidence requirements overlap with SOC 2 and what a single engagement can satisfy

A well-scoped engagement can support both ISO 27001 and SOC 2. SOC 2 CC4.1 presents penetration testing as one way to meet its requirement, together with internal audits, compliance assessments, and vulnerability scans. But if an organization’s control description promises annual third-party penetration testing, it must show that this testing took place.

SOC 2 requires evidence to be packaged and management to respond, while ISO 27001 also requires updates to the risk register, formal corrective actions, and results to feed into management reviews. Running two separate tests does not solve that administrative difference. One engagement scoped to the broader ISO 27001 ISMS boundary can satisfy both when it also covers the SOC 2 commitments.

HIPAA is a proposed-rule consideration here. HHS published a notice of proposed rulemaking on 6 January 2025 that would require penetration testing at least every 12 months. The comment period closed 7 March 2025. The proposal has not been finalized, and final action is targeted for July 2027 at the earliest.

Healthcare organizations already conducting annual ISO 27001-scoped tests are positioned to meet that proposed cadence if finalized. Across these frameworks, a sound methodology lets organizations reuse the technical evidence, though they differ in how it must be packaged and how management must follow through. ISO 27001 demands the most structured feedback loop of the three. Building that loop into one properly scoped engagement avoids redundant testing without treating the report as a substitute for risk management.