Warning signs include weak visibility into which vendors support critical functions, unclear responsibility for incident handling, and loose control over how provider risk is assessed and tracked. If a firm cannot explain why a supplier is essential, what standards it must meet, or how failures would be escalated, the programme is probably too immature for DORA level oversight.
How to recognise a third party risk programme that is not DORA-ready
A DORA-ready programme can show, without hesitation, which external providers support critical or important functions, what failure of each provider would affect, and how the firm would respond if the provider or its service path became unavailable. If those relationships are not mapped, monitored, and owned, the programme is still operating as a vendor list rather than an operational resilience control.
The strongest warning sign is that third party risk is treated as a periodic questionnaire exercise instead of a live dependency model. DORA style oversight expects traceability from service to business function, including the operational impact of subcontractors, concentration risk, and the firm’s ability to keep working when a provider fails. That means the programme must be able to explain not just who the vendor is, but why the relationship matters, EU Digital Operational Resilience Act (DORA), and how the dependency is controlled over time.
- Weak inventory: the firm cannot identify which suppliers support critical functions or what data, access, or operational dependency each supplier creates.
- Unclear ownership: no one can state who approves exceptions, who receives incidents, or who decides when a supplier is too risky to retain.
- Poor escalation: failure paths are described vaguely, so the response plan breaks down when a provider outage, breach, or material control failure occurs.
- Limited assurance: assessments are not refreshed when services, integrations, subprocessors, or access paths change.
Another sign of immaturity is poor evidence quality. If the programme cannot produce current service mappings, testing records, contractual controls, incident playbooks, or decision history, it is not yet strong enough for regulatory oversight. That is especially true where the supplier has privileged or authenticated access into systems that matter to the business, because the control question shifts from “did we assess the vendor?” to “can we contain and recover from a vendor-side failure or compromise?”
Risk and Threat Considerations
A weak third party programme creates both governance exposure and attack exposure. The risk is not limited to a bad questionnaire, it is that hidden dependencies, unclear escalation, and poor control over supplier access can turn a routine vendor issue into a service outage, data exposure, or regulatory finding. In DORA terms, the programme fails when the firm cannot demonstrate control over operational dependency and incident response.
Failure mechanism: the organisation loses sight of which providers are critical, what access or service dependency they hold, and how incidents move from supplier failure into business disruption. That gap is often widened by incomplete inventories, weak reassessment, and fragmented ownership across procurement, technology, and risk functions.
Impact: the firm may miss concentration risk, delay incident escalation, fail to recover within tolerance, or accept supplier relationships that are operationally too important to manage safely. In a regulated environment, that also weakens auditability and can make remediation slow and expensive.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | ICT third-party risk management — ICT Third-Party Risk Management | DORA directly governs critical supplier oversight, incident handling, and operational resilience for this subject. |
| Recommendation — Map critical suppliers, test incident paths, and maintain evidence of control over outsourced dependencies. | ||
| NIST CSF 2.0 | GV.SC — Cybersecurity Supply Chain Risk Management | Third-party oversight here is a supply chain governance problem tied to supplier dependencies and assurance. |
| RC.RP — Incident Recovery Plan Execution | The programme must show it can escalate and recover when a provider incident disrupts critical services. | |
| Recommendation — Maintain supplier governance, dependency mapping, and ongoing assurance for critical third parties. Validate and exercise recovery paths for supplier-driven service disruptions. | ||
| CIS Controls v8 | 15 — Service Provider Management | This question turns on whether suppliers are identified, assessed, and monitored with clear accountability. |
| Recommendation — Track provider risk, document responsibilities, and review third-party control evidence regularly. | ||
Practitioner Guidance
What to prioritise: verify whether every critical supplier has a named business owner, a mapped critical function, and a current incident path that has been tested. If any of those three are missing, the programme is not ready for DORA-level oversight even if the vendor review paperwork looks complete.
What to verify: insist on evidence that the firm can answer three questions quickly: what the supplier supports, what happens if it fails, and who can escalate or exit the relationship. That answer should be supported by current contracts, dependency maps, and a recent review cycle, not by tribal knowledge.
What good looks like: dependency, assurance, and escalation are managed as one control system, so operational resilience decisions are based on live service criticality rather than annual assessment scores.
Practitioner takeaway: a DORA-ready programme is judged less by the completeness of its questionnaires than by whether it can prove control over critical dependencies, incident ownership, and recovery decisions when a supplier fails.
Related resources from NHI Mgmt Group
- What are the signs that a third-party risk programme is not supporting business resilience effectively?
- What happens when organisations scale vendor relationships without a mature third-party risk programme?
- Why do anti-corruption controls create real regulatory risk when third-party oversight is weak?
- What are the signs that an Android app has an unmanaged third-party code risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
