Skip to content

GDPR

Statement

ClaimGuard treats GDPR as the baseline standard for personal-data handling across the product, even where customer contracts do not specifically require it. The technical foundations — encryption at rest and in transit (where it exists), role-and-org access control, audit logging, defined subprocessors, EU-region storage, a clear incident-response intake — are in place and described elsewhere in this portal. The paperwork layer (DPA template, Records of Processing Activities, formal DPIA process, lawful-basis matrix per processing activity) is not yet formalized. That is the gap that keeps this control at partial.

Implementation

What we are, GDPR-shape

  • Role. ClaimGuard is a processor for customer-controlled personal data (claim data, evidence, end-user PII the customer uploads). Customers are the controllers.
  • Subjects. Customer staff (users of the application) and any individuals whose data appears in claim narratives or evidence files.
  • Establishment. ClaimGuard's primary cloud footprint is in europe-west1 (Belgium) — data at rest lives in the EU.

What's in place technically

  • EU storage for all primary application data and snapshots. See Cloud provider and Backups.
  • Encryption at rest under GMEK across disks, snapshots, GCS, and Secret Manager. See Encryption at rest.
  • Outbound TLS for cloud-control-plane and AI-vendor traffic. See Cryptography.
  • Role + org access control with org-scoping at the SQL layer, giving a customer-controller-style isolation between tenants. See Authorization.
  • Cloud audit log with 400-day immutable retention covering privileged access. See Audit logging (cloud).
  • Documented subprocessors with EU-residency notes. See Subprocessors.
  • Vulnerability disclosure path for external researchers and a documented incident-response lifecycle (partial). See Vulnerability disclosure and Incident response.

What's not in place yet

  • No published DPA template. A DPA can be negotiated bilaterally on request today, but there is no standard template hosted under this portal.
  • No Records of Processing Activities (ROPA) document distinct from the data-classification page. ROPA is the formal artifact GDPR Art. 30 expects from a processor of any non-trivial scale.
  • No formal DPIA process triggered by, e.g., an AI integration introducing automated decision-making elements (the AI today is advisory, not automated decision-making, so this is not currently triggered — but the process to evaluate it should exist).
  • No published privacy notice customer-facing on the trust portal. Cross-listed on Privacy notice (planned).
  • No 72-hour breach-notification runbook codified per Art. 33. Cross-listed on Incident response as a known gap.
  • No data-subject-request (DSR) workflow for requests routed through ClaimGuard rather than through the customer-controller. Today such requests would be passed to the controlling customer.
  • No formal lawful-basis matrix documenting, per data class, the legal basis our customers can rely on (their contractual necessity, our legitimate interest as processor, etc.).

Data-subject rights

For end users whose data is in a customer's tenant, ClaimGuard fulfills rights via the customer-controller:

  • Right of access / rectification / erasure / restriction: the customer-controller invokes the relevant application endpoints (CRUD on claims and evidence) on the data subject's behalf. ClaimGuard supports the controller in fulfilling the right; we are not the first contact for the data subject.
  • Right to data portability: the customer-controller can export claim and evidence data via the application UI / API.
  • Objection / automated decision-making: the AI integration is advisory; a human reviewer makes determinations. See AI transparency.

For ClaimGuard's own users (customer staff who hold the application account), data-subject requests can be routed to security@dtectvision.ai and are handled per the same SLA as a vulnerability report.

International transfers

Data at rest is stored in europe-west1. Two outbound flows leave the EU boundary:

  • Google Gemini API — managed by Google globally; covered under the Google Cloud DPA. See Subprocessors.
  • Cloud-control-plane traffic to GCP services — Google's standard EU-EEA / SCC posture applies as defined in the Google Cloud DPA.

A stronger residency commitment (e.g., "no inference outside the EU") would require a Gemini API plan change and is a roadmap item under AI transparency.

Status

partial — verified 2026-04-29.

What's in place:

  • EU-region data residency for primary storage and backups.
  • Encryption at rest and the rest of the technical control set.
  • A documented subprocessor list.
  • An incident-response intake; a vulnerability disclosure path.
  • Honest data-flow disclosure for the one outbound AI integration.

Known gaps

  • No published DPA template on this portal.
  • No formal ROPA distinct from the data-classification page.
  • No DPIA process documented.
  • No 72-hour breach-notification runbook codified.
  • No DSR workflow for ClaimGuard-routed requests.
  • No lawful-basis matrix per processing activity.
  • No published privacy notice.

Roadmap

  • DPA template as a downloadable PDF on this portal.
  • ROPA as a maintained internal doc with a quarterly review.
  • DPIA process (a one-page checklist + decision record) before any new AI surface or any new data class lands.
  • Breach-notification runbook with a documented 72-hour timeline and named comms owner. Cross-listed on Incident response.
  • DSR workflow routed through security@dtectvision.ai with an initial-response SLA matching the VDP.
  • Lawful-basis matrix per data class.
  • Public privacy notice at Privacy notice once drafted.