What Article 33 asks the Lead Overseer to assess at a critical provider
Article 33 makes the Lead Overseer the primary point of contact for each critical ICT third-party service provider assigned to it, and requires the Lead Overseer to assess whether that provider has comprehensive, sound and effective arrangements to manage the ICT risk it may pose to financial entities. The assessment focuses mainly on services that support critical or important functions. For a financial entity, this means the provider's controls matter most where a failure would disrupt a function the entity depends on. For a designated provider, it means the Lead Overseer will look beyond your own contracts and into the arrangements that serve the whole financial sector. The risk Article 33 addresses is concentration. When many financial entities rely on the same cloud platform, software vendor or data center operator, a weakness at that provider can spread across banks, insurers and payment firms at once. The difficulty for the provider is that the evidence the Lead Overseer needs sits across many functions: security operations, facilities, risk management, governance, incident handling, data engineering and internal audit. No single document answers the question, so a provider preparing for oversight should first map which owners hold which evidence and confirm how quickly each can produce it.
DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure, so it can help prepare the systems, configurations, logs and written records that a provider or financial entity would later present. DeployOpen does not issue reports, assessments or opinions on any provider. The Lead Overseer and its joint examination teams conduct the assessment, and the provider's own governance and independent auditors supply the assurance. Before engaging anyone, ask the Lead Overseer or the relevant competent authority which documents they expect, in what format, and on what timetable, and confirm these points against the Regulation text in the official Article 33 text.
Which providers and services fall under Article 33 oversight
Article 33 oversight applies only to ICT providers the ESAs have designated as critical, and within those providers it focuses mainly on services that support critical or important functions. The cards below cover the scoping decisions that determine which services, group entities and subcontractors enter the assessed chain and how much evidence the provider must assemble.
Designation under Article 31
Article 33 applies to a provider only after the ESAs have placed it on the critical list and assigned a Lead Overseer. A provider that is not designated falls outside the Lead Overseer's assessment, but its customers still apply Article 28 and Article 30 to the contract. Check the current designation list before scoping, because the list is updated each year and the provider's status determines whether it must answer Lead Overseer requests directly.
Services supporting critical functions
The Lead Overseer focuses mainly on services that support critical or important functions, not on every product the provider sells. Map which of the provider's services a financial entity uses for those functions, then build the evidence set around those services. A provider with a broad catalog may need separate security, continuity and testing evidence for each service in scope, so ask customers to name the services they rely on.
Group entities inside the chain
Affiliates of a critical provider that run parts of the service, host infrastructure or operate support teams can fall inside the assessed chain. Confirm which legal entity delivers each part of the service, where it operates, and which entity signs the contract with the financial entity. Evidence for an affiliate that is not named in the designation can still be needed if it carries out work the Lead Overseer assesses.
Subcontractors in the service chain
Subcontractors that deliver ICT services supporting the critical function change the risk picture the Lead Overseer examines. Build a current map of each subcontractor, the function it performs, its location and the data it touches. Article 33 assessments and recommendations on subcontracting depend on this map, so an outdated list weakens every other piece of evidence.
Open-source and self-hosted components
When a critical provider builds its service on open-source or self-hosted components, those components become part of the assessed service even though no vendor is paid for them. Record which components run in production, which version each runs, who maintains patches, and which parts the provider operates itself. Gaps in this inventory are a common reason evidence requests come back incomplete.
Third-country providers and EU subsidiaries
A critical provider established outside the EU may have to act through an EU subsidiary under the designation rules. Confirm which legal entity holds the designation, which entity operates the service inside the Union, and where data and support staff sit. These facts decide who can produce audit evidence and where information requests are sent.
How each assessed area in Article 33(3) is tested
The Lead Overseer wants to see that the provider protects the confidentiality, integrity and availability of the services it delivers to financial entities, and that those services hold up under load, failure and attack. In practice the question is whether security is designed into the service and whether the provider can show it running, not only written down. Physical security sits in the same area, so data center access controls and environmental protections are part of the picture.
- Security policy and control design: Current information security policies, control descriptions and how they map to the service scope.
- Availability metrics: Uptime and performance reports for the services used by financial entities, with the method used to calculate them.
- Capacity and scalability records: Load test results and capacity plans showing how the service behaves at peak demand.
- Physical security evidence: Facility access logs, visitor controls and third-party reports covering data centers.
- Vulnerability and patch records: Reports showing how quickly critical findings were remediated over the review period.
Before relying on any of this, confirm with the provider which services and locations the evidence covers, since a report for one region or product line may not describe the service your firm uses.
Here the Lead Overseer examines whether the provider can keep critical services running through disruption and recover them within the limits financial entities depend on. Continuity is tested through plans, their documented scope and actual exercises, not through the existence of a plan alone. Scalability asks whether the service can grow with demand without degrading quality for customers.
- Business continuity and disaster recovery plans: Current plans with defined recovery objectives for each service supporting critical or important functions.
- Exercise records: Reports from recent failover, restoration and tabletop exercises, including the findings and the fixes that followed.
- Redundancy architecture: Diagrams and descriptions of how components, sites and dependencies are duplicated or isolated.
- Backup and restore tests: Logs showing restore tests were performed and what data was recovered.
- Dependency mapping: Records of the subcontractors and infrastructure that continuity depends on.
Ask for the most recent exercise report and check whether it tested the scenario your organization would actually face, such as loss of a region or a failed key subcontractor.
This area asks whether the provider manages ICT risk through clear accountability, a structured process and oversight by senior management. The Lead Overseer looks for evidence that risk is identified, owned, reported and acted upon at the right level of the organization, and that the people responsible have the authority and resources to do their jobs.
- Governance structure: Organization charts, committee terms of reference and named accountable executives for ICT and security.
- Risk management framework: The methodology, risk register and how risks are escalated and accepted.
- Board or management reporting: Minutes and dashboards showing that senior management reviewed ICT risk.
- Policy approval records: Evidence of who approved key policies, when, and when they were last reviewed.
- Issue tracking: A log linking identified risks to remediation owners and due dates.
Check whether the people who sign the policies are the same people who are accountable for their operation, because a gap there often signals weak oversight.
The Lead Overseer assesses how the provider identifies ICT incidents affecting financial entities and how it informs them in time for those entities to meet their own reporting duties. The emphasis is on the provider's detection, classification and communication processes, and on whether the information it passes on is accurate enough to be useful.
- Incident management procedure: A written process covering detection, triage, escalation, communication and closure.
- Notification timelines: Documented commitments to customers and the records showing how they were met.
- Incident register: Past incidents with root cause, impact on financial entities and corrective actions.
- Post-incident reviews: Reports that show lessons were recorded and that changes followed.
- Communication templates: Samples of the information provided to customers during an incident.
Confirm with the provider how it classifies incidents and whether that classification lines up with the thresholds your own incident process uses.
Portability asks whether a financial entity can move its data and applications to another provider or back in-house without losing information or depending on proprietary formats. Interoperability asks whether the service works with other systems through open and documented interfaces. The Lead Overseer looks at whether these features are real in practice, not only promised in the contract.
- Data export capability: Documented export formats, tools and the scope of data covered.
- Interface documentation: Current API specifications and integration guides.
- Migration test records: Evidence that data or workloads were actually moved or restored elsewhere.
- Exit assistance terms: The support the provider commits to during a transition, stated in the contract.
- Format standards: Use of widely adopted, documented data formats rather than proprietary encodings.
A useful test is to ask for a sample export and check whether it can be read without the provider's software.
Here the Lead Overseer checks whether the provider tests its own controls and whether independent reviews back up its claims. Testing covers security testing, resilience testing and the handling of findings. Audits cover internal audit work and independent third-party assurance. The Lead Overseer may take into account third-party certifications and audit reports the provider makes available, but it will look at their scope and what they actually cover.
- Penetration and security test reports: Summaries of recent tests, their scope and the status of findings.
- Resilience test records: Results from recovery and failover tests against the services in scope.
- Internal audit plans and reports: Coverage of ICT areas and the follow-up on audit findings.
- Independent assurance reports: Third-party audit or certification reports, with their scope statements and period covered.
- Remediation tracking: Evidence that findings were closed, with dates and verification.
Read the scope and period sections of any assurance report first, since a clean opinion over a narrow scope says little about the service a financial entity uses.
The final area asks whether the provider uses recognized national and international standards to structure its controls and management practices. The Lead Overseer is not looking for a logo. It wants to know which standards the provider follows, how it maps its controls to them and whether that mapping is kept current and checked against reality.
- Standards in use: A list of the frameworks and standards the provider applies to the services in scope.
- Control mapping: A documented link between the provider's controls and the requirements of each standard it claims.
- Scope statements: The boundaries of any certification or assessment that references a standard.
- Change history: Records showing that mappings were updated when standards or services changed.
- Gap analysis outputs: Results of internal reviews against the standards, with planned remediation.
When a provider cites a standard, ask which version it follows and which services fall inside its scope, because both answers change what the claim proves.
How the annual individual oversight plan shapes the year
The reasoned individual oversight plan under Article 33(4) sets the annual objectives the Lead Overseer will pursue at each critical ICT third-party provider it is assigned. The plan is drafted first and communicated to the provider as a draft, which means the provider gets a window to read the proposed objectives before they are fixed. Treat that draft as the start of the year's oversight cycle, not as a formality. Before it arrives, the provider should have a current map of its services that support critical or important functions, the contract clauses and audit commitments each financial entity relies on, and the certifications, audit reports and test results it could offer as evidence. Assign one owner to receive the draft, confirm the contacts named in it, and set a deadline internally that leaves time for review by legal, security and the service lines affected.
The provider may submit a reasoned statement within 15 calendar days of receiving the draft, explaining the impact the proposed plan would have on customers outside DORA's scope. That right is narrow but useful. A provider serving non-financial customers, or financial customers under other regimes, can explain where an objective would require changes that affect those customers and why. The statement needs to be specific: name the objective, describe the operational or contractual consequence, and propose an alternative or a sequencing change where one is feasible. Build the 15-day clock into the internal calendar from the day of receipt, and confirm with the Lead Overseer how it expects statements to be delivered. The exact procedure should be confirmed in the Lead Overseer's own communications and the applicable regulatory technical standards, not assumed.
Article 33(5) changes how the rest of the supervisory system deals with the provider. Once the annual oversight plans are adopted and notified, competent authorities may take measures concerning a critical provider only in agreement with the Lead Overseer. In practice, a national authority that wants to act on a provider's services cannot simply open its own track for the year. Providers should therefore keep one consistent evidence set and one set of answers across the Lead Overseer and the competent authorities of their financial customers, so that objectives agreed in the plan are not undermined by inconsistent statements elsewhere. Ask the Lead Overseer which points of contact will coordinate with national authorities, and record every request that arrives through another channel so it can be reconciled with the plan.
How a critical provider prepares for Lead Overseer assessment
This sequence turns Article 33 into a working file the provider can defend: a service map, an evidence index against the assessed areas, named owners, an internal review, a response process for the draft oversight plan, and a refresh cycle that keeps the evidence current between assessments.
Map services to critical or important functions
Start by listing every ICT service the provider delivers to financial entities and tagging each one by the critical or important functions it supports. Article 33(2) focuses the Lead Overseer's assessment mainly on services supporting those functions, so this map decides where the depth of evidence must go. Involve product, operations and the teams that hold customer contracts, because the functions a service supports are often defined by the customer rather than the provider. The output is a service map that links each service to its supported functions, the customer entities that rely on it, and the subcontractors in its delivery chain. The step is complete when each in-scope service has a documented owner and a stated function mapping that a reviewer can trace.
Build the evidence index against Article 33(3)
Create an evidence index organized by the areas Article 33(3) names: security, availability, continuity, scalability and quality of services, physical security, risk management processes, governance, incident identification and reporting, data and application portability and interoperability, testing, ICT audits, and use of national and international standards. For each area, record the policy or procedure, the control or measurement that operates it, the artifact that proves it ran, and the date it was last reviewed. Gaps should be logged rather than hidden, since an index with visible gaps and remediation owners is more credible to an assessor than one that claims full coverage. The output is an evidence index the team can hand over in a structured form. The step is complete when every area has at least one referenced artifact or a logged gap with an owner.
Assign owners for each area and artifact
Assign a named owner to every area in the evidence index and a backup for each one. Owners are usually senior staff who run the control, such as the head of security for security testing results, the continuity lead for recovery exercises, and the legal or contracts lead for customer terms and portability commitments. Make clear that the provider owns its controls and evidence, and that any outside partner supports preparation without taking over those roles. The output is an ownership register that shows who answers questions during assessment and who approves each artifact. The step is complete when no area lacks an owner and each owner has confirmed the artifacts they are responsible for.
Run an internal review before the assessment
Test the evidence index as an assessor would. A reviewer who did not build the index should pick samples from each area, ask for the underlying record, and check that it matches what the index claims. Look for artifacts that are out of date, policies that describe a process nobody runs, and incident or test records that do not reconcile with each other. Record every finding with a severity, an owner and a corrective action. The output is an internal review report with a findings log and a remediation status for each item. The step is complete when high-severity findings are closed or have an approved plan, and the review has been signed off by the accountable executive.
Prepare the response process for the draft oversight plan
Article 33(4) requires the Lead Overseer to communicate a reasoned individual oversight plan with annual objectives in draft first, and the provider may submit a reasoned statement on the impact of the plan on customers outside DORA's scope. Set up a response process before a draft arrives: a designated contact, a review group drawn from security, legal, operations and customer teams, a decision path for what goes into the statement, and a record of the reasons behind each position. Confirm the exact response window and submission route with the Lead Overseer or the provider's regulatory counsel, because the Regulation's timing is the authoritative source. The output is a documented response procedure with templates for the reasoned statement. The step is complete when the procedure has been walked through once in a tabletop exercise.
Set a recurring evidence refresh cycle
Oversight is an ongoing relationship rather than a single event, so the evidence index needs a refresh cycle with fixed triggers. Set a regular review of each artifact, plus event-driven updates after major incidents, significant architecture changes, new subcontractors, and results of testing or audits. Track changes in a version log so the provider can show what changed and why. Assign a single coordinator to keep the index, the ownership register and the response procedure aligned. The output is a refresh calendar and a change log. The step is complete when the first refresh cycle has run and the coordinator has reconciled the index against the service map.
How the Lead Overseer tests the arrangements
This table compares each area the Lead Overseer assesses under Article 33(3), the test approach it typically takes, the evidence it will ask for, and the findings that often come up. Read it as a preparation checklist for a critical provider, not as a statement of what any specific oversight plan contains. The Lead Overseer may also take into account third-party certifications and audit reports the provider makes available, so well-organized assurance material can shape how much testing is needed.
| Assessed area | Likely test approach | Evidence to prepare | Common findings to address |
|---|---|---|---|
| Security, availability, continuity, scalability and quality of services | Document review, information requests, and inspection of service design and operating records | Service level records, capacity plans, business continuity and disaster recovery test results, quality metrics | Continuity tests that do not cover the services supporting critical or important functions |
| Physical security | On-site inspection of data centers and facilities used for the services | Facility access controls, visitor logs, environmental monitoring, physical security audit reports | Access arrangements for subcontracted facilities not covered by the provider's own review |
| Risk management processes | Document review and interviews with risk owners | ICT risk framework, risk registers, treatment decisions and their approval records | Risk decisions that cannot be traced to a named owner or a documented review cycle |
| Governance | Review of management body oversight and reporting lines | Board or management minutes, accountability matrices, policy approval records | Oversight of ICT risk that is not visible at management body level |
| Incident identification and reporting to financial entities | Information requests and review of incident records and notification samples | Incident logs, notification timelines, samples of communications sent to financial entities | Gaps between the provider's detection and the time financial entities are informed |
| Data and application portability and interoperability | Review of technical documentation and, where needed, a demonstration of data export | Export formats, interface documentation, exit and migration test records | Exit arrangements that have not been exercised or that depend on proprietary formats |
| Testing and ICT audits | Review of testing programmes and audit reports, with sampling of findings | Test plans, test reports, remediation tracking, internal and external audit reports | Findings closed without evidence, or audit scope that excludes critical services |
| Use of national and international standards | Mapping of the provider's controls to the standards it adopts and review of any certificates | Certificates, assessment reports and statements of applicability, with their scope clearly stated | Certificates whose scope does not cover the services used by financial entities |
Evidence that satisfies a Lead Overseer assessment
The Lead Overseer assesses a critical provider against the areas listed in Article 33(3), and most of those areas are tested through documents and records rather than interviews alone. The artifacts below are the ones a provider can keep ready between annual cycles, so that an information request or joint examination does not start from zero.
Service inventory and dependency map
A current list of every service the provider delivers to financial entities, mapped to the components, subcontractors, data stores and locations that support each one. Assessors use it to test concentration and to see which services support critical or important functions. Refresh it on every material change to hosting, subcontracting or a service boundary, and reconcile it against the registers of information that financial entities hold about the provider. Confirm who owns each entry and when it was last checked.
Continuity and exit documentation
Business continuity plans, recovery objectives, test records for failover and restoration, and exit plans for each service supporting a critical function. Article 33(3) asks how the provider manages continuity, scalability and availability, so the plan must show tested results, not only intent. Re-test after major architecture changes, and record which exit scenarios were rehearsed and what gaps remained open.
Incident reporting records
Logs of incidents affecting financial entities, with timestamps, classification, notifications sent to clients, root cause analysis and corrective actions. The Lead Overseer checks how the provider identifies incidents and reports them to the entities it serves. Keep the records in a form that can be exported quickly, and review open actions monthly so that repeated causes are visible before the next assessment.
Test reports
Results from security testing, resilience testing and any threat-led testing the provider has taken part in, with the scope, findings, remediation status and retest evidence. Testing is one of the areas named in Article 33(3). Store each report with its scope statement so an assessor can see what was and was not covered, and log remediation dates against each finding.
Audit reports and certifications
Independent audit reports, certificates and assessment letters that cover the provider's services, together with the scope, period and any exceptions they contain. Article 40 allows the Lead Overseer to take account of third-party certifications and audit reports the provider makes available, but only where the scope matches the services in question. Track expiry dates, bridge letters for gaps in coverage, and open exceptions in one register.
Portability and standards mapping
Documentation of data and application export formats, interoperability interfaces, and a mapping from the provider's internal controls to the national and international standards it uses. Article 33(3) covers portability, interoperability and the use of standards. Update the export test results and the mapping whenever a format, API version or control set changes, and state which parts of each mapping are the provider's own assertions.
What meeting Article 33 costs in money and effort
This table breaks down the cost components around Article 33 oversight, showing who pays for each one, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for a written scope and quote, not as a price estimate. The main takeaway is that the provider carries most of the oversight fees, while the financial entity and the provider both bear internal effort that depends on how well their evidence is organized.
| Cost component | Who carries it and what it covers | One-time or recurring, and what drives it |
|---|---|---|
| Internal engineering time to build the evidence set | The critical provider's engineering, security and operations teams assemble evidence for security, continuity, portability and incident reporting | Mostly one-time to build, then recurring to refresh. Driven by the number of services in scope, system age and how much evidence already exists |
| Governance time for the reasoned statement | Management body and legal staff prepare any reasoned statement on the draft individual oversight plan, which must be submitted within 15 calendar days under Article 33(4) | Recurring each oversight cycle. Driven by how many customer-impact points the provider needs to raise and how quickly legal review can happen |
| External testing or review | Third-party testers or reviewers the provider engages to support testing and audit areas named in Article 33(3) | Recurring, usually tied to the test calendar. Driven by the depth of testing, the number of systems covered and whether results can be reused |
| Audit and certification fees the provider already carries | Independent auditors and certification bodies that the provider engages for its own reports, which the Lead Overseer may take into account | Recurring on the audit cycle set by each report or certificate. Driven by the number of audited scopes, so keeping one clear scope reduces duplication |
| Joint examination support effort | Provider staff who answer requests and host visits from the joint examination team that assists the Lead Overseer under Article 40 | Episodic, arising during investigations or inspections. Driven by the number of requests, the readiness of documents and any follow-up required within the 3-month recommendation window |
| Financial entity internal effort | The financial entity's own staff maintain register data, contract terms and exit plans that depend on the provider's oversight outcomes | Recurring. Driven by how many critical or important functions depend on the provider and how often contracts are updated |
| Written scope and quote | Ask any implementation partner for a written scope listing systems, evidence sets, testing and support, with deliverables and timelines agreed before work starts | One-time per engagement, with optional retainers for ongoing support. Ask for each cost component to be itemized so you can compare options |
Who does what: the provider, a partner and the Lead Overseer
The critical ICT third-party service provider remains the owner of its services, controls and risk. Article 33 makes the Lead Overseer its primary point of contact, and the provider must give the Lead Overseer the information it asks for during the assessment of security, continuity, governance, incident reporting, portability, testing, audits and standards. The provider answers for the accuracy of what it submits, and it is the party that receives draft oversight plans and may send a reasoned statement on the impact on customers outside DORA's scope.
- Owns the controls: The provider runs its own ICT risk management, continuity arrangements and incident processes, and it cannot hand these to a consultant.
- Responds to requests: It answers information requests and supports on-site or remote work by the joint examination team.
- Receives the oversight plan: It sees the reasoned individual oversight plan with annual objectives in draft form and may respond within the period set out in Article 33(4).
- Provides audit reports and certifications: Third-party certifications and audit reports the provider makes available may be taken into account by the Lead Overseer.
- Acts on recommendations: It implements the remediation the Lead Overseer recommends.
Before engaging anyone, confirm with the provider which internal teams own each assessment area and which documents it already keeps current.
An implementation partner helps a provider prepare for oversight by organizing systems, controls and evidence so that the provider's own staff can answer the Lead Overseer accurately. This work is preparatory. The partner does not assess the provider, does not decide whether it meets Article 33, and does not issue any report or certificate. Only the ESAs, competent authorities and independent auditors reach those conclusions.
- Evidence preparation: Mapping configuration, logs, backup records, continuity test results and incident records to the areas the Lead Overseer examines.
- Documentation support: Drafting or revising procedures that the provider's management then reviews and approves.
- Technical testing: Running security and resilience tests on the provider's systems, with results owned by the provider.
- Remediation support: Fixing gaps the provider identifies, with changes recorded for later review.
- Independence boundary: Any partner that also performs the assessment for the same provider weakens the separation the process depends on.
Ask any partner for a written scope that names the deliverables, states that it issues no attestation, and confirms who signs off each piece of evidence.
The Lead Overseer is one of the European Supervisory Authorities assigned to a critical provider. It is the provider's primary contact, it runs the assessment under Article 33, and it prepares the individual oversight plan. Under Article 40, a joint examination team made up of ESA and competent authority staff supports the Lead Overseer for each critical provider. Recommendations follow within 3 months of an investigation or inspection. Once plans are adopted and notified, competent authorities may act on critical providers only in agreement with the Lead Overseer.
- Assessment and plan: The Lead Overseer assesses the areas listed in Article 33(3) and sets the annual objectives in the oversight plan.
- Joint examination teams: These teams carry out investigations and inspections, drawing on the ESAs and national authorities.
- Recommendations: Findings become recommendations, and the Lead Overseer decides how to weigh third-party certifications and audit reports.
- Coordination with authorities: Competent authorities coordinate with the Lead Overseer on any measures they consider.
- Scope of operating rules: Delegated Regulation (EU) 2025/420 sets out how joint examination teams work, so check its provisions before planning a review.
An implementation partner can help the provider prepare for these reviews, but the outcomes come from the supervisors alone.
Where providers fall short in Lead Overseer reviews
Article 33 asks the Lead Overseer to judge whether a critical provider has sound arrangements across security, continuity, governance, incident reporting, portability, testing, audits and standards. The gaps below recur when providers prepare for that review, and each one is visible in evidence the provider already holds. Closing them before the Lead Overseer asks is cheaper than reconstructing records under examination.
Unclear mapping of services to critical functions
The Lead Overseer focuses mainly on services that support critical or important functions, so a provider must show which of its services feed which functions of which financial entities. Where that mapping exists only in sales material or in one account manager's head, the assessment starts from a weaker position. Check that every in-scope service has a documented link to the financial entity functions it supports, that the mapping is versioned, and that it matches the contractual service descriptions.
Evidence scattered across teams
Security reports sit with the security team, uptime data with operations, audit reports with legal, and incident history with support. When the Lead Overseer requests evidence for one assessment area, the provider may need weeks to assemble a coherent answer. Name a single owner for each Article 33(3) area, agree on a shared evidence index, and test whether one person can produce the current package for one area within a working day.
Weak incident reporting records
Article 33(3) includes how a provider identifies and reports incidents to the financial entities it serves. Gaps appear when timestamps are missing, severity changes are not logged, or notifications to customers cannot be matched to the underlying tickets. Check that each incident record carries detection time, customer notification time, classification history and root cause, and that a sample of past incidents can be traced end to end.
Stale continuity tests
A business continuity plan with a test record from several years ago does not show that the provider can keep services available under stress. Reviewers look at when each recovery scenario was last exercised, what it covered, and what the test found and how it was fixed. Confirm that recovery objectives in the contracts match tested recovery times, and that each finding from the last exercise has a closed action with a date.
Missing portability documentation
Article 33(3) covers data and application portability and interoperability, which the financial entity relies on when moving away from a provider. Providers often have no written export format, no tested data extraction procedure, and no description of the dependencies a customer would need to replicate. Document the export formats and schemas, run an extraction for a representative dataset, and record the time and steps taken so the result can be shown to the reviewer.
Questions about Article 33 oversight and preparation
Does a critical ICT provider have to act before the ESAs designate it?
Article 33 applies to a provider once it has been designated, so the article itself creates no duty to act earlier. Preparing before designation is still sensible, because the Lead Overseer assesses the arrangements behind services that support critical or important functions, and the draft oversight plan follows that assessment. Use the interval to map the areas listed in Article 33(3), including security, continuity, governance, incident reporting, portability, testing, audits and standards, against the evidence you already hold. Each gap you find early gives you more time to close it. Confirm the expected timeline and any interim expectations with the Lead Overseer once designation is known.
How much effort does Article 33 evidence preparation take, and what drives it?
No researched figure is available for this, so the effort depends on your own estimate from a written scope. The main drivers are the number of services that support critical or important functions, how many of those services are already covered by recent independent audit reports or certifications, and how complete your documentation is for each area in Article 33(3). Effort also rises with the depth of your subcontracting chain, the number of financial entity clients you serve, and whether data portability and exit arrangements have been tested rather than only written down. Ask any partner to break its estimate down by service and by assessment area, and to state which items it expects you to produce yourself.
Can a critical provider prepare for Article 33 oversight in-house?
Many providers can prepare in-house, especially where security, audit and governance teams already produce regular evidence. The provider owns its controls and remains responsible for them, and it needs staff who can run the testing, document the portability and continuity arrangements and answer the Lead Overseer's information requests. Gaps usually appear in areas that are rarely reviewed together, such as physical security evidence, subcontractor oversight and incident reporting to financial entities. An outside partner can prepare systems and evidence and run a gap analysis, but it cannot issue audit reports or attestations. Independent auditors and the supervisory authorities make the assessment. Decide which functions need outside support by comparing your internal capacity with the areas in Article 33(3).
What does a partner scope for Article 33 readiness usually include?
A written scope normally follows the areas named in Article 33(3) and turns each one into deliverables. Typical items include a gap analysis of current arrangements, an inventory of the services and subcontractors in scope, evidence packs for security, continuity and governance, documentation of data and application portability, a review of incident reporting to financial entities, and a plan for resilience testing and audit coordination. A partner may also help prepare materials for the joint examination team described in Article 40. Each deliverable should name the owner, the acceptance criteria and the dates agreed before work starts. Ask for an explicit list of what the partner will not produce, including any reports or attestations that only an independent auditor can issue.
How does the 15-day reasoned statement on oversight plans work?
Under Article 33(4), the Lead Overseer must communicate a draft individual oversight plan to the provider first. The provider may then submit a reasoned statement within 15 calendar days, explaining the impact the plan would have on customers outside DORA's scope. The window is short, so the material should exist before the draft arrives. Prepare a customer impact analysis that lists which of your clients fall outside DORA, how the planned objectives would affect them, and what alternatives or mitigations you propose. Keep the statement factual and tied to specific objectives in the draft. Check the exact procedure, format and contact point with the Lead Overseer when you receive the draft.
What would the Digital Omnibus proposal change for Article 33 oversight?
The Commission's Digital Omnibus proposal, COM(2025) 837 of 19 November 2025, would amend DORA Article 19 so that major incident reports and voluntary threat notifications go through a single entry point under NIS2. As of October 2026, the European Parliament's Legislative Observatory lists the procedure 2025/0360(COD) as awaiting committee decision. The supplied material describes changes to Article 19 only, so it does not establish any change to Article 33. Treat the proposal as a reason to review incident reporting routes, not as a reason to delay oversight preparation. Have counsel confirm whether any other provision is affected once the text is final, and track the procedure until it is adopted.
How DeployOpen prepares systems and evidence for Article 33 readiness
DeployOpen works on Article 33 readiness as an implementation partner. We prepare the systems, controls and evidence a critical ICT provider would present to its Lead Overseer, inside the provider's own infrastructure. The Lead Overseer and the independent auditors remain the parties that assess and report.
How we scope
- Engagements are fixed-scope, with the areas of Article 33(3) to cover agreed in writing before work starts.
- The written scope names the services supporting critical or important functions that fall within the Lead Overseer's focus.
- Each scope lists which evidence items the provider will hold, and which items the provider's own auditors or assessors must supply.
How we build
- We implement and harden the self-hosted open-source platforms in scope within the provider's own cloud accounts, data centers or air-gapped networks.
- We configure logging, access controls, backup and recovery, and incident reporting workflows so the required records can be produced on request.
- We map each assessed area to the technical controls, owners and records that show how it operates in practice.
How we hand over
- We deliver documentation covering architecture, controls, runbooks and the evidence index for each area in scope.
- We run agreed testing and document the results, remediation status and any open items the provider must decide on.
- We transfer ownership of systems, credentials and documents to the provider's team, who remain accountable for the controls.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, separate from the initial fixed-scope work.
- Ask us to confirm in the quote which upgrade, backup and documentation tasks recur and how they are priced.
- Confirm with your independent auditor or the relevant competent authority which evidence formats they will accept before we build.
