Scrydon
Compliance

GDPR

EU General Data Protection Regulation — how Scrydon supports controllers and processors on lawful basis, minimisation, retention, and the data-subject rights.

The General Data Protection Regulation (Regulation 2016/679) governs the processing of personal data in the European Union. This page covers Scrydon's GDPR-relevant controls.

In a typical Scrydon deployment, you are the controller for the personal data your organisation processes through the platform; Scrydon (the vendor) is not a processor of your data because the platform runs in your cluster and Scrydon has no access to it. This is the architectural reason "data sovereignty" maps so directly to GDPR.

Key principles → platform support

Article 5 — Principles

PrincipleScrydon support
Lawfulness, fairness, transparencyPer-workflow disclosure (intended purpose, data sources). User-facing AI disclosure on chat.
Purpose limitationWorkflow definition declares purpose; deviation triggers a change-management event.
Data minimisationColumn masking, row filters. Process only what the workflow needs. See Classification & masking.
AccuracyManaged-table profiles, evaluator block, ontology provenance.
Storage limitationConfigurable retention per organisation.
Integrity & confidentialitymTLS, encryption at rest, audit. See Security.
AccountabilityThe whole audit + governance posture.

Article 6 — Lawful basis

The platform doesn't determine your lawful basis — that's a legal question for the controller. It does help you record and enforce one:

  • Consent: a consent capture flow can be wired into workflows that handle personal data.
  • Legitimate interest: documented per-workflow as part of the AI governance impact assessment.
  • Contract / legal obligation: documented in workflow metadata.

Article 9 — Special categories

Special-category data (health, biometric, political opinion, …) gets restricted classification by default and a redact mask strategy for non-admin readers. Workflows that process special-category data require an explicit override and are flagged in the AI inventory.

Data-subject rights

GDPR grants data subjects rights you have to honour. The platform supports the technical side:

RightScrydon support
Article 15 — Right to accessPer-org export of personal data: workflows, knowledge-base documents, managed-table rows, audit events tied to a subject.
Article 16 — RectificationStandard write operations on managed tables and knowledge-base documents.
Article 17 — Right to erasurePer-subject erase across managed tables, knowledge base, chat history, audit metadata (the event remains but the subject reference is hashed).
Article 18 — RestrictionMark a record for restriction; it's excluded from query results until lifted.
Article 20 — PortabilityStructured export (JSON / CSV) of all personal data tied to a subject.
Article 21 — ObjectionWorkflow runs against an opted-out subject are blocked at execution time.

The data-subject-request UI is at Settings → Platform → Privacy.

Retention

The default retention windows are conservative:

Data typeDefaultRationale
Audit events365 daysAligns with SOC 2, extendable for financial-services compliance
Workflow run logs90 daysOperational debugging window
Chat history365 daysUser expectation
Knowledge-base documentsindefiniteControlled by user delete
Managed-table rowsindefiniteControlled by table delete

All windows are configurable per organisation. Decreasing the audit retention requires org-owner approval and only affects new events.

International transfers

If your installed integrations call cloud vendors outside the EU (OpenAI in the US, for example), those are international transfers. The platform makes this explicit:

  • The vendor catalogue declares each integration's data-residency profile.
  • Org admins can restrict the integration registry to EU-only or self-hosted providers.
  • An audit event is emitted on every transfer-relevant call (LLM call to a cross-border vendor).

See Cortex for routing controls.

Data Processing Agreement (DPA)

Scrydon publishes a DPA at https://scrydon.com/legal/dpa. For a customer-deployed platform where Scrydon has no access to your data, the DPA primarily covers:

  • The licensing relationship.
  • The support relationship (when Scrydon support engineers help debug, they don't have access to your cluster).
  • The phone-home heartbeat (no personal data flows).
On this page

On this page