Resources Governance & Compliance Helvane B.V. Case Study
Case Study · Engagement HLV-GDPR-01 · Multi-Regime Privacy Infrastructure
A twenty-person SaaS startup with no policies, no register, and a live AI feature quietly sending customer support tickets to a third-party model. Three jurisdictions later, it has a working compliance programme — and this is the record of how it was built, including the parts where the law gave no clean answer.
GDPR
Regulation (EU) 2016/679CCPA / CPRA
Cal. Civ. Code § 1798.100 et seq.DPDP
Digital Personal Data Protection Act, 2023The brief
Helvane B.V. sells customer-support software to small businesses. That means every ticket its customers receive — every complaint, every refund request, every rambling message someone typed at midnight — passes through Helvane's systems. Helvane doesn't own that data. Its customers do. Helvane just holds it.
That distinction is the spine of the entire engagement. It determines which obligations land on Helvane and which land on its customers, and getting it wrong in either direction is the most common failure mode for a company in this position. Handle a deletion request you had no authority to handle, and you've overstepped. Ignore one you were obliged to forward, and you've failed your contract.
Helvane is fictional. The regulatory analysis, the methodology, and the judgment calls are not — they are the same ones a real engagement of this shape would produce.
The engagement
Each regime was assessed on its own terms before anything was written. That sounds obvious. In practice, the commonest shortcut in multi-jurisdiction privacy work is to build once for GDPR and relabel it twice — and the second and third regimes are precisely where that shortcut breaks.
Twenty-two documents is a claim of coherence that's easy to make and hard to check from the outside. So rather than assert it, here is the actual reference chain — every arrow below is a specific clause or finding in one document that another document names directly. Click any node.
Select a document above to see its dependencies.
The work began with a Record of Processing Activities, because everything downstream depends on knowing what data actually exists. Mapping surfaced fourteen gaps. Three were critical, and one of them had been running in production for months.
Helvane's AI reply-suggestion feature was sending the full text of customer support tickets — which can contain anything an end-user chose to disclose, including health information — to a third-party AI provider. No data processing agreement. No confirmed processing region. No written assurance that the vendor wasn't training on those inputs. The feature was enabled by default.
That finding drove the sequencing of everything after it. A DPIA was conducted under Article 35, concluding the feature met four of the WP248 screening criteria and required full assessment. Its mitigations were then written directly into the customer-facing DPA as binding contractual terms — a no-training clause, an opt-in default, a thirty-day advance notice requirement for sub-processor changes — rather than left as recommendations in a document nobody would enforce.
The remaining deliverables built outward from there: a breach response plan that makes the Article 33 clock somebody's explicit job, a rights-handling procedure built around the controller/processor fork, and the external-facing policies that had to match what the register actually said.
By the time Helvane crossed into California, it had outgrown the revenue threshold and was serving US customers. Applicability was unambiguous. What was not unambiguous was whether Helvane was sharing personal information — a CPRA concept with no GDPR equivalent, which catches companies that have never sold a record in their lives.
The US web analytics vendor Helvane had used since launch — flagged but unresolved since the original GDPR register — almost certainly constitutes "sharing" for cross-context behavioral advertising under the CPRA. Not because Helvane sells anything, but because that is the default behaviour of most analytics tags unless deliberately configured otherwise. This is how an otherwise-clean B2B company acquires a Do Not Sell/Share obligation without noticing.
The assessment opened by mapping, honestly, what carried over from the GDPR work and what did not. The breach workflow transferred nearly intact. The DPIA methodology had no CCPA analogue. The DPA did not transfer at all — California expects its own contractual language for service providers, not an Article 28 agreement with the nouns swapped.
What followed was a California-specific privacy notice built to the statutory disclosure format, an opt-out mechanism designed to honour the Global Privacy Control signal, and a rights procedure with CCPA's own graduated verification standard and forty-five-day clock.
India was different in kind, not just in detail. Helvane opened a Bengaluru delivery hub and signed its first Indian customers, triggering the Digital Personal Data Protection Act on multiple independent grounds at once. But the Act's substantive obligations commence in phases, with the operative compliance requirements landing in May 2027.
That changed the brief. This was not remediation of a live violation. It was a build-and-test window — and saying so plainly, rather than manufacturing urgency, was part of the work.
The DPDP Act treats consent as the primary basis for processing, with a narrow, closed list of statutory alternatives. There is no general legitimate-interest ground. Helvane's entire Indian marketing and website operation had no lawful basis available other than consent — and its existing consent flow, built for the EU cookie model, did not meet the Act's itemisation and language-accessibility requirements.
One further structural point mattered more than it first appeared. Significant Data Fiduciary status under the Act is conferred by government notification, not self-assessment. Unlike the GDPR DPO test, Helvane cannot reason its way to that designation — so the correct posture was a documented monitoring trigger, not a self-declared conclusion.
The Act also grants a right with no GDPR or CCPA counterpart: a Data Principal may nominate another person to exercise their rights in the event of death or incapacity. That needed a process designed from first principles, and one that would work correctly the first time it was ever invoked.
Judgment
Compliance work is mostly not about knowing what a statute says. It is about taking a defensible position where the statute does not clearly say anything. These are the four places this engagement had to choose.
The security posture was genuinely strong — SOC 2, ISO 27001, encryption, restricted access. The problems were a training opt-out that hadn't been enabled and a processing region that hadn't been pinned. Both fixable in thirty days. A hard rejection would have been defensible on paper and wrong in practice: it would have killed a working product feature over problems with known remedies. The assessment issued conditional approval with a deployment-blocker deadline instead.
Helvane processes support tickets at scale, and special-category data appears in them regularly. That looks like it should trigger Article 37. But the EDPB's "regular and systematic monitoring" threshold targets behavioural tracking and profiling, not passive storage and retrieval of messages people chose to send. The conclusion was no — with two named triggers that would flip it, and a recommendation to formalise the interim privacy role now rather than wait.
Section 7(i) of the DPDP Act covers processing for employment purposes without consent. Whether it reaches the recruitment stage — before any employment relationship exists — is genuinely contestable, and the Board has not yet said. The engagement took the conservative reading: consent for applicants, statutory legitimate use only once employed. If the Board later reads Section 7(i) broadly, Helvane has collected a consent it did not strictly need. The reverse error is considerably more expensive.
There was an available argument that the vendor is a pure service provider and no sharing occurs. Taking it would have avoided building an entire Do Not Sell/Share mechanism. But that argument rests on a vendor configuration nobody had actually verified, and assuming favourably about an unverified vendor is the precise error the AI-feature DPIA had already caught once. The register says "sharing" until someone checks.
Operations
Documents describe what should happen. They are not evidence that it does. Three operational artifacts were produced to test whether the programme actually functions under load — and each one surfaced something the documents alone had not.
Every request routed across all three regimes, with deliberate edge cases: a request arriving through the wrong channel, an authorised agent acting for a former applicant, an opt-out submitted by telephone rather than the website link, a CCPA extension invoked with documented reasoning, and the first invocation of the DPDP nomination right by the nominee of a deceased data principal.
Surfaced: a hiring manager's interview notes held outside the applicant tracking system, invisible to the retention policy — found only because someone actually searched.| ID | Regime | Right(s) | Requester | Outcome | Note |
|---|
A full questionnaire across data location, retention, training use, security posture, sub-processing, and contractual terms, with the vendor's responses recorded and analysed line by line rather than filed unread.
Surfaced: the vendor's answer on model training sounded reassuring — customers can opt out — but Helvane had never actually opted out. A low-risk answer concealing a critical exposure.A deployment regression breaks tenant isolation for four hours, exposing tickets between an EU customer and an Indian customer simultaneously. Walked through in timestamped real time against the breach plan, with a completed register entry and a multi-regime notification fork.
Surfaced: the incident was caught by a nightly batch test. Had it happened during business hours, nothing would have detected it for up to twenty-four hours.Method
The order is not arbitrary. Each stage produces the facts the next one depends on, which is why programmes assembled from templates tend to contradict themselves — the policy claims one retention period, the register records another, and nobody notices until a regulator does.
Inventory every processing activity and test it against the specific regime's own categories and basis framework — not a generic one carried over from elsewhere.
Applicability thresholds, gap analysis, and formal risk assessment where the regime mandates it. Unresolved questions stay visibly unresolved rather than being assumed favourably.
Policies, contracts and procedures written against the facts established above, each one cross-referencing the register rather than restating it from memory.
Rights handling, breach response, vendor due diligence and consent management — the parts that have to work on an ordinary Tuesday, not just on paper.
Review cadence, regulatory change tracking, and standing re-assessment triggers, so the programme degrades gracefully instead of silently going stale.
The register
Twenty-four artifacts. Every document cross-references the ones it depends on — the DPA's sub-processor annex mirrors the register's open gaps, the breach annex extends the existing plan rather than duplicating it, and the privacy notices match what the register actually records.
| Document | Regime | What it does |
|---|---|---|
| Record of Processing Activities | GDPR | Art. 30 register — controller and processor activities, sub-processors, running gap tracker |
| Data Protection Impact Assessment | GDPR | Art. 35 assessment of the AI reply-suggestion feature; five risks scored, mitigations split into prerequisites and recommendations |
| Data Processing Agreement | GDPR | Art. 28 customer-facing contract; encodes the DPIA prerequisites as binding terms |
| Breach Response Plan | GDPR | Detection to notification workflow, severity triage, awareness-clock discipline, breach register |
| DSR Handling Procedure | GDPR | Rights intake, the controller/processor fork, verification, fulfilment and refusal handling |
| External Privacy Policy | GDPR | Public-facing Art. 13/14 disclosure, traced line by line to the register |
| Cookie Policy | GDPR | Cookie inventory, consent categories, control mechanics |
| DPO Necessity Assessment | GDPR | Art. 37 analysis with a reasoned negative conclusion and named re-assessment triggers |
| Internal Data Protection Policy | GDPR | Employee-facing, plain language, built around the two-hats distinction |
| Remediation Memo | GDPR | Completed legitimate-interest assessments plus four configuration-level fixes with named owners |
| CCPA Applicability & Gap Assessment | CCPA | Threshold test, sale/share analysis, and an honest GDPR-transfer mapping |
| California Privacy Notice | CCPA | Statutory disclosure format, including the per-vendor sale/share determination |
| Do Not Sell or Share Procedure | CCPA | Opt-out mechanism design, GPC handling, and the preference-collision problem |
| CCPA Consumer Rights Procedure | CCPA | Know, delete, correct and appeal, with CCPA's graduated verification standard |
| DPDP Applicability & Gap Assessment | DPDP | Multi-ground applicability, phased-commencement posture, SDF monitoring position |
| DPDP Data Mapping Addendum | DPDP | Each India-relevant activity tested against Section 6 consent or Section 7 legitimate use |
| DPDP Notice & Consent Framework | DPDP | Itemised consent design, multi-language notice, Consent Manager forward-compatibility |
| DPDP Rights & Grievance Procedure | DPDP | Data Principal rights, grievance redressal, the nomination right, and the DPDP breach annex |
| Rights Request Tracker | ALL | 15 simulated requests with edge cases, verification records and resolution reasoning — live, filterable table in the Operations section |
| Vendor Risk Assessment | ALL | Completed questionnaire and analysis for the AI API provider; conditional approval issued |
| Breach Tabletop Exercise | ALL | Timestamped incident walkthrough, completed register entry, lessons learned |
| Advisory Memos | ALL | Two business-facing analyses: training AI on customer data, and scraping for lead generation |
On what this is, and what it is not. Helvane B.V. is a constructed company. Its employees, customers, vendors and incidents are invented, and every document says so on its face.
What is not invented is the regulatory analysis, the sequencing, or the reasoning behind each position taken. The documents carry the caveats a real engagement would carry — draft status, items awaiting vendor confirmation, provisions pending counsel review — because removing them would misrepresent what the work is.
Nothing here has been reviewed by Dutch, Californian or Indian counsel, and it is not legal advice.
ORR builds real, jurisdiction-specific privacy infrastructure — mapped, assessed, and operationalised the same way this one was.