D3-ORA Operational Risk Assessment: What It Models and How to Build It

Most security risk registers list systems and vulnerabilities, yet leaders make decisions about business activities, so the register rarely answers the question they ask: what happens to this activity if that weakness is used against us? MITRE D3FEND names the defensive work of closing that gap Operational Risk Assessment (D3-ORA), synonym Mission Risk Assessment, and defines it as identifying and modelling "the vulnerabilities of, and risks to, an organization's activities individually and as a whole." It sits under the Model tactic as a child of Operational Activity Mapping (D3-OAM). This guide explains what D3-ORA models, how it differs from a system-level assessment, how to run one using the NIST publications D3FEND cites, how to keep it current and where it goes wrong. It is written for risk managers, security architects and CISOs who need security risk expressed in terms of what the organisation does.

Key takeaways

• The unit of analysis is the activity. D3-ORA assesses risk to operational activities and to the organisation as a whole, not to a single host or application, which is what separates it from a vulnerability scan or a system assessment.
• It depends on its sibling models. Without Organization Mapping, Operational Dependency Mapping and Access Modeling, an operational risk assessment has nothing reliable to assess.
• D3FEND lists no ATT&CK relations for it. The D3-ORA page shows no direct or inferred ATT&CK techniques (checked November 2026); threat scenarios come from your own threat assessment.
• D3FEND points to the NIST risk publications. Its references are SP 800-37 Rev. 2, SP 800-53A Rev. 5, SP 800-160 Volume 1, NISTIR 8011 Volume 1, the RMF Assess step FAQ and a SANS vulnerability management course.
• Identities are a dependency class of their own. Service accounts, API keys and workload identities often carry an activity end to end, so their compromise is an operational risk, not just an IAM finding.

D3-ORA at a glance

How it differs from other assessments

NIST SP 800-30 Rev. 1 describes risk assessment at three tiers: organisation, mission or business process, and information system. D3-ORA lives mainly at the middle tier and rolls up to the first; system-level results from the third tier are inputs, not the output.

What it models

• Activities: the operational activities from the parent D3-OAM model, such as taking customer payments, running a production line or releasing software, each with an accountable owner from Organization Mapping.
• Dependencies: systems, data, suppliers, people and identities each activity relies on, from Operational Dependency Mapping and system dependency maps.
• Vulnerabilities: weaknesses in those dependencies, including technical findings, missing controls, single points of failure and concentration of knowledge in one person.
• Threats and scenarios: credible events that would exploit the vulnerabilities, drawn from threat intelligence and incident history.
• Likelihood and impact: estimated per scenario for each activity, then aggregated for the organisation as a whole, since several low risks sharing one dependency can form one large risk.

Where identity fits

Activities are increasingly carried by non-human identities: a payment run depends on a scheduler's service account, a release depends on a CI token with production rights, a customer service flow depends on an AI agent's API keys. Treat each of these identities as a dependency in the model, record its owner and privileges, and assess what its compromise does to the activity. This turns findings such as "long-lived key with broad rights" into activity-level risk statements leaders can act on. The Crown jewels analysis guide covers how to pick the activities and assets to start with.

How to run one

1. Frame the assessment. Agree scope, risk appetite, the likelihood and impact scales, and whether the method is qualitative or quantitative. The Cyber Risk Appetite Statement Template helps here. NIST SP 800-30 Rev. 1 calls this the prepare step, followed by conduct, communicate and maintain.
2. Select the activities. Start with the activities whose loss would cause the largest harm, usually identified from a business impact analysis, and confirm each has a named owner.
3. Pull the dependency model. For each activity list the systems, data stores, suppliers, people and identities it needs. Where the dependency map does not exist yet, build a minimum version with the activity owner in a workshop.
4. Attach vulnerabilities to dependencies. Link vulnerability and configuration findings, control assessment results, identity findings and supplier assessments to the dependencies they affect. NISTIR 8011 Volume 1 describes automating control assessment, which is one way to keep this input fresh.
5. Develop scenarios. For each activity write a small number of concrete scenarios, for example ransomware on the scheduling servers, theft of a CI token, or loss of a single supplier, and estimate likelihood and impact against the agreed scales.
6. Aggregate. Look across activities for shared dependencies and correlated scenarios. A single identity provider, a single administrator team or a single cloud account can make many activities fail together.
7. Record and treat. Put each risk in the register with owner, rating and treatment (accept, mitigate, transfer, avoid), then feed the mitigations into control selection. NIST IR 8286 Rev. 1 (final, December 2025) describes recording cybersecurity risk in risk registers and aggregating them into enterprise risk management.
8. Communicate and maintain. Report risks per activity to the activity owners and leadership, then re-assess on triggers as well as on a schedule (see below).

For quantitative estimates of loss, see the FAIR Model and Open FAIR Standard Guide and the Cyber Risk Quantification Guide. For the overall risk process, the ISO 31000 Risk Management Guide and the NIST Risk Management Framework (SP 800-37) Guide give the wider context.

Keeping it current

A one-off workshop gives a snapshot. D3-ORA earns its place when it is re-run on events that change risk.

• Dependency changes: a new supplier, a migration to a new platform, a new integration or a new non-human identity with production rights on an assessed activity.
• Organisation changes: reorganisations, outsourcing, departure of the only person who knows a process.
• Threat changes: a new technique actively used against your sector, or a relevant incident at a peer.
• Control results: failed control assessments or a sharp rise in critical findings on a dependency.
• Incidents and exercises: lessons learned that show a scenario was more likely or more damaging than estimated.

The thresholds in the first row are examples (an NHI Mgmt Group suggestion, not a standard).

Common failure patterns

• A vulnerability list relabelled as risk: a register of CVEs with severity scores is not an operational risk assessment. Without activities and impact it cannot guide leadership decisions.
• No dependency model: assessing an activity without knowing what it depends on produces guesses. Build the minimum dependency map first.
• Missing identities and suppliers: assessments that list servers but omit the service accounts, API keys and third parties carrying the activity understate the most common attack paths.
• Risks assessed one at a time: treating each risk in isolation hides concentration. D3FEND's definition explicitly includes risks to activities "as a whole".
• No owner or no treatment: risks recorded with "IT" as owner and no date never move.
• Annual cadence only: the assessment is outdated after the first major change. Use change triggers.

Framework mapping

For operational technology, the zone and conduit method in the IEC 62443-3-2 OT Risk Assessment Guide applies the same idea to industrial processes. The parent model is covered in the MITRE D3FEND Operational Activity Mapping Implementation Guide.

Practitioner checklist

• Define the activities in scope and confirm each has an accountable owner.
• Agree likelihood and impact scales and risk appetite before scoring.
• Build or pull a dependency map for each activity, including identities and suppliers.
• Link vulnerability, control assessment and identity findings to the dependencies they affect.
• Write concrete scenarios per activity and look for shared dependencies across activities.
• Record every risk with owner, rating, treatment and date in a register that rolls up to enterprise risk.
• Re-assess on dependency, organisation, threat and control changes, not only annually.
• Track freshness, ownership and overdue treatments as programme measures.

Standards and references

• MITRE D3FEND: Operational Risk Assessment (D3-ORA)
• NIST: SP 800-30 Rev. 1 Guide for Conducting Risk Assessments
• NIST: SP 800-37 Rev. 2 Risk Management Framework for Information Systems and Organizations
• NIST: IR 8286 Rev. 1 Integrating Cybersecurity and Enterprise Risk Management
• NIST: About the Risk Management Framework
• NIST: SP 800-160 Vol. 1 Rev. 1 Engineering Trustworthy Secure Systems
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: MITRE D3FEND Operational Activity Mapping Implementation Guide · NIST Risk Management Framework (SP 800-37) Guide · Cyber Risk Quantification Guide · Crown jewels analysis · MITRE D3FEND Guide