The operational procedure for conducting Data Protection Impact Assessments (DPIAs, also called Privacy Impact Assessments / PIAs) under GDPR Article 35 and US state-law equivalents — Colorado Privacy Act §6-1-1309, Connecticut Data Privacy Act §15(a), Virginia CDPA §59.1-580, and similar provisions in Texas, Oregon, Montana, Indiana, New Jersey, Delaware, New Hampshire, Kentucky, Maryland, Minnesota, and Rhode Island. This procedure implements the Data Management Policy, the Risk Management Policy, and the AI Acceptable Use Policy.

​
When a DPIA is required

A DPIA is required before initiating or materially changing any processing activity that meets at least one of the following triggers (GDPR Art. 35(3) plus Article 29 WP / EDPB Guidelines WP248 nine-factor test, plus state-law triggers):
  • Automated decisions producing legal or similarly significant effects on the individual (denial of service, pricing differentiation that affects access, eligibility decisions).
  • Large-scale processing of special categories of data (Art. 9 — health, biometric, genetic, racial/ethnic, religious, sexual orientation, political views) or criminal-conviction data.
  • Systematic monitoring of a publicly accessible area on a large scale, or systematic employee monitoring beyond standard endpoint security.
  • Profiling that evaluates personal aspects (work performance, economic situation, health, preferences, behavior, location, movement).
  • Combining or matching datasets from separate sources beyond what data subjects reasonably expect.
  • New AI / ML features processing personal data — required for any feature in scope of the AI Acceptable Use Policy, regardless of whether other triggers apply.
  • Children’s data processing of any kind.
  • Innovative use of new technologies (e.g., novel biometrics, on-device inference using sensitive inputs).
  • Cross-border transfers that rely on derogations or that involve countries without an adequacy decision (paired with the Transfer Impact Assessment — see Cross-Border Transfers).
  • Targeted advertising, sale of personal data, or profiling that is in scope of the Colorado, Connecticut, Virginia, or other state-law DPIA requirement.
When in doubt, run the DPIA. A “screening DPIA” — the brief first section of the template — is sufficient to document a determination that a full DPIA is not required.

​
Roles

RoleResponsibility
Engineering / product proposerDrafts the DPIA, gathers input from architects and PMs
General Counsel (Privacy Officer; also acting as voluntary DPO — see DPO independence note)First reviewer (legal basis, lawfulness, minimization); reviews from data-subject-rights perspective; consults supervisory authority where required; final approval on legal sufficiency. If Art. 37 mandatory DPO is later triggered, the DPO-track review is split out to the independent DPO.
CISOReviews technical safeguards, encryption, access controls, logging
CTOApproves on technical-feasibility and architectural grounds
CEORequired sign-off only when residual risk is rated High after mitigations
For DPIAs that identify High residual risk that cannot be mitigated, GDPR Art. 36 requires consultation with the lead supervisory authority before processing begins. Determining the lead supervisory authority requires either a “main establishment” in the EU under Art. 4(16) (a place of central administration in the Union, or the establishment that determines the purposes and means of processing) or an Art. 27 representative who serves as the contact point. As of the effective date of this procedure, Neuroscale has no EU establishment and no Art. 27 representative is appointed, so no single lead supervisory authority is designated for Neuroscale, and the EDPB “one-stop-shop” mechanism does not apply. Until that changes, any High-residual-risk DPIA follows this routing:
  1. Outside counsel scoping. The General Counsel engages outside counsel (VGC LLP) within 5 business days of the High-residual-risk determination to identify each EU/EEA Member State whose residents are affected by the proposed processing.
  2. Per-Member-State consultation. For each affected Member State, the Art. 36 prior-consultation submission is filed directly with that Member State’s supervisory authority (e.g., CNIL in France, BfDI/Länder in Germany, AEPD in Spain, Garante in Italy, AP in the Netherlands, DPC in Ireland, IMY in Sweden, Datatilsynet in Denmark/Norway, ICO in the UK) using each authority’s published intake mechanism. The Privacy Officer (General Counsel) is the named contact.
  3. Processing pause. Processing does not begin until each consulted authority has responded or the eight-week (extendable) Art. 36(2) period has lapsed without objection.
  4. Establishment trigger. When Neuroscale establishes an EU presence — by hiring EU-based staff with decision-making authority over processing, opening an EU operating entity, or appointing an Art. 27 representative — the General Counsel updates this procedure with the designated lead supervisory authority and consulting authorities.
This procedure is reviewed at the annual policy-review cycle and on any material change in Neuroscale’s EU footprint.

​
DPIA template — required content

Every DPIA includes, at minimum:
  1. Project / processing description
    • Owner, team, scope, expected go-live date.
    • The processing activity (collection, generation, use, disclosure, retention, deletion).
    • Data subjects (categories and rough volume).
    • Personal-data categories, including any special-category or sensitive data.
    • Systems and sub-processors involved.
    • Data flows (a diagram is strongly preferred — sources, stores, recipients, cross-border legs).
  2. Necessity and proportionality
    • Purpose of the processing and why it is necessary for that purpose.
    • Lawful basis (GDPR Art. 6) and, for special categories, Art. 9 condition.
    • Whether the same purpose could be achieved with less data, less identifying data, or shorter retention.
    • Whether data subjects would reasonably expect this processing.
  3. Risks to data subjects (not risks to Neuroscale)
    • Likelihood and severity, on a scale, for each risk:
      • Loss of confidentiality (unauthorized access).
      • Loss of integrity (incorrect or manipulated data).
      • Loss of availability (data subjects can’t get to their own data).
      • Discrimination, exclusion, denial of service.
      • Identity theft or fraud.
      • Reputational, financial, or psychological harm.
      • Re-identification of pseudonymized or anonymized data.
      • Loss of autonomy (over-collection, dark patterns).
    • For AI features, additionally: training-data leakage, prompt injection, output bias, hallucinated personal data.
  4. Safeguards / mitigations
    • Technical (encryption, pseudonymization, access controls, rate limits, logging, retention limits).
    • Organizational (training, RBAC, vendor due diligence, contractual terms).
    • Privacy by design / by default features (minimization, granular opt-in/out, in-product transparency).
    • For AI: model evaluation, red-team results, output filters, human-in-the-loop, opt-out from training.
  5. Consultation — record any consultation with data subjects, internal stakeholders, or, for High residual risk, the supervisory authority.
  6. Outcome decision
    • Residual risk rating after mitigations: Low / Medium / High.
    • Decision: Proceed / Proceed with conditions / Do not proceed.
    • Approver names and dates.
    • Re-review date.
The DPIA template is the DPIA intake form; each section above maps to a field in that form.

​
Process

  1. Trigger. Engineering / product submits the DPIA intake form at the start of design, before significant build effort, which files into the #privacy Linear queue. The PR or RFC carries a dpia-required flag set during planning.
  2. Screening. If the proposer believes no DPIA is required, they complete the one-page screening section and route it to the General Counsel (Privacy Officer) for sign-off. The screening is itself filed in the DPIA register.
  3. Drafting. Proposer fills the full template with input from architects, security, and PMs.
  4. Review. General Counsel (acting in both Privacy Officer and voluntary DPO capacities) + CISO review in parallel. Each provides written comments in the ticket. A review meeting is held for any non-Low-residual-risk DPIA. Where Art. 37 mandatory DPO has been triggered and an independent DPO has been retained, that DPO conducts the DPO-track review separately from the Privacy-Officer review.
  5. Approval. CTO and General Counsel approve in writing (the General Counsel signs both the Privacy-Officer-track approval and, where applicable, the voluntary-DPO-track approval). CEO approves where residual risk is High.
  6. Pre-deployment gate. The DPIA approval is referenced in the release ticket (see Release Checklist). Production deploy is blocked until DPIA approval is recorded.
  7. Re-review. DPIAs are reviewed on:
    • Material change to processing (new data category, new sub-processor, new purpose, scaled-up volume).
    • At least every 24 months for active processing.
    • On a relevant breach or near-miss.
    • On regulatory change (e.g., new state law adding a trigger).

​
Integration with engineering

The DPIA flag is embedded in product / engineering process at three points:
  • PRD / RFC template — the privacy section asks “does this trigger a DPIA?”
  • Pull-request template — for PRs that touch personal-data flows, the author confirms the relevant DPIA reference or that no DPIA is required.
  • Release checklist — see Release Checklist.
GitHub Actions workflows on the neuroscale GitHub org check for the DPIA reference on PRs labeled personal-data or ai-feature.

​
Records

The DPIA register lives in the DPIA Register project in Linear and contains:
  • A row per DPIA (including screening DPIAs).
  • Status (Draft / Review / Approved / Closed / Superseded).
  • Residual-risk rating.
  • Approvers and dates.
  • Re-review date.
  • Links to the underlying RFC, PRD, and design docs.
Each DPIA file is retained for 6 years from the date the underlying processing ends (exceeds GDPR audit-trail expectations). Withdrawn drafts are also retained.

​
Public-facing summaries

Where a DPIA covers customer-facing functionality, a non-confidential summary may be published on the Trust Center at the discretion of the General Counsel (Privacy Officer). State laws (CT, VA, etc.) require DPIAs to be made available to the AG on request; the General Counsel manages those requests.

​
Cross-references

​
Version history

VersionDateDescriptionAuthorApproved by
1.0May 8, 2026Initial versionCameron WolfeIshan Jadhwani