Most organisations can list their applications but cannot say which data types each one is supposed to send to which other system, in what format and at what volume, so unexpected flows go unnoticed. MITRE D3FEND names the countermeasure that fixes this Data Exchange Mapping (D3-DEM) and defines it as identifying and modelling "the organization's intended design for the flows of the data types, formats, and volumes between systems at the application layer." It sits under the Model tactic as a child of System Mapping (D3-SYSM), next to Service Dependency Mapping, System Dependency Mapping and System Vulnerability Assessment. This page explains what a data exchange map records, where the information comes from, how to keep it current and how it feeds detection and hardening. It is written for security architects, data protection leads and detection engineers, and goes deeper than the overview in the Data flow mapping for security and privacy guide.
Key takeaways
- It models intent, not observed traffic. D3FEND frames D3-DEM as the intended design for application-layer flows; what the network actually carries is captured by the link mapping techniques, and the security value comes from comparing the two.
- Each exchange is a record with fields. Source, destination, data types, format, expected volume, protocol, identity used and the agreement or ticket that approved it make a flow testable.
- Interface descriptions are the best raw material. OpenAPI and AsyncAPI documents, integration platform configurations and information exchange agreements already describe most flows in machine-readable form.
- D3FEND lists no ATT&CK relations for D3-DEM. Like most Model techniques it has no offensive mappings; its value is indirect, through the detection and isolation techniques that use the map.
- Every flow runs as some identity. Recording the service account, API key or OAuth client behind each exchange links the data map to non-human identity governance and makes credential misuse visible.
D3-DEM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DEM (d3f:DataExchangeMapping) |
| Tactic | Model |
| Parent technique | System Mapping (D3-SYSM) |
| Synonyms in D3FEND | Data Flow Mapping, Information Exchange Mapping |
| Digital artefact | Data Dependency (D3FEND relation: maps), defined as existing "when a process, operation, or system requires specific data in order to execute correctly" |
| D3FEND references | OMG Unified Architecture Framework (UAF); Dassault Systemes Catia UAF Plugin; IBM Tivoli Application Dependency Discovery Manager 7.3.0, dependencies between resources |
| ATT&CK relations | None listed (D3FEND 1.6.0, checked November 2026) |
| Effort | Medium to start for critical systems; ongoing effort depends on how much of the map is generated from interface descriptions |
What a data exchange map records
The D3FEND definition names three properties of each flow: data types, formats and volumes, at the application layer. A usable map turns those into fields that can be checked against reality. The table below is an NHI Mgmt Group suggestion for a minimum record, not a D3FEND schema.
| Field | Example | Why it matters for security |
|---|---|---|
| Source and destination system | Order service to payments gateway | Defines the allowed pair; anything else is a candidate anomaly |
| Data types and classification | Customer name, card token; Confidential | Ties the flow to the data inventory and to handling rules |
| Format and schema | JSON over HTTPS, schema reference in the OpenAPI document | Enables schema validation and content inspection |
| Expected volume and timing | About 20,000 messages a day, business hours peak | Gives a baseline for volume anomaly detection |
| Protocol, port and direction | HTTPS 443, push from source | Feeds firewall and egress policy |
| Identity and credential | OAuth client ID, service account or workload identity | Links the flow to an owner and to credential rotation |
| Approval reference | Information exchange agreement, architecture decision or change ticket | Shows the flow is authorised (NIST SP 800-53 CA-3, CA-9) |
| Owner and review date | Integration owner, next review | Keeps the map current and accountable |
Where the information comes from
D3FEND's references point at two kinds of source. UAF, an Object Management Group standard (version 1.3, published April 2026 according to the OMG specification page), is an architecture framework whose views include operational, services, resources and security viewpoints, and modelling tools such as the Catia UAF plugin capture information exchanges between systems as part of an architecture description. IBM's TADDM documentation shows the discovery side: it models runtime relationships between components, including transactional dependencies such as a JDBC connection from an application server to a database, service dependencies on DNS, LDAP or NFS, and application to application dependencies. In practice most organisations combine several sources.
| Source | What it gives the map | Limits |
|---|---|---|
| Architecture models (UAF, C4, enterprise architecture repositories) | Intended flows, design rationale, stakeholders | Drift as soon as the system changes, unless models are maintained |
| Interface descriptions (OpenAPI for HTTP APIs, AsyncAPI for message-driven APIs) | Operations, schemas, servers and security schemes in machine-readable form; AsyncAPI 3.0.0 adds channels and send or receive operations | Cover only documented APIs; volumes are not described |
| Integration and messaging platforms | Topic and queue definitions, ETL and file transfer jobs, producer and consumer lists | Platform specific; batch jobs often sit outside them |
| Information exchange agreements and records of processing | Approved exchanges with external parties and personal data transfers | Written for compliance, often at too coarse a level for detection |
| Application dependency discovery | Observed runtime connections between components | Shows what happens, not what was intended; use it to find gaps in the map |
| Threat models and data flow diagrams | Processes, data stores, flows and trust boundaries for a system | Usually per system and not joined up across the estate |
The OWASP Threat Modeling Cheat Sheet asks for data flow diagrams that show trust boundaries, data flows, data stores and processes, saved "in a form the team can update". The same diagrams are a strong starting point for D3-DEM when they are collected into one queryable model. See the Threat Modelling Guide for the method.
Where identity fits
An application-layer exchange is always performed by an identity: a service account opening the database connection, an API key on the partner call, an OAuth client in a SaaS integration or a workload identity in a cloud pipeline. Recording that identity per flow does two things. It gives every non-human identity a documented purpose, which is the hardest field to fill during an NHI inventory, and it lets a detection rule flag the same credential appearing on a flow it was never approved for. The NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide covers finding the identities themselves.
How to build it
- Scope by consequence. Start with systems that hold or move regulated or business-critical data, plus every flow that crosses a trust boundary (internet, partner, cloud tenant, OT zone). Use the D3-DI Data Inventory to decide which data types count.
- Harvest machine-readable descriptions. Collect OpenAPI and AsyncAPI documents, integration platform exports and scheduled transfer job definitions into one repository. Each operation or channel becomes a candidate flow record.
- Interview owners for the rest. File drops, database links, shared storage and vendor connectors are rarely described in specs. A short form per system (what it sends, to whom, how often, as which identity) fills the gap.
- Add volumes and identities. Volumes come from owners, platform metrics or a short observation period; identities come from connection configuration and secrets stores.
- Reconcile against observed traffic. Compare the map with connections seen by flow logs, proxies or dependency discovery. Every observed connection without a record is either a missing record or an unapproved flow; every record with no observed traffic may be dead and removable.
- Publish and connect. Store the map where policy and detection tooling can read it (a CMDB relationship type, an architecture repository with an API, or version-controlled YAML). Link each record to its system in the D3-SYSDM System Dependency Mapping and service records.
- Make change update the map. Add a "new or changed data exchange" question to architecture review and change approval, so a new integration cannot go live without a record. Rolling back is simple: a record marked retired keeps its history and its detection rule is removed after the flow is confirmed gone.
How it feeds other countermeasures
D3-DEM does not detect or block anything on its own. Its value comes from the techniques that consume it. These connections are NHI Mgmt Group's view of practical use, not D3FEND relations.
- Network and application allowlisting: approved source, destination, protocol and port per flow become egress and segmentation rules.
- Volume and schema anomaly detection: expected volumes and schemas give baselines for data transfer size alerts, unusual destination alerts and schema validation at API gateways.
- Data loss prevention: knowing which flows legitimately carry Confidential data lets DLP policies allow those paths and alert on others. See the Data Loss Prevention (DLP) Guide.
- Incident scoping: when a system is compromised, the map answers which data it could have sent onward and to whom, which matters for notification decisions.
- Privacy compliance: GDPR Article 30 records of processing must describe recipients and third country transfers; a maintained exchange map makes those records accurate.
How to verify it works
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | What it shows |
|---|---|---|
| Observed application connections matched to a flow record | Above 95% for in-scope systems | The map reflects reality |
| Flow records with an identity and owner recorded | 100% for flows carrying Confidential data | Accountability and NHI linkage |
| Records reviewed within their review period | Above 90% | The map is maintained, not a one-off project |
| New integrations live without a record | Zero per quarter | Change control is updating the map |
| Alerts on unmapped flows triaged and closed | Tracked monthly | Detection is using the map |
Limits and failure patterns
- Diagram without data: a picture in a slide deck cannot be queried by a firewall or SIEM. Keep records structured and let diagrams be generated from them.
- Intent never compared with reality: D3-DEM models intended flows. Without reconciliation against observed traffic it misses shadow integrations, which are exactly the flows an attacker or an unsanctioned tool creates.
- Volumes left blank: volume is in the D3FEND definition for a reason. Without it, bulk exfiltration over an approved path looks normal.
- Shared credentials across flows: one service account used for many exchanges makes it impossible to tell which flow a connection belongs to; split identities per integration where practical.
- SaaS and AI integrations missed: OAuth grants between SaaS platforms, and AI tools connected to data sources, move data at the application layer without passing any network control the organisation owns. Include them in scope.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-03 | "Representations of the organization's authorized network communication and internal and external network data flows are maintained" |
| NIST SP 800-53 Rev 5 | CA-3 Information Exchange | Document interface characteristics, security requirements and the impact level of information exchanged with other systems |
| NIST SP 800-53 Rev 5 | CA-9 Internal System Connections | Document each internal connection, including the nature of the information communicated, and review its continued need |
| NIST SP 800-53 Rev 5 | AC-4 Information Flow Enforcement | The enforcement control that uses the approved flows |
| NIST SP 800-53 Rev 5 | PL-8 Security and Privacy Architectures | Architectures that describe dependencies on external systems and services |
| CIS Controls v8.1 | Safeguard 3.8 Document Data Flows | Data flow documentation including service provider flows |
| ISO/IEC 27001:2022 Annex A | A.5.14 Information transfer | Rules and agreements for information transfer |
| MITRE D3FEND | D3-SYSM, D3-DEM | Parent and technique |
Related countermeasures
- Service Dependency Mapping (D3-SVCDM) and System Dependency Mapping (D3-SYSDM): sibling System Mapping techniques that model which services and systems depend on each other; D3-DEM adds what data moves along those dependencies. See D3-SVCDM Service Dependency Mapping.
- Passive Logical Link Mapping (D3-PLLM): builds the observed view of network connections that the intended map is reconciled against. See D3-PLLM Passive Logical Link Mapping.
- Data Inventory (D3-DI): the record of what data exists and where, which supplies the data types each flow carries.
- The parent technique is covered in the MITRE D3FEND System Mapping Implementation Guide.
Practitioner checklist
- Define a flow record with source, destination, data types, format, volume, protocol, identity, approval and owner.
- Scope first to regulated data and to flows that cross trust boundaries.
- Import OpenAPI, AsyncAPI and integration platform definitions instead of typing flows by hand.
- Record the non-human identity used by every flow and give it an owner.
- Reconcile the map against observed connections at least quarterly and investigate every unmatched flow.
- Store the map in a structured, queryable form that policy and detection tools can read.
- Add a data exchange question to architecture review and change approval.
- Include SaaS to SaaS OAuth integrations and AI tool connectors in scope.
Standards and references
- MITRE D3FEND: Data Exchange Mapping (D3-DEM)
- NIST: Cybersecurity Framework 2.0 (ID.AM-03)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (CA-3, CA-9, AC-4)
- OMG: Unified Architecture Framework (UAF)
- IBM: TADDM 7.3.0, dependencies between resources
- OpenAPI Initiative: OpenAPI Specification
- AsyncAPI Initiative: AsyncAPI Specification 3.0.0
- OWASP: Threat Modeling Cheat Sheet
Related NHI Mgmt Group resources: Data flow mapping for security and privacy · Data Mapping and ROPA Guide · Data lineage, data quality and data contracts as security controls · API Inventory Template · MITRE D3FEND Guide