Article 37: Request for information

Article 37: request for information requirement means a DORA Lead Overseer can compel a critical ICT third-party service provider to produce any information needed for oversight, from contracts and policies to audit reports and incident records, including details about the provider’s own outsourcing chain (Regulation (EU) 2022/2554, Article 37). To operationalize it, you need a governed intake-and-response process, a pre-built evidence library, and contractual/operational readiness to respond quickly and completely.

Key takeaways:

• Build a single “supervisory evidence register” that maps Article 37 requests to owners, systems of record, and pre-approved response packages.
• Treat subcontractor/outsourcing transparency as first-class evidence; you will be asked for it.
• Run readiness drills and track remediation through closure so your responses stay consistent under pressure.

Article 37 is a supervision mechanic, not a policy-writing exercise. It gives the DORA Lead Overseer the authority to request (or formally require by decision) information from critical ICT third-party service providers to support the overseer’s duties (Regulation (EU) 2022/2554, Article 37). The practical impact for a Compliance Officer, CCO, or GRC lead is immediate: if your organization is a critical ICT third-party service provider, you must be able to assemble and deliver a complete, defensible evidence package across security, resilience, operations, and third-party outsourcing with short notice.

Even if you sit in a regulated financial entity, Article 37 still matters operationally. Your key ICT providers may be designated “critical,” and their supervisory interactions can spill into your own risk posture: contract terms, incident coordination, audit access, and service continuity planning often depend on how well the provider can satisfy oversight requests. The fastest path to readiness is to (1) define accountable owners, (2) centralize evidence pointers (not just documents), (3) pre-negotiate what can be shared and how, and (4) rehearse the workflow so Legal, Security, and Operations do not improvise during an active request.

Regulatory text

Excerpted requirement (operator view). The Lead Overseer may require critical ICT third-party service providers to provide all information necessary to carry out oversight duties, including business/operational documents, contracts, policies, documentation, ICT security audit reports, ICT-related incident reports, and information about parties to whom the provider has outsourced operations (Regulation (EU) 2022/2554, Article 37).

What this means in practice. You must be able to:

• Identify and retrieve relevant documents and records across functions (Security, IT, Risk, Legal, Procurement, Operations).
• Produce complete and consistent information sets (no contradictions between policy, contract, and observed practice).
• Explain your outsourcing chain (subcontractors, material fourth parties, what they do, and how you control them).
• Respond under governance (controlled communications, legal review, version control, audit trail).

Plain-English interpretation (requirement-level)

If you are a critical ICT third-party service provider, you need an operational capability to handle supervisory information demands end-to-end: receive, triage, collect, validate, approve, deliver, and retain records of what you sent and why. The standard is “all information necessary,” so you should plan for broad scope and follow-up questions (Regulation (EU) 2022/2554, Article 37).

Who it applies to (entity and operational context)

In scope directly

• Critical ICT third-party service providers subject to oversight, because Article 37 requests are directed at them (Regulation (EU) 2022/2554, Article 37).

In scope operationally (indirect impact)

• Regulated financial entities that depend on a critical ICT third-party service provider. Even if you are not the recipient of the request, you will often be pulled into:
  • contract interpretation (audit rights, disclosure limits),
  • incident coordination and timelines,
  • continuity plans and exit strategies,
  • data location and access questions.

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

1) Assign accountability and escalation paths

1. Name an Article 37 Response Owner (often Compliance, Operational Resilience, or TPRM lead).
2. Define a cross-functional response cell: Legal, Security (SOC/IR), IT Ops, Privacy, TPRM/Procurement, and service/product owners.
3. Write an escalation matrix for sensitive items (customer data exposure, privileged legal advice, trade secrets, cross-border transfer constraints).

Deliverable: a one-page RACI and escalation tree tied to your incident and regulatory communications playbooks.

2) Build a “request-to-evidence” register (your evidence map)

Create a register that maps likely Article 37 request categories to:

• System of record (GRC, contract repository, ticketing, SIEM, IR platform, audit repository).
• Document owner and backup owner.
• Most recent version and location.
• Approval requirements (Legal sign-off, customer notification, redaction rules).

Minimum evidence categories to index because they are explicitly named:

• contracts, policies, documentation,
• ICT security audit reports,
• ICT-related incident reports,
• outsourcing/subcontractor information (Regulation (EU) 2022/2554, Article 37).

Practical tip: store pointers plus hashes (or immutable references) rather than emailing PDFs around. It reduces version drift.

3) Pre-package standard response bundles

Prepare “ready-to-send” bundles that can be tailored:

• Corporate/operational: org chart for service delivery, locations, key processes.
• Contracting: master service agreements, key schedules, audit and subcontracting clauses, change logs.
• Security & resilience: security policies, audit reports, testing outcomes, remediation tracking.
• Incident: incident response policy, incident classification, sample incident report template, incident logs and post-incident reviews.
• Outsourcing chain: subcontractor list per service, what is outsourced, control inheritance model, oversight cadence (Regulation (EU) 2022/2554, Article 37).

4) Implement a controlled intake-and-response workflow

Build a workflow that works for both “simple request” and “decision” formats (Regulation (EU) 2022/2554, Article 37):

1. Intake: log the request, channel, scope, and deadline in a tracked system.
2. Triage: classify by sensitivity and breadth; identify which evidence bundles apply.
3. Collection: pull evidence from systems of record; avoid ad hoc narratives unless necessary.
4. Validation: confirm documents match operational reality (e.g., incident report matches ticket timeline).
5. Legal/compliance review: privilege checks, redactions, confidentiality constraints, and contractual notifications.
6. Submission: controlled delivery method, cover letter with index, and a versioned evidence pack.
7. Post-mortem: record follow-ups, gaps, and corrective actions.

This is where a platform like Daydream fits naturally: it can hold the evidence map, route approvals, and maintain an audit trail without building a bespoke workflow in spreadsheets.

5) Prove you can explain your outsourcing chain

Article 37 explicitly calls out information relating to parties to whom the provider has outsourced operations (Regulation (EU) 2022/2554, Article 37). Operationalize that with:

• a service-to-subcontractor mapping ¹,
• data access and processing descriptions per subcontractor,
• control responsibility split (provider vs subcontractor),
• monitoring and assurance evidence (reviews, audits, performance and incident metrics where available).

6) Run readiness drills and close gaps

Schedule periodic internal drills that simulate:

• a narrow request (single service, single incident),
• a broad request (contracts + audits + outsourcing chain + incident history).

Track the resulting gaps as corrective actions with owners and closure evidence. Keep the drill artifacts; they become proof of operational discipline when questions arise (Regulation (EU) 2022/2554, Article 37).

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository with retention aligned to your regulatory and contractual requirements:

• Request log: date/time, requester, scope, deadline, delivery channel, and internal ticket ID.
• Evidence index: list of documents/records provided, versions, and sources of record.
• Approval trail: legal/compliance approvals, redaction decisions, sign-offs.
• Submission proof: delivery confirmation, checksum/hashes where used, and final pack.
• Follow-up Q&A log: questions received, answers provided, and supporting citations to evidence.
• Outsourcing chain dossier: subcontractor mapping, contracts/DPAs where relevant, oversight reports (Regulation (EU) 2022/2554, Article 37).
• Remediation tracker: issues found during preparation, corrective action plans, and validation evidence.

Common exam/audit questions and hangups

Expect supervisors (or internal audit) to ask:

• “Show me the last time you received an oversight request and your full response trail.”
• “Where is the authoritative record for subcontractors supporting this service?” (Regulation (EU) 2022/2554, Article 37)
• “How do you ensure incident reports you provide are complete and consistent with tickets and post-incident reviews?” (Regulation (EU) 2022/2554, Article 37)
• “Who can approve disclosures that involve customer information or privileged material?”
• “How do you prevent different teams from sending conflicting answers?”

Hangups that slow teams down:

• scattered contract repositories,
• no consistent incident report format,
• subcontractors managed by engineering with limited documentation,
• unclear internal authority to disclose.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating Article 37 as a one-time document request.
   Fix: build a standing workflow and evidence map that stays current (Regulation (EU) 2022/2554, Article 37).

2. Mistake: Missing the outsourcing chain.
   Fix: maintain service-level subcontractor inventories and control ownership splits; validate them during change management (Regulation (EU) 2022/2554, Article 37).

3. Mistake: Shipping raw, inconsistent exports.
   Fix: standardize response packs with an index, clear definitions, and reconciliation steps (incident timeline vs tickets vs post-incident report).

4. Mistake: No audit trail of what was sent.
   Fix: versioned evidence packages, submission proof, and preserved approvals.

5. Mistake: Legal review happens at the end.
   Fix: embed Legal early in triage, especially for privileged, confidential, or cross-border material.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list case examples.

Operational risk is still real: inability to produce requested information can trigger intensified supervisory scrutiny, broaden the scope of follow-up requests, and expose gaps in outsourcing governance and incident management that customers and regulators will both care about (Regulation (EU) 2022/2554, Article 37). For regulated customers, a provider’s weak response discipline can become a concentration and continuity risk that shows up in their own third-party oversight.

Practical 30/60/90-day execution plan

The plan below is intentionally phase-based so you can start immediately without pretending every organization moves at the same speed.

First 30 days (Immediate readiness)

• Appoint the Article 37 Response Owner and approve RACI.
• Stand up the intake workflow in your ticketing/GRC tool.
• Inventory where the explicitly named evidence types live: contracts, policies, audit reports, incident reports, outsourcing details (Regulation (EU) 2022/2554, Article 37).
• Draft your standard evidence index template and cover letter template.

Days 31–60 (Operationalize and test)

• Build the request-to-evidence register with owners and systems of record.
• Create the first version of standard response bundles (security, incident, contracting, outsourcing chain).
• Run a tabletop drill; record timing bottlenecks and missing artifacts.
• Open corrective actions for gaps (missing subcontractor mapping, inconsistent incident reports).

Days 61–90 (Harden and scale)

• Integrate change management: any new subcontractor or material service change updates the evidence register.
• Add quality controls: reconciliation checklist, redaction guidance, approval SLA targets (internal).
• Run a second drill with a broader scope and include executive sign-off.
• Consider consolidating evidence and workflows in Daydream to reduce fragmentation, maintain a clean audit trail, and keep response packs current between requests.

Frequently Asked Questions

Does Article 37 apply to all third parties we use?

Article 37 requests are directed at critical ICT third-party service providers under DORA oversight (Regulation (EU) 2022/2554, Article 37). As a regulated entity, you still feel the impact because your critical providers may need your coordination to respond.

What information will the Lead Overseer ask for most often?

The text explicitly includes contracts, policies, documentation, ICT security audit reports, ICT-related incident reports, and outsourcing-chain information (Regulation (EU) 2022/2554, Article 37). Build your evidence library around those categories first.

How do we handle confidentiality or customer data in a response pack?

Use a documented triage and Legal review step before submission, with a recorded decision on redactions and disclosure constraints. Keep an approval trail showing who authorized each sensitive disclosure.

What if our subcontractor inventory is incomplete?

Treat that as a priority gap because Article 37 explicitly reaches outsourced operations information (Regulation (EU) 2022/2554, Article 37). Start with service-to-subcontractor mapping for the most critical services and tie updates to change management.

Can we respond with policies only, or do we need operational records too?

Article 37 enumerates operational records like audit reports and incident reports in addition to policies (Regulation (EU) 2022/2554, Article 37). Assume policies without supporting records will trigger follow-up questions.

How should we prove what we sent and when?

Keep a request log, a versioned evidence index, approval records, and delivery confirmation in a controlled repository. That audit trail is often as important as the documents themselves during reviews.

Footnotes

1. Regulation (EU) 2022/2554, Article 37