Buying a data security posture management (DSPM) tool is the easy part; the hard part is turning thousands of sensitive data findings into fixed exposures without drowning the data owners. DSPM discovers where sensitive data lives across cloud storage, databases, SaaS and AI services, who and what can reach it, and whether it is protected. This template is the operating playbook that sits behind the tool: when a finding becomes an incident, who acts, how exposure is contained and fixed, and how the programme is rolled out and tuned. It is written for data security, cloud security and privacy teams, and it is vendor-neutral, using Microsoft Purview, Amazon Macie and Google Cloud Sensitive Data Protection only to illustrate documented capabilities. For selecting a product, see the DSPM Buyer's Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [Data Security Lead] and [SIEM], with your own names, systems and thresholds.
- "Must" is mandatory; "should" is recommended practice where a documented exception is acceptable.
- Sections 1 to 8 are the response workflow for a DSPM finding that indicates real exposure. The final section, Implementation guidance, covers rollout, tuning and metrics.
- Keep this playbook alongside the [Organisation] incident response plan. Confirmed exposure of personal data moves into that plan and the notification process in section 7.
- Review the playbook every [6] months and after every significant exposure.
1. Scope and triggers
1.1 This playbook covers sensitive data held in [cloud object storage, managed databases, data warehouses, SaaS collaboration platforms, AI and machine learning data stores] that are connected to [DSPM tool].
1.2 Sensitive data is defined by the [Organisation] data classification scheme. See the Data Classification Policy Template.
1.3 The playbook must be triggered when any of the following is detected:
| Trigger | Example DSPM signal | Default severity |
|---|---|---|
| Public exposure of sensitive data | Bucket, container or share readable by anonymous users or "anyone with the link" and containing [Confidential] data | Critical |
| Overshared internal data | Sensitive files shared with all employees, large groups or external guests | High |
| Shadow or unmanaged copy | Production personal data found in a test, analytics or backup location with no owner | High |
| Excessive machine access | Service account, role or AI agent able to read sensitive data it does not need | High |
| Missing protection | Sensitive store without encryption, label, logging or retention | Medium |
| Secrets in data | Credentials or keys detected in files or environment variables | High; also run the leaked credential process |
| Sensitivity change | A store's sensitivity rating rises after new data arrives | Medium |
1.4 Findings that do not meet a trigger are handled as posture backlog under the Implementation guidance section, not as incidents.
2. Roles and contacts
| Role | Responsibility | Name and contact |
|---|---|---|
| [Data Security Lead] | Owns the playbook, the DSPM tool and its tuning; declares severity | [Name, phone] |
| DSPM analyst (on rotation) | Triage of findings within the service level in section 3 | [Queue or rota] |
| Data owner | Business decision on whether the data should exist there and who should access it | From the data inventory |
| Platform owner | Executes containment on the storage, database or SaaS platform | [Cloud platform team, M365 team] |
| Identity team | Removes excessive human, service account and agent access | [IAM team] |
| Incident manager | Takes over where exposure is confirmed or data access by a third party is suspected | [SOC or IR lead] |
| Privacy officer or DPO | Assesses notification duties for personal data | [Name] |
| Legal | Contractual and regulatory obligations | [Name] |
2.1 Every connected data store must have a named data owner. A store without an owner must be escalated to the [Data Security Lead], and its default treatment is restriction, not deletion.
3. Detection and triage
3.1 DSPM findings must flow to [ticketing system] and Critical and High findings to [SIEM]. Examples of documented integrations: Google Cloud Sensitive Data Protection can publish data profiles to Security Command Center and send Pub/Sub notifications when a profile's sensitivity level changes; Amazon Macie produces sensitive data findings for individual S3 objects; Microsoft Purview DSPM consolidates signals from DLP, Insider Risk Management and sensitivity labels.
3.2 Triage service levels: Critical [1 hour], High [1 business day], Medium [10 business days].
3.3 The analyst must answer, and record in the ticket:
- Is the classification correct? Open a sample through the tool's evidence view. Note that sampling-based discovery (for example Macie automated sensitive data discovery) selects representative objects, so a negative result is not proof that a store is clean; run a full discovery job where the decision depends on it.
- Who and what can reach it? Public access settings, sharing links, group membership, and machine identities: roles, service accounts, access keys, OAuth apps and AI agents.
- Has it been accessed? Check data access logs (for example S3 server access or CloudTrail data events, Microsoft 365 audit, BigQuery audit logs) for anonymous or unexpected principals. Look for T1619 Cloud Storage Object Discovery and T1530 Data from Cloud Storage patterns.
- Who owns it and why does it exist? Confirm with the data owner.
3.4 If logs show access by an unknown or external party, the analyst must hand over to the incident manager immediately and preserve logs before any change.
4. Containment
4.1 Containment removes the exposure while keeping the data, so evidence and business use are preserved.
- Public storage: enable the platform's public access block, remove anonymous ACLs or policies, revoke shared access signatures or signed URLs. See the Cloud Storage Exposure Playbook.
- SaaS oversharing: remove "anyone" and organisation-wide links, remove external guests, restrict the site or folder. Microsoft Purview DSPM documents remediation such as removing public sharing links and revoking permissions from its data risk assessments.
- Machine access: detach the policy or role, disable the access key or OAuth grant, or scope the agent's permission. Do not delete identities until dependencies are known. See the Service Account Security Guide.
- Secrets found in data: revoke and rotate first. See the Leaked Credential Response Playbook.
4.2 Containment actions must be recorded with time, actor and before-and-after configuration. Where an automated remediation policy exists, it must log the same.
5. Eradication
5.1 With the data owner, decide one outcome for each store: keep and protect, move to an approved location, minimise (mask, tokenise or delete fields), or delete in line with the Data Retention and Disposal Policy Template.
5.2 Fix the cause, not only the instance: the pipeline that copied production data to test, the template that creates public buckets, the default sharing setting, or the role that grants wildcard read.
5.3 Where a misconfiguration came from infrastructure as code, the fix must be made in code and enforced by a policy check, or it will return.
6. Recovery
6.1 Confirm business processes still work after access changes, with the data owner signing off.
6.2 Re-scan the store. In Google Cloud Sensitive Data Protection, deleting or forcing a reprofile triggers profiling again; in Macie, run a targeted discovery job; in other tools use the equivalent rescan.
6.3 Apply missing protections: encryption, sensitivity labels, logging of data access and retention rules.
6.4 Close the ticket only when the DSPM finding has cleared on rescan.
7. Communication and notification
7.1 Critical findings must be reported to the [CISO] and data owner on the same day.
7.2 Where personal data may have been accessed by an unauthorised party, the privacy officer must assess notification duties without delay. Under GDPR Article 33, a personal data breach must be notified to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to individuals. Other jurisdictions differ. See the Data Breach Notification Checklist and the Breach Notification Laws by Country Guide.
7.3 Exposure without evidence of access is still recorded in the breach register with the reasoning for the decision.
7.4 Customer or partner data exposures follow contractual notice terms recorded in [contract register].
8. Post-incident review
8.1 Every Critical finding, and any High finding with confirmed access, must have a review within [10] business days.
8.2 The review records: how long the exposure existed, how it was found (DSPM, external report or attacker), root cause, which control should have prevented it, and the preventive change. The Microsoft Azure Storage exposure of 2024 is a useful reference case: an Azure storage server open to the internet without password protection held code and configuration files containing internal credentials.
8.3 Feed recurring causes into DSPM policy, preventive guardrails and the data owner training plan.
Implementation guidance
Phased rollout
- Define what "sensitive" means first. Map classification levels to detectors: managed identifiers (for example Macie managed data identifiers or Sensitive Data Protection infoTypes), custom identifiers for internal formats such as customer or employee IDs, and allow lists for known test values.
- Connect read-only, in discovery mode. Start with the highest-risk estate, usually public cloud object storage and the main collaboration platform. Use dedicated, read-only scanning identities and record them in the NHI inventory; a DSPM scanner that can read everything is itself a sensitive identity.
- Baseline and assign owners. Expect a large first result set. Assign owners to stores before raising tickets, using tags, account ownership and the data map. See the Data Mapping and ROPA Guide.
- Tune. Exclude log buckets and known non-sensitive stores (Macie lets administrators exclude specific buckets, such as those storing AWS logging data), add allow lists, and validate detector accuracy on samples. Track false positive rate per detector.
- Turn on triggers in section 1. Route Critical and High to the SIEM and ticketing; leave Medium as backlog.
- Automate carefully. Enable automated remediation (for example removing public links) only for findings with a low false positive rate and with data owner agreement, and log every automated change.
- Extend coverage to databases, warehouses, SaaS and AI data stores. Purview DSPM, for example, lists coverage of Microsoft 365, Azure and Fabric, with Google Cloud, Snowflake and Databricks and partner integrations for other locations.
Choosing the operating model
| Situation | Recommended approach |
|---|---|
| Small organisation, one cloud and one SaaS suite | Native tools (cloud provider discovery, collaboration suite DSPM) and a weekly review; one analyst part-time |
| Multi-cloud with many data stores | Central DSPM, owners assigned per account or subscription, findings routed to platform teams' queues |
| Heavy AI and analytics use | Include training data, vector stores and agent access paths in scope; review machine identity access monthly |
| Regulated personal data | Link DSPM inventory to the ROPA and breach register; privacy officer reviews Critical findings |
Metrics
- Percentage of data stores in scope that are connected and scanned.
- Percentage of sensitive stores with a named owner.
- Mean time to contain Critical findings (target: within [24] hours).
- Number of publicly exposed sensitive stores (target: zero), trended monthly.
- Number of machine identities with read access to [Restricted] data, trended down.
- False positive rate per detector after tuning.
Framework alignment
| Playbook element | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Discovery and data inventory | ID.AM-07 | CM-12, PM-5(1) |
| Exposure risk scoring | ID.RA | RA-3 |
| Access remediation | PR.AA-05 | AC-3, AC-6, AC-21 |
| Protection of stored data | PR.DS-01 | SC-28 |
| Containment of confirmed exposure | RS.MI-01 | IR-4 |
| Retention and minimisation | ID.AM-08 | SI-12 |
For the related controls in the NCCoE data confidentiality practice guide, see NIST SP 1800-28. Related NHI Mgmt Group pages: the Data Loss Prevention (DLP) Guide and the Data Classification Guide.
Standards and references
- Microsoft: Learn about Data Security Posture Management
- AWS: Amazon Macie automated sensitive data discovery
- Google Cloud: Sensitive Data Protection data profiles
- NIST NCCoE: Data Confidentiality, SP 1800-28
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: DSPM Buyer's Guide · Cloud Storage Exposure Playbook · Data Classification Policy Template · Incident Response Plan Template