DSPM, data security posture management, is the practice of finding where sensitive data lives across your systems, classifying it, seeing who and what can reach it, and fixing exposure. The label is an industry term, not a NIST one, but the underlying outcomes are in NIST CSF 2.0 and you can pursue them with or without a product.
What problem is it solving?
Data copies itself. A production database feeds a warehouse, which feeds an analytics notebook, which exports to a spreadsheet that someone attaches to a ticket. Meanwhile, cloud storage is created in minutes. Security teams usually protect the systems they know about. Sensitive data sitting in places nobody listed has no owner, no access review and no encryption plan.
DSPM is the label for answering four questions continuously: where is the sensitive data, what type is it, who or what can access it, and is it protected the way policy says?
Which NIST outcomes cover this?
NIST Cybersecurity Framework 2.0 has no DSPM category, but several outcomes describe the work.
- ID.AM-07: inventories of data and corresponding metadata for designated data types are maintained. This is the "where is it" question.
- PR.DS-01 and PR.DS-02: the confidentiality, integrity and availability of data at rest and in transit are protected.
- PR.DS-10: the confidentiality, integrity and availability of data in use are protected.
- PR.DS-11: backups of data are created, protected, maintained and tested.
- PR.AA-05: access permissions, entitlements and authorizations are defined in a policy, managed, enforced and reviewed, and incorporate least privilege and separation of duties. This is the "who can reach it" question.
Together these are a fair specification of a data security program. Any tool that claims to help should map to them, and any manual process you build should too.
How would you do this by hand?
Start with the data types your obligations care about: personal data, health records, payment data, credentials, source code, contracts. For each, name the systems of record, then trace copies. Ask engineers where exports, replicas, backups, logs and test data go. Search the places that tend to hide data: object storage buckets, shared drives, ticket attachments, chat uploads, notebooks and developer laptops.
Then classify with a simple scheme of three or four levels, attach an owner to each store, and review access against need. Most first reviews find stale permissions and test environments holding production data.
Where do tools help and where do they not?
Tools that scan stores for patterns can cover far more ground than a person, and can monitor change. Their limits are classification accuracy, since pattern matching produces both false positives and misses, and coverage, since they only see connected sources. They show exposure. Fixing it still needs owners, decisions and change control.
A constructed example
A company runs a customer data review. The system of record is a managed database, as expected. Tracing copies finds a nightly export to a storage bucket for a reporting team, a CSV of 20,000 customer emails in a support ticket attachment, a full production snapshot restored into a staging environment that 40 contractors can reach, and a debug log containing request bodies. The bucket and snapshot get owners and access reviews. The staging copy is replaced with masked data. Log redaction is added to the application. No tool was needed for the first pass, only questions and a list.
How to check or apply this
- Define sensitive data types and who decides the classification.
- Inventory systems of record, then trace every copy: exports, replicas, backups, logs, tests, analytics.
- Record owner, classification, location and retention for each store.
- Review access to each store against least privilege, and remove what is not needed.
- Check encryption at rest and in transit, key ownership and backup protection.
- Replace production data in test with masked or synthetic data.
- Repeat on a schedule, and trigger a review when new stores or integrations appear.
- If you evaluate tools, test them on a known sample: how much of your seeded sensitive data do they find, and how many false alarms do they raise?
Quick check
Is DSPM defined by NIST?
No. NIST CSF 2.0 does not use the term, though its outcomes for data inventory, data protection and access control describe the same work.
Do I need a tool to start?
No. A data inventory, an owner for each store and an access review are the foundation. A tool helps with scale and change tracking after that.
Sources
Last reviewed: 18 October 2026.
