The privacy tech stack, layer by layer

"Privacy software" covers at least six different kinds of tool, built for different buyers and solving different problems. Knowing which layer a product sits in, and what it needs from the layers around it, is most of what it takes to buy sensibly.

This article goes through the stack from the user-facing edge inward, then looks at how the layers connect and what a small company and a large one actually need. It is vendor-neutral. For the buying process itself, see Choosing privacy software without regretting it and the buyer's checklist.

The layers at a glance

Consent and preference management

This is the layer users see: the cookie banner, the preference center, the "Do not sell or share" link, the email unsubscribe. A consent management platform (CMP) blocks or allows scripts based on the user's choice, records the choice with a timestamp and version, and passes it to tags, SDKs and downstream systems.

What to watch:

• Enforcement, not just display. A banner that records "reject" but lets analytics scripts fire anyway is worse than no banner, because it creates a record of non-compliance. Test with a clean browser and a network inspector.
• Opt-out preference signals. California's regulations require businesses to honor signals such as Global Privacy Control as a valid opt-out of sale and sharing (CCPA regulations, section 7025), and several other states require recognition of universal opt-out mechanisms. Your CMP should detect the signal and apply it without a banner click.
• Propagation. A consent or opt-out recorded on the website has to reach the CRM, ad platforms and email tool. This is where the consent layer depends on the data map: you can only propagate to systems you know about.

DSR automation

Request tools handle the workflow of rights requests: an intake form or portal, identity verification, deadline tracking, task routing to system owners, a secure way to deliver results, and an audit trail. The more advanced ones connect directly to systems to search, export and delete. The details are in the DSR automation guide and in How privacy request automation tools work.

The key dependency is the data map. A request tool can only search systems that are in its list, by identifiers it knows those systems use. Teams that buy request automation without a current inventory often end up with a well-organized manual process: the ticket is tidy, but someone still has to log into each tool by hand. Requests that arrive through agent services in bulk, covered in Requests from Mine, Privacy Bee and other agent services, make this gap obvious quickly.

Data discovery and mapping

The mapping layer finds systems (from SSO, procurement and cloud inventories), scans them for personal data, classifies what it finds, and maintains the inventory and ROPA. It is the hub of the stack: every other layer reads from it. The data mapping and discovery guide covers how discovery and classification work and where they fail, including false positives and data hidden in free text.

Questions that separate tools in this layer:

• Does it discover systems, scan their contents, or both?
• For each connector, does it support discovery only, or also search, export and deletion for requests?
• How does it handle unstructured data (documents, tickets, chat)?
• Where are sampled values stored, and who can see them? A discovery tool is itself a sensitive system.
• Can ROPA entries link to live inventory records, so a change to a system shows up in every activity that uses it?

If you are deciding whether this layer is worth buying, the data map cost page explains what drives the cost of the manual alternative.

Vendor and third-party risk

Every SaaS tool that handles personal data is a processor (or sometimes an independent controller) that needs a contract, due diligence, and periodic review. Vendor risk tools manage security and privacy questionnaires, store DPAs, track sub-processor changes, and schedule reassessments.

This layer and the mapping layer overlap heavily. The vendor list is a subset of the system inventory, and the data categories a vendor receives determine how much scrutiny it needs. When the two live in different tools with no link, you end up with two vendor lists that disagree. Either pick tools that integrate or designate one as the source of truth.

Assessments: DPIAs, PIAs and risk assessments

GDPR Article 35 requires a data protection impact assessment for processing likely to result in a high risk. Most US state comprehensive laws require data protection assessments for targeted advertising, sale of personal data, certain profiling and processing of sensitive data, and California's risk-assessment regulations took effect on January 1, 2026, with attestations due to the CPPA by April 1, 2028 (CPPA).

Assessment tools provide questionnaires, routing for review and sign-off, versioning and a searchable record. Their value grows with volume: if you run a handful of assessments a year, a well-structured document template may be enough. The dependency again is the map: describing the processing (systems, data categories, recipients, transfers) is the first section of any assessment, and pulling it from the inventory saves time and keeps it consistent with the ROPA.

Privacy engineering and PETs

The innermost layer lives in your own systems rather than in a privacy team's tool. It includes:

• Tokenization and pseudonymization. Replacing direct identifiers with tokens, so most systems never see the raw value. GDPR Article 4(5) defines pseudonymization; pseudonymized data is still personal data, but the technique reduces exposure and is cited in Articles 25 and 32 as an appropriate measure.
• Encryption and key management, including field-level encryption for sensitive columns. See security controls for personal data.
• Access controls and logging tied to purpose: support agents see what they need for a ticket, analysts work on de-identified datasets.
• Deletion and retention pipelines that actually remove data on schedule and on request, including from backups and derived datasets, on a documented timeline.
• Privacy-enhancing technologies for analytics and sharing, such as aggregation thresholds, differential privacy, secure enclaves or clean rooms. These are specialized; most companies need the basics above long before they need these.

Engineering controls make every other layer cheaper. A system that stores a token instead of an email address is one fewer system to search in an access request. A pipeline that deletes data after its retention period shrinks what the scanner finds.

How the layers connect

Draw the stack as a hub and spokes, with the data map in the middle:

• Map → requests: which systems to search and how.
• Map → consent: where opt-outs need to propagate.
• Map → vendor risk: which vendors get which data.
• Map → assessments: the description of processing.
• Vendor risk and engineering → map: new vendors and new data stores create inventory records.
• Requests → map: a request that finds data in an unlisted system is a discovery event.

The practical test for any tool is whether it reads from and writes to this hub, or keeps its own private copy of your systems and vendors. Private copies drift.

What a small company needs versus a large one

The line between the two columns is not headcount. It is when manual work starts to fail: requests miss deadlines, the map is out of date within months, or vendor reviews pile up. If you are in the first column and wondering when to move, the first 90 days article covers sequencing, and Hiring a data privacy consultant covers when outside help makes sense.

Buying in the right order

1. Get the map good enough first, even in a spreadsheet. Every other tool depends on it.
2. Fix consent enforcement if you run third-party tags; it is the most visible layer and the easiest for regulators and plaintiffs to test from outside.
3. Automate requests once volume or deadline pressure justifies it, choosing a tool whose connectors cover your highest-volume systems.
4. Add vendor risk and assessment tooling when the number of vendors and new projects outgrows a checklist.
5. Invest in engineering controls continuously. They reduce the load on every other layer.