A data security posture management (DSPM) platform is granted read access to your most sensitive data stores so it can find and classify that data, which makes its connectors one of the broadest data access paths in your estate. To classify data, most DSPM tools read content, not just metadata: they connect to cloud accounts, databases, file shares and SaaS applications, run scanners, and keep findings, data samples and an access map in their console. Some can also remediate, changing permissions or labels on your behalf. This guide is for data security, cloud security and platform teams that run or are buying a DSPM platform. It covers admin roles, connector identities, scanner placement, the sensitive data the platform keeps, remediation guardrails, logging and lifecycle. It is vendor-neutral: confirm setting names in your vendor's documentation. For what DSPM does and how to choose a deployment model, see the Data Security Posture Management (DSPM) guide.
Key takeaways
- The connectors are the risk. A DSPM read role across every data store is a ready-made exfiltration path; scope it, protect its credentials and watch how it is used.
- Know where content is processed. Decide whether scanning runs inside your accounts or the vendor's, and whether data samples leave your environment.
- The console is now a sensitive data store. Findings, samples and access maps describe where your crown jewels are and who can reach them; restrict and log access to them.
- Separate read from remediate. Write permissions for automated remediation belong to a different identity with narrow scope and approval steps.
- Offboarding must remove every role. Leaving a DSPM product means deleting cross-account roles, application consents and database accounts in every connected system.
What makes up the platform's attack surface
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Management console | Findings, classification results, data samples, access maps, connectors, users | A map of sensitive data and the identities that reach it, plus sample values | SSO with phishing-resistant MFA, least-privilege roles, audit log export |
| Cloud account connectors | Cross-account roles with read access to storage, databases and configuration | Bulk reading of data stores through a trusted role | Scoped roles, trust limited to the vendor's documented principal and a unique external identifier |
| Scanners | Compute that reads data content, in your account or the vendor's | Data copied or snapshots shared outside your control | In-account scanning where possible, isolated network, no persistent copies |
| Database and file share credentials | Accounts that read tables and shares | Direct database access with broad read rights | Dedicated read-only accounts, managed credentials, network restriction |
| SaaS connectors | OAuth consents to read files, messages and records | Tenant-wide read of documents and mail | Minimum scopes, admin-approved consent, conditional access on the app |
| Remediation identity | Change permissions, labels or sharing settings | Opens data to the public or removes protections | Separate identity, narrow write scope, human approval |
| Integrations (SIEM, ticketing, DLP, data catalogue) | Tokens and webhooks; export of findings | Findings and samples sent to the wrong place | Per-integration credentials; no samples in tickets |
Admin roles and console access
- Separate duties: define platform administrator (users, connectors, integrations), data security analyst (findings and triage), data owner (findings for their own stores), remediation approver and auditor. Connector management is as sensitive as administrator rights, because a new connector extends the platform's reach.
- Sample viewing is a separate right: many platforms can show a snippet of the sensitive value that triggered a classification. Restrict who can see unmasked samples, log every view, and turn sample storage off where you do not need it.
- Authentication: enforce SSO and phishing-resistant MFA, keep one documented break-glass account, and raise SSO and MFA at procurement. The CISA and FBI Secure by Demand guide suggests buyers ask whether SSO comes at no additional cost and whether MFA is enabled by default. See the Break-Glass Account Guide.
- Admin devices: administer from managed devices. See the Privileged Access Workstations Guide.
- Review: review roles, connector owners and sample viewers every quarter (our recommendation).
Connector identities and credentials
NSA's Top Ten Cloud Security Mitigation Strategies (March 2024, several issued jointly with CISA) open with upholding the shared responsibility model and using secure cloud identity and access management practices. The NCSC's shared responsibility guidance applies the same thinking to managed service providers with privileged access: apply least privilege, avoid high-level roles such as global administrator, and keep the ability to audit their actions. In NHI Mgmt Group's view, a DSPM vendor's connector deserves the same treatment.
| Connector | Needs | Avoid | Pattern |
|---|---|---|---|
| Cloud account read role | List data stores, read configuration, read content for classification | Administrator or broad write policies; permission to decrypt with every key | Cross-account role assumed by the vendor's documented principal with a unique external identifier; content read limited to in-scope stores |
| Scanner workload identity | Read data from in-scope stores and write results | Long-lived access keys on scanner hosts | Workload identity or instance role, no static keys |
| Database accounts | Read schema and sample rows | Database owner or administrator rights | Dedicated read-only account per database, managed password or certificate, network allowlist |
| SaaS application consent | Read files or records for classification | Mail send, write or tenant administration scopes | Admin-approved consent with the smallest scope; app restricted by conditional access where supported |
| Remediation identity | Change permissions or labels on defined stores | Being the same identity as the read connector | Separate role, narrow scope, actions require approval |
- Prefer federation: use cross-account role assumption and workload identity federation over static keys. See the Workload Identity Federation Guide.
- Static credentials: where a connector needs a password or key, store it in a secrets manager, give it an owner and expiry, and rotate it (our recommendation: at least every 90 days). See the Service Account Security Guide.
- Encryption keys: to read encrypted data, the connector may need permission to use your keys. Grant use of specific keys for in-scope stores only and log every use. See the Cryptographic Key Management Guide.
- Treat DSPM roles as a finding category: include the DSPM's own roles in your regular cloud access review. See the Cloud IAM Review Checklist.
Where scanning happens and what the platform keeps
- Scanner placement: in-account scanning keeps content inside your environment and sends only metadata and results out. Vendor-side scanning may copy snapshots or data out of your account. Ask exactly what leaves, where it is processed, and how long it persists.
- Data samples: decide whether the console stores sample values at all. If it must, require masking by default and set a short retention.
- Residency and support access: confirm regions for findings and samples, and who at the vendor can access your tenant and under what approval.
- Encryption: ask whether you can supply your own key for data the platform stores, and how key revocation affects it.
- Classify the console: treat findings and access maps at the highest classification of the data they describe.
The DSPM RFP Template includes platform security requirements you can reuse for these questions.
Remediation guardrails
- Start read only: run the platform without write permissions until findings are tuned.
- Approve before change: require a named approver for permission or sharing changes, at least on production and regulated stores.
- Limit blast radius: cap the number of objects changed per run and per hour (our recommendation) and exclude break-glass and platform identities from automated change.
- Record and reverse: log the previous state of every change so it can be rolled back.
Logging and monitoring
- Two sides of logging: export the console audit log (sign-ins, role changes, new connectors, sample views, exports, remediation actions) to your SIEM, and monitor the connector identities in your own cloud and SaaS logs. The second view is the one an attacker inside the vendor cannot alter.
- Baseline connector behaviour: alert when a DSPM role reads from stores outside its scope, from unexpected source addresses or regions, or at unusual volume.
- Alert on reach changes: new connectors, new data stores added to scope, and new remediation permissions.
See the Cloud Logging and Audit Trail Guide.
Lifecycle and decommissioning
- Onboard: record every connector, its identity, scope, owner and approval in an inventory before the first scan.
- Change: treat scope extensions and new remediation rights as changes needing approval.
- Offboard a data store: remove it from scope and confirm the connector can no longer read it.
- Leave the product: delete cross-account roles, revoke SaaS consents, drop database accounts and key grants, export audit logs you must keep, and obtain written confirmation that findings and samples are deleted.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Console roles and sample access | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Connector identities and keys | IA-5, SC-12 | PR.AA-01 | T1098.001 Additional Cloud Credentials, T1530 Data from Cloud Storage |
| Data held by the platform | SC-28, SC-8 | PR.DS-01 | T1530 Data from Cloud Storage |
| Audit log protection | AU-6, AU-9, AC-6(9) | PR.PS-04 | T1685 Disable or Modify Tools |
| Vendor access | SA-9, SR-3 | GV.SC-07 | T1199 Trusted Relationship |
Common failure patterns
- Read everything, decrypt everything: the connector was granted organisation-wide read and key use during a proof of concept and never narrowed.
- Samples in the console: unmasked card numbers and personal data sit in findings visible to every analyst.
- One identity for read and fix: a stolen connector credential can also change sharing settings.
- Orphaned roles: a trial ended, but cross-account roles and SaaS consents remain.
- Watching only the console: nobody monitors what the DSPM roles do in the cloud audit logs.
Practitioner checklist
- Enforce SSO with phishing-resistant MFA and keep one tested break-glass account.
- Separate administrator, analyst, data owner, remediation approver and auditor roles; restrict sample viewing.
- Scope cloud read roles to in-scope stores, with a documented trust principal and unique external identifier.
- Use workload identity for scanners and dedicated read-only database accounts.
- Grant SaaS consents with minimum scopes and admin approval.
- Decide where scanning runs and whether samples are stored; mask and limit retention.
- Keep remediation on a separate identity with approval and change caps.
- Monitor connector identities in your own logs as well as the console audit log.
- Maintain a connector inventory and a tested offboarding checklist.
Standards and references
- NSA: Top Ten Cloud Security Mitigation Strategies
- NCSC: Shared responsibility model
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NCSC: Secure system administration
- CISA and FBI: Secure by Demand Guide
- OWASP: Logging Cheat Sheet
Related NHI Mgmt Group resources: Data Security Posture Management (DSPM) · DSPM Buyer's Guide · DSPM Implementation Playbook · Cloud IAM Review Checklist