Article 38: General investigations

Article 38 requires you to be investigation-ready for DORA oversight of critical ICT third-party service providers: the Lead Overseer can conduct investigations (with a joint examination team) when necessary. Operationalize this by establishing a documented regulatory-response workflow, mapping accountable owners to evidence, and running repeatable readiness drills so you can produce complete, consistent artifacts on demand. (Regulation (EU) 2022/2554, Article 38)

Key takeaways:

• Article 38 is an “authority power” requirement; your job is to make your organization and your critical ICT third parties investigation-ready. (Regulation (EU) 2022/2554, Article 38)
• You need a single, owned investigation playbook: intake, triage, legal review, evidence collection, delivery, and remediation tracking.
• Evidence discipline matters: build a register that ties the requirement to controls, owners, and concrete supervisory artifacts.

“Article 38: general investigations requirement” is short, but it drives real operational expectations. Under DORA, the Lead Overseer (supported by a joint examination team) may conduct investigations of critical ICT third-party service providers where necessary. (Regulation (EU) 2022/2554, Article 38) For a Compliance Officer, CCO, or GRC lead, the practical question is not whether the authority can investigate, but whether you and your ICT sourcing ecosystem can respond quickly, accurately, and with defensible evidence.

Even if your firm is not a critical ICT third-party service provider, Article 38 still affects you if you rely on one. Your regulators will expect you to manage third-party risk such that oversight actions, provider investigations, and follow-on remediation do not break your operations, your customer commitments, or your own compliance posture.

This page focuses on operationalizing investigation readiness: roles, workflows, evidence, and drills. It also highlights common breakdowns seen in supervisory interactions (slow responses, conflicting narratives, incomplete artifacts) and how to design your program to avoid them. Where helpful, it references commonly used control approaches (e.g., ISO 27001-aligned evidence packs, SOC report handling, incident runbooks) without claiming those frameworks are required by Article 38.

Regulatory text

Text (excerpt): “In order to carry out its duties under this Regulation, the Lead Overseer, assisted by the joint examination team referred to in Article 40(1), may, where necessary, conduct investigations of critical ICT third-party service providers.” (Regulation (EU) 2022/2554, Article 38)

Operator interpretation (what this means for you):

• Supervisors have an explicit power to investigate critical ICT third-party service providers. (Regulation (EU) 2022/2554, Article 38)
• “May, where necessary” implies investigations are situational: triggered by risk signals, incidents, concentration concerns, or supervisory priorities. Article 38 does not define triggers, so you should plan for requests that arrive with short deadlines and broad scope. (Regulation (EU) 2022/2554, Article 38)
• Your operational objective is investigation readiness: the ability to coordinate internally, coordinate with the third party, produce coherent evidence, and manage remediation and communications.

Plain-English requirement

Maintain a repeatable capability to respond to DORA supervisory investigations involving your critical ICT third-party service providers by:

1. assigning clear accountability across compliance, ICT risk, security operations, procurement/vendor management, and legal;
2. maintaining a traceable evidence set that demonstrates relevant controls operate; and
3. executing a controlled regulatory-response workflow that withstands scrutiny.

Who it applies to

Primary scope (direct)

• Critical ICT third-party service providers that fall under DORA’s oversight regime can be investigated by the Lead Overseer. (Regulation (EU) 2022/2554, Article 38)

Practical scope for most financial entities (indirect but operationally real)

Even if you are a regulated financial entity (not the provider), Article 38 affects your operations when:

• your business relies on a provider that may be investigated as “critical,” and you must support information gathering, remediation, exit planning, or customer impact management; or
• your regulator asks how you ensure continuity and risk control if a key provider becomes subject to supervisory investigation and follow-up actions.

Operational contexts where this shows up

• Major cloud/hosting, core banking platforms, payment processing, identity services, security monitoring providers, and other high-dependency ICT services where disruption or control failure has outsized impact.
• Multi-entity groups where procurement contracts sit in one entity, but operational risk sits in another.

What you actually need to do (step-by-step)

Step 1: Establish investigation governance (named owners, not committees)

Create an Investigation Response RACI that includes, at minimum:

• Regulatory Response Owner (RRO): accountable for end-to-end response coordination.
• Legal Counsel: privilege decisions, response positioning, disclosure checks.
• ICT Risk / Security: technical evidence, control narratives, incident reconstruction.
• Third-Party Owner (Service Owner): contract, service architecture, escalation to provider.
• Records/Evidence Manager: evidence integrity, version control, chain-of-custody discipline.

Operator tip: write down delegation authority (who can approve responses, who can commit to remediation dates, who can disclose incident details). Delays often come from unowned approvals.

Step 2: Build a “request-to-fulfillment” regulatory-response workflow

Document a workflow that starts the minute a request arrives and ends only when remediation is validated and closed. Minimum states:

1. Intake & logging (central mailbox/ticket queue; unique case ID)
2. Scope triage (what is being asked; which entities/providers; due dates)
3. Privilege & confidentiality screen (legal review; NDA/contract constraints)
4. Evidence collection plan (who pulls what; formats; timestamps)
5. Quality review (consistency check; reconcile contradictions)
6. Submission & communications (single voice; tracked delivery)
7. Remediation/CAPA management (actions, owners, proof of completion)
8. Lessons learned (update controls, templates, and evidence register)

This is where Daydream fits naturally: teams often manage this in email and spreadsheets until the first high-pressure supervisory request. Daydream can hold the investigation playbook, map obligations to owners and artifacts, and keep a clean audit trail of drafts, approvals, and final submissions without losing context.

Step 3: Create an evidence register tied to Article 38

Article 38 is about the authority’s power, so your “control” is readiness. Create a register entry for Article 38 that maps:

• Readiness controls (workflow, governance, escalation paths)
• Accountable owners
• Evidence artifacts (see list below)
• Storage location and retention expectations (your policy-based retention, not invented regulatory durations)

Minimum design goal: one place a supervisor-facing response team can open and understand “how we respond” and “where the proof lives.”

Step 4: Pre-negotiate and document third-party cooperation mechanics

Investigation readiness fails when the provider does not respond, or responds inconsistently. For critical ICT third parties:

• Confirm named escalation contacts (primary and backup).
• Align on evidence formats (SOC reports, ISO certificates, pen test summaries, incident reports, architecture diagrams).
• Define how you will handle regulator-originated questions that you must route to the provider.
• Confirm subcontractor visibility expectations (what the provider can share about fourth parties).

You may not be able to force all terms, but you can document constraints and build contingency plans.

Step 5: Run readiness drills (tabletop + artifact pull)

Run periodic drills that simulate:

• a short-deadline evidence request,
• a cross-functional evidence pull,
• a provider escalation,
• and a remediation commitment with later validation.

Make the drill measurable without inventing numeric targets: you want to see whether you can produce a coherent pack, on time, with consistent narratives and approvals.

Step 6: Close the loop with tracked remediation and validation evidence

Investigation outcomes often include follow-up actions. Treat these like formal CAPAs:

• assign owners,
• define completion criteria,
• collect validation evidence (screenshots are weak; prefer logs, change tickets, control test results),
• and record sign-off.

Required evidence and artifacts to retain

Keep artifacts that prove you can respond and that you responded with control and integrity:

Governance and workflow

• Investigation Response RACI (current version + change history)
• Written regulatory-response workflow and escalation path
• Approval matrix (who can sign/submit)

Evidence management discipline

• Case log template (intake, deadlines, requests, responses)
• Evidence collection checklist
• Version-controlled response drafts and approvals
• Record of what was provided, when, and by whom

Third-party coordination

• Third-party contact lists and escalation procedures
• Contract excerpts or addenda on cooperation/information sharing (where available)
• Provider evidence pack inventory (what exists, last updated)

Remediation tracking

• CAPA register entries tied to investigation items
• Validation proof and closure sign-offs
• Lessons learned notes and resulting control updates

Common exam/audit questions and hangups

Expect questions like:

• “Show me your documented process for responding to DORA oversight requests involving critical ICT third parties.” (Regulation (EU) 2022/2554, Article 38)
• “Who is accountable for coordinating responses, and who approves submissions?”
• “How do you ensure the evidence you provide is complete and consistent across teams?”
• “How do you coordinate with the third party and handle delays or refusal to share artifacts?”
• “How do you track and validate remediation commitments that result from supervisory engagement?”

Hangups auditors repeatedly find:

• No single workflow, only “we handle it case by case.”
• Conflicting narratives between compliance, security, and procurement.
• Evidence stored in personal drives and chat threads, with no integrity controls.
• Provider artifacts outdated, missing, or not mapped to services you actually consume.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating Article 38 as “the provider’s problem.”
   Fix: build internal readiness anyway; your regulator will test your dependency management and continuity planning when a critical provider is under scrutiny.

2. Mistake: RACI without decision authority.
   Fix: explicitly document who can commit to remediation, timelines, and disclosures. If approvals require a steering committee, define an emergency path.

3. Mistake: Evidence pack is a document dump.
   Fix: produce an indexed submission with a short control narrative for each artifact and a clear mapping to the question asked.

4. Mistake: No remediation validation.
   Fix: require closure evidence and independent review (second set of eyes) before marking actions complete.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 38, so this page does not cite case outcomes.

Practically, investigation readiness gaps create:

• Regulatory risk: slow, incomplete, or inconsistent responses undermine supervisory confidence.
• Operational risk: urgent evidence pulls disrupt BAU, especially if your provider coordination is weak.
• Third-party risk: a critical provider under investigation may face mandatory remediation or operational constraints that cascade into your services.

A practical 30/60/90-day execution plan

The source catalog does not include time-based regulatory expectations. The plan below is an execution structure you can adapt to your internal priorities.

First 30 days (Immediate)

• Assign an executive owner and name the Regulatory Response Owner.
• Draft and approve the investigation response workflow (intake through closure).
• Stand up a central case log and evidence repository structure with access controls.
• Identify your critical ICT third parties and confirm escalation contacts.

Next 60 days (Near-term)

• Build the Article 38 evidence register entry: owners, artifacts, storage locations.
• Collect baseline provider artifacts and document gaps or sharing constraints.
• Train core responders (compliance, legal, ICT risk, service owners) on the workflow and approval path.
• Run a tabletop drill; document failures and fixes.

Next 90 days (Stabilize and operationalize)

• Convert drill findings into tracked CAPAs with validation evidence.
• Add investigation-readiness checkpoints into third-party governance (QBRs, risk reviews).
• Implement tooling to manage requests, approvals, and evidence traceability. If your process is email-based, Daydream is a sensible next step because it centralizes obligation-to-evidence mapping and preserves an audit trail across teams.

Frequently Asked Questions

Does Article 38 impose direct obligations on my financial entity?

Article 38 states the Lead Overseer may conduct investigations of critical ICT third-party service providers. (Regulation (EU) 2022/2554, Article 38) As a financial entity, you still need operational readiness because your regulator may ask how you manage dependencies and support oversight-driven remediation.

What should I do if a critical third party refuses to share investigation-related evidence?

Escalate through your documented contacts and contract mechanisms, and document each request and response. If you cannot obtain an artifact, provide a clear explanation of constraints, compensating controls, and your remediation plan.

What counts as “evidence” for investigation readiness?

Evidence is whatever proves your process operates: case logs, approvals, indexed submissions, provider communications, and CAPA closure validation. Favor artifacts that show timestamps, authorship, and change history.

How do we prevent inconsistent responses across compliance, security, and procurement?

Use a single response owner, a controlled drafting process, and a required consistency review before submission. Maintain a standard response template that forces teams to align on scope, systems, and terminology.

Should we run drills even if we’ve never received a DORA investigation request?

Yes. Drills reveal whether you can collect evidence quickly, coordinate with third parties, and manage approvals under pressure. Capture gaps as CAPAs and retest after fixes.

Where does Daydream help most with Article 38?

Daydream is strongest where teams struggle most: mapping Article 38 to owners and evidence, running a consistent regulatory-response workflow, and maintaining a clean audit trail of requests, approvals, submissions, and remediation closure.