Pen test requirement according to ISO/IEC 27001:2022 Annex A: What is really required

ISO/IEC 27001:2022 was published on October 25, 2022; the transition period ends on October 31, 2026 (IAF MD 26). The standard does not mention the term penetration test in the normative part, but requires a technical effectiveness test via Annex A 8.8 (management of technical vulnerabilities), 8.29 (security tests in development and acceptance) and 5.36 (conformity with guidelines). In practice, auditors expect a pen test, vulnerability scan or red team exercise.

Anyone who is confronted with initial ISMS certification or a re-audit is faced with a concrete burden of proof: which test, to what depth, at what frequency, with which report? This article clarifies the legal situation, organises the relevant controls, shows the minimum expectation of reports and describes how CIVAC, as a compliance platform and officer-as-a-service, brings together vulnerability management and audit evidence. The appointment certificate, signed, filed, verifiable.

The normative part of ISO/IEC 27001:2022 does not specify a pen test requirement, but requires monitoring and measurement of information security performance in clause 9.1. This results in the obligation to objectively demonstrate the effectiveness of technical measures. A documented penetration test is the standard industry evidence for this.

Annex A of 27001:2022 has been slimmed down from 114 to 93 controls compared to the 2013 version. Three controls are central to the pen testing discussion: 8.8 (management of technical vulnerabilities), 8.29 (security testing in development and acceptance) and 5.36 (conformity to security policies, rules and standards). All three require verified effectiveness, not just documented intent.

The associated implementation guide ISO/IEC 27002:2022 is clearer here and explicitly names penetration testing as a recognised method. Auditors use 27002 as a design standard, even if it itself is not subject to certification.

In practice, this means: Without a structured vulnerability scan plus regular pen testing, the evidence remains incomplete. A pure service provider report without risk assessment and tracking of measures in the ISMS is not enough.

The obligation is therefore indirect but operationally binding. Anyone who signs the Annex A Declaration of Applicability (SoA) as an Information Security Officer assumes the burden of proof towards the certifier and their own management.

Audit-proof, documented, Annex-A-firm. Technically it is nothing more. Less is not enough.

Control 8.8 (Management of Technical Vulnerabilities) requires a regulated process for identifying, evaluating and dealing with technical vulnerabilities. Vulnerability scanning is the basis, pen testing is the in-depth effectiveness test. The cycle must be documented, including CVSS assessment, person responsible and response period.

Control 8.29 (Security Testing in Development and Acceptance) is aimed at in-house developments and purchased systems before go-live. Pen tests in staging environments, static and dynamic code analysis and acceptance criteria belong here. Anyone who takes software live without a security test is in immediate violation.

Control 5.36 (Compliance with Policies, Rules and Standards) requires regular checking of compliance with internal and external requirements. A pen test is a central mechanism here because it reflects the actual hardening against the declared security guidelines.

In addition, controls 8.16 (monitoring), 8.23 ​​(web filtering) and 8.28 (secure coding) have a flanking effect. Auditors check whether the pen test findings flow back into the risk treatment planning according to clause 6.1.3 and do not disappear in the attachment of an email correspondence.

It is important to ensure consistency with the Statement of Applicability: Anyone who declares Control 8.8 to be applicable must also provide evidence of the process. An excluded applicability (exclusion) is only possible with comprehensible justification.

In practical terms, this means that the service provider's report is just one building block. In addition, scope, approval, risk analysis, treatment plan and review are required.

The market distinguishes between three depth levels. Vulnerability scans (automated, broad, superficial) provide an inventory of known CVE and are scheduled monthly to quarterly. Pen tests (manual, focused, exploit-oriented) check attack paths and are expected at least annually or when there are significant changes.

Red team exercises (scenario-based, multi-week, against a protection target) are the most demanding form and are relevant for regulated sectors such as financial services or KRITIS operators. The Bundesbank's TIBER-DE methodology is the recognised reference framework here.

For ISO/IEC 27001:2022, the combination of regular scans and at least annual external pen tests of the systems in need of protection is sufficient in most industries. Which systems are in need of protection is determined by the risk analysis, not by the budget.

In addition to the test, auditors evaluate the reaction: Were critical findings closed within the defined SLA? Are residual risks accepted by management? Has there been a retest of the fixed vulnerabilities?

The cycle must be anchored in the security guidelines. Common practice: scan monthly, external pen test annually, retest after major release. Anyone affected by NIS 2 should link the cycle to the NIS 2 obligations in Germany.

A thin, one-page report without methodology is not enough. OWASP top 10 coverage, OSSTMM or PTES methodology and comprehensible severity rating are expected.

An audit-proof pen test report starts with the scope document: which IP ranges, applications, interfaces, cloud accounts? Which tests are allowed and which are excluded? These Rules of Engagement must be signed by the client, ideally with reference to § 202c StGB and § 303a/b StGB.

The methodology follows. Black box, gray box or white box are common, combined with OWASP web security testing guide for web applications and PTES for infrastructure. The report must identify the chosen methodology and justify why it is appropriate for the scope.

Findings are rated with CVSS 3.1 or 4.0, with base, temporal and environmental scores, respectively. A pure traffic light without CVSS is not sufficient for risk treatment according to clause 6.1.3 of 27001:2022.

Every finding needs a technical description, a proof of concept, a recommendation and an estimated residual risk assessment after resolution. Screenshots are helpful, but must not contain any real data, otherwise there is a risk of conflicts with Art. 32 GDPR.

The management summary must be readable for non-technical people because management must accept residual risks. A final action plan with those responsible, deadlines and re-test date belongs in the ISMS, not in the outbox.

The auditor calls, the evidence is ready. Complete, methodical, with re-test.

The client is the management, the commission is actually commissioned by the ISB or CISO. The ISB's appointment certificate should expressly include the authority to commission external security tests, otherwise there will be a gap between responsibility and mandate.

Liability applies externally to the company; internally, managing directors can be held personally liable according to Section 43 GmbHG if essential tests were negligently omitted. For companies affected by NIS 2, Section 38 NIS2UmsuCG-E further tightens this line.

The service provider is contractually liable in accordance with BGB work contract law, usually limited to the order volume. Anyone who commissions a pen test as a pure compliance exercise is not buying a security level, but rather a snapshot.

The data protection impact assessment in accordance with Art. 35 GDPR must be checked as soon as personal data is within the test scope. An order processing contract in accordance with Art. 28 GDPR is standard. Anyone who tests in the cloud also needs the approval of the hyperscaler (AWS, Azure, GCP).

The commissioning, approval, report, risk acceptance, re-test and the update of the statement of applicability are required to be documented. Incomplete documentation is the most common finding in the audit, not missing tests.

CIVAC keeps this chain together in a workspace so that external data protection officer and ISB reference the same documents.

The NIS 2 Directive (Article 21 Paragraph 2 Letter f) explicitly requires procedures for assessing the effectiveness of risk management measures. Penetration testing is the obvious method. Anyone who implements ISO/IEC 27001:2022 and NIS-2 in parallel can use the same test for both proofs, provided the scope and depth are coordinated.

DORA (Regulation 2022/2554) tightens the requirement for the financial sector: Threat-Led Penetration Tests (TLPT) will be mandatory for major institutions from 2026 and are linked to the TIBER-EU methodology. Frequency: at least every three years, plus additional tests in the event of significant changes.

BSI IT-Grundschutz addresses pen tests in the building blocks DER.1 (detection) and OPS.1.1.6 (software tests). Anyone working according to basic protection will find more specific test depths here than in ISO/IEC 27001:2022. A combined certification is possible, but requires careful mapping of the requirements.

KRITIS operators according to Section 8a BSIG must prove the effectiveness of their security measures every two years. Pen tests are regularly included in this evidence, supplemented by organisational audits.

Industry standards such as B3S Hospital, BAIT, VAIT and KAIT further tighten the requirements for their sectors. If you are in several regimes, you should choose the scope, methodology and reporting format so that one test uses multiple pieces of evidence.

Duplicate work costs money, but more trust. Multiple use is permitted and desired if documented.

The most common finding is a non-renewed test older than 24 months. Auditors usually expect a test in the current certification cycle, i.e. at least once every three years, but in practice annually. A test from the initial certification audit without a follow-up test is a clear finding.

The second most common is the scope mismatch: only the marketing website was tested, but the core system is certified. The connection between risk analysis and test scope is missing here. Auditors insist on a comprehensible justification of the scope.

Thirdly, lack of action tracking: Findings were reported but not entered in the ISMS action plan. This breaks the effectiveness loop, which directly affects Clause 10.1 (Continuous Improvement).

Fourth, unclear risk acceptance. If management bears a residual risk, this acceptance must be filed in the ISMS in writing, with a date and signature. A verbal promise is not enough.

Fifth, missing re-tests: If a critical vulnerability was marked as closed without a re-test taking place, it is still considered open for the auditor. Re-test reports must be part of the action ticket.

CIVAC links test report, risk acceptance, action plan and re-test in one reporting line, so that the ISO 27001:2022 transition succeeds without any open points.

Step 1: Define scope. Derivation from the risk analysis according to clause 6.1.2 of 27001:2022. Which systems are critical, which personal data are processed, which interfaces are accessible externally?

Step 2: Select service provider. Criteria are OSCP/OSEP-certified testers, industry experience, German-language reports and hosting of the findings data in the EU. References should be checked, not just logos.

Step 3: Write down the rules of engagement. Test time window, escalation path, permitted and prohibited techniques, emergency abort procedures. This agreement protects both parties under criminal law.

Step 4: Implementation and support. The ISB should be available as a central contact to quickly clarify escalations, false positives and real attack mix-ups.

Step 5: Receive report, evaluate findings, create action plan. The assessment must flow into the ISMS, with those responsible, deadlines and CVSS score.

Step 6: Re-test the fixed vulnerabilities and update the Statement of Applicability. Without this step the cycle remains incomplete. Licence the workspace for your internal representatives, or have our representatives order it. This creates 490 ready-to-use audit templates, 93 controls and a documented pen test cycle in one hand.

Pen test requirement according to ISO/IEC 27001:2022 is not an isolated task, but a recurring process of scope, test, evaluation, treatment and re-test. Anyone who conducts this process in Excel lists and email attachments will lose time during the re-audit and, in an emergency, money.

CIVAC is a compliance platform and officer-as-a-service. The workspace holds together the appointment certificate, reporting line, 93 controls according to ISO/IEC 27001:2022, 490 audit templates and the vulnerability management module in an EU-hosted environment. Pen test reports, risk acceptances and action plans are stored in an audit-proof manner.

Licence the workspace for your internal representatives, or have our representatives order it. In the second model, experienced information security officers with a CIVAC SLA of two working days take over the ordering, the ongoing reporting line and the audit support.

Others run compliance like a filing cabinet. We run it like software. The consequence: When the audit question is asked about the pen test, the report, measures and re-test can be accessed with two clicks and are not buried in a mailbox archive.

Write to info@civac.de or use the contact form on civac.de. In the initial consultation, we clarify the level of maturity of your ISMS, the open Annex A gap and whether a licence or mandate is a better fit.

Turn reading into a mandate.