Privacy management platforms are usually bought to replace spreadsheets for records of processing, subject requests and assessments, then underdeliver because the data map is still populated by questionnaire and every request still ends in a manual search. The category spans data mapping and records of processing activities (RoPA), data subject request (DSAR) workflow, DPIA and privacy impact assessments, vendor and processor management, breach management, consent and cookie modules, and regulatory content. Suites and point products overlap heavily, so the module list tells you little; the data model, the connectors and the quality of the workflow decide the fit. This vendor-neutral buyer's guide is for DPOs, privacy operations, legal and security teams writing requirements, running an RFP or consolidating tools. It covers what to define first, the criteria to score, questions that expose weak answers, red flags and a proof of concept on your own data.
Key takeaways
- Buy the data model, not the module list. The RoPA, DSAR, assessment, vendor and breach modules should share one inventory of systems, data categories, purposes and processors, or you will maintain five inconsistent registers.
- Automated discovery beats questionnaires, within limits. Connectors find personal data in systems people forget, but each one is a privileged non-human identity with read access to your most sensitive stores.
- DSAR identity verification is a security control. Weak checks send one person's data to an impostor; heavy checks breach proportionality. The EDPB says a copy of an identity document "should generally not be considered an appropriate way of authentication".
- Deadlines must be computed, not remembered. The platform should track the one-month DSAR clock, pauses for clarification, extensions and the 72-hour breach notification window per jurisdiction.
- The platform is a sensitive data store itself. It holds identity documents, request responses, breach details and your full processing map, so score its own security, residency and exit terms as hard as its features.
Define requirements
Agree scope internally before vendor demos and write it into the RFP. The Global Privacy Regulatory Map helps list the laws in play.
- Jurisdictions and obligations: which laws apply (for example UK GDPR, EU GDPR, CCPA and other US state laws) and which outputs each requires: RoPA, DSAR responses, DPIAs, breach notifications, and from 2026 California risk assessments. Greenberg Traurig reports that the revised CCPA regulations took effect on 1 January 2026, with risk assessments for ongoing activities due by 31 December 2027 and the first summary submission by 1 April 2028.
- Volumes: DSARs per month by type (access, deletion, correction, opt-out), assessments per year, processors in scope, and legal entities.
- Systems to integrate: identity provider, HR, CRM, customer databases, data warehouses, file stores, ticketing, the security incident platform, and procurement for new vendors.
- Users: privacy team, system owners who answer assessments, legal reviewers, and external requesters through a portal.
- Data constraints: where the platform may store request contents, identity evidence and breach records, and retention for each.
Size changes the answer. A mid-sized organisation with a few hundred DSARs a year often needs a good intake portal, workflow, templates and a maintained RoPA more than deep discovery. A consumer business with high request volumes and many data stores needs automated discovery, connectors that execute search and deletion, deduplication and redaction. A group with many entities needs multi-entity hierarchies, delegated administration and reporting by entity.
| Module | Obligation it supports | NIST Privacy Framework 1.0 | What to check |
|---|---|---|---|
| Data mapping and RoPA | GDPR Art. 30: purposes, categories of individuals, data and recipients, transfers, retention, security measures | ID.IM-P (Inventory and Mapping) | Art. 30 fields for controller and processor records; export on request. See the Data Mapping and ROPA Guide |
| DSAR workflow | GDPR Arts. 12, 15 to 22; UK one-month limit with "reasonable and proportionate" searches; CCPA requests to know, delete and correct | CT.DM-P (Data Processing Management) | Clock rules, pause and extension logic, redaction, secure delivery. See the DSAR Guide: Handling Data Subject Requests |
| DPIA and PIA | GDPR Art. 35 high-risk processing, assessed "prior to the processing"; Art. 36 prior consultation | ID.RA-P (Risk Assessment) | Screening, editable templates, ICO high-risk list, residual risk sign-off. See the DPIA Guide: Running a Data Protection Impact Assessment |
| Vendor and processor management | GDPR Art. 28 contracts; sub-processor changes; transfer safeguards | ID.DE-P (Data Processing Ecosystem Risk Management) | Processor records link to RoPA entries and contracts |
| Breach management | GDPR Art. 33 notification within 72 hours where a risk is likely; Art. 34 high-risk communication; record all breaches | Communicate-P function | Risk assessment logic, jurisdiction clocks, decision record when not notifying |
| Consent and cookies | ePrivacy Art. 5(3), PECR reg. 6, CCPA opt-out signals | Control-P function | See the Consent Management Guide: Cookies, CMPs and GPC |
This table maps regulatory requirements to platform features and is not legal advice; confirm obligations for your jurisdictions with counsel.
Evaluation criteria
An illustrative weighting for a consumer business is 25% DSAR and identity verification, 20% discovery and mapping, 15% assessments, 10% vendors, 10% breach, 20% integrations and platform security. Adjust it to your volumes rather than copying it.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Data discovery and mapping | Connectors for your warehouses, databases, file stores and SaaS; classification you can tune; findings feed the inventory with owner and confidence; scheduled rescans | Discovery sold separately and not linked to the RoPA; sampling hidden from you |
| RoPA | Art. 30 fields for controller and processor records, versioned, built from the shared inventory, exportable | Free-text records with no link to systems or vendors |
| DSAR workflow | Intake portal and channels, deduplication, clock with pause and extension rules, tasks to system owners, automated search and deletion through connectors, redaction, secure delivery | Ticketing with a privacy label; deadlines tracked manually |
| Identity verification | Reuses existing login where the requester has an account, proportionate step-up for others, configurable per request type, evidence deleted after closure | Default demand for passport copies; verification evidence kept indefinitely |
| Assessments | Screening questions that trigger DPIAs, editable templates, risk scoring, mitigations tracked to closure, reuse of inventory data | Static questionnaires; no link from risk to processing activity |
| Vendor and processor management | Processor inventory, Art. 28 contract tracking, sub-processor change notices, transfer mechanism records, links to procurement | A separate vendor list that never reaches the RoPA |
| Breach management | Intake from the incident process, risk assessment, jurisdiction-specific deadlines, notification drafts, decision log for unreported breaches | A form with no deadline logic |
| Regulatory content | Maintained law summaries and template updates with change notices, sources cited, and a dated record of what changed | Content with no dates or sources; updates that silently overwrite your templates |
| Reporting | DSAR volumes and timeliness, assessment backlog, RoPA coverage, vendor risk; API and export for all data | Static PDF reports only |
| Platform security and residency | SSO with enforced MFA, granular roles, customer-visible audit log, named regions and sub-processors, encryption, current independent assurance such as ISO/IEC 27001 or ISO/IEC 27701:2025 certification, documented exit | Shared admin accounts; vague sub-processor answers; no data deletion commitment |
Identity verification is where privacy meets identity security
A DSAR portal is an account recovery channel by another name: anyone who passes verification receives a complete copy of someone's data. The EDPB's Guidelines 01/2022 on the right of access allow extra checks only with "reasonable grounds for doubting the identity", say a login and password "should be sufficient" for account holders, and call it "disproportionate to require a copy of an identity document" from someone already authenticated. The ICO likewise says "You should only request formal identification if necessary." California sets explicit tiers for non-account holders: matching two data points for categories of information, and three plus "a signed declaration under penalty of perjury" for specific pieces. Ask how the platform reuses your identity provider sessions, how it handles authorised agents, and whether verification is logged without retaining documents. See the Identity Verification Buyer's Guide.
Discovery connectors are privileged non-human identities
To scan and delete data, the platform holds service accounts, API keys and OAuth tokens for your warehouses, databases and SaaS applications, often with read access to everything and sometimes with delete rights. The Snowflake breach showed what stolen credentials to data warehouses without MFA can reach. Map connector risk to the OWASP Non-Human Identities Top 10, particularly NHI5:2025 Overprivileged NHI, NHI7:2025 Long-Lived Secrets and NHI3:2025 Vulnerable Third-Party NHI. Require read-only scanning identities separate from deletion identities, short-lived or federated credentials, network restrictions, a named owner per connector and an exportable connector inventory. See the NHI Security Platform Buyer's Guide.
Questions to ask vendors
- Show a DSAR from intake to delivery using our test systems, including clock pauses, an extension, redaction and secure delivery.
- Which connectors execute search and deletion natively, and which only create a task for a human?
- For each connector, what permissions are requested, can scanning and deletion use separate identities, and do you support federated or short-lived credentials?
- How does discovery sample or scan data, where are findings and data snippets stored, and for how long?
- How do RoPA entries, DPIAs, vendors and breaches share one inventory, and what happens when a system is retired?
- How do you verify requesters with and without an account, and what identity evidence do you retain after closure?
- How are regulatory content updates sourced, dated and delivered, and can we hold a template version during an audit?
- Which regions and sub-processors handle our data, and what independent assurance covers your platform today?
- What does pricing count (requests, connectors, data volume, entities or modules), and what happens to cost when request volumes spike?
- At contract end, what do we receive, in which formats, and when is our data deleted?
Red flags
- "Automated" DSAR fulfilment that turns out to be email tasks to system owners.
- Connectors that need administrator or owner rights or only accept long-lived API keys.
- Default identity checks that collect passport or driving licence copies for every request.
- Separate inventories per module that cannot be reconciled.
- Regulatory content with no sources, dates or change history.
- No customer-visible audit log for who viewed or exported request data.
- Pricing per request or connector that discourages automating the systems that matter.
Proof of concept
- Scope it: choose one legal entity, two jurisdictions, five systems (identity provider, CRM, a customer database, a warehouse and a file store) and ten processors. Agree pass criteria and weights before the first demo.
- Connect with least privilege: create dedicated read-only scanning identities with named owners and expiry, and a separate deletion identity for one test system only. Record every permission requested.
- Seed test data: plant synthetic personal data for ten test subjects across the five systems, including one in an unexpected location.
- Run discovery and build the RoPA: measure what was found, false positives, and how long it takes to produce Art. 30 records for two processing activities.
- Run requests end to end: access, deletion and correction requests for test subjects, one from an account holder and one from a non-account holder, with a clarification pause. Check the clock, verification, redaction and deletion results in the source systems.
- Exercise assessments and breach: run one DPIA from screening to sign-off and one simulated breach to a notify or not-notify decision within the 72-hour window.
- Test the exit and roll back: export everything, revoke every connector credential, confirm the connectors stop working, and request written confirmation of deletion.
Track after go-live: DSAR on-time completion rate, median days to close, percentage of systems with automated search, RoPA records reviewed in the last 12 months, DPIA backlog age, and connectors with an owner and credentials rotated on schedule.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Privacy Programme Guide for Security Teams · GDPR Compliance Guide for Security Teams · Data Classification Guide · Service Account Security Guide