CloudTick: a processor with a discretionary sub-processor clause
CloudTick provides ticketing software to 140 event organisers, all based in the EU. Its data processing agreement states that CloudTick 'may engage sub-processors at its discretion'. In 2022 it onboarded an SMS provider in a third country without telling anyone. In May a regulator from outside the EU sent CloudTick a legally binding order for the ticket-buyer records of one organiser. CloudTick's legal team wants to hand over the records to avoid daily penalties. Separately, a misconfigured storage bucket exposed 3,000 ticket-buyer records - names, emails, partial card numbers - for six hours in April. CloudTick notified the affected organisers on day 9, after confirming the scope, and did not say which records were involved or what the card data looked like. One organiser's DPO is now asking whether CloudTick is fit to remain a processor.
1. Which PII processor obligations were breached by the sub-processor arrangement, and how would you remediate it across 140 contracts?
Read the worked answer
Annex B processor controls require that sub-processors are engaged only with the controller's authorisation, that the controller is given the information needed to exercise any right to object, and that the same data-protection obligations are flowed down to the sub-processor. A clause permitting engagement 'at discretion' is not authorisation in any meaningful sense, and silent onboarding in 2022 breached both the notice and the flow-down expectations.
Remediation across 140 contracts, in order:
- Inventory every sub-processor actually in use - name, location, function, data categories, transfer mechanism. You cannot re-paper what you have not mapped.
- Re-paper the DPA template with specific or general written authorisation, a notice window before new sub-processors are added, an objection route, flow-down obligations, and liability for sub-processor acts.
- Re-issue to all 140 customers, with a clear list of current sub-processors so the change is transparent rather than buried.
- Handle objections case by case - typically by offering a regional alternative or a documented risk acceptance from the controller.
- Put a gate in procurement. The failure was a process failure: onboarding a vendor without a privacy review. A checklist tied to the PIMS records is the actual fix.
- Record it all (Annex B records of processing, sub-processor list, contract versions), because the next customer audit will ask for exactly this.
2. How should CloudTick respond to the foreign disclosure order, and who decides?
Read the worked answer
The trap is treating this as a CloudTick decision. It is not: CloudTick is a processor and the organiser is the controller, so the decision about disclosure of controller data belongs with the controller.
Sequence:
- Do not hand over data on day one of the order. Confirm the order's validity and legal basis, the identity and authority of the requesting body, and the precise scope - which data, which individuals, which period.
- Notify the controller immediately, unless legally prohibited from doing so, and give it enough detail to decide: the order, the scope, the deadline, and the penalty exposure. If a gagging provision applies, escalate to legal counsel and follow the documented escalation route rather than deciding informally.
- Assess and challenge. Ask for the order to be narrowed, ask for the requesting authority to route via mutual legal assistance, and check whether the transfer restrictions and any conflict-of-laws provisions in the DPA apply.
- Minimise if disclosure is unavoidable - specific records, not the whole tenancy, and record what was disclosed and to whom.
- Support the controller's downstream duty to inform affected PII principals where required.
If CloudTick's contract is silent on government access requests, that silence is itself the finding: the DPA should define notification, challenge and minimisation duties. Paying penalties to avoid a hard conversation is not a privacy control.
3. Assess the breach notification: was day 9 defensible, and what should the notification have contained?
Read the worked answer
Day 9 is hard to defend, and the reasoning matters more than the number.
- The obligation is notification to the controller without undue delay, as set out in the processor provisions and normally sharpened in the contract. ISO/IEC 27701 does not fix an hour count; the point is that the controller's own downstream clock - typically 72 hours to a supervisory authority where required - starts when it learns, not when the processor finishes investigating.
- 'We wanted to confirm scope first' is the wrong order of operations. A first notification with what is known, flagged as preliminary, plus a commitment to update, is normal practice. Waiting nine days to send a single complete message means the controller lost the ability to make a timely assessment.
- The content was inadequate. It should have covered: nature of the incident, categories and approximate number of data subjects and records, the fields exposed (specifically that partial card numbers were included, which changes the risk assessment), likely consequences, measures taken and planned, and a named contact for follow-up.
What to fix: a documented incident response procedure with a processor-side timeline, a notification template, an escalation contact per controller, an agreed channel, and a rule that preliminary notification is mandatory rather than optional. CloudTick should also expect the customer DPO's question to be answered with evidence - the procedure, a test record, and the April timeline - not assurances.