Third-Party Exposure Monitoring for Financial Services: A DORA-Ready Buyer’s Checklist
Table des matières
Third-party risk has quietly become the main way financial institutions get breached. Not through their own networks, but through the analytics provider, the payments processor, or the software support vendor sitting quietly inside their data flow.
The Digital Operational Resilience Act (DORA) has applied since 17 January 2025, and most firms have now built their Register of Information and renegotiated their ICT contracts. That work was necessary. It also would not have prevented a single one of the major third-party incidents of the past eighteen months.
This guide explains why, what DORA actually requires when it comes to ongoing monitoring, and the twelve questions to ask any vendor selling you third-party exposure monitoring.
Why did eighty banks get breached through one vendor?
On 14 August 2025, attackers moved through a SonicWall firewall into the network of Marquis Software Solutions, a Texas company supplying data analytics, CRM and compliance reporting to more than 700 banks, credit unions and mortgage lenders.
By January 2026, American Banker’s analysis of state attorney general filings put the toll at 823,548 individuals across at least 80 financial institutions.
Marquis later sued SonicWall, alleging that a compromise of SonicWall’s cloud backup service exposed the firewall configuration data that enabled the intrusion. Marquis had stored a backup of that configuration file in SonicWall’s cloud. SonicWall has said it has no evidence linking its own September 2025 security incident to the wave of ransomware attacks on firewall customers, and the litigation is ongoing.
Follow the chain: SonicWall, then Marquis, then eighty regulated institutions.
Every one of those institutions had Marquis in its vendor inventory. None of them had SonicWall’s cloud backup service in scope for anything. The failure was not a documentation failure. It was a visibility failure.
What does DORA actually require for third-party risk?
DORA’s third-party provisions sit in Chapter V and rest on three articles.
Article 28: general principles. A third-party ICT risk strategy owned by the management body, a Register of Information covering every contractual arrangement for ICT services, pre-contractual risk assessment, and documented exit strategies for arrangements supporting critical or important functions.
Article 29: concentration risk. A mandatory assessment before you sign, covering whether the provider is substitutable, whether you already hold arrangements with the same or a connected provider, and how opaque the subcontracting chain is.
Article 30: key contractual provisions. The baseline clauses every ICT contract needs, plus an enhanced set where the arrangement supports a critical or important function.
Most compliance budgets went to Article 28(3) and Article 30. That is understandable. The Register of Information is a defined artefact with a template and a deadline attached. Contract clauses are tractable legal work with a clear finish line. Both are now largely done across the sector.
The ongoing monitoring obligation is where the gap sits.
Which DORA article requires continuous monitoring?
No single one, and that is precisely why it has been under-resourced.
Article 28(6) is frequently cited in this context, but it actually governs access, inspection and audit rights. The ongoing obligation is distributed across the regulation:
Article 28(1) makes ICT third-party risk an integral component of your ICT risk management framework, which is a continuous obligation by construction.
Article 28(7) makes termination conditional on circumstances identified through the monitoring of ICT third-party risk, which presupposes that monitoring is happening.
Recital 65 describes the third-party risk strategy as rooted in continuous screening of all ICT third-party dependencies.
The result is that the obligation most relevant to how firms are actually being compromised is the one with no deliverable attached to it. A register has a template. Contract clauses have a signature. Continuous screening has neither, which made it the easiest thing to defer.
Two things it rules out in practice:
An annual questionnaire will not satisfy it. A questionnaire records what a supplier asserted on the day they completed it.
A contract will not satisfy it. A contract records what a supplier promised.
Screening requires observation.
Why don’t security ratings catch third-party data exposure?
Security ratings platforms score the vendor. They assess patch hygiene, certificate configuration, exposed services and reputational signals, then produce a grade. That grade is genuinely useful for procurement triage and for deciding which relationships deserve deeper scrutiny.
It does not tell you where your data is.
Consider the Frost Bank incident. Attackers accessed an SFTP server operated by Sefas, a supplier providing software support, with unauthorised access running from December 2025 to April 2026 and public disclosure following on 20 May 2026. The exposed files included Social Security numbers, tax forms and bill pay check images.
Le Everest extortion group had posted Frost Bank and Citizens Financial to its leak site on the same day that April, a same-day pairing that pointed to a shared supplier before either institution named one. Both banks confirmed the compromise originated at a third party rather than on their own networks.
A security rating on Sefas would have described the company’s general posture. It would not have told Frost Bank that files containing its customers’ tax documents were sitting on a support server.
Those are different questions, and only the second one produces a breach notification with your name on it.
The scale of the shift is no longer in dispute. The 2026 Verizon Data Breach Investigations Report found third-party involvement in 48% of breaches, a 60% year-on-year increase following a year in which the figure had already doubled. Verizon also reports that only 23% of third-party organisations fully remediated their cloud exposure.
What can’t your Register of Information tell you?
The Register of Information is a record of contractual arrangements. Its primary key is the contract, not the data. That is the right design for supervisory purposes, and it creates three blind spots that no amount of register completeness will close.
It records where data is supposed to be, not where it is. A register entry captures the contracted processing and storage location. It has no field for actual location, and the two diverge through ordinary operational drift: support tickets with attachments, file transfer staging directories, backup targets, test environments seeded with production extracts. Sefas was contracted for software support. The exposed files were tax forms and check images on an SFTP server.
It follows the delivery chain, not every dependency. Subcontracting disclosure reaches providers in the delivery chain for critical or important functions. SonicWall was not in Marquis’s delivery chain. It was a security vendor to Marquis, sitting alongside the data flow rather than inside it, which put it outside the register’s data model entirely while remaining directly upstream of eighty institutions’ customer data.
It runs on an annual clock against incidents that move in weeks. Marquis was compromised on 14 August 2025 and completed its forensic review in late October, roughly ten weeks later, with customer notifications beginning in late November. Unauthorised access at Sefas ran from December 2025 to April 2026 and was disclosed on 20 May. In both cases the affected institutions learned of the exposure from the supplier, downstream of the supplier’s own detection and downstream again of the supplier’s disclosure decision.
None of this makes the register the wrong artefact. It makes it a governance record rather than a detection capability, and the mistake has been treating the two as interchangeable.
The concentration problem is now formally recognised. On 18 November 2025 the European Supervisory Authorities designated nineteen critical ICT third-party providers under Article 31, placing hyperscale cloud platforms, data centre operators, telecoms providers and specialist financial technology firms under direct EU oversight.
That helps, but it also narrows the field. The failure modes that produced the 2025 and 2026 incidents were not at designated critical providers. They were at mid-tier suppliers that no regulator will ever oversee directly. Xcape security engineer Noelle Murata, quoted in Infosecurity Magazine’s coverage of the Marquis filings, put it plainly: a single mid-tier provider sitting inside the data flow of many banks creates a national blast radius without ever appearing systemically important.
That responsibility stays with you.
What should you ask a third-party exposure monitoring vendor?
Use these twelve questions in any evaluation. They are written so that a fair assessment separates genuine exposure monitoring from posture scoring, whichever provider you end up choosing.
Coverage and discovery
- Which of my suppliers can you monitor without their cooperation, and what changes if they refuse to participate?
- How do you discover subcontractors my supplier has not disclosed to me, and can you show an example from a live account?
- What proportion of your findings originate outside the supplier’s own infrastructure, in cloud storage, file transfer services, code repositories and underground forums?
Evidence quality
- When you find exposed sensitive documents, do you retrieve and analyse the content, or do you simply report that an exposure exists?
- Who validates a detection before it reaches me, and what is the false positive rate on qualified incidents?
- Can you produce a dated, auditable record of continuous monitoring that would stand up in a supervisory conversation about ongoing ICT third-party risk?
Detection scope
- How do you correlate exposed credentials to my domains and to my suppliers’ domains, and how quickly after they appear?
- What is your coverage of dark web marketplaces, underground forums and extortion leak sites, and how do you measure it?
- Can you detect my data on a supplier’s misconfigured server, or only signals about the supplier itself?
Operational fit
- What does remediation support actually include, and does it extend to takedown requests against third parties?
- How does onboarding a new supplier work, and what is the time from adding a supplier to first meaningful finding?
- What happens during an incident at a shared supplier affecting multiple clients, and how do you handle disclosure between them?
Questions 4, 6 and 9 are the ones that will separate the field. Most providers answer the first three well.
If you want a vendor-agnostic framework covering the wider category, our buyer’s checklist for external threat intelligence platforms works through the horizontal criteria.
How should you run a proof of concept?
Thirty days, three suppliers, and one success criterion: did the platform surface something you did not already know?
Choose your three suppliers carefully: one designated critical provider, one mid-tier supplier supporting a critical or important function, and one supplier you consider low risk. The third matters most. Marquis was a marketing and compliance vendor and Sefas was a software support provider. Neither would have topped a criticality ranking.
Measure four things:these should include the time from onboarding to first qualified incident. Number of previously unknown assets or subcontractors discovered. Number of exposed credentials correlated to your domains or your suppliers’ domains. Volume of noise, counted as detections that reached your team and required no action.
Insist on qualified incidents rather than raw alerts. A platform that forwards everything it detects transfers the analytical burden to your team, which is the opposite of the evidenced, managed screening supervisors expect to see.
Ask for the detection latency number. How long between your data becoming externally observable and the platform telling you about it? That figure is the honest measure of whether a control is working, and most institutions currently cannot answer it for their own environment.
Does DORA apply to US financial institutions?
Not directly, but the reach is wider than most US firms assume.
Through your EU entities. DORA applies to financial entities operating in the EU, which captures EU subsidiaries, branches and licensed entities of US-headquartered groups.
Through your contracts. Article 30 requires specific clauses in every ICT agreement supporting an EU financial entity, and those obligations flow to the provider regardless of where it is incorporated. A US technology supplier with EU financial clients is already answering these questions.
We cover the scope question in more depth in our guide to DORA and EU financial regulations.
Strengthen your DORA third-party monitoring with CybelAngel
CybelAngel detects your exposed data outside your perimeter, including at suppliers you have no control over and subcontractors you may not know exist.
de prévention contre les violations de données surfaces sensitive documents exposed on misconfigured servers, cloud storage and file transfer services, at your organisation and across your supply chain.
Surveillance du Dark Web tracks mentions of your organisation and your suppliers across underground forums, marketplaces and extortion leak sites.
Credential Intelligence identifies exposed credentials correlated to your domains and your suppliers’ domains.
Every detection is validated by an analyst before it reaches you, and delivered as a qualified incident with context and remediation guidance rather than a raw alert.
See how we support financial services teams, or request a demo to find out what is already exposed across your supply chain.
FAQ
A structured inventory, required under Article 28(3), of every contractual arrangement for ICT services, maintained at entity, sub-consolidated and consolidated level and updated on an ongoing basis. It records the provider’s identity, the service supplied, the function it supports and whether that function is critical or important, where data is processed and stored, and whether subcontractors are involved. Article 28(3) requires firms to report at least yearly to their competent authority on new arrangements, provider categories and services involved, and to make the full register available on request. The first reference date was 31 March 2025, and the European Supervisory Authorities used that first round of registers as the data source for identifying candidates for critical provider designation.
No single one, which is part of why it has been under-resourced. Article 28(6) is frequently cited but actually concerns access, inspection and audit rights. The ongoing obligation is distributed across Article 28(1), which embeds third-party risk in your ICT risk management framework as a continuous component, Article 28(7), which makes termination conditional on circumstances surfaced through monitoring, and Recital 65, which frames the strategy as rooted in continuous screening of ICT third-party dependencies. None of that prescribes a method, which is why interpretations vary widely.
They contribute, and they are useful for procurement triage. They answer a different question from the one that produces breach notifications. A rating describes a supplier’s general security posture. It does not tell you that your customer tax documents are sitting on that supplier’s support server. Both the Marquis and Sefas incidents turned on the second question, not the first.
A provider designated under Article 31 by the European Supervisory Authorities as systemically important to the EU financial sector, based on criteria covering systemic impact, the criticality of the functions it supports, the number and importance of dependent financial entities, and substitutability. Designated providers fall under direct ESA oversight through Joint Examination Teams, each with an assigned Lead Overseer. The first list of nineteen was published in November 2025. Designation does not transfer your obligations. You remain responsible for managing the risk you carry through that relationship.
A third-party risk assessment evaluates a supplier’s controls, certifications and posture, usually through questionnaires, evidence review and external scanning. Exposure monitoring looks for your data outside your perimeter: sensitive documents on misconfigured servers, exposed credentials tied to your domains or your suppliers’ domains, and mentions of your organisation on dark web marketplaces and extortion leak sites. The first tells you how likely a supplier is to have a problem. The second tells you whether a problem has already produced consequences for you.
This is one of the more practical problems in third-party risk, and it is why the first question in the checklist above matters. Exposure monitoring that depends on supplier participation stops working precisely where you need it most. Monitoring that observes externally visible exposure does not require the supplier’s permission or awareness, which is what makes it usable across a long tail of suppliers who will never complete your questionnaire.
À propos de l'auteur
