Periodic review fails because DORA expects continuous accountability across the full ICT dependency chain, including downstream providers and lifecycle changes. If teams only reassess vendors at renewal or annually, they miss access drift, control ownership gaps, and evidence gaps that matter most during audit or incident review. Resilience governance has to operate on change, not calendar cadence.
Why periodic review breaks DORA-style third-party risk governance
Under DORA, the unit of control is not the annual vendor checklist, it is the live ICT dependency chain. That means the risk picture changes whenever a provider, sub-provider, integration, access path, or supporting control changes. A periodic review can record a snapshot, but it cannot prove that the arrangement stayed controlled between reviews.
For that reason, third-party risk under DORA has to be treated as an operating state, not a calendar event. The real question is whether the firm can trace who owns each dependency, what changed, and whether evidence still matches the current service reality.
What periodic review misses in the dependency chain
A review at renewal or year-end tends to focus on documents that are easy to collect: policy attestations, control summaries, and overdue questionnaires. That approach misses the operational drift that creates the largest exposure, especially when downstream providers change, privileges expand, or an integration is reconfigured without a formal “vendor review” event.
The gap is not only technical. It is also a governance problem, because DORA expects financial entities to maintain continuous oversight of ICT third-party risk across the full chain of dependencies, including sub-outsourcing and material service changes. That is why a static review calendar can look compliant while the operating model has already drifted out of sync.
In practice, the missed failure mode is evidence decay. If ownership, access rights, or incident records are only checked on a fixed cycle, the organisation may discover too late that it cannot show who approved a change, who inherited the risk, or which downstream provider supplied the affected service.
What continuous accountability looks like in practice
Continuous accountability does not mean nonstop manual reassessment. It means the organisation can detect meaningful change, assign responsibility, and keep evidence aligned to the current state of the service. For third-party risk, that usually involves change-triggered review, inventory discipline, contractual visibility, and incident-ready records rather than one large annual recertification.
The strongest control patterns are the ones that keep the dependency map current. A live register should capture the service, the provider, the critical subcontractors, the control owner, and the evidence source. When that map is current, teams can assess whether a control failure is isolated or inherited from a downstream party. SOC 2 Trust Services Criteria is useful here as a benchmark for how assurance, availability, confidentiality, and change-related control evidence can be organised for third-party review.
Where access and secrets are involved, the same principle applies to credentials that support the service relationship. A vendor can remain contractually approved while the actual access paths become stale, overbroad, or undocumented. That is why practitioners should pair third-party review with Top 10 NHI Issues style lifecycle thinking, because stale access and unmanaged credentials often create the audit gap that periodic review never sees.
How to tell whether your DORA process is still calendar-bound
If your programme only reacts at renewal, the symptoms are usually visible: control evidence is gathered late, service owners cannot name all downstream providers, access recertification lags operational reality, and incident questions turn into archaeology. Those are all signs that the review process is not tracking the actual dependency chain.
Threats and failures also accumulate faster than a quarterly or annual cadence can absorb. A stolen token, a compromised integration, or a provider-side control change can affect multiple customers before the next scheduled review ever happens. Recent third-party incidents show the pattern clearly: OAuth token theft through a third-party integration and stolen vendor API keys both demonstrate how a seemingly narrow provider issue can expand into broader exposure when the dependency chain is not continuously governed.
In other words, periodic review fails when it is used as the control itself instead of as one input to an always-current oversight process. The organisations that cope best are the ones that treat service change, access change, and subcontractor change as triggers for immediate reassessment.
Risk and Threat Considerations
When third-party risk is handled as a periodic exercise, the main exposure is blind time. Access drift, subcontractor drift, and evidence drift can all occur between reviews, leaving the firm unable to prove control over the live service relationship during an audit, incident, or regulatory challenge.
Failure mechanism: The organisation assumes the last review still reflects the current dependency chain, while provider changes, downstream access changes, and control ownership gaps accumulate unnoticed.
Impact: A late review can miss the exact conditions that matter most, including unauthorized access paths, unowned controls, and incomplete evidence for incident response or supervisory scrutiny.
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 NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Cybersecurity Supply Chain Risk Management Strategy | DORA third-party governance depends on managing supplier and dependency chain risk continuously. |
| GV.RM-01 — Risk Management Strategy | The question is about governance that must adapt as ICT third-party risk changes over time. | |
| Recommendation — Maintain a live third-party risk strategy and update it when providers, services, or dependencies change. Tie third-party oversight to the organisation’s risk strategy and trigger reassessment on material change. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | Third-party service oversight requires defined controls for external ICT services and shared responsibility. |
| CA-7 — Continuous Monitoring | Periodic review fails where continuous oversight is needed for changing provider risk and evidence. | |
| Recommendation — Define external service requirements, responsibilities, and oversight evidence for each critical provider. Implement continuous monitoring for provider control changes, access drift, and evidence freshness. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier relationships are central because the risk sits in the live dependency chain, not just annual review. |
| Recommendation — Maintain ongoing supplier security obligations and review them when the relationship or service changes. | ||
| DORA | ICT third-party risk management | DORA directly governs continuous oversight of ICT third-party dependencies and service changes. |
| Recommendation — Track ICT third-party dependencies continuously and reassess them whenever material change occurs. | ||
Practitioner Guidance
What to prioritise: Move from time-based vendor review to change-based oversight. The first thing to stabilise is the dependency inventory, because you cannot govern what you cannot currently name.
What to verify: For each critical provider, verify who the downstream providers are, which access paths are active, and who owns the evidence for each control. If any of those cannot be answered quickly, the process is already behind the operational reality.
Practitioner takeaway: Under DORA, third-party risk is not a yearly compliance checkpoint, it is a continuously changing control environment, and the strongest programmes are the ones that can prove they stayed aligned as the service changed.
Related resources from NHI Mgmt Group
- What breaks when third-party cyber risk is managed as a periodic vendor review?
- Why does third-party access create so much regulatory risk under DORA and NIS2?
- Why do third-party ICT dependencies create the biggest operational resilience risk under DORA?
- What breaks when third-party risk assessments are treated as one-time exercises?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org