What a cloud compliance check keeps, and what it never sees

When a compliance tool reads an employee’s email, the first thing a data protection officer wants to know is not how good the detection is. It is what the tool keeps afterward. A system that analyses every outgoing message is, by definition, touching a stream of personal data, often about third parties who never agreed to anything. If that system retains the message content, you have built a second copy of every sensitive thing your staff ever wrote, sitting in a vendor’s database, waiting to become a subject access request, a breach, or a discovery target.

So the right question for a cloud-deployed compliance check is narrow: what does it store, and what does it never see again after the analysis returns? The answer should be short, and you should be able to put it in front of your DPO on one page.

The principle the answer has to satisfy

Under the GDPR, Article 5(1)(c) requires that personal data be “adequate, relevant and limited to what is necessary”, the data minimisation principle. A compliance check needs the draft text for a few seconds to analyse it. It does not need to keep that text to do its job afterward. Keeping it would fail the necessity test, because the purpose, checking the message before it sends, is complete the moment the result is returned.

There is a second obligation that pulls the other way, and the design has to hold both. Article 30 requires a record of processing activities, and a compliance function needs to show that controls ran: that messages were checked, what categories fired, how often, in which department. That is a reporting obligation, and it is real. The trick is that you can satisfy it without keeping a single sentence of message content.

What a cloud check should keep, and what it should drop

The split is cleaner than most procurement teams expect. The event is kept. The content is not.

Read that table as a DPO would. Everything in the “kept” column is metadata about a control firing. None of it is the email. If a subject access request lands, there is no stored message to produce. If the vendor is breached, the exposure is a log of rule names and timestamps, not a corpus of your staff’s correspondence. The reporting still works, because the reporting was always built on the event, not the text.

The one exception, and why it is off by default

Some organisations do want the flagged phrase retained, because their own audit process needs to see exactly what was caught and how it was rewritten. That is a legitimate choice, and it should be exactly that: a choice the organisation makes deliberately, defaulting to off. When content storage is off, the enforcement happens at the point of writing: the content is dropped before it is ever persisted, so retention does not depend on the client behaving correctly. The safe default is the one where a misconfiguration leaks nothing, because there was nothing to leak.

The other question hiding behind retention: training

Retention is only half of what a DPO is really asking. The other half is purpose. Even if the message content is not stored, is it used, in the moment it is processed, to train or improve a model? Under the GDPR that is Article 5(1)(b), purpose limitation: data collected for one purpose, checking a message, cannot quietly be repurposed for another, improving a vendor’s model, without a lawful basis for that second purpose.

The clean answer is that the text is processed for the check and for nothing else. It is not added to a training set, not retained as an example, not used to tune the model that reads the next customer’s draft. This matters commercially as much as legally: a firm that would never let its client correspondence become training data for a shared model needs that written down, not assumed. Ask for it explicitly, and ask for it in the contract, not the sales call.

Who is the controller, and who is the processor

In a cloud deployment the vendor processes personal data on your behalf, which under Article 28 makes them your processor and you the controller. That is not a formality. Article 28 requires a contract that binds the processor to act only on your documented instructions, to impose confidentiality, to help with subject access and breach obligations, and to delete or return the data at the end. A cloud compliance vendor who cannot produce a data processing agreement that says these things is asking you to take on controller liability for processing you cannot actually govern.

The retention design and the contract have to agree. If the DPA says content is not retained, the system has to drop it at the point of processing, not merely promise to delete it later. The strongest version is the one where there is no deletion step to trust, because the content was never written down.

Five questions to put to any cloud compliance vendor

1. Is the message content retained after the analysis returns, and if so, by default or by choice?
2. Is our text used to train or improve any model, ours or anyone else’s?
3. What exactly is kept, and can you show it to us as a field list?
4. Where is the processing region, and does any sub-processor sit outside the EU or EEA?
5. Will you sign a data processing agreement under Article 28 that matches those answers?

If the first four answers are clean and the fifth is yes, the retention risk of a cloud compliance check is small and governable. If any answer is vague, the vagueness is the finding.

Where the cloud edition fits, and where it stops

Cloud is the right deployment when your constraint is location and retention, not egress. If your position is “the analysis can run in the EU, by a vendor, as long as the text is not kept and not used to train anything”, the cloud edition answers that completely, and it is live in minutes with no infrastructure on your side. The data minimisation posture above is what makes that defensible to a DPO.

Cloud stops being the answer at one specific line: when the text is not allowed to leave your network at all. No retention policy fixes that, because the issue is the transfer itself, not the storage after it. An organisation on that side of the line needs the model inside its own boundary, which is a different deployment edition entirely. The point of having four editions is that the same check can meet both postures; the point of this one is that for most commercial firms, a cloud check that keeps the event and drops the content is both sufficient and cleaner than the alternatives they were bracing for.

Where the pre-send check fits

VerbaPulse is a pre-send check for accidental risk: it reads a draft before it is sent and returns the sentences that create legal exposure. In the cloud edition that analysis happens in the EU and the message content is not stored, so the control runs without building a shadow archive of everything your staff writes. It complements your archiving and supervision stack rather than replacing it, and it is deliberately not an adversarial boundary.

The takeaway

Ask any cloud compliance vendor for their data-retention answer on one page, and read it against Article 5(1)(c). If the message content is retained by default, you are being sold a second copy of your own risk. The answer you want is the short one: the text is processed and dropped, the event is kept, and content storage is a decision you make, not a default you inherit.