In November 2024, a critical cloud provider published a notice on its trust portal: a sub-processor in a non-adequate jurisdiction had been added to the data-handling chain for one of its core services. The notice was three sentences long, posted on a Saturday afternoon. The financial entities relying on that service had two months until DORA took effect. Several of them were still mapping their critical ICT third parties.

The Digital Operational Resilience Act took effect across the European Union on 17 January 2025. It applies to almost every entity in the EU financial sector, including banks, payment institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, and trading venues. It also reaches deep into the supply chain that supports those entities. Critical ICT third-party service providers are now in scope of direct EU oversight, and every in-scope financial entity is required to maintain an up-to-date register of contractual arrangements, monitor concentration risk, manage incidents end-to-end, and report major incidents to their competent authority within hours.

DORA is enforceable, prescriptive, and unforgiving on documentation. The cost of missing a sub-processor change, a status page outage, a DPA amendment, or an ESA guidance update is no longer abstract. It is a citation in your next supervisory review, or worse, a penalty under Article 50.

This guide covers what DORA actually requires in practice, where the monitoring obligations sit, which third parties and regulatory sources to track, how to set up automated monitoring with PageCrawl, and how to turn detected changes into the kind of audit trail a competent authority expects to see.

What DORA Actually Requires

DORA is structured around five operational pillars. Each pillar generates monitoring obligations that, in most organizations, used to be split across compliance, security, procurement, and IT. Under DORA they have to be unified.

ICT risk management framework

Article 5 through Article 16 require every financial entity to maintain a documented ICT risk management framework that is reviewed at least annually and after every major ICT-related incident. The framework has to cover identification, protection and prevention, detection, response and recovery, learning and evolving, and communication.

The monitoring implication is that every assumption you make about a third-party provider, the security controls they advertise, the regions they operate in, the sub-processors they engage, has to remain accurate. If a provider quietly changes any of these, your framework documentation drifts out of alignment with reality and your next supervisory review will catch it.

ICT-related incident management and reporting

Article 17 through Article 23 require classification, management, and reporting of ICT-related incidents. Major incidents must be reported to the relevant competent authority through three notifications: an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month.

The monitoring implication is twofold. First, you need to detect incidents at your providers as fast as your provider does, ideally before. Status page outages, security advisories, RCA publications, and CVE bulletins are the leading indicators. Second, every change to your incident response procedures has to be tracked, since the regulators will want to see version history.

Digital operational resilience testing

Article 24 through Article 27 require every financial entity to test its ICT systems and tools at least annually, with threat-led penetration testing every three years for entities identified as significant. Test results, lessons learned, and remediation plans must be documented and shared with competent authorities on request.

The monitoring implication is that any change at a critical provider that could invalidate prior test conclusions, a new sub-processor, a region change, an authentication-flow update, has to surface immediately. If you tested resilience against provider X under configuration Y, and provider X moves to configuration Z without notice, your test conclusions are stale.

ICT third-party risk management

Article 28 through Article 30 are the heaviest monitoring obligation. Every financial entity must maintain a register of all contractual arrangements with ICT third-party providers, classify the criticality of each, perform pre-contractual due diligence, monitor performance and risk continuously, and conduct exit strategies for critical functions.

Article 28(3) is explicit: financial entities must include in their register, among other things, "any subsequent material changes" to the contractual arrangement. The register must be updated on a continuous basis, not annually, not quarterly. The European Supervisory Authorities published Implementing Technical Standards on the register format in 2024 and the templates have been refined since.

The monitoring implication is that every public-facing artefact a critical provider publishes (sub-processor list, DPA, security whitepaper, regional availability matrix, certification status, sub-contractor disclosures) is part of your contractual context. When any of these change, your register has to reflect the change, often within days.

Information sharing

Article 45 establishes voluntary information-sharing arrangements among financial entities for cyber threat intelligence. Many trade associations and ISACs have published frameworks; the relevant ones depend on your sector.

The monitoring implication is the lightest of the five but still matters. ENISA, ESAs, and sector ISACs publish threat advisories, vulnerability notices, and best-practice updates on a continuous basis.

What to Monitor for DORA Compliance

The monitoring obligations under DORA do not divide neatly into "things our team writes" and "things vendors publish". The bulk of evidentiary material a competent authority will inspect comes from external sources that your team has no control over. The most cost-effective DORA monitoring program combines internal change tracking with disciplined external monitoring of providers and regulators.

Critical ICT third-party providers

Every entity classified as a critical ICT third-party provider, and every entity supporting a critical or important function at your institution, is in scope. The pages worth tracking on each provider include:

Sub-processor lists. Sub-processor changes are typically the trigger for a customer-notification clock under your DPA, often 30 days. Providers publish sub-processor changes on a dedicated page, an RSS feed, or buried inside the trust center. Examples include the AWS sub-processor list at aws.amazon.com/legal/sub-processors, the Stripe SSA at stripe.com/legal/ssa, the Microsoft Online Services Subprocessors page, and the equivalent for every SaaS in your stack.

Data Processing Addenda and contractual terms. DPAs, MSAs, AUPs, and SLAs change more often than most procurement teams notice. A provider may substantively amend a DPA section on cross-border transfers without sending an email. Watch the canonical DPA URL each provider publishes.

Trust centers, security whitepapers, and certifications. Loss of an ISO 27001 certification, expiry of a SOC 2 attestation, or a change in certification scope is material under DORA's continuous risk management requirement. Watch the trust center page where certifications are listed and dated.

Status pages and incident postmortems. Real-time outage notices and root-cause analysis publications are leading indicators for incident-reporting obligations under Article 19. Most providers maintain their status page at status.{provider}.com or an equivalent subdomain. Many also publish RCAs in a separate "incidents" or "post-incident review" path.

Regional and operational disclosures. Providers regularly publish regional availability changes, data residency tier additions, and operational practice updates. These can change the regulatory profile of a service. Monitor the trust portal and the cloud regions/availability page.

Certifications and compliance attestations. Many providers publish a real-time list of their compliance certifications at trust.{provider}.com or compliance.{provider}.com. A change here, especially the removal of a previously claimed certification, is an immediate concern.

European Supervisory Authorities and competent authorities

DORA is administered jointly by the three ESAs: EBA (banking), ESMA (markets), and EIOPA (insurance and pensions). National competent authorities enforce on the ground and frequently publish supplementary guidance. Pages worth tracking include:

EBA single rulebook page on DORA at eba.europa.eu/regulation-and-policy/operational-resilience. The EBA publishes consultation papers, final RTS and ITS, opinions, and Q&A.

ESMA DORA pages at esma.europa.eu, particularly the operational resilience workstream, the ITS register templates, and the consultation paper archive.

EIOPA DORA workstream for insurance entities. Useful even for non-insurance entities because the ESAs publish joint RTS that EIOPA frequently summarizes.

National competent authority pages. Each EU member state's banking, securities, and insurance regulators publish DORA implementation guidance. Examples include BaFin in Germany, AMF and ACPR in France, the Central Bank of Ireland, the Bank of Italy, the Spanish CNMV and Bank of Spain.

ENISA bulletins at enisa.europa.eu. ENISA publishes threat landscape reports, sector-specific advisories, and cooperation guidance that ESAs frequently incorporate by reference.

The Joint ESAs publications page at esas-joint-committee.europa.eu, which is the primary distribution point for joint ESA reports, RTS, and ITS that apply across all three ESAs.

Critical ICT third-party providers designated under Article 31

The ESAs maintain and publish a list of critical ICT third-party providers (CTPPs) designated under Article 31. The list itself is a moving target as more providers are designated. Watch the published CTPP list page on the EBA, ESMA, and EIOPA websites for additions and removals. Designation changes the regulatory perimeter your entity operates in.

Sector-specific guidance

Beyond the ESAs, most sub-sectors have additional guidance worth tracking. Banking entities watch the EBA Pillar 3 disclosure templates. Trading venues monitor ESMA market structure publications. Payment institutions track the EBA payment services workstream. Insurance entities watch EIOPA outsourcing guidelines as a complement to DORA.

Setting Up DORA Monitoring with PageCrawl

The volume and diversity of pages described above is exactly the kind of monitoring problem that breaks under manual coverage. The pattern that scales is to set up monitoring once, route signals into a single feed, and let AI summaries and importance scoring filter the noise.

Building the third-party register feed

Start with the providers you have already classified as supporting critical or important functions. Add the canonical URL for each artefact (sub-processor list, DPA, trust center, status page, certification page) as a separate monitor, tagged by provider name and artefact type.

A simple tag taxonomy that scales:

• vendor:aws, vendor:stripe, vendor:salesforce, one tag per provider
• artefact:subprocessor, artefact:dpa, artefact:trust, artefact:status, artefact:certs
• criticality:critical, criticality:important, criticality:standard
• function:payments, function:identity, function:hosting, mapped to your internal function register

Tags allow per-tag default settings (frequency, AI brief, notification routing) without duplicating configuration. A status-page monitor on a critical provider can run every 5 minutes; a DPA monitor on a standard provider can run daily. The taxonomy keeps the per-source overhead low.

Telling PageCrawl what your entity looks like

Workspace instructions are the single most underused feature for compliance teams. A short paragraph describing your entity ("A regulated EU payment institution with primary supervision under BaFin, focused on B2B card issuing and SCA compliance, with critical ICT third parties in the cloud-hosting, identity-verification, and KYC categories") changes how the AI summarizes detected changes across every source. The same Stripe SSA update produces a different brief for a payment institution than for an insurance broker, because the AI understands which clauses matter to which entity.

Workspace instructions live under Settings > Workspace > Integrations > AI. Set them once, refine quarterly, and the entire monitoring stack becomes contextual.

Routing signals to the right team

Status pages and incident postmortems should route to operational and security teams in real time. Sub-processor changes and DPA amendments should route to compliance and procurement on a daily summary. ESA and competent authority guidance should route to the regulatory affairs team weekly.

PageCrawl supports per-source notification channels and per-tag defaults, so the routing rules are declarative. Slack and Microsoft Teams handle real-time signals, scheduled email digests handle weekly compliance updates, and webhooks integrate with the GRC system you use to maintain the Article 28 register.

Keeping the audit trail in shape

Every detected change is timestamped and stored with before/after snapshots. The change history is exportable to PDF, Excel, or CSV. For DORA evidence purposes, the most useful pattern is to schedule a monthly export of the full change log per critical provider, attach it to that provider's entry in your register, and retain it for the period your competent authority requires (typically five years).

The change history page is also shareable as a read-only public link. Useful for sharing the timeline of a specific provider's sub-processor changes with your auditor, your legal counsel, or a client, without having to grant a workspace seat.

Tamper-proof attestation in the AI era

In an era when generative AI can fabricate plausible screenshots, HTML pages, and PDFs in seconds, a self-stored archive proves nothing on its own to a supervisory inspection. PageCrawl Ultimate-plan archives are captured as WACZ files with cryptographic attestations from independent providers: an embedded WACZ Auth signature, plus three sidecar timestamp proofs (an OpenTimestamps Bitcoin anchor and two RFC 3161 timestamps from independent commercial Trust Service Providers). Each proof is independently verifiable offline, with no PageCrawl account required.

For EU financial entities that need the strongest available evidentiary credential, eIDAS qualified timestamps under Regulation 910/2014 Article 41(2) are available as a Custom plan add-on. A qualified timestamp carries statutory legal presumption of accuracy of the date and time and of the integrity of the bound data: the answer to a supervisory question of "when did this archive exist". Contact sales to scope the Qualified Trust Service Provider arrangement.

When an inspector asks for a specific provider's portal as it appeared on a specific date, the response is one signed link. The inspector opens it, sees the manifest hash and every cryptographic attestation, and verifies the proofs against public certificate chains and the Bitcoin blockchain without ever touching the firm's systems.

A Worked Example: Article 28 Register Maintenance

The Article 28 register is where DORA monitoring obligations land most heavily. Here is a concrete pattern that several teams have built on top of PageCrawl.

Initial registration

For each critical or important ICT third-party provider, create a folder named for the provider. Inside the folder, add monitors for each public artefact: sub-processor list, DPA, trust center / certifications page, status page, security whitepaper URL, AUP, SLA. Tag each monitor with vendor:{provider}, the artefact type, and the criticality.

Set workspace instructions to describe your entity's regulatory profile. Set a tag default for criticality:critical to check every 15 minutes (or every 5 minutes for status pages). Set a tag default for criticality:standard to check daily. Route artefact:status and artefact:incident to your security operations Slack channel; route everything else to a weekly compliance digest.

Continuous monitoring

When a sub-processor list changes, you receive an alert with the AI summary highlighting the new sub-processor, the jurisdiction, and the function it serves. Your compliance team logs the change in the Article 28 register, raises a ticket if the new sub-processor triggers a customer-notification obligation under your DPA, and closes the loop in PageCrawl by marking the change as reviewed with a note linking to the ticket.

When a DPA section is amended, the AI summary highlights the diff, classifies the materiality, and the compliance team triggers a redline review. The change history retains the before/after for the next supervisory review.

When a trust portal certification expires or changes scope, you have the leading indicator your team needs to update its risk classification of the provider before your annual ICT risk assessment goes stale.

Annual review and supervisory inspection

At the annual review of your ICT risk management framework, the change log per provider is the source of truth for what shifted in the contractual relationship. At a supervisory inspection, the timestamped change history is the evidence that your register was maintained continuously, not retrofitted on the day before the inspection.

Common Pitfalls

A few patterns separate teams that keep DORA monitoring sustainable from teams that rebuild it twice a year.

Tracking too many pages on a critical provider

Every critical provider has hundreds of pages, but only a handful are evidentiary. Sub-processor list, DPA, trust portal, status page, AUP, SLA, and the certifications page are usually enough. Adding marketing pages, blog posts, and product update pages buries the signal under noise.

Ignoring slow-moving artefacts

Some artefacts change once every two years. Teams skip them because nothing has happened in twelve months. When the change comes (a CTPP designation, a regional restructure, an SCC version update), it tends to be the most material change of the year. Continuous monitoring at low frequency is cheap, and the alert is only generated when something actually shifts.

Treating ESA pages as static

ESA workstreams are not static. The DORA Q&A is updated on an ongoing basis, ITS templates are revised, and joint ESA opinions are added regularly. Treating these as one-time references means your team will discover the change at the next supervisory inspection.

Forgetting workspace instructions

Without a workspace-level description of your entity, AI summaries default to generic reading. The same Stripe sub-processor change produces a useful brief for a payment institution and a less-useful one for an insurance broker. Five sentences of workspace instructions change the quality of every summary across every source.

Choosing your PageCrawl plan

PageCrawl's Free plan lets you monitor 6 pages with 220 checks per month, which is enough to validate the approach on your most critical pages. Most teams graduate to a paid plan once they see the value.

Plan	Price	Pages	Checks / month	Frequency
Free	$0	6	220	every 60 min
Standard	$8/mo or $80/yr	100	15,000	every 15 min
Enterprise	$30/mo or $300/yr	500	100,000	every 5 min
Ultimate	$99/mo or $990/yr	1,000	100,000	every 2 min

Annual billing saves two months across every paid tier. Enterprise and Ultimate scale up to 100x if you need thousands of pages or multi-team access.

Compliance monitoring is the cheapest insurance you can buy. A single missed regulatory change can trigger fines in the tens or hundreds of thousands, not to mention the audit overhead of proving you did not see it coming. Enterprise at $300/year covers 500 regulatory pages with unlimited history and timestamped screenshots, which is usually exactly what an assessor wants to see. All plans include the PageCrawl MCP Server, so your compliance team can ask Claude to summarize every change to a specific regulation over the last quarter and pull the exact diff, turning your monitoring history into a queryable audit trail. Paid plans unlock write access so AI tools can create monitors and trigger checks through conversation. Standard at $80/year is enough to cover 100 pages across your primary regulatory bodies if your program is smaller.

Getting Started

Set up DORA monitoring in three steps:

1. List your critical ICT third-party providers. For each, create monitors for the sub-processor list, DPA, trust portal, and status page. Tag by vendor, artefact type, and criticality.
2. Add the ESA and competent authority pages your entity is supervised under. Tag them as regulator:eba, regulator:esma, regulator:eiopa, regulator:bafin etc, and route to your weekly digest.
3. Set workspace instructions describing your entity so AI summaries and importance scores adapt to your regulatory profile.

Once it is set up, the system runs in the background and produces an audit trail your competent authority will recognize. The monitoring is not a project. It is a piece of infrastructure your compliance program runs on.

For related guides, see banking regulatory compliance monitoring, SaaS sub-processor list monitoring, and GDPR and CCPA change tracking.

If your team is building a continuous DORA monitoring program, the Regulatory Intelligence use case walks through the full setup, including workspace instructions, tag-level inheritance, and digest routing for cross-jurisdictional compliance work.