Data Security Guide: DSPM, DDR and Data Exposure

Most organisations cannot say where all their sensitive data is, who and what can read it, or which copies are exposed, and that gap is where most data breaches and leaks start. Data now sprawls across SaaS tenants, cloud buckets, warehouses, file servers, pipelines and AI tools, and much of it is read by service accounts and integrations rather than people. This guide sets out the parts of a data security programme (discovery, classification, posture management, access governance, protection, retention and monitoring) and how they fit together. It gives a vendor-neutral view of data security posture management (DSPM) and data detection and response (DDR), including their limits and how to evaluate them. It is written for security architects, data protection leads and CISOs building or reviewing a programme.

Key takeaways

• Start with exposure, not tools. The fastest risk reduction usually comes from closing public buckets, organisation-wide shares and anonymous links on data you already know is sensitive.
• DSPM finds and ranks problems; it does not fix them. It answers where sensitive data is, who can reach it and how it is protected, but remediation still needs data owners, access changes and policy.
• Machine identities read most of the data. ETL jobs, BI connectors, backup tools, AI assistants and the DSPM scanner itself hold broad standing read access that access reviews rarely cover.
• Copies are the real sprawl. Exports, test datasets, pipeline staging areas and old snapshots hold production data without production controls; retention and deletion are security controls.
• AI multiplies oversharing. Assistants and retrieval systems surface whatever the user or agent identity can read, so permission hygiene has to come before AI rollout.

How the pieces of a data security programme fit

CIS Control 3 summarises the job as to "identify, classify, securely handle, retain, and dispose of data." NIST's data confidentiality practice guides split it the same way: SP 1800-28 covers identifying and protecting assets, and SP 1800-29 covers detecting, responding to and recovering from data breaches. The SP 1800-28 reference architecture combines Data Management ("discovery and tracking of files throughout the enterprise"), Data Protection, User Access Controls, Policy Enforcement, Logging (a baseline "of a normal enterprise activity for comparison") and Network Protection. The table shows how the main capabilities depend on each other.

The order matters. Without discovery, every other control covers only the data you already knew about; without identity data, posture findings cannot say who is exposed to what.

Discovery, classification and shadow data

• Scope every store type: object storage, managed databases and warehouses, SaaS (CRM, collaboration, ticketing, code hosting), file servers and NAS, endpoints, backups and snapshots. Structured and unstructured data need different techniques: schema and column sampling for databases, content inspection for files.
• Know how scanning works: full scans are slow and expensive at petabyte scale, so tools sample. Amazon Macie's automated discovery, for example, "uses sampling techniques to identify and select representative S3 objects", and points to targeted discovery jobs for "deeper, more immediate analysis". Sampling is right for coverage and wrong for proving a specific store is clean.
• Hunt shadow data deliberately: shadow data is sensitive data in places nobody governs: developer and test copies of production, CSV exports in personal drives, pipeline staging buckets, old database snapshots, abandoned analytics projects and data held by former suppliers. These are the copies that turn up in breach notifications.
• Classify with a small scheme: four levels (public, internal, confidential, restricted) are enough for most organisations. ISO/IEC 27001:2022 A.5.12 (classification) and A.5.13 (labelling) expect a scheme; CIS safeguard 3.7 asks for one to be maintained and 3.2 for a data inventory.
• Link data to purpose and owner: every sensitive store needs a named owner who can approve access and deletion. Personal data inventories also feed records of processing. See the Data Mapping and ROPA Guide.
• Do not forget secrets in data: CRM records, tickets, wikis and logs routinely contain API keys and passwords. Include secret detection in discovery. The Sisense breach reportedly combined a credential in a repository with storage full of customer tokens.

DSPM: what it does and where it stops

Microsoft says its DSPM "centers on the data itself", identifying where data resides, who can access it, how it is used and whether it is adequately protected. That is a fair category definition. A DSPM platform typically connects to cloud and SaaS APIs, discovers and classifies data stores, correlates them with identity and permission data, and ranks risks such as public exposure, missing encryption, sensitive data in non-production accounts, over-retention and over-permissioned access.

Limitations to plan for

• Coverage: cloud and major SaaS are usually well covered; on-premises file servers, mainframes, niche SaaS and endpoints often are not, or need agents or partner connectors.
• Classification accuracy: pattern-based detection produces false positives on test data and misses context-dependent data such as contracts or source code without tuning.
• Sampling blind spots: a store marked "no sensitive data" may simply not have been sampled deeply.
• It does not enforce: DSPM recommends; blocking happens in DLP, IAM, sharing settings or the data platform. Automated fixes such as removing public links need human approval for anything business-critical, and even vendor guidance says administrators "review, approve, or customize automated actions."
• The scanner is a privileged identity: to read data, DSPM needs broad read roles or snapshot access across accounts. Treat its roles and keys as tier-zero non-human identities.
• Findings without owners decay: thousands of findings with no data owner become a backlog nobody works.

Evaluating DSPM vendor-neutrally

Data exposure and over-permissioned data

Exposure is sensitive data reachable by more people or identities than intended, and it is usually accidental. The common forms are predictable:

• Public cloud storage and snapshots: buckets, blobs and database or disk snapshots shared publicly or with unknown accounts. AWS IAM Access Analyzer's external access analyzer generates a finding "for each instance of a resource shared outside of your account", covering S3, KMS keys and EBS and RDS snapshots, and its internal access analyzer shows which principals inside the organisation can reach selected business-critical resources. The Football Australia AWS keys exposure shows how keys in website code opened 127 buckets.
• Organisation-wide and anonymous sharing: in Microsoft 365 the "Everyone except external users" group makes content effectively available to every employee. SharePoint's data access governance reports identify sites with the broadest access, items shared with "Everyone" or EEEU, and sharing link activity over the last 28 days. Remediation options include Restricted access control and a site access review by owners. The Microsoft SAS token exposure is the storage-link version of the same mistake.
• Open file shares: on Windows file servers, share or NTFS permissions granting Everyone, Authenticated Users or Domain Users on folders holding HR, finance or customer data. Report on these first; they are the easiest wins.
• Data warehouses and ETL: broad analyst roles on production schemas, pipeline service accounts with read-all, staging tables that keep raw personal data after transformation, and unmasked sensitive columns. Use masking and row access policies for sensitive columns and review role grants. In Snowflake, the ACCESS_HISTORY view records "a single record per SQL statement" with the objects and columns accessed and the masking or row access policies enforced, which supports both review and monitoring.
• Stale access: leavers, movers and former suppliers who still hold access. Data access reviews should cover data stores, not just applications. See the Access Reviews Guide.
• Secure data sharing: when data must go to partners, share governed views or clean-room style outputs with expiry rather than full extracts, and record each share with an owner and end date. See the Privacy-Enhancing Technologies Guide.

Where identity fits

Data access is an identity question, and the identities with the widest reach are rarely people.

• Pipeline and integration identities: ETL service accounts, reverse-ETL tools, BI connectors and backup products often hold read access to entire warehouses. Inventory them as data consumers, scope them to the schemas they need and rotate their credentials. See the Service Account Security Guide.
• Cloud roles: in the Capital One breach, credentials for a firewall's cloud role were used to read data affecting 106 million people. Use unused-access and permission analysis to cut roles back. See the Cloud PAM and CIEM Guide.
• User credentials on data platforms: the Snowflake breach showed infostealer credentials without MFA unlocking customer data warehouses. Enforce MFA or key-pair authentication and network policies on every warehouse account.
• Posture across both: combine DSPM findings with identity posture so a finding reads "restricted data readable by 14 identities, 9 of them non-human, 3 unused for 90 days". See the ISPM Guide.

Data detection and response (DDR)

DDR is the monitoring half of the programme: watching access to sensitive data in near real time and acting when it looks wrong. It is a capability built on logs rather than a standard, and it only works where data-plane logging exists. NIST SP 1800-29 frames the goal as being able to detect, respond to and recover from data confidentiality attacks.

• Log sources: object-level storage logs (for example CloudTrail data events), warehouse query and access history, SaaS audit logs, file server object access auditing, and identity provider sign-ins for context. CIS safeguard 3.14 asks organisations to log sensitive data access.
• Signals: an identity reading far more records than its baseline, access to restricted data by an identity that never touched it before, new external shares on labelled content, queries from new networks, and mass downloads before a resignation date.
• Response actions: revoke the session or token, remove the share, apply a restrictive label or access control, and open an incident with the data owner. Agree in advance which actions can be automated.

For the egress side of the same problem, use DNS and proxy telemetry and the SIEM. See the SIEM Guide and the Insider Threat and Identity Guide.

Securing data for AI

AI assistants and retrieval-augmented generation answer from whatever the requesting identity can read. Oversharing that was low risk because nobody found the file becomes high risk once an assistant can search it. OWASP's LLM02:2025 Sensitive Information Disclosure lists access control ("Only grant access to data that is necessary for the specific user or process"), restricting data sources and data sanitisation among its mitigations.

• Fix permissions before rollout: run oversharing reports and remediate organisation-wide access on sensitive sites before enabling an enterprise assistant. See the Enterprise AI Copilot Security Guide.
• Enforce permissions at retrieval: retrieval must filter by the caller's entitlements, not the indexing identity's. See the Permission-Aware RAG Guide.
• Control training and fine-tuning data: classify datasets, remove or mask personal data and secrets, and record provenance.
• Find unsanctioned AI use: data pasted into personal AI tools is a data security problem. See the Shadow AI Discovery Guide.
• Watch agents as data consumers: the EchoLeak vulnerability showed how a prompt injection could make an assistant leak company data it could read.

Protection, retention and deletion

• Encryption and keys: encrypt sensitive data at rest and in transit (CIS 3.10, 3.11; CSF PR.DS-01 and PR.DS-02) and manage keys separately from the data. The security value sits in key custody and access to decrypt, not in the algorithm. See the Cryptographic Key Management Guide.
• Masking and tokenisation: use them for non-production copies and analytics so most consumers never see raw values (ISO/IEC 27001:2022 A.8.11 Data masking).
• Data loss prevention: apply DLP to the channels where labelled data leaves (ISO A.8.12, CIS 3.13), driven by the same classification scheme.
• Retention: set retention per data class and enforce it with lifecycle rules (CIS 3.4). GDPR Art. 5(1)(e) storage limitation makes over-retention of personal data a compliance issue as well as a breach multiplier.
• Deletion and sanitisation: delete data at end of retention, including copies, exports and snapshots (ISO A.8.10, CIS 3.5). NIST SP 800-88 Rev. 2 defines sanitisation as a process that "renders access to target data on the media infeasible for a given level of effort"; cryptographic erase is the practical option for cloud and encrypted storage.
• Backups: CSF PR.DS-11 requires backups to be "created, protected, maintained, and tested". Backups are full copies of sensitive data and need the same access control and encryption.

Rolling out the programme

1. Days 1 to 30, baseline: agree the classification scheme and owners for the top 20 data stores; enable data access logging on them; run built-in exposure reports (public storage, external access analysers, organisation-wide sharing, open file shares).
2. Days 31 to 60, quick wins: close public and anonymous exposure on confidential and restricted data, with owner sign-off and a record of each change so it can be reverted; start DSPM or native discovery in read-only mode on one cloud and one SaaS platform.
3. Days 61 to 90, access: remove organisation-wide permissions from sensitive sites and shares, scope pipeline and BI identities, and run the first data access review on restricted stores.
4. Next, expand and automate: extend discovery coverage, connect findings to ticketing with owner routing, enable automated remediation only for low-risk fixes after a pilot, and add DDR detections.
5. Roll back safely: for every permission change keep the previous ACL or policy; when a business process breaks, restore that single grant with an expiry and fix it properly.

Small organisations: rely on native tools (cloud provider discovery, SaaS sharing reports, built-in labels) and focus on exposure and MFA; a separate DSPM platform is hard to justify with only a few cloud accounts and SaaS platforms. Large organisations: multi-cloud, many SaaS tenants and on-premises data justify DSPM for a single inventory, but budget at least as much effort for owner-driven remediation as for the tool.

Measuring the programme

• Discovery coverage: percentage of known data stores scanned and classified in the last 90 days.
• Critical exposure: count of restricted or confidential stores that are public, anonymously linked or shared organisation-wide, and median days to close.
• Over-permissioned access: identities with read access to restricted data that have not used it in 90 days, split by human and non-human.
• Owner coverage: percentage of sensitive stores with a named, current owner.
• Retention compliance: volume of data past its retention date, including snapshots and exports.
• Logging coverage: percentage of restricted stores with data access logging feeding the SIEM.

Framework mapping

Common failure patterns

• Buying DSPM before owners exist: the platform produces thousands of findings and nobody has authority to change access on the data.
• Classifying everything as confidential: a scheme where most data is top level gives DLP, access reviews and DSPM no way to prioritise.
• Ignoring non-production: production data copied to development and analytics accounts without masking, where controls and monitoring are weakest.
• Reviewing applications, not data: access reviews certify application roles while service accounts and BI connectors keep read-all access to the warehouse underneath.
• Turning on AI over existing oversharing: an assistant makes years of "Everyone" permissions searchable on day one.
• Keeping data forever: snapshots and exports from closed projects outlive retention schedules and enlarge every breach.

Practitioner checklist

• Publish a four-level classification scheme and name an owner for every sensitive data store.
• Run exposure reports for public storage, external sharing, organisation-wide permissions and open file shares, and close critical findings.
• Inventory non-human identities with read access to sensitive data and scope or remove them.
• Treat DSPM and backup scanner roles as tier-zero credentials.
• Enable data access logging on restricted stores and send it to the SIEM.
• Mask or tokenise personal data in non-production and analytics copies.
• Enforce retention with lifecycle rules, including snapshots and exports.
• Remediate oversharing before enabling AI assistants, and enforce permissions at retrieval.
• Run a data access review on restricted stores at least twice a year.

Standards and references

• NIST: SP 1800-28, Data Confidentiality: Identifying and Protecting Assets Against Data Breaches
• NIST: SP 1800-29, Data Confidentiality: Detect, Respond to, and Recover from Data Breaches
• NIST CSF 2.0 (csf.tools rendering): PR.DS Data Security
• CIS: Control 3, Data Protection
• NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
• OWASP: LLM02:2025 Sensitive Information Disclosure
• Microsoft Learn: About Data Security Posture Management
• Microsoft Learn: Data access governance reports

Related NHI Mgmt Group resources: Data Mapping and ROPA Guide · Cryptographic Key Management Guide · Privacy-Enhancing Technologies Guide · Shadow AI Discovery Guide · Access Reviews Guide