Data Subject Rights Against an Immutable Archive

Last updated: 14 September 2026 · Applies to: Converight v1.1.0 Data processor: Thinkdata Labs LLP, trading as Converight

This document sets out how data subject rights work against an archive that is immutable by design.

Most rights guidance assumes a system where data can be edited and deleted. This one cannot, by design. Each right below sets out what is possible, what is not, and why — including where the answer is that Converight cannot carry out the request itself.

Nothing here is legal advice, and the characterisations are ours rather than counsel's. Where a position is arguable it is marked as one.

Who answers, and who asks

The customer is the controller. They decide that their support history is archived, for how long, and when a record is erased. A data subject's request goes to them.

We are the processor. We act on the controller's documented instructions and assist them under Art. 28(3)(e). We do not decide whether a request should be granted; we make it possible to carry out.

If a data subject writes to privacy@converight.com directly, we pass the request to the controller and support them in answering it. We do not act on it ourselves, because doing so would mean deciding something that is theirs to decide.

Separately, we are the controller of our own customers' account data — names, email addresses, audit entries of who did what in our dashboard. Requests about that come to us, and the ordinary rights apply in the ordinary way.

Everything below concerns the archive, where we are processor.

The rights, one at a time

Art. 15 — Access

Fully supported.

A contact-scoped lookup resolves a person to every record they appear in: their contact record, and every conversation in which they took part. That resolution is the same mechanism erasure uses.

The controller can then read each transcript as archived and export it as JSON, CSV or PDF with a SHA-256 checksum attached, so the recipient can verify the file independently.

One caveat worth disclosing to a data subject. Where Intercom returned a conversation with more parts than its API will serve, the archived record is flagged incomplete and carries a note saying which messages are missing. An access response built from such a record should say so rather than present it as the whole conversation.

Art. 16 — Rectification

We cannot correct an archived record, and that is the design rather than a limitation.

Archived objects are written under S3 Object Lock and cannot be modified for their retention period. An archive whose contents could be edited would not be evidence of anything — the entire value of the record is that nobody, including us, can change it after the fact.

What can be done instead. The controller corrects the record in Intercom. The next backup archives the corrected state as a new version. Both versions then exist: the archive shows what was said, when it changed, and what it changed to.

For most rectification requests this is the substantively correct outcome — a support conversation is a record of what was actually said, and "correcting" it would falsify history. The prior version remains readable alongside the corrected one.

This is an arguable position, not a settled one. Art. 16 gives a right to rectification; Art. 17(3)(b) and Art. 89 contemplate exemptions where processing is necessary for compliance with a legal obligation or for archiving purposes. Whether a commercial retention archive qualifies is a question for the controller's counsel, and the answer may differ by jurisdiction and by why the archive exists. We provide the versioning; we do not assert the exemption.

Art. 17 — Erasure

Supported, by destroying the key rather than the record.

Each record is encrypted with its own data key. An erasure destroys that key and nulls the searchable identifier columns — name, email address, conversation title, tags — and removes the link recording that the person took part in the conversation. The ciphertext remains under Object Lock and becomes permanently unreadable.

It survives a restore. A database backup taken before an erasure still contains the key that erasure destroyed, so restoring it would resurrect the record. Every erasure is therefore written to an append-only ledger held under Object Lock outside the database, and the application re-applies anything a restore brought back, at startup.

Whether residual ciphertext counts as erased is not settled law. Cryptographic shredding is widely used and is not universally blessed. We document what we do precisely so a controller can take their own view of it.

What erasure does not reach. We hold read-only access to Intercom and cannot delete anything there. An erasure carried out in the archive does not touch the customer's Intercom workspace, their own backups, or any other integration they have connected. A data subject told "your data has been erased" on the strength of our action alone would be told something incomplete.

Legal Hold outranks erasure. A record under hold is not shredded, and the erasure request reports that rather than silently skipping it. That is deliberate: a hold usually exists because a court or regulator requires preservation, and that obligation is one of the grounds on which erasure may be refused. The controller decides which prevails.

Art. 18 — Restriction of processing

Supported.

A restriction can be placed on a contact, a conversation, a company or the whole workspace. While the restriction is active, ordinary processing stops. The record remains stored but is removed from search, retrieval and export. The encrypted object is untouched.

It also protects against deletion. A restricted record survives retention expiry, and an erasure request covering it is reported as blocked rather than carried out — because Art. 18(1)(b) exists for a data subject who wants the record kept rather than deleted, and erasing it would do the opposite of what was asked. The controller decides which prevails.

A Legal Hold is not a substitute, and the difference matters. A hold guarantees a record survives and says nothing about who may read it. A controller asked to restrict processing who places a hold instead preserves exactly the access the data subject objected to. The two coexist and each does its own job.

Which Art. 18(1) ground applies is recorded, not free text, because the ground decides when the restriction may lawfully be lifted and a controller answering a supervisory authority has to name it. The target, the person who acted, both timestamps and a stated reason for placing and for lifting are all written to the audit log.

Art. 20 — Portability

Supported.

Exports are produced as JSON and CSV, which are structured, commonly used and machine-readable, with a checksum manifest. A controller can hand the output directly to a data subject or to another processor.

Whether a given archive falls within the portability right at all is the controller's determination — it applies to data the subject provided, processed on consent or contract, which may cover an end user's own messages but not a teammate's replies about them.

Art. 21 — Objection

Routed to the controller; we hold no independent purpose to object to.

We process archived content solely on the controller's instructions and for no purpose of our own. We do not use it for product development, analytics, advertising, or training machine-learning models. There is therefore no processing by us that a data subject could object to independently of the controller's decision to archive.

Where a controller upholds an objection, the mechanism available is erasure.

Art. 22 — Automated decision-making and profiling

Not applicable. We perform none.

Converight copies, encrypts, indexes and serves records. It makes no decisions about individuals, produces no scores or inferences, and no output of ours affects anyone's rights.

Timing

The controller's deadline under Art. 12(3) is one month, extendable by two further months for complex requests.

Our obligation is to assist without undue delay. In practice:

Access and portability — self-service. The controller can search, read and export without involving us at all.
Erasure — self-service from the dashboard. Shredding is immediate; the request records what was and was not shredded, including anything withheld under Legal Hold.
Anything else — privacy@converight.com.

Nothing here requires us to be in the loop for the routine cases, which is deliberate: a processor who has to be emailed before a controller can answer a subject request is a processor who causes the controller to miss deadlines.

Retention, and why it is no longer than necessary

Two things govern the retention period:

The customer sets the policy. Retention is configured per workspace and per resource type. We do not impose a period beyond the floor below, and we do not retain for purposes of our own.

Object Lock enforces a floor of 365 days. An archived object cannot be deleted before its retention date — this is what makes the archive an archive. It is the mechanism a customer is buying, and it is the reason erasure is performed cryptographically rather than by deletion.

On disconnection, backups stop and the archive is held for 30 days, then crypto-shredded — and only once a human has acknowledged the disconnection. A workspace disconnected because Intercom rejected its token is not treated as a customer's decision to delete, and is never purged on that basis alone.

What this rests on

The assistance described here is contractual. The Data Processing Addendum commits us to it — in particular to restricting a record on the customer's instruction, and to recording the ground, target, actor, timestamps and stated reason.

Two limits are worth stating plainly, because they decide what a controller can promise a data subject:

Erasure within Converight does not reach Intercom, the customer's own systems, or any other integration. Each is erased separately.
The legal status of shredded ciphertext is not settled law. We present crypto-shredding as a defensible response to an erasure request, not as a settled one, and the reasoning is set out under Art. 17 above.

Our Data Processing Map and incident response runbook are available on request to security@converight.com.