APP-005 Penetration Testing
Description
Penetration testing of production applications, APIs and infrastructure is conducted at a defined frequency of at least annually and after significant architectural changes. Testing is performed by parties independent of the team responsible for the system under test. Test scope and methodology are documented. Adversary simulation exercises are run at a defined frequency under written rules of engagement that are agreed before the exercise begins and that name the objectives, the systems in scope, the permitted techniques and the escalation route. Findings from both activities are documented, risk-rated and remediated according to a defined schedule, and retesting confirms remediation. Published terms state the conditions on which the organisation takes part in a penetration test a customer commissions against the organisation's own production environment, naming the notice required, the testing window, the systems a customer's testers may reach, the threat intelligence the organisation supplies and the route by which several customers of one service commission a single test between them. A test run under those terms produces the same recorded findings, risk ratings, remediation and retest as a test the organisation commissions itself.
Rationale
Automated scanning finds known vulnerability patterns and misses logic flaws, chained vulnerabilities and novel attack paths, so independent testing supplies the adversarial validation tools cannot. Adversary simulation asks a further question that a scoped penetration test does not: whether the detection and response capability sees an attacker who is trying not to be seen. That is why the rules of engagement matter as much as the test plan, and why the findings belong in the same tracker rather than in a separate report nobody schedules against. A customer-commissioned test inverts the usual arrangement: the testers answer to somebody else, the target is the live estate and the rules of engagement are agreed with a party that is not paying for the remediation. Published terms stop each request being argued from first principles, and the pooled route stops one service being tested a dozen times a year to answer the same question. VND-014 grants the audit and inspection right; APP-005 states the testing terms that right is exercised under.
Applicability (9 profiles)
The deployer's own estate and integrations. The provider's test reports for the product are reviewed under VND-006.
The deployer's own estate and integrations. The provider's test reports for the product are reviewed under VND-006.
EX-93 written in S8 wave B (migration 057). Published terms now state the conditions on which the organisation takes part in a penetration test a customer commissions against its own production environment, the notice required, the testing window, the systems a customer's testers may reach, the threat intelligence supplied and the route by which several customers of one service commission a single test between them, with the findings handled as the organisation's own. Art. 30(3)(d) holds full. RTS 2024/1773 Art. 8(2) stays partial here: its access, inspection, audit, certification and audit-report methods sit on VND-014.
Framework Mappings (11)
| TVM-07 | Penetration Testing | full |
| TVM-07 | Penetration Testing | full |
| DORA-Art.30.3.d | Participation in threat-led penetration testing | full |
| DORA-RTS-2024/1773-Art.8.2 | Contractual audit, inspection and testing methods | partial |
| HIPAA-164.308.a.8 | Evaluation | informative |
| AML.M0035 | AI Red Team | informative |
| NIS2-CIR-6.5 | Security Testing | partial |
| CA-8 | Penetration Testing | full |
| CA-8(1) | Penetration Testing | Independent Penetration Testing Agent or Team | full |
| CA-8(2) | Penetration Testing | Red Team Exercises | full |
| CC7.1 | Detection and Monitoring Procedures | informative |
Evidence (4)
Penetration test report from the most recent annual engagement, conducted by an independent third party, with findings, risk ratings, and remediation status.
Example: Penetration test report (PDF) from a named third-party security firm, covering production systems and applications, dated within the last 12 months. Report must include: scope statement, methodology, finding list with severity ratings, and a remediation status column.
Test: Request the most recent penetration test report. Verify: (1) the report is dated within the last 12 months, or within 30 days of a significant architectural change if that occurred sooner, (2) the testing firm is independent of the development team, (3) the scope covers production-facing systems and applications, (4) all critical and high findings are either remediated (confirmed by retest) or have a documented risk acceptance signed by an authorised individual, (5) a retest report exists for any originally critical/high findings.
Remediation tracking records showing that penetration test findings were triaged, assigned, and resolved within the defined SLA.
Example: Jira or equivalent issue tracker export showing all findings from the most recent pen test as individual tickets, each with severity, assignee, target remediation date, and current status (open/in-progress/closed). Closed tickets must include a resolution note.
Test: Cross-reference the pen test finding list against the issue tracker. Verify: (1) every finding from the report has a corresponding ticket, (2) critical findings were resolved within the policy-defined SLA (typically 30 days), high within 60–90 days, (3) any open findings beyond their SLA have a documented risk acceptance or extension approval, (4) retest evidence exists for all remediated critical/high findings. (5) findings from a test a customer commissioned against the production environment in the period appear in the same tracker, under the same ratings and the same retest discipline as findings from a test the organisation commissioned.
Adversary simulation exercise report with the signed rules of engagement it ran under.
Example: Adversary simulation report and rules of engagement, engagement RT-2026-02
Test: Request the most recent adversary simulation report. Verify: (1) the rules of engagement were signed before the exercise start date, (2) they name the objectives, the systems in scope, the permitted techniques and the escalation route, (3) the report records the attack paths attempted and which of them the detection capability raised, (4) findings entered the same remediation tracker as penetration test findings, (5) the exercise falls within the defined frequency, (6) detection gaps the exercise surfaced resolve to a monitoring change or a recorded acceptance.
Published terms on which the organisation takes part in a penetration test a customer commissions against its production environment, with the record of any such test run in the period.
Example: Customer-commissioned security testing terms v1.2, dated 2026-05-11, published in the trust centre, with the pooled test of July 2026 covering four customers of the same service
Test: Read the published participation terms and take any customer-commissioned test run in the period. Verify: (1) the terms state the notice required, the testing window and the systems a customer's testers may reach, (2) they state the threat intelligence the organisation supplies and the route by which customers of one service commission a single test between them, (3) a test run in the period ran under those terms rather than under terms negotiated from scratch, (4) its findings carry the ratings, the remediation schedule and the retest the organisation applies to its own tests, (5) where no such test was requested, the terms are current and reachable by the route a customer would use.
Questions (3)
Is penetration testing of production applications, APIs and infrastructure conducted at a defined frequency of at least annually?
Testing must be performed by a party independent of the development team, either an external firm or a distinct internal red team. Self-assessed or developer-led testing does not satisfy this control.
How are penetration test findings managed after testing is complete?
Every finding must have a corresponding ticket. Critical findings should be remediated and retested within 30 days. Untracked or unconfirmed remediation significantly weakens the value of the pen test. The strongest option separates out the case that usually leaks: a test a customer commissioned against the production estate produces findings that belong in the same tracker on the same terms, not in a report filed with the account team.
Which of the following best describes the scope and approach of your most recent penetration test?
Options run strongest to weakest. At minimum, production APIs and public-facing applications belong in scope. Count an adversary simulation only where written rules of engagement were agreed before it started; an unscoped exercise is a different activity with a different risk profile. A bug bounty alone does not satisfy this control.