You cannot protect, monitor or report a breach of data you do not know you hold, and most organisations hold far more copies of sensitive data, in more places, than their records show. MITRE D3FEND names the countermeasure Data Inventory (D3-DI) and defines it as identifying and recording "the schemas, formats, volumes, and locations of data stored and used on the organization's architecture." It sits under the Model tactic as a child of Asset Inventory (D3-AI), alongside Asset Vulnerability Enumeration, Configuration Inventory, Hardware Component Inventory, Network Node Inventory and Software Inventory. This page explains what a data inventory should record, how discovery tooling and owner input combine, how to keep the inventory current and how it feeds detection, hardening and privacy obligations. It is written for data security leads, security architects and privacy teams, and goes deeper than the Data Classification Guide on the inventory itself.
Key takeaways
- Four attributes define the record. D3FEND names schemas, formats, volumes and locations; add classification, owner and the identities with access, and the inventory becomes usable for security decisions.
- Databases and document files are the artefacts. D3FEND models D3-DI as inventorying Database and Document File, which covers structured stores, file shares, mailboxes, code repositories and credential stores.
- Discovery tools find, owners explain. Scanners locate stores and detect sensitive data types; only owners can say why the data is there, how long it must be kept and who may use it.
- Freshness is the hard part. Profiles must rerun when schemas or contents change, and new stores must be picked up automatically, or the inventory decays within months.
- Access belongs in the record. Recording which service accounts, workload identities and AI agents can read each store turns the data inventory into a map of non-human identity blast radius.
D3-DI at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DI (d3f:DataInventory) |
| Tactic | Model |
| Parent technique | Asset Inventory (D3-AI) |
| Synonyms in D3FEND | Data Discovery, Data Inventorying |
| Digital artefacts | Database and Document File (D3FEND relation: inventories) |
| D3FEND reference | Patent US11240273B2, "Data processing and scanning systems for generating and populating a data inventory" (OneTrust LLC) |
| ATT&CK relations | Inferred only, through the Database and Document File artefacts (D3FEND 1.6.0, checked November 2026) |
| Effort | Medium for cloud stores with native discovery; high for on-premises file shares and legacy databases |
What a data inventory records
D3FEND's reference patent describes generating a data model for the data assets an organisation uses and mapping relationships between them, where a data asset is any system that collects, processes, contains or transfers personal data. Security use needs the same structure, extended beyond personal data. The fields below are an NHI Mgmt Group suggestion built on the four D3FEND attributes.
| Field | D3FEND attribute | Example | Security use |
|---|---|---|---|
| Location | Locations | Cloud account and bucket, database instance, file share path, SaaS tenant, region | Scope for monitoring, residency and incident response |
| Schema and data types | Schemas | Table and column names; detected types such as payment card numbers or national identifiers | Classification and DLP rules |
| Format | Formats | Relational table, Parquet, CSV export, Office documents, backups | Which inspection tools can read it |
| Volume | Volumes | Row count, object count, size; growth rate | Breach impact estimates; anomaly baselines |
| Classification | (addition) | Public, Internal, Confidential, Restricted | Handling and control requirements |
| Owner and purpose | (addition) | Business owner, processing purpose | Accountability; retention and deletion decisions |
| Identities with access | (addition) | Groups, service accounts, workload identities, AI agents | Least privilege reviews and blast radius analysis |
| Retention and copies | (addition) | Retention period, backups, replicas, analytics copies | Finding stale and duplicate data to delete |
Building it: discovery plus ownership
Discovery tools answer where data is and what it looks like. Major cloud platforms document native discovery services; examples, listed alphabetically, show the common pattern.
- Amazon Macie (AWS): automated sensitive data discovery evaluates the Amazon S3 bucket inventory on an ongoing basis, uses sampling to select representative objects, and as the analysis progresses each day produces sensitive data findings, statistics and inventory data, an S3 buckets map and sensitivity scores per bucket. By default it covers all S3 general purpose buckets, and buckets such as logging stores can be excluded.
- Google Cloud Sensitive Data Protection: the discovery service (data profiler) creates profiles for BigQuery, Cloud SQL, Cloud Storage, Vertex AI training data and, through connectors, Amazon S3 and Azure Blob Storage. Profiles record predicted infoTypes, sensitivity and data risk levels; by default a resource is reprofiled 30 days after its last profile if relevant changes occurred, with daily, weekly or monthly schedules available.
- Microsoft Purview Data Map: captures technical metadata (schemas, data types, columns) through scanning, business metadata such as glossary terms, semantic metadata such as classifications, and lineage between assets, across on-premises, multicloud and SaaS sources. Incremental scans process only objects changed since the previous scan.
Data security posture management and data classification products extend the same approach across providers; the Data Security Posture Management (DSPM) guide covers that category. Ownership, purpose and retention cannot be scanned: they come from owners, from records of processing and from the data classification process.
Implementation steps
- Agree the record and the classification scheme. Fix the fields above and the classification levels before scanning, so findings land in a consistent structure. A Data Classification Policy Template is a practical start.
- Enumerate stores from the asset inventory. Pull databases, storage accounts, buckets, file servers and SaaS tenants from the CMDB and cloud account inventories. Stores not in the asset inventory are the first finding.
- Run discovery in report-only mode. Enable native or third-party scanning on a pilot set of accounts, exclude logging and backup stores where cost demands, and review findings with owners before any automated remediation.
- Assign owners and confirm purpose. Every store with Confidential or Restricted data gets a named owner, a purpose and a retention period. Stores nobody claims are candidates for archive or deletion through change control.
- Attach access. Record which human groups and which non-human identities can read and write each sensitive store, from cloud IAM policies, database grants and share permissions.
- Automate freshness. Schedule reprofiling, alert on new stores created without tags, and feed new stores to the scanner automatically from account creation pipelines.
- Roll back safely. Scanning reads data and uses compute and quota; if a scan affects a production database, pause it, scope it to replicas or snapshots, and reschedule outside peak hours.
Where identity fits
Data inventories traditionally record human access groups. The identities that actually touch most data stores are non-human: ETL service accounts, application database logins, backup agents, analytics workloads and, increasingly, AI agents and retrieval pipelines with read access to document stores. Recording them per store answers the question an incident responder asks first when a credential leaks: what could this identity read. The NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide covers building the identity side of that join.
ATT&CK techniques D3FEND relates to D3-DI
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-DI. Its knowledge base infers relations through the Database and Document File artefacts and their sub-types (D3FEND treats the Windows Registry and password databases as databases, and email and Office files as documents), and labels them "inferred and experimental" (D3FEND 1.6.0, checked November 2026). Each ID below was checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques D3FEND relates | Practical relevance to a data inventory |
|---|---|---|
| Collection | T1114.001 Local Email Collection; T1213.003 Code Repositories | Mailbox archives and code repositories are data stores; inventory them with their sensitive content |
| Credential Access | T1003.002 Security Account Manager; T1003.004 LSA Secrets; T1003.008 /etc/passwd and /etc/shadow; T1555.001 Keychain; T1555.002 Securityd Memory; T1555.003 Credentials from Web Browsers; T1552.002 Credentials in Registry | Credential stores are databases in D3FEND terms; an inventory that flags stores holding credentials points hardening at them |
| Initial Access | T1566.001 Spearphishing Attachment; T1566.002 Spearphishing Link | Weak: relation via document files, not via inventory practice |
| Persistence and Privilege Escalation | T1137.003 Outlook Forms; T1137.006 Add-ins; T1543.003 Windows Service; T1546.012 Image File Execution Options Injection; T1546.015 Component Object Model Hijacking; T1548.004 Elevated Execution with Prompt | Weak: relation via registry and Office files |
| Defense Impairment and Stealth | T1112 Modify Registry; T1207 Rogue Domain Controller; T1218.005 Mshta; T1218.014 MMC; T1564.003 Hidden Window; T1564.005 Hidden File System; T1564.007 VBA Stomping | Weak: relation via registry and document artefacts |
| Discovery | T1012 Query Registry; T1614.001 System Language Discovery | Weak: relation via the registry artefact |
Read these rows as artefact overlap, not coverage. A data inventory does not detect any of these techniques. Its realistic contribution is the Collection and Credential Access rows: knowing where sensitive data and credential stores sit, so monitoring and hardening are aimed at them. For the most relevant technique, see the T1114 Email Collection Defensive Guide.
How it feeds other countermeasures
- Data loss prevention and egress monitoring: classification and location tell DLP which stores and paths matter.
- Access reviews: per-store identity lists focus entitlement reviews on stores holding Restricted data.
- Data flow modelling: the inventory supplies the data types each flow carries in D3-DEM Data Exchange Mapping.
- Breach response: volumes and data types answer how many records and which categories were exposed, which drives notification decisions. See the Data Breach Notification Checklist.
- Privacy records: GDPR Article 30(1) requires records of processing that include the categories of data subjects and personal data, recipients, transfers to third countries, envisaged erasure time limits where possible, and a general description of security measures where possible. A data inventory is the evidence base for those records.
How to verify it works
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | What it shows |
|---|---|---|
| Data stores in the asset inventory covered by discovery | Above 95% of cloud stores; rising for on-premises | Coverage |
| Stores holding Confidential or Restricted data with a named owner | 100% | Accountability |
| Median age of the latest profile for sensitive stores | Within the agreed reprofiling period | Freshness |
| New stores discovered without tags or owner | Falling quarter on quarter | Provisioning controls are working |
| Sensitive stores with a complete list of non-human identities with access | Rising quarter on quarter | Identity linkage |
A simple test: seed a test bucket or share with synthetic sensitive records (generated values, never real data), and confirm the store appears in the inventory with the right classification within the expected scan cycle.
Limits and failure patterns
- Scanning only the cloud: native services make cloud discovery easy, so file servers, endpoints, backups and SaaS exports are left out, and those are often where old bulk exports sit.
- Sampling treated as complete: sampled discovery estimates sensitivity per store; it does not prove that an unflagged object is clean. Use full scans for high-risk stores.
- Classification without owners: a store flagged as sensitive but owned by nobody cannot be remediated, retained correctly or deleted.
- Copies outside the inventory: analytics extracts, test environments seeded from production and AI retrieval indexes hold copies of sensitive data under different names. Track derived copies back to their source.
- Credential stores missed: configuration files, CI variables and repositories hold secrets as well as data; D3FEND's own artefact relations include credential stores, and leaving them out of the inventory leaves them out of hardening.
- Scanner identity over-privileged: the discovery service account can read every sensitive store by design. Protect it like a privileged identity, monitor its use and restrict who can change scan scope.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-07 | "Inventories of data and corresponding metadata for designated data types are maintained" |
| NIST CSF 2.0 | ID.AM-08 | Systems, hardware, software, services and data are managed throughout their life cycles |
| NIST SP 800-53 Rev 5 | CM-12 Information Location | Identify and document where information is processed and stored, who has access, and changes to location |
| NIST SP 800-53 Rev 5 | PM-5(1) Inventory of Personally Identifiable Information | Inventory of systems, applications and projects that process PII |
| CIS Controls v8.1 | Safeguard 3.2 Establish and Maintain a Data Inventory | Data inventory based on the data management process |
| ISO/IEC 27001:2022 Annex A | A.5.9 Inventory of information and other associated assets; A.5.12 Classification of information | Inventory and classification controls |
| GDPR | Article 30 Records of processing activities | Records that a data inventory supports |
| MITRE D3FEND | D3-AI, D3-DI | Parent and technique |
Related countermeasures
- Asset Inventory (D3-AI): the parent. See the MITRE D3FEND Asset Inventory Implementation Guide.
- Configuration Inventory (D3-CI) and Software Inventory (D3-SWI): sibling inventories that record how the systems holding data are configured and what runs on them.
- Data Exchange Mapping (D3-DEM): models where data moves once you know where it lives.
Practitioner checklist
- Define the inventory record with location, schema, format, volume, classification, owner, access and retention.
- Start from the asset inventory and treat stores missing from it as findings.
- Enable native discovery on every cloud account and set a reprofiling schedule.
- Extend discovery to file servers, backups, mailboxes, code repositories and SaaS exports.
- Give every sensitive store a named owner, a purpose and a retention period.
- Record the non-human identities and AI agents with access to each sensitive store.
- Protect and monitor the discovery service identity as a privileged account.
- Test detection quarterly with synthetic sensitive data and record the result.
Standards and references
- MITRE D3FEND: Data Inventory (D3-DI)
- NIST: Cybersecurity Framework 2.0 (ID.AM-07)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (CM-12, PM-5(1))
- EUR-Lex: Regulation (EU) 2016/679 (GDPR), Article 30
- Google Patents: US11240273B2, data processing and scanning systems for generating and populating a data inventory
- AWS: Amazon Macie automated sensitive data discovery
- Google Cloud: Sensitive Data Protection data profiles
- Microsoft Learn: Microsoft Purview Data Map
Related NHI Mgmt Group resources: Data Classification Guide · Data Mapping and ROPA Guide · Data Security Posture Management (DSPM) · Asset Inventory and CMDB Security Guide · MITRE D3FEND Guide