DORA is an acronym with three serious meanings: Britain's 1914 Defence of the Realm Act, the EU Digital Operational Resilience Act (Regulation (EU) 2022/2554), and DORA metrics from DevOps research. The past-tense “was” most often points to the 1914 law.
But does recognizing the acronym tell you which rules, history, or measurements someone means? Not necessarily. A history teacher, a banking supervisor, and an engineering manager can all say DORA while discussing entirely different subjects.
Four Meanings of DORA and How to Tell Them Apart
The four meanings of DORA at a glance
| Meaning | Full name | Field | Core idea | Period |
|---|---|---|---|---|
| Wartime emergency law | Defence of the Realm Act | British government, First World War | Emergency powers over communications, industry, and civilians | Historical, no longer in force |
| EU financial regulation | Digital Operational Resilience Act | EU financial sector | Technology risk, incident reporting, and resilience testing | Current regulatory framework |
| Software delivery metrics | DevOps Research and Assessment metrics | Software engineering | Measures of delivery speed and stability | Used in software delivery research and practice |
| Cultural reference | Dora the Explorer; the given name Dora | Children's television and names | Not an acronym for a regulation or metric | Ongoing cultural use |
The quickest way to answer “What was DORA?” is to inspect the surrounding words, not the capitalization alone. Someone may capitalize a television character's name in a headline, while an engineer may write an acronym informally in lowercase.
Match the surrounding vocabulary
- History language: Britain, wartime censorship, ports, military information, and emergency powers point to the Defence of the Realm Act. Your next step is to understand what Parliament authorized and how ministers used those powers.
- Financial regulation language: Banks, fintechs, supervisors, ICT risk, and outsourcing point to the EU regulation. Start by identifying the legal entity and its regulated activities.
- Engineering language: Deployments, commits, release pipelines, rollbacks, and recovery point to software delivery metrics. Start with the team's production deployment records.
- Entertainment or personal language: A cartoon, a child's programme, or someone named Dora usually means a cultural reference or given name. There's no compliance framework to decode.
ICT means information and communication technology. In the financial context, it includes the systems and services a firm relies on to operate, not just the software its security team monitors.
Don't transfer one meaning into another
An engineering dashboard doesn't establish that a financial institution meets a regulation. Likewise, a discussion of wartime censorship doesn't explain modern software delivery practices.
Practical rule: Expand DORA into its full name before deciding what advice applies.
Say a lawyer receives a financial client's supplier questionnaire asking about DORA. Answering with deployment statistics would miss the client's concern: whether the communications service can support the client's operational obligations.
A history student faces the opposite problem. Searching only for DORA may produce banking guidance even though the assignment concerns government power during wartime. Adding “Defence of the Realm” makes the intended subject clear.
What the Defence of the Realm Act Was
The Defence of the Realm Act was Britain's principal First World War emergency statute: UK Parliament's historical account records its passage on 7 August 1914 and royal assent on 8 August. Legislators passed it without a printed text available, illustrating how urgently Parliament acted.
The opening milestones distinguish parliamentary passage from royal assent.
Key dates in the Defence of the Realm Act
| Date or stage | Event | Why it matters |
|---|---|---|
| Early wartime emergency | Britain enters the First World War | Ministers seek emergency powers |
| Parliamentary passage | Parliament passes the Act without a printed text available to legislators | Legislative scrutiny takes place under exceptional pressure |
| Royal assent | The Act becomes law | Ministers gain the statutory foundation for emergency action |
| During the war | Amendments and Defence of the Realm Regulations expand the framework | Controls reach censorship, labour, industry, food, and alcohol |
| Armistice | Fighting ends | Emergency legislation doesn't disappear immediately |
| Postwar period | The law eventually ceases to remain in force | Its operation extends beyond the fighting |
How a security law reached civilian life
The initial purposes were national security: controlling communications, protecting ports and military information, and allowing civilians to face military courts. Its broad wording also gave ministers room to introduce further regulations.
Think of a building permit that allows the council to authorize additional rooms later. The initial permission matters, but the eventual structure can become much larger than the first drawing suggests.
DORA developed in a comparable way. Ministers used its legal framework to regulate activities far beyond the immediate protection of military sites.
Why historians distinguish the Act from its regulations
The Act supplied authority; regulations translated that authority into detailed controls. A newspaper editor confronting censorship and a worker facing industrial restrictions could therefore encounter different rules grounded in the same emergency framework.
That distinction prevents a common misunderstanding: DORA wasn't just a ban on publishing military secrets. It became a foundation for domestic administration, surveillance, economic direction, and restrictions on dissent.
For a reader encountering it in a history book, the central question is how a parliamentary state expanded executive power under wartime pressure. It's a historical law, not an obligation a present-day business must satisfy.
DORA Metrics for Software Delivery Teams
| Metric | What it measures | Elite benchmark | Common mistake |
|---|---|---|---|
| Deployment frequency | How often code reaches production | Use the applicable report's definition, not a universal target | Counting staging deployments |
| Lead time for changes | Time from code commit to production | Match the benchmark to the report and measurement method | Starting the clock at ticket creation |
| Change failure rate | Share of deployments requiring remedial action | No universal numerical cutoff established here | Ignoring hotfixes and rollbacks |
| Time to restore service | Recovery duration following a service failure | Check whether the definition covers all incidents or failed deployments | Mixing incident scopes or timestamp conventions |
These are the familiar core measures associated with DevOps Research and Assessment. They concern a delivery system: how a team gets changes into production and handles failures.
Numerical “elite” thresholds need a specific report and definition attached to them. Treat an unattributed benchmark chart cautiously, especially if it combines older recovery terminology with newer measures.
Measure the production path consistently
Deployment frequency counts production deployments, not successful test runs. A GitHub Actions workflow that builds an application without releasing it to users isn't evidence of production delivery.
Lead time for changes follows committed code into production. Starting at ticket creation instead measures a broader work-management interval, which may include planning and prioritization before anyone changes code.
Change failure rate connects deployments with remedial work. If a release requires an urgent hotfix or rollback, excluding that event can make the dashboard look healthier without improving the service.
Recovery time needs an explicit incident scope and consistent timestamps. Record failure onset, detection, mitigation, and restoration separately where possible; do not alternate between them without clarity.
Read speed alongside stability
A car dashboard is a useful analogy. Speed tells you how quickly you're moving, but warning lights and other gauges tell you whether continuing at that speed is sensible.
Say a team starts shipping smaller changes more frequently. That's useful if users receive improvements sooner without more disruption; it's less useful if the team spends its time reversing those changes.
Use delivery metrics to find constraints in the team's system, not to rank individual developers.
Release logs alone won't explain every failure. Pair deployment identifiers with incident records so engineers can reconstruct what changed, who responded, and how service returned.
For communicating that account beyond engineering, Fivenines' guide to writing stakeholder-facing incident reports is a useful companion. A stakeholder needs the impact, response, and preventive actions, not just a recovery-duration figure.
Definitions also evolve. Before comparing teams or importing a dashboard template, agree on production boundaries, failure criteria, and the treatment of retries and rollbacks.
What the EU Digital Operational Resilience Act Requires
The EU's Digital Operational Resilience Act, Regulation (EU) 2022/2554, treats technology resilience as continuous operational control. A financial entity needs functioning processes and evidence, not merely a cybersecurity policy.
The requirement is easier to understand as connected operational responsibilities.
- Manage ICT risk: Identify important systems, assign control owners, and maintain a risk-management framework.
- Handle incidents: Establish escalation, response, and incident-management processes.
- Keep usable records: Record ICT incidents and significant cyber threats so staff can investigate and make reporting decisions.
- Prevent recurrence: Perform root-cause analysis and track corrective action through to validation.
Turn requirements into operational evidence
The framework brings together ICT risk management, incident management and reporting, resilience testing, third-party risk, and information sharing. Information sharing shouldn't be confused with an unrestricted duty to disclose confidential operational details.
Under the regulation's testing provisions, financial entities other than microenterprises must test systems and applications supporting critical or important functions at least annually, while certain entities must conduct advanced threat-led penetration testing at least every three years. Advanced testing involves live production systems, including relevant underlying and outsourced services.
Think of a fire-safety code. Buying an alarm doesn't establish that evacuation procedures, inspections, and drills all work.
The same distinction applies to encryption. Confidentiality doesn't establish that users can authenticate during disruption, recover access safely, or continue an essential business process.
Connect technical failures to business effects
For transaction-dependent services, Glentorion's discussion of real-time processing in core banking provides context for why interruptions can affect downstream operations. Map each critical function to its dependencies, detection signals, recovery objectives, and retained test evidence.
A practical explanation of what business continuity means helps connect technical recovery to the work employees and customers must still complete. Outsourcing incident-reporting work doesn't transfer the financial entity's reporting accountability.
The following video offers another way to approach the regulatory context.
Whether DORA Applies to Your Organization
Eligibility criteria to check before assuming DORA does or does not apply
| Criterion | What to check | Why it matters |
|---|---|---|
| Entity type | Bank, investment firm, payment institution, insurer, or crypto-asset business | Establishes the relevant scope category |
| Size | Employee count and financial measures against the applicable definition | May affect available proportional treatment |
| Excluded entity types | Whether your category is excluded from a particular concession | Small size alone doesn't settle eligibility |
| Regulated activity | The financial services you're authorized to perform | Identifies relevant obligations and supervisor |
| Outsourcing | Which functions rely on external ICT services | Changes the dependencies you must govern |
| National supervisor view | Guidance from your national competent authority | Helps resolve entity-specific application questions |
ESMA's DORA guidance identifies 17 January 2025 as the application date for in-scope financial entities and describes a microenterprise generally as having fewer than 10 employees and annual turnover or a balance-sheet total not exceeding EUR 2 million. Don't treat that size definition as automatic permission to use every simplified requirement.
Separate scope from proportionality
First establish whether the legal entity falls within the regulation. Then determine which provisions, exclusions, exemptions, or proportionate arrangements apply to its precise category.
“Small firm” and “outside DORA” aren't interchangeable descriptions. Nor should a microenterprise-related concession be assumed to mean eligibility for a separate simplified ICT-risk-management framework.
Say a small payment business asks whether its headcount settles the question. It doesn't: its authorization, category, financial measures, and applicable provisions still need checking.
Before deciding: Ask which legal provision permits the simplification, not simply whether the business feels small.
Check the business relationship too
A lawyer, healthcare professional, or security researcher serving a financial client shouldn't assume that the client's regulatory status automatically becomes their own. The relevant question may instead concern the service contract, information handling, or supplier assurance.
Similarly, understanding how to get ISO 27001 certified can help organize security governance, but certification doesn't settle DORA eligibility. Confirm your classification and any claimed concessions with the national competent authority.
Vendors and Third-Party Providers Under DORA
A supplier's claim of DORA compliance isn't a substitute for the financial firm's assessment. The firm needs to understand whether it can govern, audit, and, when necessary, replace the service.
The European Banking Authority's DORA preparation guidance addresses registers of contractual arrangements with ICT third-party providers, including entity, sub-consolidated, and consolidated levels. A completed questionnaire alone doesn't provide that ongoing record.
Test the dependency before accepting the label
Ask whether the product is an ICT service under the regulation. Then determine whether it supports a critical or important function, rather than assuming that every application has equal operational significance.
Finally, examine concentration and substitutability. Could the firm move the work elsewhere if the provider failed, restricted access, or became commercially unsuitable?
For important dependencies, an exit strategy should describe the destination, migration steps, access arrangements, and validation needed to resume the function. Document and test it rather than relying on a promise that data is exportable.
Request evidence you can use
- Arrangement inventory: Identify the service, owner, supported function, and dependencies.
- Contract record: Review incident notification, security measures, audit cooperation, and continuity terms.
- Resilience test results: Ask what was tested, what failed, and whether corrective actions were verified.
- Retention and deletion evidence: Establish what persists, where it persists, and how deletion is demonstrated.
- Exit documentation: Check how the function and necessary information would move to another arrangement.
An ephemeral communications service can retain little content yet still become operationally important. Evaluate whether disappearing records suit the business process before adopting it.
Guidance on data protection in the cloud helps distinguish information-handling concerns from service-dependency concerns. EU oversight of designated critical providers isn't blanket approval of every supplier or every proposed use.
Confirm Which DORA You Need Before You Act
For historical study, consult the UK Parliament entry on the Defence of the Realm Act. Look for the distinction between statutory authority and the regulations ministers made under it.
For financial regulation, use the legal text on EUR-Lex alongside ESMA and EBA guidance. Bring your entity classification, authorizations, and proposed simplifications to the national competent authority rather than asking only whether DORA applies to small businesses.
For software delivery, agree on definitions before configuring dashboards. Collect a consistent sample of production deployments, commits, and linked incidents, then investigate delays and failures before comparing performance labels.
For a procurement decision, take the vendor evidence checklist into the supplier discussion. For privacy-focused communications, ask specifically whether retention limits conflict with recordkeeping duties and whether incident-notification terms support your response process.
Keep the meaning you chose in mind whenever you read a vendor claim, dashboard, or news story.
Ciphar offers browser-based, identity-free encrypted chat for short conversations, with client-side encryption and self-destructing channels. It isn't a regulated-communications tool or a substitute for operational-resilience controls. Visit Ciphar to review its security model and decide whether its deliberately temporary design fits your conversation.
