D3-ODM Operational Dependency Mapping: Linking Business Activities to the Systems They Need

When a server, a cloud service or a certificate fails, security teams are asked which business activities stop, and most cannot answer without a day of phone calls. MITRE D3FEND names the countermeasure that prepares this answer Operational Dependency Mapping (D3-ODM): it "identifies and models the dependencies of the organization's activities on each other and on the organization's performers (people, systems, and services.)" and may include "modeling the higher- and lower-level activities of an organization forming a hierarchy, or layering, of the dependencies in an organization's activities." It sits under the Model tactic as a child of Operational Activity Mapping (D3-OAM). This page explains what such a dependency model contains, how mission dependency research structures it, how to build one with ordinary enterprise data and how it feeds incident response and prioritisation. It is for security architects, resilience and business continuity leads, and SOC managers who need to translate technical events into business impact.

Key takeaways

• It models activities, not just assets. D3-ODM links what the organisation does to who and what performs it: people, systems and services, layered from high-level objectives down to components.
• The research behind it is mission impact analysis. D3FEND's references include MITRE's Cyber Command System, JHU APL's Dagger and a NATO paper on mission dependency modelling, all built to answer "what happens to the mission if this fails?"
• Dependency logic matters. Whether an activity needs all of its inputs or any one of several (redundancy) decides whether a failure is critical or absorbed.
• D3FEND lists no ATT&CK relations. The technique page shows none; D3-ODM supports response and prioritisation rather than countering a specific technique.
• Non-human identities are performers too. Service accounts, API keys and certificates are dependencies whose expiry or revocation can stop an activity as surely as a server outage.

D3-ODM at a glance

How the model is structured

D3FEND's parent technique, Operational Activity Mapping, identifies the organisation's activities and who performs them, then "establishes the dependencies of the activities on the systems and people that perform those activities." D3-ODM is the dependency layer of that work. The NATO IST-148 paper cited by D3FEND gives a worked structure: a hierarchical graph running from missions through objectives, tasks and functions down to IT assets, with each edge a directed dependency from parent to child.

The same paper models two kinds of dependency. Conjunctive (AND) dependencies require every child to succeed; disjunctive (OR) dependencies are satisfied by any one child, such as a primary or backup server. It also weights each edge with a criticality score, so a query starting at a failed asset can trace upwards to the tasks and objectives it degrades and flag non-redundant critical dependencies as single points of failure. These properties are what make the model useful under pressure rather than just a diagram.

What the D3FEND references show

• MITRE CyCS: described by MITRE as enabling "the mapping of mission operations to the network operations that support those missions", with mission impact assessment through situational awareness and impact analysis.
• JHU APL Dagger: a modelling and visualisation suite that shows "how system failures impact mission status". Its fact sheet describes status updated manually or in real time through data adapters, model import from CSV and GraphML, and "what if" scenarios for course of action analysis.
• OMG UAF: an architecture framework standard (version 1.3 at the time of checking, November 2026) whose primary modelling elements include Operational Performers and Operational Activities. Organisations that already use architecture frameworks can hold dependency data there.

Most enterprises will not deploy defence mission tooling. The lesson from these references is the data model: layered activities, typed dependencies with AND/OR logic, criticality weights and live status feeds. Those can be held in a CMDB with service mapping, a graph database or an architecture repository.

How to build the map

1. Start from the business impact analysis. Take the prioritised activities and recovery objectives already agreed for continuity planning; the Business Impact Analysis Template gives a structure. Do not invent a separate list of important activities.
2. Decompose each priority activity. Work with the process owner to list tasks, the services each task uses, and the people, suppliers and systems behind each service. Stop at the level where a single failure is meaningful.
3. Join to technical discovery. Link services to CMDB items and to discovered application dependencies (connections between hosts, queues, databases and external APIs). Discovery finds dependencies owners forget; owners explain which ones matter.
4. Add identities and secrets. For each service, record the service accounts, API keys, certificates and OAuth integrations it needs, with their owner and expiry. These are dependencies that rarely appear in diagrams.
5. Type every dependency. Mark AND or OR, add a criticality weight, and note the recovery time each dependency can tolerate.
6. Store it as a graph. Use a structure that can be queried upwards and downwards; a static drawing cannot answer "what does this asset affect?" during an incident.
7. Connect status feeds. Link monitoring, incident tickets and vulnerability data to nodes so the model shows current health, as Dagger's design intends.
8. Review on change and on a cycle. Update on major changes and new suppliers, and review each priority activity with its owner at least annually or on the business continuity review cycle.

Where identity fits

Expired certificates, rotated keys that were not updated in a dependent system, and a deleted service account are common causes of outages, and they are invisible in a model that stops at servers. Recording non-human identities as performers lets you answer "what breaks if we revoke this credential?" before you revoke it during an incident, which speeds containment. It also makes ownership gaps visible: a credential that a priority activity depends on but no one owns is a resilience risk as well as a security one. See How to assign owners to orphaned service accounts.

How the map is used

Decision guidance

• Small organisations: a spreadsheet or lightweight graph for the five to ten activities that matter most, built in workshops, is enough. Add the credentials each one needs.
• Mid-size organisations: extend the CMDB with business service records and service mapping, and connect the business impact analysis to it, so the model is maintained by existing processes.
• Large or regulated organisations: a graph store or architecture repository with automated discovery feeds, typed dependencies and live status, linked to operational resilience obligations such as important business services and impact tolerances where regulators require them.
• Depth versus currency: a shallow model that is current beats a deep one that is a year old. Model priority activities fully and the rest at service level.

How to verify it works

• Tabletop test: pick a real asset or credential, query the model for impact, then walk through the scenario with service owners and compare.
• Incident replay: after each significant incident, check whether the model predicted the activities that were actually affected; add missing edges.
• Recovery test cross-check: during disaster recovery tests, confirm the restoration order matches the dependency graph.

Example metrics (illustrative, not a standard):

• Percentage of priority activities with a complete dependency model reviewed in the last 12 months.
• Number of known single points of failure under priority activities, and how many have a treatment plan.
• Percentage of dependent non-human identities with a named owner and recorded expiry.
• Incidents where the model correctly predicted affected activities.
• Time from asset alert to stated business impact during incidents.

Limits and common failure patterns

• Asset-only maps: a CMDB of servers with no activities above them cannot answer business impact questions.
• No dependency logic: treating every link as critical hides redundancy, and treating every link as redundant hides single points of failure.
• Missing suppliers and SaaS: external services and integrations often carry the most critical dependencies; the Change Healthcare Breach 2024 showed how one provider's compromise can stop activities across many dependent organisations.
• Missing credentials: certificates, keys and service accounts are left out, so the model cannot predict credential-driven outages or the impact of revocation.
• One-off exercise: a model built for an audit and never updated misleads responders. Assign owners and tie updates to change.
• Too much detail: modelling every component of every activity stalls the project. Prioritise.

Framework mapping

Related countermeasures

D3-ODM sits under Operational Activity Mapping, covered in the MITRE D3FEND Operational Activity Mapping Implementation Guide, alongside Organization Mapping (D3-OM) and Operational Risk Assessment (D3-ORA). Technical dependency techniques under System Mapping, such as Service Dependency Mapping (D3-SVCDM) and System Dependency Mapping (D3-SYSDM), supply the lower layers of the graph. The Business Continuity and Disaster Recovery Guide covers the continuity programme the model supports.

Practitioner checklist

• Start from the agreed business impact analysis and its priority activities.
• Decompose each priority activity to tasks, services and performers with its owner.
• Join the model to CMDB records and discovered application dependencies.
• Record service accounts, keys, certificates and integrations as dependencies with owner and expiry.
• Mark each dependency AND or OR, with a criticality weight.
• Store the model as a graph that can be queried upwards and downwards.
• Use the model in incident triage and containment decisions, and replay incidents against it.
• Review priority activities at least annually and on major change.

Standards and references

• MITRE D3FEND: Operational Dependency Mapping (D3-ODM)
• NIST: IR 8179 Criticality Analysis Process Model
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• OMG: Unified Architecture Framework (UAF)
• Heinbockel, Noel and Curbo: Mission Dependency Modeling for Cyber Situational Awareness (NATO IST-148)
• MITRE: Cyber Command System (CyCS)
• JHU APL: Dagger Fact Sheet

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Cyber Resilience Guide · Asset Inventory and CMDB Security Guide · Business Impact Analysis Template