Data-centric system threat modelling is a threat modelling approach that starts with the data an application, service, or platform stores, processes, or transmits. It maps where the data lives, who can access it, how it moves, and what threats could expose, alter, or destroy it.
How data-centred threat modelling works
Data-centric threat modelling starts from the information itself, not the application boundary. It asks what data exists, where it is created or stored, how it moves, and which systems, users, and integrations can touch it. That lens is useful when a single dataset spans multiple services, trust zones, or lifecycle stages.
Why the data-first lens matters
Traditional threat modelling can over-focus on servers, APIs, or network paths and miss the value of the data being protected. A data-first approach helps teams distinguish between sensitive records, routine telemetry, derived data, and replicated copies, then identify which parts of the environment would create the most harm if exposed, altered, or destroyed.
It is especially helpful where data crosses organisational boundaries, is cached or transformed by several components, or is reused in analytics, AI, or third-party workflows. The key security question becomes not just “what can be attacked?” but “which data assets, if compromised, would matter most?”
What gets modelled in practice
The model usually tracks data categories, custody, access paths, trust boundaries, storage locations, and the operations performed on the data, such as read, write, copy, export, or delete. It also considers integrity threats, because many data failures are not about theft alone, but about silent manipulation, poisoning, or loss of provenance.
That makes the method useful for prioritising controls around encryption, access restriction, logging, segregation, backup, retention, and recovery. It also exposes hidden dependencies, for example when a supposedly isolated service actually relies on a shared data store, shared keys, or broad administrative access.
How it differs from system-centric modelling
System-centric modelling often begins with components and then asks what data they hold. Data-centric modelling reverses that order, which can surface different threats and different owners. A system may look low-risk in isolation, yet still be a critical exposure point if it handles high-value or regulated data.
The approach does not replace system or application threat modelling, but it sharpens them. Used well, it produces a clearer view of data flow, sharper scoping for safeguards, and more accurate prioritisation of where compromise would matter most.
Risk and Threat Considerations
Data-centric threat modelling matters because attackers often target the easiest path to valuable information, including replicated stores, exports, backups, caches, logs, and downstream analytics systems. It also helps identify where integrity failure can be as damaging as disclosure, especially when records drive decisions, automation, or audit evidence.
Failure mechanism: Weak inventory, unclear data ownership, or incomplete flow mapping can hide a high-value data path until a breach, corruption event, or recovery failure exposes it.
Impact: Organisations may miss critical exposure points, under-protect sensitive records, or fail to detect when stolen, altered, or deleted data has spread beyond the primary system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Data-centric models often expose overbroad data access paths and shared privileges. |
| AU-2 — Event Logging | Data flow and access tracking depend on logging the key data handling events. | |
| CP-9 — System Backup | The approach highlights backup and recovery as part of data availability and resilience. | |
| Recommendation — Apply AC-6 to limit who can read, modify, export, or delete each data set. Log data access, transfers, and changes so modelled pathways can be monitored. Use CP-9 to protect critical data against loss and support recovery validation. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Data-centric threat modelling directly supports protecting sensitive data wherever it resides. |
| Recommendation — Map sensitive data locations and apply CIS-3 safeguards across storage, transfer, and use. | ||
Practitioner Guidance
Why practitioners should care: The method is most useful when the data lifecycle is more complex than the hosting stack. If the same dataset appears in production systems, exports, test environments, search indexes, or partner integrations, the threat model should follow the data wherever it goes, not stop at the original application.
What to watch for: The biggest warning sign is when teams can name the application owner but not the data owner, or when they can describe infrastructure controls but not the controls that protect each sensitive data class across its full journey. That usually means the threat model is incomplete.
Related resources from NHI Mgmt Group
- Guide: Threat Modelling AI Agents
- Threat Modeling
- How should security teams choose between file-centric DLP and user-centric insider threat monitoring for data loss prevention?
- AI Data Loss Threat Modeling
- What is the difference between compliance-driven identity control and threat-centric identity control?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org