Zendesk Advanced Data Privacy and Protection: What You Get

A disclosure up front, since it shapes what this article can be. Our developer instance does not have ADPP and we couldn't turn it on, so there are no screenshots of these features working. What we could do is work out how an account tells you what it has, which turns out to be less obvious than it sounds and is the part most people actually need.

What is in the bundle

Zendesk's overview of the add-on groups it into a handful of capabilities. They're worth separating, because they serve different buyers.

Data masking hides personally identifiable information from agents in custom roles. Zendesk's data masking documentation frames it around regulatory compliance. This is the one that matters when your answer to "who can see a customer's date of birth" needs to be narrower than "everyone in support".

Advanced encryption lets you encrypt service data with your own enterprise key management service, per Zendesk's advanced encryption documentation. The practical driver here is rarely the encryption itself. It's a requirement in a contract or a questionnaire that specifies customer-managed keys.

Access logs record views. The audit log records changes, and sits with the other settings covered in our Zendesk security checklist. This is the distinction that catches people out: the standard audit log tells you who edited a setting, and an access log tells you who looked at a ticket. If your obligation is to detect inappropriate viewing, the audit log doesn't answer it.

Advanced retention and redaction covers more deletion schedules, more conditions on them, redaction suggestions that highlight PII in a ticket, and automatic redaction driven by triggers.

Call transcription redaction is the one people forget, because it only matters if you run Zendesk Talk. It redacts PII and payment card data out of transcribed call recordings, card numbers and CVVs included. If you take card details by phone, this is the item that decides whether your recordings are a compliance problem.

The retention limit is the one you will hit first

Of those, the retention piece is the most likely to be the reason you look at the add-on at all, because it's the one that shows up as a wall during ordinary work rather than during a procurement exercise.

Without the add-on our instance allows one active deletion schedule per data type, and says so on the page:

This is the most useful ADPP artifact you can obtain without buying ADPP: the paywall, stated by Zendesk, on your own account. It also shows the five data types a schedule can target, which is the shape of what the add-on multiplies. Zendesk's guide to end-user deletion schedules adds a second limit: with the add-on you can activate up to ten schedules, and without it you can add only one condition beyond the required duration field.

One rule per data type and one condition on it is enough for "delete everything older than N years" and nothing more. That constraint interacts with storage too, since attachment deletion is a separate data type and therefore a separate schedule. The moment your policy says "except billing disputes" or "shorter for EU customers", you need a second rule, and that's the paid tier. We wrote about the mechanics and a silent failure we hit in setting up data deletion schedules.

How to tell what your account has

This is the part we could establish first-hand, and it's the practically useful bit, because the answer isn't written anywhere obvious.

The Security overview gives a top-line count of your settings by state.

Note the last row. Unavailable reads zero on our account, and our account demonstrably lacks ADPP features. So the overview isn't listing the things we can't use and marking them unavailable; those settings are simply absent from the page. You can't discover a gap here, which means an admin reading a healthy-looking security overview can reasonably conclude there is nothing more to configure.

The API is more direct. The account settings endpoint exposes feature flags, and the ADPP-related ones read false on our instance. Our Zendesk API guide covers authenticating a call like this one:

Two flags, both false. Read them carefully, though, because they are weaker evidence than they look.

Neither flag appears in Zendesk's documented settings table, and data_masking_configured_in_roles describes configuration rather than entitlement: an account that holds ADPP and has not switched masking on for any role would presumably read false too. We only tested the negative case. So this is a fast signal that is consistent with not having the add-on, and it is not proof that you lack it.

Treat the flags as a first look and the upgrade prompt above as the stronger evidence, since a paywall only renders when there is something to sell you.

The third signal is the upgrade prompt itself. Where a limit exists because of entitlement, Zendesk tends to say so at the point of the limit, which is how we found the one-schedule-per-data-type constraint. Those notices are the most honest inventory of what you don't have, and they only appear when you go looking for the thing you can't do.

Evaluating it without a trial

If you can't switch it on to look, the buying question is which single capability is forcing the conversation, because the bundle is priced as a bundle and the features have very little to do with each other.

If it is a contractual requirement for customer-managed keys, the evaluation is short: you either need advanced encryption or you don't, and no amount of testing changes the answer.

If it is a retention policy with exceptions, the evaluation is arithmetic. Count the distinct retention rules your policy actually requires. One means you're fine as you are. Two or more means you need the add-on, and knowing that before you write the policy saves rewriting it.

Zendesk does not publish an ADPP price, so the arithmetic needs a number from somewhere. Third-party write-ups put it around $50 per agent per month, Enterprise only. That is the figure our own Zendesk pricing breakdown and what Zendesk really costs both carry, flagged in each as third-party rather than official, and strac.io is one of the sources quoting it. No Zendesk page states it, so treat it as approximate and confirm with sales before you build a business case on it. Taken at that figure, a thirty-agent desk is looking at roughly $18,000 a year, which reframes the question. At that price nobody buys ADPP to run a second deletion schedule. They buy it because a contract requires customer-managed keys or an auditor requires access logs, and the retention rules come along with it.

One limitation worth raising before you sign, because it is the kind that gets discovered late. Strac, which sells a competing product and therefore has an interest in the answer, states that ADPP's automatic redaction does not reach inside attachments: PDFs, images, screenshots, spreadsheets and documents. We could not test that, and the source is not neutral, so treat it as a question to put to Zendesk rather than a fact. But it is the right question. A spreadsheet carrying the same card number as the ticket comment is the obvious hole in any redaction scheme, and it has a definite answer a salesperson can give you in one sentence.

If it is data masking, the honest test is whether you can achieve the same outcome with roles and ticket redaction. Sometimes you can. Masking earns its price when the requirement is that agents never see the data at all.

If it is call transcription redaction, the question is narrow and answers itself: do you take card details over the phone, and are those calls recorded? If both, your recordings currently hold card numbers, and no amount of ticket-side redaction touches them.

If it is access logging, the question is whether you need to answer "who viewed this" under audit. That obligation is usually external and specific, and if nobody has asked, this isn't the reason to buy.

The incentive, stated plainly

Bundling is a pricing decision, and it's worth seeing clearly.

These capabilities have almost nothing in common architecturally. What they share is the type of customer who asks for them: regulated, audited, and large enough to have a compliance function. Selling them as one add-on means the customer who needs only key management also pays for masking they'll never enable, and the average revenue per customer who needs any one of them goes up considerably.

That's a completely normal way to price enterprise software. The consequence for you is that your evaluation should follow the one feature you need, not the length of the feature list, because the rest aren't a discount you're receiving. They're the reason the price is what it is.

Common questions

How do I check whether my Zendesk account has ADPP? There is no single definitive check we could find. On our instance access_logs_enabled and data_masking_configured_in_roles both read false in the account settings API, which is consistent with not having the add-on, though the second names configuration rather than entitlement. The clearest signal is an upgrade prompt at the point of a limit, since those only appear when something is being sold to you. The Security overview page did not flag anything as unavailable, so it is not the place to look.

What is the difference between the audit log and an access log? The audit log records changes, such as who edited a setting. The access log records views, such as who opened a ticket or ran a search. Only the second answers a question about inappropriate viewing.

How many deletion schedules can I have without ADPP? Our instance allows one active schedule per data type. Zendesk documents that the add-on raises this to ten for end-user schedules, and that without it you can add only one condition beyond the required duration.

Is data masking the same as redaction? No. Redaction removes data from a ticket permanently. Masking hides existing data from agents in particular roles while it remains stored. Compliance requirements sometimes specify one and accept the other, so check which word the requirement uses.

Which plans can buy ADPP? It's sold as an add-on to enterprise-level plans. Confirm against Zendesk's buying guide for your own account, since plan naming changes.

Where an AI layer fits

Data privacy and AI automation intersect in one specific place worth being precise about: what the agent is allowed to read.

An AI layer reading your tickets sees whatever the credentials it runs under can see. If your reason for wanting masking is that some fields should be invisible to most humans, the same reasoning applies to an automation, and the question to ask a vendor is what its integration reads and under whose permissions.

That question has a concrete answer and it's worth making somebody give you one, rather than accepting a general statement about security posture.

Macha works on top of your existing Zendesk and inherits its permissions rather than holding a second copy of your data. That suits teams whose privacy controls already live in Zendesk and who want automation to operate inside them. It suits you less well if your compliance model depends on data never leaving a specific boundary, because any AI layer processes what it reads and that needs its own review. Our Zendesk integration page sets out what is read and what is stored.

Start your free trial and check what it reads, and under whose permissions, before you commit to anything.