Article 32 names encryption as one half of one of four listed items, alongside ongoing resilience and a process for regularly testing the measures. Encryption is the easiest of the four to state, which is a different thing from being the hardest to satisfy.
The harder part is erasure. Whether a particular derived copy falls in scope is a question for your counsel, and the engineering problem arrives either way: the derived copies in an analytics stack are typically precomputed aggregates and cached result sets, which are not usually built to record which rows produced them.
Start With Article 28, Because the Role Decides the Architecture
Before any technical question, settle whether the analytics platform processes personal data on your behalf. If it does, it is a processor and Article 28 governs the relationship.
Three clauses do most of the work. Article 28(1) requires that a controller "shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures". Article 28(2) states that "the processor shall not engage another processor without prior specific or general written authorisation of the controller", which is the clause that makes your vendor's own subprocessor list your business.
Article 28(3)(g) is the clause this page borrows its vocabulary from. It requires that the processor "deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data". (Article 28 GDPR, read 20 August 2026.)
Read the scope before the phrase. This obligation fires after the end of the provision of services, so it is about winding a processor down rather than about a single person's deletion request.
Its contribution here is the phrase existing copies, which names the problem more concretely than anything in the other three articles read for this page. We did not search the full regulation, so read that as a comparison across four articles rather than across the whole text.
Article 17 Gives the Right, and Says Nothing About Your Cache
The ordinary case, one person asking for their data to go, is Article 17, and it puts the obligation on the controller. Article 17(1) states that "the data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies".
Article 17(2) extends this to data the controller made public: the controller "shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data". (Article 17 GDPR, read 20 August 2026.)
Aggregates and caches appear in neither article. Article 17 obliges the controller on request, Article 28(3)(g) obliges the processor at the end of a service, and the two fire at different moments. They share a precondition that neither one states: somebody has to be able to list the copies.
Neither article says how, and we did not read the rest of the regulation to find out whether anything else does.
A note on sourcing. Every article quoted on this page comes from a published transcription of the regulation by intersoft consulting; the authoritative text is the one in the Official Journal of the European Union. The material on aggregates, caches and exports is an engineering reading of that text rather than legal advice, and those words appear in none of the articles. Compliance decisions belong with your counsel.
The Deletion Request Travels the Path the Data Took
The five stages are ours. The regulation names no stages, and the point of setting them out is to locate where the listing problem starts.
Stages one and two are tractable because both hold a key. A source row can be found by identifier, and a transformation model that carries lineage can be traced back to the rows it consumed.
Stage three is where it breaks. A precomputed aggregate is a number, and a number does not record which rows produced it. Delete the row and the total is now wrong, and nothing in the number itself reports that, because a stale total looks exactly like a fresh one.
Stage four depends on a design decision made long before anyone thought about erasure. If your cache key is a hash of the query text, the key alone cannot tell you which entries contain a given subject, so unless something else in the system records that mapping the remaining option is to flush the cache and accept the cost.
Stage five has left your systems. A scheduled report delivered as an attachment, a spreadsheet a customer downloaded, an alert email quoting a row: once delivered, none of those three can be recalled by the system that sent it. Links that expire are the exception and the reason they are worth preferring, which is why the scope of what you export deserves the same review as the scope of what you store.
Three Questions That Separate a Mechanism From a Badge
A certification tells you an auditor looked at controls. It does not tell you what happens when the request arrives.
Ask how a deletion reaches materialised aggregates. The good answers are specific: aggregates are rebuilt on a schedule short enough to satisfy the undue delay standard you have documented, or the aggregate stores contributing row identifiers, or aggregation happens at query time and no materialised copy exists.
Ask what happens to cached result sets. The good answer names the cache key and says whether a targeted invalidation is possible, or admits that a full flush is the mechanism.
Ask whether exports are in scope. The good answer is that they are not recallable, followed by what the vendor does instead: shorter retention on generated files, or links that expire rather than attachments that persist.
An answer in mechanisms is one you can check afterwards; an answer that names a certification is not. That is the reason to ask for the mechanism, because the certification is available to a vendor who has not built one.
Article 30 Asks for Erasure Time Limits Where Possible
Article 30(1) requires that "each controller and, where applicable, the controller's representative, shall maintain a record of processing activities under its responsibility", and it lists what the record contains. (Article 30 GDPR, read 20 August 2026.)
One of those items points straight back at this page. Item (f) requires, "where possible, the envisaged time limits for erasure of the different categories of data".
What you can write there about a precomputed aggregate depends on how it gets rebuilt. The qualifier is "where possible", so the record asks for the envisaged time limits rather than a guarantee, and that is still a good reason to settle the mechanism before launch rather than after.
Article 32 Lists Encryption as Half of One of Its Four Examples
Article 32(1) asks the controller and the processor to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk", and gives four examples, introduced as "including inter alia as appropriate" rather than as a closed list. Encryption is half of the first one: item (a) is "the pseudonymisation and encryption of personal data". (Article 32 GDPR, read 20 August 2026.)
The other three items are worth reading next to it: ongoing confidentiality, integrity, availability and resilience; the ability to restore access after an incident; and "a process for regularly testing, assessing and evaluating the effectiveness" of the measures.
Encryption is easy to state and item (a) states it. Item (d) asks a different question, about a process for regularly testing and evaluating the effectiveness of the measures, encryption among them. Our treatment of the data paths sits in embedded analytics security.
Article 32 does not settle the question this page is about, because none of its four items concerns enumerating derived copies.
Judge an embedded analytics product on the erasure question rather than on the certification list. The three mechanism questions above take one call to ask, and a badge on a homepage does not answer any of them.
Where to go next
- Embedded analytics security: the paths to the data, including the ones a scheduled job opens.
- Row-level security: what a row policy decides, and what it does not.
- Embedded analytics guide: the routes to shipping it, and what each one leaves you owning.
- Embedded Analytics articles: the full cluster index.
Ready to launch customer-facing analytics?
Stop losing customers to competitors with better analytics. Sumboard's customer-facing analytics platform lets you launch self-service dashboards in days, not months.
