---
title: "Scoping a SOC 2, PCI DSS or DORA pentest that includes AI agents"
canonical: https://pharosone.ai/knowledge/preparing-for-a-soc2-or-dora-pentest-with-ai-agents
publisher: PharosOne (Agentic Mind, Inc.)
updated: 2026-10-23
license: "Open for reuse: crawling, copying, quoting, summarising and model training permitted without asking; citation of the title and canonical URL requested (see https://pharosone.ai/terms#reuse)"
cite_as: "\"Scoping a SOC 2, PCI DSS or DORA pentest that includes AI agents\". PharosOne, 2026-10-23. https://pharosone.ai/knowledge/preparing-for-a-soc2-or-dora-pentest-with-ai-agents"
---

# Scoping a SOC 2, PCI DSS or DORA pentest that includes AI agents

> Which clauses require a pentest and which only expect one, the agent inventory for the scope, and what reviewers look for in the report and the retest.

URL: https://pharosone.ai/knowledge/preparing-for-a-soc2-or-dora-pentest-with-ai-agents · Category: Guides · Published: 2026-10-22 · Updated: 2026-10-23 · Author: PharosOne Research · Reviewed by: PharosOne editorial

*PharosOne sells pentests, including pentests of AI agents, and wrote this article.*

**In short.** SOC 2, PCI DSS, DORA and ISO 27001 do not name agents, and each asks for evidence in its own terms. A reviewer looks for a report with the scope and dates stated, the methodology named and every finding reproducible and rated, plus a record of what was fixed; PCI DSS 11.4.4 alone requires that corrected findings are retested, and DORA requires that weaknesses found are remedied and the fix validated. When AI agents are on the stack, list them in the scope with their tools, MCP servers, memory and data flows, because each one reads untrusted content and calls your tools. This guide gives the clauses, the agent inventory, the pre-call checklist and what reviewers check in a report; whether a report is accepted is always the reviewer's decision.

## Key facts

- Updated: 23 October 2026
- For: security leads and compliance owners with an audit date and AI agents on the stack
- Time: about 3 weeks from the scoping call to the report, then your remediation and the retest; plan back from the date your evidence is due
- You receive from this guide: the reviewers' questions by clause, the agent inventory for the scope, the pre-call checklist, a report review checklist (what reviewers usually look for; acceptance is the reviewer's decision)
- Standards: SOC 2 CC4.1, PCI DSS 11.4, DORA Art. 24–25, ISO 27001 A.8, EU AI Act Art. 9 and 15, AIUC-1, OWASP Agentic Top 10 (all compared in the [standards crosswalk](/research/ai-standards-crosswalk))
- DORA scope: this guide covers ordinary testing under DORA Articles 24–25; it does not describe or replace threat-led penetration testing (TLPT) under Articles 26–27
- Checked: legal and standards references on 23 October 2026
- Next step: book a 30-minute scoping call at audit@pharosone.ai

## What do reviewers ask for?

Each framework asks in its own words, and the report has to answer in those words.

| Framework | Clause | What it asks | What the report must show |
|---|---|---|---|
| SOC 2 | CC4.1 (COSO Principle 16), CC4.2 | "ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning"; the points of focus name penetration testing as one type of evaluation; CC4.2 asks that deficiencies reach the people who take corrective action | date, scope, method, findings; evidence that results reached management and were tracked (CC4.2) |
| PCI DSS v4.0.1 | 11.4 (11.4.1–11.4.4) | "External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected"; a defined methodology; tests at least once every 12 months and after significant changes | methodology, dates, scope against the cardholder data environment, correction-and-retest evidence |
| DORA | Art. 24 and 25 | a "sound and comprehensive digital operational resilience testing programme"; appropriate tests "at least yearly" on ICT systems supporting critical or important functions (24(6)); penetration testing among the tests (25); procedures to remedy what tests reveal and to validate that weaknesses are addressed (24(5)) | the test within the programme; systems mapped to critical or important functions; findings, remediation and its validation |
| ISO 27001:2022 | Annex A.8.8, A.8.29 | management of technical vulnerabilities; security testing in development and acceptance | vulnerabilities found and treated; the test before acceptance |
| EU AI Act (high-risk AI only; Annex III systems from 2 December 2027) | Art. 9(6)–(8), Art. 15(5) | testing "against prior defined metrics and probabilistic thresholds" before placing on the market; resilience "against attempts by unauthorised third parties to alter their use, outputs or performance" | adversarial test results for the agent with the metric, the threshold and the date |

([AICPA TSC](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022); [PCI DSS v4.0.1](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf); [DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj); [ISO/IEC 27001:2022](https://www.iso.org/standard/27001); [EU AI Act Art. 9](https://artificialintelligenceact.eu/article/9/), [Art. 15](https://artificialintelligenceact.eu/article/15/).) The EU AI Act's high-risk duties apply to standalone Annex III systems from 2 December 2027 and to AI in Annex I products from 2 August 2028, after the AI Omnibus, Regulation (EU) 2026/1744, moved them from 2 August 2026 and 2 August 2027 ([OJ L, 2026/1744](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744); [European Commission timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act)). Whether an agent is high-risk depends on its use under Annex III. The [standards crosswalk](/research/ai-standards-crosswalk) adds AIUC-1, ISO/IEC 42001, the NIST AI RMF and the OWASP Agentic Top 10.

## What is required, and what is common practice?

Auditors and customers often expect more than the text of a framework requires. Keep the two apart when you plan:

| | Required by the text | Common practice |
|---|---|---|
| A pentest at all | PCI DSS 11.4: internal and external, at least every 12 months and after significant changes. DORA Art. 24(6) and 25: appropriate tests at least yearly on systems supporting critical or important functions, penetration testing among them. SOC 2: none; CC4.1 names penetration testing as one evaluation type. | an annual pentest for SOC 2, because auditors and customers ask for one |
| Fixing findings | PCI DSS 11.4.4: exploitable findings corrected and the test repeated. DORA Art. 24(5): issues remedied and the fix validated. SOC 2 CC4.2: deficiencies communicated to those who correct them. | a retest of every finding and a closure letter |
| Timing | PCI DSS and DORA: at least yearly. SOC 2 Type II: the evaluation sits inside the observation period. | the report and retest finished before the evidence is due |
| AI agents | named by none of them | listed in the scope with tools, MCP servers, memory and data flows |

## What does DORA require for penetration testing and retesting?

DORA requires financial entities, other than microenterprises, to run a risk-based digital operational resilience testing programme in which penetration testing is one of the listed tests (Article 25(1)), with appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions (Article 24(6)). DORA has no clause named "retest": Article 24(5) requires procedures to prioritise, classify and remedy every issue the tests reveal, and internal validation methodologies to ascertain that all identified weaknesses are fully addressed, and a retest is the usual way to supply that validation ([Regulation (EU) 2022/2554, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)).

- **Who tests.** Tests are undertaken by independent parties, internal or external; an internal tester needs sufficient resources and no conflict of interest (Article 24(4)).
- **Which systems.** The yearly tests cover the ICT systems that support critical or important functions. An agent that supports such a function is one of those systems; DORA does not name agents.
- **When to retest.** DORA sets no retest window. Retest after the fixes and before the validation is recorded in your programme; the 90 days in our offer is a commercial term.
- **TLPT is separate.** Threat-led penetration testing under Articles 26 and 27 applies only to financial entities identified by their competent authority, at least every 3 years, on live production systems, with a scope the authority validates. An ordinary pentest under Articles 24–25 does not stand in for it, and this guide does not cover it.

## What must the scope include when agents are on the stack?

A reviewer reads the scope first, and a missing component that reads untrusted content and calls tools draws the next question. Hand the tester this inventory before the call:

- **Agents.** Each agent by name, purpose, model and provider, owner, and whether it is customer-facing.
- **Tools.** Every function each agent can call, with the permission it runs under and whether it reads, writes, pays or sends (OWASP ASI02, ASI03; [OWASP, 9 December 2025](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)).
- **MCP servers.** Which servers each agent connects to, who hosts them, which tools they expose; their descriptions and results are inputs the agent trusts (ASI04).
- **Memory.** What the agent stores between sessions, who can write to it, and whether a user's content can reach it (ASI06).
- **Data flows.** Every untrusted input (users, documents, web pages, email, a knowledge base) and every channel out (messages, URLs, images, files, tool calls). An agent with all three of private data, untrusted content and a way out has what Simon Willison calls the lethal trifecta ([Willison, 16 June 2025](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)).
- **Guardrails already in place.** Input filters, allow-lists, rate limits, human approval steps; the test should say which ones held.

With this inventory the tester chooses the depth: the AI exposure check included in every engagement (an inventory and a first attempt on each agent; it stops short of a test of the agent), or the full AI agents scope (from €15,000, one agent or LLM application with everything it touches: its tools, MCP servers, memory and knowledge base) when the agent is the product or moves money or data ([human pentest](/knowledge/human-pentest)).

## What should I prepare for the scoping call?

Thirty minutes is enough with these on the table:

1. The reviewer and the date: which framework, which clause, when fieldwork starts.
2. The asset list: domains, applications, APIs, cloud accounts, network ranges, repositories, and which touch regulated data.
3. The agent inventory from the section above.
4. Roles and accounts: which user roles exist and who will provision test accounts.
5. Environment: production, staging or both, and what must never be touched.
6. The previous report, if any, and the changes since it, because PCI DSS 11.4 ties a new test to "significant changes".
7. The test window and the contacts who can be reached during it.

The engineer on the call is the engineer who tests; the SOW follows within 3 days with a fixed scope and price.

## What does a reviewer check in the report?

A reviewer wants to reproduce every finding and see what happened afterwards. Check for:

- scope, dates and the names of the systems tested, matched to the inventory;
- the methodology, named, and the tester's independence from the system owner;
- each finding with a CVSS score and vector, the affected assets, the evidence that reproduces it, the risk, the business impact and the remediation; for agent findings, CVSS scores the underlying permission or design flaw, and the attack success rate is reported beside it;
- the attack chain, from the first foothold to the final impact;
- a "what is working" section;
- the standards mapping: which finding touches which clause, and for agents which AIUC-1 control;
- the remediation status and, where a retest was run, its result.

A scanner export presented as a pentest, a report without dates or scope, and findings without evidence draw questions under every framework. A missing retest is a gap under PCI DSS, where 11.4.4 requires that exploitable vulnerabilities are corrected and the test repeated ([PCI SSC, v4.0.1](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf)). Under SOC 2 and DORA the reviewer looks for a record that findings were tracked and remedied, and a retest is one common way to show it. The checklist above makes a report easier to review; it does not decide the outcome.

## What about the retest and the closure letter?

One retest within 90 days of the report is included in every PharosOne human pentest, the AI agent pentest among them; the €3,900 AI agent security assessment has no retest. The 90 days are our commercial term, and none of the frameworks above sets that window. The engineers re-run every finding against the fixed system and issue a closure letter stating what was fixed and what remains. For PCI DSS 11.4.4 the retest is required; for SOC 2 and DORA the letter is one way to show that findings were remedied. A second retest round, if the first leaves findings open, costs 15% of the project price ([PharosOne pricing](https://pharosone.ai/pricing), October 2026).

## What is the timeline?

| Step | When | Output |
|---|---|---|
| Scoping call | Day 0 | 30 minutes; scope and reviewer understood |
| SOW | Day 1–3 | fixed scope, fixed price, test window |
| Testing | Week 1–2 | the agreed scope, with the AI exposure check |
| Report | Week 3 | executive summary, findings, attack chain, standards mapping |
| Remediation | your schedule | fixes applied |
| Retest | within 90 days of the report | closure letter |

Plan back from the date your evidence is due: about three weeks to the report, then the time your team needs to fix, then the retest. How early that has to start depends on the framework and the auditor. For a SOC 2 Type II report the test has to fall inside the observation period, and for PCI DSS the retest has to be done before you claim the requirement is met. For an agent that changes every sprint the report ages fast; [continuous testing](/knowledge/continuous-testing) keeps the evidence current between audits, in step with AIUC-1's quarterly retests and annual re-certification ([aiuc-1.com](https://www.aiuc-1.com/)).

## FAQ

### Does SOC 2 require a penetration test?

No. CC4.1 requires ongoing and/or separate evaluations of internal control, and its points of focus name penetration testing as one type of evaluation among several. Many companies commission an annual pentest for their SOC 2 report because auditors and customers expect one; that is common practice, and the criteria do not require it.

### Does DORA require a penetration test every year?

Article 24 requires tests at least yearly on all ICT systems and applications supporting critical or important functions, and Article 25 lists penetration testing among the tests the programme must provide for. Which test applies to which system follows the entity's risk-based programme.

### Do AI agents have to be in the scope?

SOC 2, PCI DSS, DORA and ISO 27001 do not name agents. They cover the systems inside the scope of the audit or the testing programme, and an agent that reads untrusted content and calls tools is one of those systems. Whether it must be in a particular pentest depends on that scope, which you agree with your auditor or set in your DORA testing programme.

### Does DORA require a retest after a penetration test?

Not by that name. Article 24(5) requires procedures to remedy every issue a test reveals and internal validation that each weakness is fully addressed; a retest of the fixed findings is the usual way to supply that validation. DORA sets no retest window. Threat-led penetration testing (TLPT) under Articles 26 and 27 is a separate regime for entities identified by their competent authority.

### What makes a reviewer question a pentest report?

Common reasons are a scanner export presented as a pentest, missing dates or scope, findings without reproducible evidence and no stated methodology. Under PCI DSS 11.4.4 a missing retest of exploitable findings is a gap; under SOC 2 and DORA the reviewer looks for a record that findings were tracked and remedied. The decision is always the reviewer's.

### How far ahead of the audit should I book?

Count back from the date your evidence is due: about 3 weeks from the scoping call to the report, then your remediation time, then the retest. For a SOC 2 Type II report the test must fall inside the observation period; ask your auditor which dates count.

## Sources

1. [2017 Trust Services Criteria (With Revised Points of Focus – 2022), criteria CC4.1 and CC4.2](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022). AICPA, 2022.
2. [PCI DSS v4.0.1, Requirement 11.4](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf). PCI Security Standards Council, 2024-06.
3. [Regulation (EU) 2022/2554 (DORA), Articles 24 and 25](https://eur-lex.europa.eu/eli/reg/2022/2554/oj). Official Journal of the European Union, EUR-Lex, 2022-12-27.
4. [ISO/IEC 27001:2022, Annex A.8 Technological controls](https://www.iso.org/standard/27001). ISO, 2022-10.
5. [EU AI Act, Article 9, Risk Management System](https://artificialintelligenceact.eu/article/9/). artificialintelligenceact.eu, 2024.
6. [EU AI Act, Article 15, Accuracy, Robustness and Cybersecurity](https://artificialintelligenceact.eu/article/15/). artificialintelligenceact.eu, 2024.
7. [OWASP Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/). OWASP GenAI Security Project, 2025-12-09.
8. [The lethal trifecta for AI agents](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/). Simon Willison, 2025-06-16.
9. [Regulation (EU) 2026/1744 (AI Omnibus), amending Regulation (EU) 2024/1689](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744). Official Journal of the European Union, EUR-Lex, 2026-07-24.
10. [Regulation (EU) 2024/1689 (AI Act) implementation timeline, after the AI Omnibus](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act). European Commission, AI Act Service Desk, 2026.
11. [AIUC-1, certification process (quarterly retests, annual validity)](https://www.aiuc-1.com/). Artificial Intelligence Underwriting Company, 2026.
12. [PharosOne pricing](https://pharosone.ai/pricing). PharosOne, 2026-10-22.

Source: PharosOne, "Scoping a SOC 2, PCI DSS or DORA pentest that includes AI agents", https://pharosone.ai/knowledge/preparing-for-a-soc2-or-dora-pentest-with-ai-agents, updated 2026-10-23.

---

PharosOne is a product of Agentic Mind, Inc., an independent AI agent security company. Site map for agents: https://pharosone.ai/llms.txt