Six weeks until the 25th of May. The customer-portfolio GDPR programmes are in their final stretch, and the operational gotchas surfacing in the past month are worth writing down both for the customer briefings and as a contemporaneous record for the GDPR-implementation literature that will be written in the next several years.
The portfolio readiness picture, rolled forward from January. Browne Jacobson is in good shape; the final tabletop on the breach-notification protocol last week revealed two minor process gaps that are being remediated this week. Towry is in good shape; the Standard Contractual Clauses migration completed two weeks ago, the records of processing activities are current, and the data-subject-rights workflow is operational. Northcott has tightened up substantially in the past month; the DPO function is now operational, the records are current, and the consent-management posture for the customer-facing services is in deployment. The manufacturer is the largest piece of work and is on a tight schedule but is going to land — the cross-border data flow inventory is complete, the DPIA programme has covered the high-risk processing activities, the processor-relationship documentation is in place. The new financial-services client (added in September 2016) is in good shape; their compliance maturity has been higher than the average from the start. The retailer added in October 2017 is the closest to the wire — the breach-response posture is the principal area where I want to see more depth before the 25th, and we have a final tabletop scheduled for early May.
The operational gotchas surfacing in the final stretch. First, the data-processor relationships. The vendor-side contracts that customer organisations have with their cloud, SaaS, and outsourcing providers have, in many cases, required substantial GDPR-related amendment, and the negotiation cadence with the larger vendors (the major cloud platforms in particular) has produced delays. The Article 28 processor agreements are, on paper, well-defined. The actual contract negotiation has been more heterogeneous than the regulation's clean structure suggests. Several customers have ended this stretch with processor agreements that are still being finalised. The legal posture for that is acceptable — the customer is acting in good faith and the principal terms are agreed — but the documentation is going to be in motion past the 25th in some cases.
Second, the records of processing activities. Article 30 requires controllers and processors to maintain records of processing activities that include, among other things, the categories of personal data, the categories of recipients, the international transfers, the retention periods, and the security measures. Compiling those records accurately is a substantially harder operational task than the regulation's text might suggest. Customer organisations have been finding processing activities they did not know they had — historical data flows, dormant integrations, third-party relationships that had drifted out of active management. Each surfaced activity produces work. The records-compilation exercise has been, for several customers, the most useful single piece of GDPR work in terms of organisational visibility into actual data practice.
Third, the breach-notification mechanics. Article 33's 72-hour requirement is operationally demanding. The customer-organisation question is whether, at any moment, the people who would need to be involved in a notification decision are reachable, briefed, and authorised, and whether the technical telemetry to support a notification decision exists and is queryable on a 72-hour timeline. The tabletop exercises across the portfolio have been the most operationally useful part of the run-up — they surface the specific failure modes (the right people were on holiday, the technical lead did not know who held the legal authority, the privileged-access logs from three months ago were not retained at the granularity the notification required, the supervisory authority's online portal was not pre-configured) that are easy to fix in advance and very hard to fix during an actual incident.
The things I am not seeing customers prepare for. First, the data-subject-rights operational load. The right to access, the right to erasure, the right to data portability, and the right to object are operational obligations that scale with the data-subject population. Most customers have been working on the technical mechanism for fulfilling specific requests, but few have planned for the volume. The post-25-May customer-rights traffic is, on the experience of organisations that have been honouring comparable rights under the existing Data Protection Act 1998, going to be substantially higher than the pre-GDPR baseline. Resourcing the rights-fulfilment function for that volume is a question several customers will face in earnest over the summer.
Second, the regulatory-engagement posture. The Information Commissioner's Office is going to be busy. The interactions customer organisations have with the ICO over the next year — formal consultations, breach notifications, data-protection-officer notifications, complaints arising from data-subject submissions — are going to set the tone of the relationship for some years. The customer-organisation playbook for ICO interaction is, for most customers, underspecified. Several customers have asked me whether to engage proactively or reactively with the ICO; my advice is proactive, in cases where the customer can show a programme of good-faith implementation and use the engagement to test specific interpretive questions before they become enforcement questions. The opposite advice — wait until questioned — is, on the regulation's incentive structure, the wrong advice.
Third, the international-transfer environment. Privacy Shield continues to operate but the substantive challenge under Schrems-style litigation is, in the legal community, expected to land in the next 18-30 months. The contingency planning for the potential invalidation of Privacy Shield is, for the customer organisations whose data flows depend on it, an item to have on the strategic list. We are advising customers to maintain a posture in which Standard Contractual Clauses or similar transfer mechanisms can be activated if Privacy Shield is invalidated, even if the customer is currently relying on Privacy Shield as the active mechanism. The cost of that posture is small; the cost of being unprepared for invalidation is large.
The Emily team has been working through April on a GDPR-relevant capability that I have not previously written about. The data-subject-rights fulfilment workflow benefits substantially from automated identification of which records, across the customer's data estate, relate to a given subject. We have built — initially as an internal tool, now as a feature that EmilyAI customers may eventually receive — a subject-search capability that uses the same indexing and entity-resolution work the alert-triage pipeline uses, applied to customer-data discovery. The posture is conservative: the tool surfaces candidate records for human review rather than automating the rights-fulfilment decision. The early customer feedback is positive. The capability is not on the v1 product roadmap for EmilyAI commercial release but is in the planning for v2 in autumn.
Onward to the 25th. The customer briefings continue. The tabletop exercises continue. The work, mostly, is in good shape.