DORA Compliance Overlay | Design-Time Contract

Design-Time Authority

Has the PM documented acceptable behavioural parameters as an architectural commitment before deployment?

Incomplete

Agent Scope Statement * Article 5(2), 6(1)

Concise statement of what decisions this agent makes and under what conditions. Example: "Approves credit decisions up to $50k for retail customers with utilisation <60%"

0/300

Decision Boundaries * Article 6(2)

Specific rules: what decisions can be made, what cannot, what requires human override.

Field Name	Field Type	Value

Data Access Boundaries * Article 6(2)

What data can the agent access, from which systems, with what restrictions.

Field Name	Field Type	Value

PM Architectural Approval * Article 5(2)(d)

This is not a compliance sign-off. This is the PM formally approving these parameters as architectural intent.

I confirm these parameters reflect our product intent and architectural commitment.

Design-Time Documentation Structure * Article 6(1)

Describe where and how your parameters are documented. Where would a regulator or auditor find the original design decisions? How is it versioned?

We have documented design-time parameters in an internal system (RFC, wiki, decision log, etc.)

0/300

DORA Anchor

Article 5(2): Management body must "define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework."

Article 6(1): Entities must maintain a "sound, comprehensive and well-documented ICT risk management framework."

Article 6(8): Framework must include a "digital operational resilience strategy" explaining how ICT risk will be addressed.

Ongoing Monitoring Mandate

Is someone actively monitoring the agent's behaviour against documented parameters on a continuous basis?

Incomplete

Monitoring Metrics * Article 10(2), 6(8)(c)

What metrics track whether the agent is operating within its documented parameters? Define measurable indicators.

Metric Name	Measurement Method

Alert Thresholds * Article 10(2)

At what values should alerts trigger? Define thresholds for each metric.

Metric / Condition	Alert Threshold

Named Monitoring Owner * Article 5(2)(c)

Who holds explicit responsibility for monitoring this agent? Not optional, not shared.

Monitoring Owner Responsibility Statement * Article 5(2)(c)

The owner confirms they understand their accountability.

0/300

Monitoring Review Cadence * Article 10(1), 17(2)

How often is monitoring reviewed? Daily, weekly, monthly?

Monitoring Data Access & Organization * Article 10(3)

Describe how monitoring metrics are organized and how the monitoring owner retrieves them. How are they queryable? What's the system/tool and how is access managed?

0/300

DORA Anchor

Article 10(1): Entities must have "mechanisms to promptly detect anomalous activities...including ICT network performance issues and ICT-related incidents" and test them regularly.

Article 10(3): Entities must "devote sufficient resources and capabilities to monitor user activity, the occurrence of ICT anomalies and ICT-related incidents."

Article 17(2): Entities must establish procedures for "consistent and integrated monitoring, handling and follow-up of ICT-related incidents."

Evidentiary Chain

Can you produce a connected record linking parameters, monitoring data, and decisions for regulatory review?

Incomplete

Parameter Documentation & Versioning * Article 17(2)

How are parameters version-controlled and auditable? Can you retrieve the exact parameters that were in effect on a specific date?

0/300

Decision & Monitoring Log Linkage * Article 17(3)(b)

How do you connect a specific agent decision to monitoring metrics at that point in time? How would you audit a single decision?

0/300

Root Cause Analysis Process * Article 17(2), 17(3)(b)

How are deviations or incidents investigated and documented? How is root cause identified and linked back to parameters?

0/300

Incident Documentation & Linkage * Article 17(3)(c), (e)

How are incidents involving this agent documented? How is root cause documented and linked back to the agent, parameters, and monitoring?

0/300

Last Reviewed Date * Article 6(5)

When were all three conditions last reviewed together? (Auto-updates on save.)

Regulatory Readiness Checklist

Confirm that this evidentiary chain would withstand regulatory examination.

All three conditions are documented and linked in a retrievable format.

Monitoring data is timestamped and linked to specific decisions or incidents.

Root cause analysis process is documented and deviations are traced back to parameters.

Parameter changes and reviews are version-controlled with dates.

DORA Anchor

Article 17(2): Entities must "record all ICT-related incidents" and establish procedures to ensure "root causes are identified, documented and addressed."

Article 17(3)(b): Requirements to "identify, track, log, categorise and classify ICT-related incidents."

Article 19(4): Mandatory submission of reports "after collecting and analysing all relevant information" including initial notification, intermediate reports, and final reports.

Accountability Assessment

Overall Readiness