Security Overview

The technical and organizational measures TheAccessible.org uses to protect customer data and service integrity.

Version
1.0
Published
April 21, 2026
Next review
April 21, 2027
Approved by
Larry Anglin

1. Scope

This page describes the security controls we apply to the operation of the Service. It supplements our Privacy Policy, AI & ML Disclosure, and Data Retention Policy.

It is intentionally practical: we describe what we actually do, not what is theoretically possible.

2. Encryption

  • In transit — TLS 1.2 or higher for all public endpoints. HSTS is enabled. Older TLS versions and weak ciphers are disabled at the edge.
  • At rest — AES-256 for databases (managed by Supabase) and object storage (managed by AWS). Backups are encrypted on the same terms.
  • Secrets in transit between services — service-to-service calls use TLS plus a shared secret header; see also §5.

3. Access control

  • Production access is restricted to named personnel via SSO with MFA required. Credentials that grant production access are provisioned from a central identity provider and revoked on role change or departure.
  • Database access uses Supabase's Row Level Security where applicable; the service-role key is confined to server-side code and never exposed to browsers.
  • Least privilege is applied to IAM roles, API tokens, and third-party keys. Tokens that don't need write access are scoped to read only.
  • Access reviews are performed periodically and after material personnel changes.

4. Network security

  • Edge protection — Cloudflare provides DDoS mitigation and rate-limiting in front of our public endpoints.
  • Segmentation — the API is deployed behind AWS API Gateway with request validation. Internal-only endpoints (/internal/*) require a shared secret or admin auth and are not routable from the public internet without one of those credentials.
  • CORS is configured to specific origins in production, not wildcard.

5. Secrets management

  • Canonical store — AWS Systems Manager Parameter Store (SecureString). Lambda loads secrets at cold start; no secrets are committed to the repo.
  • Rotation — rotation automation is in place for credentials that support it. Rotating secrets that are sensitive long-term (e.g., audit hash salts) is deliberately excluded — rotating them would break downstream integrity properties.
  • Scope separation — single-purpose tokens (e.g., the account-restore token) are signed with a secret distinct from the Supabase JWT secret so a leaked restore token cannot be used as a session token.

6. Application security

  • Dependency management — Dependabot scans weekly; npm audit runs in CI; critical and high advisories block merge unless explicitly documented.
  • Input validation at the API boundary. Parameterized database queries only; no string-concatenated SQL.
  • Sandboxing of untrusted input — document rendering and AI-assisted processing run in isolated execution contexts; untrusted content is not trusted to produce HTML for the browser.
  • SDLC — every change is reviewed via pull request. Tests (unit, coverage, lint, typecheck) must pass before merge.

7. Monitoring and logging

  • Structured logs — the service emits JSON-structured log records (service, requestId, userId, path, etc.) via the shared logger package.
  • Aggregation — logs flow to Grafana Loki; dashboards and alerts are provisioned centrally.
  • Alerting — high error rates, fatal events, and missing heartbeats page the on-call engineer. Email alerts via Resend are additionally sent for service-down conditions.
  • Log retention follows our Data Retention Policy.

8. Change management

  • Infrastructure changes go through pull requests and CI like application code. Destructive actions (secret rotation, DB migrations) are logged and documented.
  • Migrations are applied through a reviewed process and recorded in version control. Schema changes that affect personal-data tables are flagged for an extra review.

9. Personnel

  • Production access is granted only to personnel with a current need.
  • Employees and contractors are bound to confidentiality obligations as a condition of access.

10. Physical security

Our infrastructure runs on AWS, Cloudflare, and Supabase. Physical security of data centers is the responsibility of those providers, each of which maintains SOC 2 and ISO 27001 attestations. We do not operate our own data centers.

11. Business continuity

  • Backups — Supabase performs automated daily database backups; AWS S3 provides durable object storage. Our retention schedule for backups is described in the Data Retention Policy.
  • Recovery — we test restores periodically. Recovery procedures are documented internally.
  • Multi-AZ — AWS services we rely on are deployed across multiple availability zones in their default configurations.

12. Compliance and assurance

  • Accessibility — WCAG 2.2 Level AA for our own interfaces. See the Accessibility Statement.
  • Privacy — GDPR, UK GDPR, CCPA/CPRA. See the Privacy Policy and DSAR Procedure.
  • Subprocessors — listed at Subprocessors with signed DPAs in place.
  • Formal attestations — We do not currently hold SOC 2 or ISO 27001 certification. A SOC 2 Type I audit is planned for July 1, 2026, with Type II to follow. Procurement teams that need interim assurance can request our security questionnaire responses (CAIQ / SIG-lite) from legal@theaccessible.org.

13. Reporting security issues

Please report vulnerabilities through our Vulnerability Disclosure Policy. We do not pursue legal action against researchers acting in good faith within the scope described there.

Urgent reports: security@theaccessible.org.

14. Incident response

In the event of a confirmed personal-data breach, we notify affected customers per our Breach Notification Policy — without undue delay and in any event within 72 hours of confirmation.

15. Changes to this document

We will update this page as our controls evolve. The effective date appears at the top of this page. Prior versions remain available from the version history link below.

16. Contact