GDPR

Everything else on this page follows from one distinction, and getting it the wrong way round is the most common error a vendor makes about their own position.

A worked example, because the abstraction is slippery. A German manufacturer uses SorviAI Finance and stores their own customers’ names, addresses and payment histories. They decide what that data is for, so they are the controller. We hold and process it for them, so we are the processor. We may not decide to use it for a purpose of our own: doing so would make us a controller of data we are not authorised to control, which is one of the clearest ways to breach the regulation.

We hold both roles at once, and a reviewer who sees only one half is entitled to assume the other was overlooked. Our marketing list is ours to answer for. Your ledger is not.

Article 28 requires a written agreement between controller and processor. It is not paperwork attached to the relationship: it is what makes the relationship lawful.

When it exists, it will cover what Article 28 requires it to cover: the subject matter and duration of the processing, its nature and purpose, the categories of data and of data subjects, processing only on your documented instructions, confidentiality obligations on our staff, the security measures we apply, the conditions under which we engage a sub-processor, our assistance with data subject rights, with breach notification and with impact assessments, deletion or return of your data at the end, and your audit rights.

It will not name our sub-processors in its own text. That list changes when a vendor changes, and a list inside the agreement would mean re-executing the agreement each time; it is referenced by URL instead, which is the section below.

A sub-processor is any third party that can touch your personal data: hosting, email delivery, error tracking, support tooling, payment providers.

• The list is published, not supplied on request. It lives on our Compliance page with the vendor, what they do, which categories of data they can reach, where they hold it, and the safeguard that covers the arrangement.
• You are told before a new one starts, not after. The notice period is [SUB-PROCESSOR NOTICE PERIOD].
• Each is bound by terms no weaker than ours. That is an Article 28 condition on us, and it is the reason the list is short rather than convenient.

We operate from India, so data reaching us from the EEA is a transfer to a third country and needs a lawful basis of its own. This is the piece most often missing from a vendor’s answer, and the piece a DPO checks first.

This area of law has moved several times, and each move invalidated arrangements that were compliant the day before. We would rather leave the rows blank until counsel confirms the current position than publish a mechanism that was correct at the time of writing, which is exactly how vendors end up describing an arrangement a court has since set aside.

A request from an individual comes to you, not to us. You are the controller, and our obligation is to give you what you need to answer it.

Where a request needs us, our turnaround is [RIGHTS ASSISTANCE TURNAROUND]. You generally have one month to answer the individual, so ours has to be meaningfully shorter than that to be worth anything, and it has to be a number we can staff rather than a number that reads well.

Export today is [CONFIRM: SELF-SERVE, OR REQUIRES ENGINEERING]. That distinction matters to you more than the format does, because a request you cannot fulfil without emailing your supplier is a request with our queue in the middle of it.

You have 72 hours to notify your supervisory authority of a personal data breach. Our duty is to notify you early enough that you can still meet it.

• Our commitment: [NOTIFICATION COMMITMENT TO CONTROLLERS]. Whatever number fills that blank has to be meaningfully shorter than 72 hours, because a commitment of 72 hours consumes your entire window and is therefore worth nothing to you.
• What you would be told: what happened, which categories of your data were involved, when it occurred and when we detected it, what we have done, and what you need to do.
• Who we would tell: the workspace administrators on record, and any additional contact you have given us for this purpose.

The same commitment appears on our Security page, and the two are not allowed to differ. If you find that they do, the shorter one binds and we have a documentation failure to fix.

Article 32 requires technical and organisational measures appropriate to the risk. Ours are described in full on the Security page rather than summarised twice and allowed to drift apart.

• Tenant isolation. Each customer is provisioned with a dedicated PostgreSQL schema, so your records are not co-mingled in shared tables.
• Access control. Permissions are role-based and scoped per application, and administrative rights are tiered rather than binary.
• Audit logging. An audit log is written into your own schema. Its scope and retention are [CONFIRM: AUDIT SCOPE], which matters here because Article 30 records and any breach investigation both depend on knowing who accessed what.
• Encryption. In transit today; the at-rest position is stated openly on the Security page, including what is not yet confirmed.

This is the section a vendor is most tempted to write loosely, and the one where a loose sentence causes the most damage. It concerns what happens when someone asks you to erase their data and that data sits inside your accounts.

An accounting system is built so that records are immutable. Invoices, journal entries and ledgers are not meant to be editable after the fact, and in most jurisdictions statutory retention requires them to be kept for years. A general ledger you can quietly delete rows from is not a general ledger, and the audit trail that makes your books defensible is the same mechanism that makes erasure hard.

So an erasure request can collide with a retention obligation, and both are legal requirements pointing in opposite directions. The resolution is not to pick one: it is to establish which data carries a retention obligation, to separate personal data from the transactional record, and to pseudonymise rather than delete where retention is mandatory.

We would rather show you an unanswered question than a promise the platform cannot perform. Promising erasure that a retention rule forbids is a commitment breached routinely, quietly, and in writing.

For a DPA, a rights request that needs our help, or a question this page does not answer.

The words on this page that carry a specific legal meaning, in plain language.