1.1 Alignment scope
Atom9 treats DORA as a financial-sector operational resilience overlay when a customer app, workflow, or workspace supports a regulated or potentially regulated financial service.
DORA
Digital operational resilience for financial-sector work.
DORA is the EU financial-sector regulation for digital operational resilience. Atom9 aligns financial-sector customer work with DORA-style controls for ICT risk, incident handling, resilience testing, third-party provider risk, business continuity, approvals, and evidence.
Effective date
June 27, 2026. This page describes Atom9's DORA alignment for customer apps and workspaces that involve financial-sector operational resilience. It does not decide whether a customer is a regulated financial entity. Customers remain responsible for their own regulatory classification, supervisory duties, legal advice, and regulated service operation.
DORA 1
DORA is handled as a sector overlay on top of privacy, security, AI, and operational controls.
DORA alignment mapThe same customer app should not have separate disconnected compliance tracks.
GovernResponsibilityOwner, role, decision, and approval records.
ControlICT riskAccess, sessions, data, change, and safe defaults.
RespondIncidentsDetect, classify, preserve evidence, notify, improve.
VerifyResilience testingLaunch checks, recovery checks, workflow tests, review.
BoundariesProvider riskProvider inventory, criticality, access, location, exit.
EvidenceTraceabilityRecords that explain who did what and why.
Legal anchors: DORA 2 covers roles, DORA 3 covers ICT risk, DORA 4 covers incidents, DORA 5 covers testing, and DORA 6 covers provider risk.
1.2 Customer classification
The customer identifies whether the service is financial, regulated, outsourced ICT, critical, important, or otherwise subject to sector rules. Atom9 records the classification used for the project and routes the work through the matching controls.
1.3 Combined obligations
DORA alignment does not replace privacy, AI, consumer, contract, or security obligations. Atom9 maps financial-sector resilience requirements together with GDPR, AI governance, security, cookie, and customer-app notices.
1.4 Evidence standard
For DORA-aligned work, Atom9 favours visible evidence over informal memory. Classification, owner decisions, approvals, tests, incidents, provider choices, and launch checks are recorded where the workflow requires accountability.
DORA 2
Financial-sector work needs clear ownership before the agent builds.
2.1 Responsible customer owner
The customer assigns an owner for financial-sector projects. The owner is responsible for confirming the service purpose, regulated status, launch readiness, required approvals, and customer-side supervisory obligations.
2.2 Role boundaries
Atom9 uses role boundaries, approval gates, workspace permissions, and account controls so financial-sector changes are not approved silently by the wrong person or by an agent acting outside its assigned scope.
2.3 Agent instructions
An AI agent working on a DORA-aligned project must ask clarifying questions about regulated purpose, affected users, data categories, required notices, continuity expectations, and human review before treating a plan as ready.
2.4 Change accountability
DORA-aligned projects use visible change reasons, approval records, launch checks, and rollback or correction paths for material changes to login, data fields, financial workflows, user communications, or provider settings.
DORA 3
ICT risk management is translated into product controls users can understand.
3.1 ICT risk management
ICT risk management covers the people, software, providers, data, access, workflows, and operational dependencies needed to provide the customer service safely.
3.2 Data and service mapping
Atom9 records service purpose, data categories, customer-app flows, files, connected tools, AI context, user roles, and key provider boundaries so the customer can see what the service depends on.
3.3 Access and session controls
Financial-sector work can require stronger login methods, shorter sessions, stricter role assignment, verified domains, controlled callback paths, and extra approval before sensitive data or workflow changes are exposed.
3.4 Continuity expectations
Business continuity expectations are captured during setup when the customer service depends on availability, booking, payment, identity, document access, time-sensitive notifications, or regulated customer communication.
3.5 AI risk in financial workflows
AI assistance in financial-sector workflows requires clear purpose, data governance, transparency, human oversight, output review, model/provider records, and stronger escalation where the workflow can materially affect people.
3.6 No unsupported shortcuts
Customers and users must not bypass product controls, direct users to unsupported internal paths, copy private tokens, or treat debug output as an integration surface. Approved product surfaces remain the supported way to operate Atom9.
DORA 4
Incidents are handled as operational, security, privacy, and customer-service events.
Incident pathA useful response preserves facts and fixes the service, not just the error message.
DetectSignalUser report, monitoring, failed job, provider issue, or security alert.
ClassifyImpactSecurity, privacy, AI, availability, financial workflow, or provider issue.
ContainLimit harmRestrict access, pause workflow, revoke tokens, or isolate the affected path.
InformNotifyTell affected customers, users, providers, or authorities when required.
ImproveClose loopFix, document, review controls, and update future launch checks.
Legal anchors: DORA 4.1 to 4.6 define detection, classification, containment, notice support, and post-incident improvement.
4.1 Incident detection
Atom9 records and reviews signals from product errors, failed jobs, access issues, customer reports, security reports, provider failures, suspicious sessions, and AI workflow problems where they affect the service.
4.2 Incident classification
Incident classification separates availability, confidentiality, integrity, privacy, AI, provider, financial workflow, and customer-notice concerns so the correct escalation path is used.
4.3 Evidence preservation
Incident records preserve useful context such as time, workspace, customer app, affected workflow, visible user action, approval state, provider involvement, and safe screenshots or logs. Reports must not include passwords, session cookies, private keys, or unnecessary personal data.
4.4 Customer notification support
Atom9 supports affected customers with facts, timelines, impact notes, evidence, and remediation status needed for customer notices, regulatory reporting, data-breach assessment, or contractual escalation.
4.5 Recovery and correction
Recovery work can include restoring data, revoking access, pausing a workflow, replacing provider configuration, correcting customer-facing content, rebuilding a failed automation, or rerunning a verified task under review.
4.6 Lessons learned
Material incidents produce an improvement record. The record can update controls, prompts, launch checks, templates, provider settings, training notes, support guidance, or customer-app configuration.
DORA 5
Resilience testing checks whether the service can be trusted before and after launch.
5.1 Launch tests
Financial-sector customer apps require launch checks for login, roles, data fields, forms, notices, files, AI explanations, automations, emails, redirects, provider settings, and customer approval before production use.
5.2 Resilience testing
Resilience testing checks recovery expectations, failed provider behaviour, missing data handling, permission denial, email delivery failure, broken automation, and user-facing error paths.
5.3 AI workflow verification
AI-generated plans, forms, pages, automations, and user journeys are reviewed against the approved spec, legal notices, data minimisation, human oversight needs, and customer service purpose before they are accepted.
5.4 Security verification
Security verification checks account flow, callback paths, session behaviour, role restrictions, upload handling, connected-tool permissions, exposed data, rate limits, and unsupported bypass paths.
5.5 Privacy verification
Privacy verification checks lawful basis, data minimisation, retention, subject rights, consent where needed, customer-app KYC fields, cookie choices, transfer safeguards, and processor or sub-processor involvement.
5.6 Test evidence
Tests must leave a record that a customer, reviewer, or support person can understand later: what was tested, which version was tested, what passed, what failed, who accepted it, and what remains open.
DORA 6
Third-party ICT risk is about dependency, control, location, and exit.
Provider risk mapA provider is not just a vendor name. It is a dependency with a purpose and a boundary.
PurposeWhy used?What customer outcome depends on it?
AccessWhat can it reach?Data, files, identity, messages, telemetry, or AI context.
LocationWhere processed?Region, transfer safeguards, and customer residency choices.
CriticalityHow important?Can the service run if the provider fails?
ExitHow replaced?Export, fallback, migration, or deactivation path.
Legal anchors: DORA 6.1 to 6.6 define provider inventory, criticality, customer approval, subcontracting visibility, and exit planning.
6.1 Provider inventory
Atom9 documents relevant identity, hosting, file, email, AI, search, analytics, observability, payment, support, and integration providers used for a customer service where the workflow requires provider awareness.
6.2 Third-party ICT risk
Third-party ICT risk includes provider failure, concentration, security weakness, data location, access scope, contractual limits, support dependency, and the ability to recover or move away.
6.3 Critical or important functions
The customer identifies whether a provider supports a critical or important function. Atom9 records that status and can require stronger review before launch or provider change.
6.4 Sub-provider visibility
Where a provider chain matters to the customer service, Atom9 records relevant sub-processor, model provider, infrastructure, or integration involvement and connects it to privacy and provider-boundary explanations.
6.5 Customer approvals
Provider choices that materially affect regulated service delivery, personal data, AI behaviour, login, notifications, files, payments, support, or monitoring require customer approval through the project workflow or a signed agreement.
6.6 Exit and portability
Financial-sector customers should define export, migration, replacement, credential rotation, data deletion, and fallback expectations for important provider dependencies before the service becomes hard to change.
DORA 7
DORA works best when mapped to the other compliance documents instead of duplicated.
7.1 GDPR synergy
DORA controls reuse GDPR work where the same fact matters: data categories, processors, sub-processors, transfer safeguards, retention, breach assessment, rights support, and data minimisation.
7.2 Security and NIS2 synergy
DORA controls reuse security and NIS2-aligned work for risk analysis, incident handling, business continuity, supply-chain care, access control, encryption choices, vulnerability handling, and operational monitoring.
7.3 AI Act synergy
DORA controls reuse AI governance where an AI workflow is part of a financial-sector service: risk classification, transparency, human oversight, data governance, logging, provider identity, and serious-incident escalation.
7.4 Notice and cookie synergy
DORA controls reuse customer-facing notice work where browser storage, customer-app notices, AI explanations, onboarding, communication preferences, and consent choices affect financial-sector customer trust.
7.5 One evidence trail
Atom9 should not create separate evidence silos for every regulation. A single evidence trail can support DORA, GDPR, AI Act, NIS2, security, contract, and customer-app review when records are tagged clearly.
7.6 Signed documents still control
If a customer agreement, DPA, security addendum, service level, regulator instruction, or sector-specific statement requires stricter controls than this public page, the stricter customer-specific document controls that relationship.
DORA 8
Atom9 keeps DORA guidance tied to official sources and customer review.
8.1 Official sources
Atom9 reviews DORA-aligned guidance against official EU source material, including the DORA regulation text, supervisory authority material, and customer-specific legal or regulatory instructions where they apply.
8.2 Change tracking
When DORA guidance, supervisory expectations, provider behaviour, security posture, or Atom9 product controls materially change, Atom9 updates the relevant product controls, documentation, templates, or customer guidance.
8.3 Customer evidence requests
DORA-aligned customers can request appropriate product, security, privacy, provider, incident, and test evidence through agreed support or contract channels. Atom9 does not disclose private architecture, secrets, or unsupported operational routes.
8.4 Legal review
This page is public product guidance. Customer-specific DORA obligations, regulated outsourcing duties, regulator communications, and contractual commitments must be reviewed against the customer's own facts and signed documents.