GBOS

REVIEW-READY DRAFT — GBOS-specific and factual, but NOT final and NOT legal advice. Must be confirmed by a qualified solicitor before GBOS relies on it (see the [SOLICITOR TO CONFIRM] items).

Security Schedule (Annex II — Technical & Organisational Measures)

Version 2026-08-r1 · Effective 2026-08-02

The technical and organisational security measures GBOS implements (Art. 32).

1. Tenant isolation

Tenancy is enforced in the application (every query scoped to the session-derived tenant) AND independently at the database layer using PostgreSQL row-level security with FORCE ROW LEVEL SECURITY, run under a non-superuser, non-BYPASSRLS role. If the tenant context is missing the policy matches no rows (fail-closed) rather than leaking data. Coverage and the restricted-role denial behaviour are proven by automated tests against real PostgreSQL.

2. Audit integrity

The governance audit stream is a per-tenant, tamper-evident hash chain using HMAC-SHA256 with an owner-provisioned key, so a rewritten history cannot be re-signed without the secret. At the database, audit events are append-only under row-level security (SELECT/INSERT only for the application role; no UPDATE/DELETE), proven against real PostgreSQL.

3. Authentication and access

Authentication is provided by Better Auth: hashed passwords, mandatory email verification in production, optional MFA (TOTP + backup codes), and password reset. Sensitive financial approvals require a server-verified second factor (step-up) that fails closed; a client-supplied claim is never trusted. Governed actions enforce approvals and segregation of duties.

4. Encryption

Encryption in transit is enforced (TLS; HSTS with a long max-age and preload). Encryption at rest is provided by the hosting and database providers. An application-level secret vault using AES-256-GCM envelope encryption exists as a seam for provider credentials; the external KMS integration is present as a clearly-marked seam and requires owner activation before production use of that path.

5. Network and application hardening

Strict security response headers are served (Content-Security-Policy, HSTS, X-Frame-Options: DENY, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP). Authentication and other sensitive endpoints are rate-limited per IP+endpoint. A known limitation is that CSP retains ‘unsafe-inline’ for scripts/styles pending a nonce rollout (tracked internally).

6. Secure development and supply chain

CI runs unit and real-database integration tests, migration up/down verification, a server-action export guard, an RLS-coverage guard, static security linting (SAST) and dependency vulnerability scanning on every change. Dependency advisories are tracked in a disposition register.

7. Data-subject tooling

GBOS provides governed, audited data export (tenant self-service) and a governed account-deletion process (grace period, explicit confirmation, tenant-scoped sweep, workspace anonymisation, retained deletion record).

8. Organisational measures (owner to complete)

Personnel confidentiality, access governance, incident-response runbook, vendor due diligence, and backup/restore rehearsal. [SOLICITOR TO CONFIRM] which of these are contractually committed. Several organisational measures are owner actions to finalise before relying on this schedule externally.

Clauses a solicitor must confirm

The following points in this document require qualified legal sign-off before GBOS relies on it.

  • That this schedule adequately evidences Art. 32 “appropriate” measures for the DPA.
  • Which measures are contractually committed vs described as current practice (avoid over-committing to controls that are still seams, e.g. external KMS).

This document is a GBOS-specific, review-ready draft. It is not final and does not constitute legal advice; it must be confirmed by a qualified solicitor (see the clauses flagged above) before GBOS relies on it.