Skip to main content

Security & Compliance Foundations

0. Purpose​

This document defines Evalium’s security and compliance baseline for backend development:

  • Security baseline: OWASP ASVS Level 2 (target posture for the whole backend).
  • Privacy baseline: GDPR / UK GDPR “data protection by design and default” and “security of processing”. Article 25 and Article 32 set expectations for technical + organisational measures. (Legislation.gov.uk)
  • Future certification readiness: capture artefacts and evidence that support an eventual ISO/IEC 27001 ISMS (and optionally ISO/IEC 27701 for privacy management). (ISO)

This is a living standard: every backend feature should link back to the relevant sections below (controls + tests + logs + documentation).

1. Non-Negotiable Architectural Security Invariants​

These are “foundational controls” that support ASVS L2 now and keep you L3-ready where needed.

1.1 Database is the security boundary (tenant + org isolation)​

  • All requests follow: Auth → Scope middleware → TxManager → RLS.
  • TxManager injects tenant/org scope with SET LOCAL only; never SET SESSION to avoid connection-pool scope leaks.
  • RLS is mandatory and enforced at connection level (row_security = on).
  • Siloed tables must include tenant_id, org_unit_id, RLS policies, and indexes.

Evidence present

  • Explicit RLS + TxManager design and “developer checklist” is documented.
  • Changelog notes full RLS tenant + org siloing and removal of app-level org filters (“RLS is primary enforcer”).

1.2 Auth is required everywhere (no bypass)​

  • All /api/v1/** routes require a valid session cookie; only /auth/login, /auth/verify, /health are public.
  • No dev bypass; tests mint real cookie sessions via scripts.

1.3 Authorisation is capability-based (never hard-coded roles)​

  • Session claims contain roleIds, not capabilities; capability lookup is server-side.
  • Route → capability matrix is defined and enforced.

1.4 Immutable versioning + snapshots protect integrity (high-stakes alignment)​

  • Questions/evaluations are versioned and immutable; submissions freeze a version_snapshot.
  • Results remediation is append-only with score version history and idempotent apply/revert.

2. ASVS Level 2 Mapping​

Goal: ASVS L2 as the backend “definition of done”. (We don’t restate ASVS line-by-line here; we map the major control areas to Evalium’s design and the evidence you require per feature.)

2.1 Authentication & Session Management​

Current controls

  • Magic-link login endpoints and cookie sessions are in place.
  • Sessions are minimal by design; capabilities are resolved server-side.

Required evidence per feature

  • Tests proving unauthenticated access is rejected on /api/v1/** and that public endpoints remain only /auth/login, /auth/verify, /health.

Key gaps to track

  • Rate limiting / abuse protection for auth endpoints (brute force and token spraying).
  • Token replay hardening: confirm tokens are stored hashed, single-use enforced, expiry enforced, and enumeration-safe responses (you have “single-use tokens” referenced—ensure implementation + tests demonstrate it).

2.2 Access Control (AuthZ) & Tenant Isolation​

Current controls

  • Capability gating is implemented broadly and documented as a rule (“no hardcoded role checks”).
  • Multi-tenant + multi-org isolation is enforced via TxManager + RLS policies.

Required evidence per feature

  • For each handler/service: tests proving no cross-tenant and no cross-org access by ID (including “list endpoints”, not just detail endpoints).
  • “Fail closed” behaviour when scope is missing/invalid (RLS should deny).

Key gaps to track

  • Property-level authorisation (“excessive data exposure”) in API responses: ensure DTOs never include PII beyond role/capability intent (especially for reporting and public verification).

2.3 Input Validation & API Hardening​

Current controls

  • Backend-first discipline and “prohibited patterns” are explicitly documented (helps stop handler-level security drift).

Required evidence per feature

  • Explicit request validation (type/range/enum) with consistent error responses.
  • Reject unexpected fields where it matters (prevents “mass assignment” style issues).

Key gaps to track

  • Standardise validation + error schemas across handlers (so security testing is consistent).

2.4 Cryptography, Secrets, and Secure Configuration​

Current controls

  • Server fails fast if SESSION_SECRET missing for web sessions (and JWT_SECRET remains required for assignment tokens).

Required evidence per feature

  • No secrets in logs; no secrets in repo; config documented.
  • TLS assumptions documented for production (reverse proxy / ingress).

Key gaps to track

  • Document your key management approach early (rotation strategy, environments, breach handling).

2.5 Logging, Auditability, and Monitoring​

Current controls

  • Audit logging exists (roles changes, auth failures, magic link flows).
  • High-stakes flows have integrity-friendly structures: remediation ledger and programme snapshots.

Required evidence per feature

  • “Security-significant events” must emit audit logs with correlation identifiers.
  • Logs must avoid sensitive payloads.

Key gaps to track

  • Audit event taxonomy is defined in docs/security/operational-audit-taxonomy.md; expand coverage to new high-stakes flows.
  • Retention and export strategy (ties into GDPR + ISO later).
  • Ensure privacy/compliance flows emit ledger + audit entries with correlation IDs; compliance API now lives at /api/v1/compliance (requires privacy.manage), user DELETE triggers soft-delete + privacy job (anonymize_user) and ledger entry; privacy worker also handles dsar_export jobs (artifact refs TBD).
  • Ledger event taxonomy is tracked in docs/security/compliance-ledger-taxonomy.md (current vs required events); new high-stakes flows must emit the appropriate event.
  • Retention/anonymization policy is drafted in docs/security/data-retention-policy.md; implement retention worker + deleted_at where missing.

3. GDPR / UK GDPR “By Design” Checklist​

GDPR expects technical + organisational measures, especially:

3.1 Decisions you should lock in now (foundational)​

  1. Data minimisation defaults (Article 25): store only what you need for assessment delivery, integrity, and reporting. (Legislation.gov.uk)
  2. Retention + deletion mechanics: define retention windows per data type (sessions, telemetry, submissions, audit logs) and implement deletion/anonymisation pathways early (this is painful to retrofit).
  3. Logging hygiene: ensure audit and app logs are designed to avoid PII leakage while still providing accountability. (Article 32 risk-based security; ICO guidance emphasises “appropriate measures”.) (Legislation.gov.uk)

3.2 “Organisational” processes to draft early (lightweight)​

  • DSAR handling (access/export/deletion requests)
  • Incident response and breach notification workflow
  • Vendor/sub-processor inventory (hosting, email, telemetry/analytics) ICO guidance explicitly frames “by design/default” as an accountability practice you must be able to demonstrate. (ICO)

4. ISO 27001 Readiness​

ISO/IEC 27001 is an ISMS standard (management system + evidence), not just a code checklist. (ISO) You will need both:

  • Process evidence (risk management, policies, training, supplier controls, incident response), and
  • Technical evidence (secure development practices, access control, monitoring, vulnerability management).

4.1 “Build the evidence as you build the product”​

Start capturing the following now, because they become expensive if you backfill later:

A) ISMS core artefacts

  • Scope statement (what systems, environments, and data are covered)
  • Risk register (top threats + mitigations)
  • Asset inventory (data stores, services, keys, logs, backups)
  • Supplier register (hosting, email provider, etc.)

B) Secure development artefacts (code + process) ISO 27001:2022 Annex A includes controls around secure development lifecycle; summaries often reference A.8.25 Secure development life cycle and adjacent development controls. (dataguard.com) Practical evidence you can generate “for free” from your existing discipline:

  • ADRs for security-sensitive design choices (you already do this)
  • CI outputs: tests, race checks, dependency checks
  • Change log + release notes (you already maintain CHANGELOG.md).

4.2 ISO 27701 as the privacy counterpart (optional later)​

ISO/IEC 27701:2025 is positioned as a privacy information management system standard (PIMS). (ISO) If you later want a standards track for privacy alongside 27001, it’s worth considering once you’ve stabilised GDPR processes.

5. “High-Stakes Surfaces” that should be L3-Ready by Design​

Even if you certify/claim Level 2 as your overall posture, these areas should be designed to support higher assurance:

  • Certificate verification endpoint (public trust surface).
  • Results remediation apply/revert (high integrity + high blast radius).
  • Lockdown/security_config enforcement & probe (delivery integrity).
  • Telemetry / proctoring evidence (privacy + integrity).

6. Immediate Gap List​

Based on current docs and changelog, the “highest ROI” gaps to address early:

  1. Rate limiting / abuse controls for /auth/login, /auth/verify, and other high-value endpoints.
  2. Privacy/retention model: define and implement retention/deletion/anonymisation policies (Article 25 “default” and Article 32 risk-based security). (Legislation.gov.uk)
  3. Audit taxonomy: standard event types + correlation IDs + “no PII in logs” rules; ensure coverage for high-stakes flows (cert issuance/verify, remediation apply/revert).
  4. Public verification data minimisation: ensure /certs/verify/\{token\} only returns what a verifier truly needs (avoid accidental personal data exposure).