If you're managing DORA, the EU AI Act, and NIS2 with spreadsheets and shared inboxes, you're not running a compliance program. You're running a failure audit in slow motion.
The connective infrastructure between horizon scanning, obligation mapping, and evidence collection determines whether your program catches gaps before your regulator does. This checklist walks through the operational requirements for tracking regulatory obligations at scale, where "at scale" means managing multiple overlapping frameworks without anything falling through the cracks.
What This Checklist Covers
This operational readiness checklist is for compliance teams managing obligations across multiple regulatory frameworks simultaneously. It covers the three critical workflow stages where manual processes break down: horizon scanning, obligation mapping, and evidence collection. Each item addresses a specific failure point that compounds regulatory risk when left unresolved.
Prerequisites
Before you start this checklist, ensure you have:
- Named obligation owners for each regulatory framework your organization must comply with (DORA, EU AI Act, NIS2, UK FCA/PRA requirements, etc.).
- Write access to your organization's system of record for compliance obligations, whether that's a GRC platform, a structured database, or a well-maintained spreadsheet.
- Authority to change workflows around how regulatory updates are received, assigned, and tracked to completion.
If you lack these, your first step is securing them. Without clear ownership and the ability to change workflows, you're documenting a process you can't fix.
Checklist Items
1. Regulatory update sources are centralized in a single intake point
All regulatory updates from the European Banking Authority, European Securities and Markets Authority, Information Commissioner's Office, AI Office, FCA, and PRA must land in one place, not scattered across individual inboxes.
Good looks like: A shared inbox or automated feed where every relevant regulatory update arrives, timestamped, with no manual forwarding required.
2. Each incoming update receives a classification within 48 hours
Someone with regulatory expertise reviews each update and determines: Does this create a new obligation? Does it clarify an existing one? Is it informational only?
Good looks like: A classification tag on every update within two business days of receipt, with a named reviewer and a brief justification.
3. Obligation records link directly to their source requirements
Every obligation in your tracking system must cite the specific article, section, or guidance that created it. Under DORA Article 30, that means each ICT third-party provider assessment links back to Article 30's contractual requirements.
Good looks like: You can pull up any obligation record and immediately see which regulatory text created it, when that text was published, and whether it has been updated since.
4. Guidance updates automatically flag affected obligation records
When the EBA issues a Q&A clarifying Article 30's scope, your system identifies which provider assessments that clarification touches. This cannot be a manual search-and-update process.
Good looks like: A workflow that identifies affected obligations based on their source requirement tags and generates task assignments to the relevant owners without manual intervention.
5. Every obligation has a named owner and a completion deadline
No obligation sits unassigned. Every record includes who is responsible for fulfilling it and when it must be complete.
Good looks like: You can filter your obligation tracking system by owner and see every open obligation assigned to them, with deadlines visible and sortable.
6. Evidence is attached to the obligation record it supports
Proof of compliance lives with the obligation, not in a folder structure someone will need to reconstruct during a supervisory review.
Good looks like: Opening an obligation record shows you the requirement, the owner, the deadline, and every piece of evidence collected to demonstrate compliance, all in one view.
7. High-risk AI systems are mapped to both AI Act and DORA obligations
If you use AI for credit decisioning, employment screening, or critical infrastructure, those systems trigger obligations under both the EU AI Act's high-risk requirements and DORA's ICT third-party service rules. Your tracking system must reflect that overlap.
Good looks like: A single AI system record shows all applicable obligations from both frameworks, with separate evidence trails for each but a unified view of the system's regulatory status.
8. Obligation status is updated within five business days of completion
When an owner completes an obligation, the record updates immediately. Stale status information creates false confidence.
Good looks like: Your tracking system shows the date each obligation was marked complete, who marked it, and what evidence supports that status, with no record older than one week unless it's genuinely still in progress.
9. Audit trails are complete and exportable
You must be able to produce a complete history of who did what, when, and based on which Regulatory Obligation, without manual reconstruction.
Good looks like: An export function that pulls obligation records, evidence attachments, status change logs, and owner assignments into a format your auditor or regulator can review without additional explanation.
10. The system handles volume spikes without manual triage
When one quarter brings DORA technical standards, revised AI Act guidance, an FCA consultation, and updated NIS2 transposition from three member states simultaneously, your workflow doesn't collapse.
Good looks like: Your intake, classification, and assignment process runs the same way whether you receive five updates in a quarter or fifty, with no backlog of unclassified items older than 48 hours.
Common Mistakes
Treating horizon scanning as a separate activity from obligation tracking. If the regulatory update doesn't flow directly into an obligation record or a classification decision, you're creating a gap between what you know and what you're tracking.
Building obligation records at too high a level. "Comply with DORA Article 30" is not an actionable obligation. "Review and update ICT service agreement with [provider name] to include termination rights per Article 30(2)(i)" is.
Storing evidence in folder structures instead of attaching it to obligation records. When your regulator asks for proof of compliance with a specific requirement, you should pull up one record, not search three folders.
Assuming automation means no human judgment. Automation handles routing, tracking, and audit trails. Determining whether an EBA Q&A changes your risk position under DORA still requires regulatory expertise.
Next Steps
If you checked fewer than eight items, your obligation tracking process has structural gaps that will surface during your next supervisory review. The fix is not buying a platform. It's diagnosing where your manual process breaks down and building workflows that close those specific gaps.
High-risk AI system obligations under the EU AI Act apply from 2 December 2027. If your current tracking method can't handle the overlap between DORA, the AI Act, NIS2, and UK requirements without manual triage, you have 30 months to build something that can.
The question is not whether your program is compliant today. It's whether your tracking system will catch the failure before your regulator does.
