DSPM Platform Compromise Playbook

A compromised data security posture management (DSPM) platform gives the attacker read access to your data stores, a map of exactly where your most sensitive data lives, and in many deployments stored samples of that data. DSPM platforms connect to cloud accounts, databases, data warehouses and SaaS applications so they can discover and classify data, which means they hold cloud roles, database credentials and OAuth grants across the estate. The incident can start with a stolen admin login, a leaked API token, a compromised scanner you host in your own account, or a breach at the vendor that exposes connector credentials for every customer. This playbook covers containment from the data store side, deciding whether data was taken, rotating every connector credential, and rebuilding the platform with narrower trust. It is vendor-neutral and written for data security, cloud security and incident response teams. Hardening before an incident is covered in Securing the DSPM platform itself.

Key takeaways

Treat this as a possible data breach from the start. The platform can read sensitive data by design, so assume collection until logs show otherwise, and start the notification clock analysis early.
Cut access at the data stores. Disabling the platform's roles, database users and OAuth grants stops data access even if the console is still in hostile hands.
The classification inventory is a target list. Use it the way the attacker would: the stores it ranks as most sensitive are where you look for access first.
Stored samples and snapshots are data too. Classification snippets, match previews and scan snapshots may sit in the platform or in a scanning account, and must be found and deleted.
Reconnect read only, scoped and federated. Bring connectors back one store at a time with new credentials, no remediation rights and the minimum scope.

What the platform can reach

This is NHI Mgmt Group's view of common DSPM components and what each gives an attacker. Not every product has every component; check your own architecture before an incident.

Component	What an attacker gains	First containment action
Cloud account connector roles (discovery and read)	Read access to object storage, managed databases and snapshots across accounts (T1530 Data from Cloud Storage)	Deny or detach the roles; revoke active sessions
Database and data warehouse credentials	Direct queries against production data	Disable the platform's database users or rotate their passwords and keys
SaaS OAuth grants and API tokens (file sharing, collaboration, CRM)	Documents, messages and records in SaaS tenants (T1528 Steal Application Access Token)	Revoke the grants and tokens in each SaaS admin console
Snapshot or scanner workloads in your account	Copies of disks and databases, and compute inside your network	Stop the workloads; check snapshot copies and sharing
Classification samples, previews and inventory	Sensitive data extracts and a ranked map of where the rest is	Establish where they are stored and who could read them
Remediation actions (change permissions, revoke sharing, apply labels)	Ability to open data up, or to remove protections, under a trusted name	Remove write roles and disable automated remediation
Admin console, SSO and API tokens	Control of all of the above	Disable accounts, revoke tokens, reset SSO trust

How the compromise shows up

Connector identities active outside the scan pattern: the platform's role assumed from an unexpected source, region or time, seen in AWS CloudTrail AssumeRole events, Microsoft Entra service principal sign-in logs or Google Cloud audit logs.
Bulk object reads or full table queries: object-level data events, or database audit logs showing full reads where the platform normally samples.
Snapshots created, copied or shared outside the scanning account: in AWS, CreateSnapshot and ModifySnapshotAttribute events, and SharedSnapshotCopyInitiated or SharedSnapshotVolumeCreated when someone acts on a snapshot you shared.
Permission or sharing changes by the platform: buckets or files made more open, labels removed, or remediation runs nobody approved.
Exports of the inventory or findings: bulk downloads or API reads in the platform's audit log.
New admins, tokens, SSO changes or connectors: persistence inside your tenant of the platform.
A vendor notice: a security advisory asking customers to rotate connector credentials.

Triage: the first hour

Where did it start? Your tenant (admin, token, SSO), a scanner you host, a connector credential, or the vendor's service.
Where does scanning happen? Data processed in your own account limits what left your boundary; data processed in the vendor's environment means samples and snapshots may be held there.
What does the platform store? Confirm whether it keeps classification samples, match previews or full records, and for how long.
Which connectors exist and what can each do? List every cloud account, database, warehouse and SaaS tenant, with the identity used and whether it can write.
Which stores are most sensitive? Export the inventory ranked by data type: regulated personal data, payment data, health data, credentials and secrets.
Is access ongoing? Recent role use or queries from unknown sources mean containment starts now.

Containment by priority

Remove write and remediation rights. Deny or detach any role that can change permissions, sharing or labels, and switch off automated remediation.
Cut active sessions on read roles. In AWS, Revoke active sessions attaches an inline policy named AWSRevokeOlderSessions that denies all actions to sessions whose aws:TokenIssueTime is earlier than the revocation; it does not affect requests signed with long-term IAM user keys, which must be deactivated separately. In Microsoft Entra, Microsoft's playbook for compromised applications recommends disabling the service principal (accountEnabled set to false) first. In Google Cloud, disable the service account or its keys; Google advises disabling keys first and deleting them once you are sure they are not needed.
Break cross-account trust. For AWS cross-account roles, change the trust policy so the vendor's existing sts:ExternalId no longer matches, or deny until a new integration is ready. AWS documents the external ID as unique per customer and controlled by the vendor.
Disable database and warehouse users. Lock the platform's database accounts or rotate their credentials; for warehouses with key pair or token authentication, remove the registered key.
Revoke SaaS grants. Remove the platform's OAuth applications and tokens in each SaaS tenant it scans.
Stop data movement. Stop scanner workloads, list snapshots created by the platform's roles, remove createVolumePermission entries that share them with accounts you do not own, and delete copies after evidence is taken.
Lock the platform tenant. Disable compromised admins, revoke API tokens, remove unknown SSO and connector changes.

Rollback: keep a record of every role, trust policy, database user and grant you changed, with its previous state, so connectors can be restored deliberately.

Credential rotation and trust reset

Credential or trust	Rotation action	Check afterwards
AWS cross-account role external ID	Request a new external ID from the vendor and update the trust condition	The old ID fails; only the vendor's principal can assume the role
AWS IAM user access keys (legacy connectors)	Deactivate, then delete; replace with a cross-account role	No requests signed with the old key
Entra application secrets and certificates	Microsoft's playbook: add a new certificate, then remove every old password and key credential on both the application and service principal objects	No unexpected credential additions in the audit log afterwards
Google Cloud service account keys	Disable, then delete; prefer workload identity federation	Key authentication events stop for the old key IDs
Database and warehouse credentials	New passwords or key pairs, read-only grants limited to the schemas in scope	Old credentials fail; no unknown sessions
SaaS OAuth grants and tokens	Re-consent with the narrowest scopes after review	Old refresh tokens revoked
Secrets the platform could read in data stores	Rotate credentials found in scanned files, tables or disks, starting with production and cloud keys	Secret scanning finds no live old values

Microsoft's playbook orders downstream rotation by exposure: secrets directly retrieved first, then the rest of the exposed vaults, then the rest of the exposed subscriptions. The same order works for data stores: start with stores the logs show were read, then everything else the connector could reach. See the Cloud Credential Compromise Playbook for cloud key response.

Where identity fits

Every DSPM connector is a non-human identity with read access to sensitive data, and many are created once during onboarding and never reviewed. Read access to data is not "low risk" just because it cannot write. During rebuild, give each connector its own identity per account or store, prefer federation and roles over stored keys and passwords, and record an owner for each. See the Workload Identity Federation Guide.

Scoping the data exposure

The legal and customer outcome depends on what was read, so scoping runs alongside containment.

Start from the inventory: for each high-sensitivity store, pull access logs for the platform's identities across the window.
Compare with the scan baseline: volume, object counts, query shapes and source addresses outside the platform's normal pattern indicate collection.
Account for logging gaps: if object-level or query logging was off for a store, you may not be able to rule out access; record that clearly.
Include the platform's own copies: samples and previews held by the platform count as exposed if the attacker had console or vendor-side access.

The Data Security Incident Scoping Playbook covers this step in depth.

Eradication and rebuild

Hunt in connected accounts: new users, keys, role trust changes and service principal credentials created during the window (T1098.001 Additional Cloud Credentials).
Reverse unauthorised data changes: restore bucket policies, sharing links, ACLs and labels the platform changed, using a known good baseline.
Rebuild hosted scanners from clean images in a fresh account or subscription where possible.
Purge stored samples: ask the vendor to delete samples and previews from the window, get written confirmation, and reduce sample retention in the new setup.
Clean the tenant: remove unknown admins, tokens, connectors, policies and exceptions.

Recovery and reconnection

Pilot one low-risk store with a new read-only identity and confirm a full scan cycle matches the vendor's documented access pattern.
Turn sampling down: where the product allows, keep classification metadata but not sample values, or set the shortest retention.
Expand in rings by sensitivity, with the most sensitive stores last.
Add remediation last, for named actions only, with approval for anything that widens access.

Evidence to preserve and notification

Cloud and data store logs: audit logs and data events for every connected store, covering the window, exported before retention expires.
Platform records: audit log, export history, connector changes and the inventory as it stood during the incident.
Snapshots: IDs, sharing attributes and copies, with before and after state.
Vendor communications: notices, case numbers and statements on samples and retention.

Personal data is often in scope here. Under GDPR Article 33 a controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, and Article 34 requires telling individuals where the breach is likely to result in a high risk to them. Sector and national rules may apply too: see the Cyber Incident Reporting Requirements Map. If the vendor was breached, it may be acting as your processor, and your contract's notification clauses apply.

Decision guidance

Situation	Choose	Trade-off
Vendor-side breach, scanning runs in your accounts	Rotate all connector trust and keep scanning on new credentials	Short coverage gap, but relies on the vendor's scope statement
Vendor-side breach, scanning or samples in the vendor's environment	Disconnect, rotate, scope sample exposure, consider notification	Longer outage and legal work
Signs of collection in your stores	Full disconnect and data breach response	Loss of posture visibility; compensate with native cloud data discovery
Remediation rights were active	Audit every change made under the platform's name and reverse it	Time consuming, but opened permissions may persist otherwise
Small estate	Manual rotation per store	Fast, but easy to miss a SaaS grant without a written list
Large estate	Organisation-level deny policies and scripted trust updates	Needs tested automation and a named owner per platform

Detection and measurement

Time to cut data access: from declaration to all connector identities denied or disabled.
Connector inventory accuracy: percentage of connectors with a named owner, identity and documented rotation steps.
Rotation completeness: connector credentials rotated out of those held.
Logging coverage: percentage of high-sensitivity stores with object or query level logging, so access can be ruled in or out.
Stored sample volume: retention days for samples and previews; NHI Mgmt Group recommends the shortest period the product allows.
Baseline alerts: connector identities used from unexpected sources or at unusual volume, tested at least yearly.

Framework mapping

Framework	Reference	Where it applies
NIST CSF 2.0	RS.MA-01, RS.AN-03, RS.MI-01, RS.MI-02, RC.RP-05	Coordinated response, root cause, containment, eradication, verified restoration
NIST SP 800-53 Rev. 5	IR-4, IR-6, AC-2, AC-6, IA-5, SA-9, AU-6, SC-28	Incident handling and reporting, accounts, least privilege, authenticators, external services, log review, data at rest
NIST SP 800-61 Rev. 3	CSF 2.0 Community Profile for incident response	Overall response structure
CIS Controls v8.1	Control 3, Control 5, Control 6, Control 15, Control 17	Data protection, accounts, access, service providers, incident response
ISO/IEC 27001:2022 Annex A	5.19, 5.22, 5.24 to 5.28, 5.34	Supplier security, incident management and evidence, privacy and protection of PII
MITRE ATT&CK	T1199, T1078.004, T1530, T1528, T1098.001	Trusted relationship, cloud accounts, cloud storage collection, token theft, persistence

Common failure patterns

Calling read access low risk. A read-only connector to a customer database is a data breach path in its own right.
Waiting for the vendor before rotating. In the Sisense breach, an analytics vendor's own stores reportedly held customer tokens and credentials; customers who rotate what they gave a vendor without waiting for its full root cause reduce their exposure.
Forgetting the platform's own copies. Samples and previews outlive the connector that produced them.
Missing SaaS grants. Cloud roles get rotated, while OAuth grants to file sharing and CRM tenants stay live.
Reconnecting with the same scope. Restoring organisation-wide read and remediation rights recreates the exposure.
No data-level logs. Without object or query logging, you cannot show what was not read, which can widen notification.

Practitioner checklist

Keep a list of every connector, its identity, scope, owner and rotation steps.
Know where scanning happens and what samples the platform keeps.
Remove remediation rights first, then revoke read sessions and break trust.
Disable database users and revoke SaaS grants alongside cloud roles.
Check snapshot creation, sharing and copies across the window.
Scope data access store by store, most sensitive first.
Rotate every connector credential and secrets found in scanned data.
Get written confirmation of sample deletion from the vendor.
Reconnect read only, in rings by sensitivity, remediation last.
Run the notification analysis early, with legal and the data protection officer.

If your DSPM platform is compromised: containment, credential rotation and rebuild playbook