Security & Compliance

Security and GDPR compliance you can verify

obqo is built for European educational institutions. Privacy and data sovereignty aren't a feature — they're the foundation.

Data residency

All customer data is stored in the EU (Frankfurt, Germany) via Supabase EU

No data ever leaves Europe

Backups and replication within the same EU region

Encryption in transit

All connections between your browser, obqo application servers (Vercel, fra1 Frankfurt), and the database (Supabase Frankfurt) use TLS 1.2 or higher

Plaintext HTTP is rejected — all traffic is redirected to HTTPS

Internal service-to-service calls (application → database, application → email API) are encrypted over TLS

Encryption at rest

All data at rest is encrypted using AES-256 by Supabase (underlying AWS RDS and S3)

Encryption is applied at the database, backup, and object-storage layer by default — no per-tenant configuration required

Encryption keys are managed by Supabase's Key Management Service; Van Moose does not hold root encryption keys

Storage volumes for the application layer (Vercel) contain no persistent customer data — all state lives in the encrypted Supabase database

Authentication

SURFconext SSO (SAML) for Dutch institutions

Magic-link authentication as fallback — no passwords stored in obqo

Authentication: Supabase Auth (EU, Frankfurt). Google + Microsoft OAuth, magic-link / one-time code, and per-tenant SURFconext SAML SSO; MFA via the institution IdP

Role-based access control with 5 permission levels (Coach, Flow Builder, Admin, Billing Admin, Owner)

Tenant isolation via host-based routing + scoped database queries; cross-tenant lookups blocked in code review

Row Level Security on all 30 obqo_* tables (audit 2026-04-29: 30/30)

No inbox access

obqo supports coaching workflows without delegated access to mail or calendar:

No delegated access to mailboxes or calendars

No scanning of inboxes, contacts or files

No integration with student email or personal accounts

AI data handling

AI features (session summaries, flow suggestions, congratulations-email drafts, alumni-pulse parsing) use Anthropic's Claude API. Optional session-recording uses OpenAI Whisper for transcription. Both providers are US-based; doorgifte happens under EU SCC + DPF.

AI is off by default for new tenants — Organization.settings.featureFlags.aiEnabled must be explicitly set true

A single per-tenant gate (lib/feature-flags.ts) protects every OpenAI/Anthropic callsite — 9 in total, asserted by automated tests on every release

No student data is used for model training (contractual with Anthropic and OpenAI)

AI requests are stateless — no conversation history is retained by the provider

When AI is enabled, full session transcripts are sent to Claude for summarisation; recording-audio is sent to Whisper for transcription, then the audio is deleted from storage immediately on success

Session recording is protected by four sequential consent gates: (1) tenant admin must explicitly enable recording in Organisation settings; (2) coach must opt in for their own sessions; (3) student receives an explicit consent prompt before each recorded session and recording does not start until confirmed; (4) student can withdraw consent at any time, triggering immediate deletion of the audio and transcript

Session-type enum is neutral (PRIORITY, not CRISIS) — no health implication is recorded structurally

For the UvA tenant both flags are off; no obqo customer data reaches Anthropic or OpenAI

Alumni opt-out and unsubscribe

Every outbound alumni mail carries a universal opt-out footer and RFC 8058 one-click headers, so the unsubscribe button in Gmail and Outlook resolves the request without any further interaction.

Three self-service links on every mail: "Fewer emails" (channel-specific), "Unsubscribe" (kill switch), "Delete my data" (triggers soft-delete and the deletion grace window)

List-Unsubscribe + List-Unsubscribe-Post: List-Unsubscribe=One-Click headers on every alumni mail

Token-gated endpoint /api/alumni/unsubscribe — HMAC-signed, idempotent, audit-logged

Per-channel opt-out (career signals only) and tenant-wide kill switch (all emails off) tracked separately in AlumniConsent

Privacy contact for alumni surfaced in every outbound mail footer, alongside the institution's own alumni privacy statement

Yearly re-consent

Once a year — start of the academic year — alumni receive an explicit re-consent mail asking whether they still want to be registered. Three response options drive the next year's communication.

Cron /api/cron/alumni-reconsent at 1 September 09:00 UTC

Three signed-token replies: keep registered · fewer emails · delete me

No response after the cycle = status quo; next year asked again. No implicit deletion without an explicit request.

Replies update AlumniConsent.lastReconsentAt + reconsentResponse for auditability

Audit logging

All access to student personal data produces an immutable audit record. Logs are stored in the same EU (Frankfurt) region as primary data and are available to the institution's DPO on request.

Every read, write and delete of student coaching data is audit-logged with actor identity, timestamp, and resource ID

Role changes, invitation events, and bulk exports are logged separately

Cross-tenant access by platform administrators is logged with an additional warning entry and deduplicated hourly audit notifications

Audit logs retained for 12 months for security investigation and breach notification purposes

Log entries are append-only; no editing or deletion of log records is possible through the application layer

Subprocessors

Direct subprocessors engaged in delivering obqo. DPA Bijlage C of the tenant's processor agreement is the authoritative version of this list.

Service	Purpose	Region	Transfer basis	Certifications
Supabase Inc.	Database, storage & authentication	Frankfurt, Germany (EU)	Within EER; EU SCC Module 2 for exceptional support access	SOC 2 Type II
Vercel Inc.	Application hosting	EU edge, fra1 Frankfurt (Vercel entity US-domiciled)	EU SCC + DPF for incidental US control-plane access	SOC 2 Type II, ISO 27001
Van Moose (Truncus)	Transactional email (internal subprocessor)	AWS eu-west-1 (Ireland)	Within EER	—
Amazon Web Services EMEA SARL	Underlying SES infrastructure for Truncus	eu-west-1 (Ireland)	Within EER; AWS GDPR DPA via Service Terms	ISO 27001, ISO 27017, SOC 2 Type II
Anthropic PBC (Claude)	AI features — disabled by default	United States	EU SCC + DPF; engaged only when tenant explicitly enables AI features (off for UvA)	SOC 2 Type II
OpenAI LLC (Whisper)	Session-recording transcription — disabled by default	United States	EU SCC + DPF; engaged only when tenant explicitly enables session recording (off for UvA)	SOC 2 Type II

All subprocessors above have signed a Data Processing Agreement with Van Moose. Signed DPAs are available to the institution's DPO on request via info@obqo.co.

Sub-subprocessors via Supabase

Supabase, in turn, engages the following sub-subprocessors for delivering its service to obqo. The complete list lives in Schedule 3 of the Supabase Data Processing Addendum.

Service	Purpose	Notes
Amazon Web Services Inc.	Hosting infrastructure for Supabase databases	EU region for UvA tenant
Cloudflare Inc.	Hosting / CDN services	EU edge for UvA tenant
Sentry (Functional Software Inc.)	Error monitoring and tracing	Anonymised error reports only
OpenAI LLC	Supabase-internal dashboard AI features only	No obqo customer data reaches OpenAI through this path

Email delivery infrastructure

obqo runs on Truncus, our own EU-native email infrastructure. Every student invitation, mentor notification, and reminder is delivered via AWS SES eu-west-1, with synchronous delivery confirmation (send_sync) and built-in DMARC monitoring on incoming aggregate reports. No third-party email vendors. No data leaving the EU.

Delivery + bounce events written to obqo’s database in real time — no waiting on third-party webhooks

Sender reputation isolated per traffic type (transactional invites stay separate from any outreach)

DMARC aggregate reports from Gmail, Yahoo, Outlook ingested by Truncus directly — not forwarded to a US-based deliverability vendor

All sender domains under EU SES, all storage in Supabase Frankfurt

Data retention

Personal data is retained no longer than necessary for the documented purpose, in accordance with GDPR Article 5(1)(e). The processor agreement's Bijlage D is the authoritative source for per-category retention windows; the controller (university) sets them.

Coaching session notes: 3 years from graduation or early programme exit; afterwards the notes field is cleared and only aggregated metadata (date, type, duration, format) remains for accreditation

Alumni records: 10 years from graduation or early exit; afterwards the PII fields (name, email, exact employer, LinkedIn URL) are cleared

Aggregate-preserving retention strategy: when alumni PII is cleared, the child rows (CareerOutcome, JobApplication, NetworkingContact) keep their non-personal columns (company, role, industry, country, date) so cohort-level and employer-level reporting continues indefinitely

Session recordings: audio is deleted from storage immediately after Whisper transcription succeeds; transcripts retained 1 year, or earlier on revocation of consent — not applicable for tenants with recording disabled (UvA)

Audit logs: 12 months for security and breach investigation

After contract termination: 90-day export window (CSV/JSON via /api/orgs/[id]/export), then Supabase removes the data within its own 30-day retention regime

Automated weekly retention sweep (/api/cron/retention-sweep) enforces the windows per tenant; opt-in per organisation while the controller finalises Bijlage D values

Right to erasure per GDPR Article 17 honoured at any time — soft-delete + 30-day recovery, then hard-delete

Cookies & tracking

Only functional cookies for authentication

No advertising cookies

No third-party analytics

No cross-site tracking

Rate limiting

All API endpoints are rate-limited per authenticated user and per IP address

Authentication endpoints (sign-in, invitation acceptance) apply stricter per-IP limits to prevent brute-force attacks

Rate-limit state is stored in an EU-hosted Redis instance; if Redis is unavailable, requests are allowed through rather than blocking legitimate users (fail-open)

Secret scanning & supply-chain controls

Every commit is scanned for secrets (API keys, database credentials, signing tokens) by gitleaks before it reaches the repository — a failed scan blocks the push

Live credentials never appear in source code or build artefacts; secrets are injected via Vercel environment variables at build time

Dependencies are pinned and audited; security advisories trigger an immediate patch cycle

All production deployments go through Vercel's signed deployment pipeline — no direct server access for code changes

Availability

Availability target: 99.5% uptime (documented in the service agreement)

Maintenance windows: 48-hour advance notice for planned maintenance

Status notifications for unplanned disruptions

Incident reporting

Report security incidents to info@obqo.co

Response time: acknowledgement within 24 hours.

IB&P classification

obqo meets the IB&P LOW/LOW/LOW classification for availability, integrity and confidentiality. This means the platform is suitable for processing non-sensitive personal data in higher education.

Procurement documentation

The following documentation is available on request:

Data Processing Agreement (DPA), aligned with the SURF model processor agreement
Subprocessor list with regions and DPA status
Security overview and description of controls
Retention and deletion policy
Accessibility statement (WCAG 2.1 AA)

Requests: info@obqo.co

Request the procurement pack

Get a complete bundle: DPA, subprocessor list, security overview, retention policy and accessibility statement.

Request documentation