betool betool

Documentation

GDPR audit & access log

How betool traces access to user content, handles the right of access (Article 15) and the right to erasure (Article 17).

GDPR audit & access log

betool is built to meet GDPR requirements without bolted-on compliance: every access to user content by an agent belonging to another organisation is logged, and every organisation can consult its own log.

The access log

A dedicated table records, for each cross-tenant access:

  • The timestamp (microsecond precision)
  • The target org (whose content was read)
  • The reading org (typically the vendor)
  • The role / agent / user that performed the read
  • The entity type (closed vocabulary: exchange_text, knowledge_chunk, audio_segment…)
  • The entity ID
  • The usage context (mission, ticket, proposal)

The entity vocabulary is closed at the database level (CHECK constraint) and closed at the code level (application whitelist). Adding a type requires a new migration plus whitelist update. No surprise entries.

Right of access (Article 15)

Each organisation can consult ITS OWN access logs via:

GET /api/admin/me/content-reads

Available filters: time range, entity type, entity ID, reading identity. CSV / Excel export for sharing with a data protection officer.

No cross-org access on the audit log: the vendor never sees a customer's audit logs.

Right to erasure (Article 17)

Three levels of erasure are supported:

  1. User erasure — an end-user requests the deletion of their data within a customer organisation. The organisation triggers the erasure via the admin panel or the admin API.
  2. Organisation erasure — an organisation leaves betool. All its resources are deleted: tables filtered by org_id, file storage purged, secrets removed. Default contractual window: 30 days for retraction, then irreversible purge.
  3. Legal erasure — on court order, deletion of specific items without touching the rest. Logged in the audit trail with a reference to the legal basis.

Cross-tenant read opt-in & opt-out

By default, the cross-tenant read opt-in is set to FALSE. An organisation can enable it under Administration → Privacy → Cross-tenant read.

Three modes:

  • Full refusal — default. The vendor cannot access any content from this org. Consequence: no cross-org content-level support is possible (structural support and business flags remain available).
  • Temporary opt-in — authorisation for a fixed time window, revocable.
  • Permanent opt-in — for customers who want proactive support (rare in banking, common in standard SaaS).

The vendor CANNOT activate this opt-in on behalf of the customer. This is a fundamental test: if the vendor can toggle without a customer action, the architecture is broken.

Destructive-ops guardrail

Any operation that destroys or replaces content (DELETE, REPLACE-IN-PLACE) is refused at the validator if the target org has not activated the read opt-in. Rationale: without visibility, the operator would be proposing a payload that could blindly overwrite existing content.

Cascading denial if audit is unavailable

If the audit database is unavailable (infrastructure incident), all cross-tenant reads are refused. Strict policy: no read without a trace.

Code-side consequence: a caller that catches an exception must re-raise the audit error before any business processing. This is an invariant verified by the security benchmark.

On the marketing site and chat widget, only strictly necessary cookies are set. No third-party analytics cookies without a compliant consent banner.