Governing policy · POL-01

Information Security Policy

Version 1.0 · effective 13 July 2026 · owner: Jonny Allum

OwnerJonny Allum (Security Lead)
Version1.0 · Effective 13/07/2026 · Review annually (July)
Applies toJonnyAI agency, BizOS platform, HubSuite, JAIOS, all devices and accounts used for the business

1. Objective

Protect the confidentiality, integrity and availability of customer data and business systems, with controls proportionate to a sole-operator SaaS business whose tenants include regulated care, compliance and financial workloads.

2. Principles

  1. Least privilege by construction. Multi-tenancy is enforced in the database, not the app: every tenant table carries row-level security (RLS), portal roles (contractor/tenant/client) are enforced at page, action and database level, and service-role keys never reach the browser.
  2. Public surfaces trust nothing. Public write paths (quote acceptance, storefront checkout, booking) re-resolve prices server-side, enforce caps and rate limits, and use possession-based tokens. GET requests never mutate.
  3. Defence in depth over heroics. Secret-guarded cron endpoints, webhook signature verification (Stripe), confirm-steps on AI actions, immutable audit trails (C05) — controls that hold even when the operator is asleep.
  4. Secure by default in development. Local dev runs against file-backed stores with no production credentials; production credentials exist only in the VM environment and the password manager (SOP-09).

3. Scope of assets

  • Production: the GCP VM (PM2 + Caddy + Let's Encrypt, static IP), the Supabase project (data, auth, RLS), Stripe, Resend, Anthropic API, DNS/domains (jonnyai.co.uk and client domains).
  • Source: the jonnyallum GitHub account and its repositories (biz-os and product/client repos).
  • Endpoints: the operator's workstation and phone.
  • Data: tenant business data (including special category data for care tenants — see POL-02), platform billing data, prospect/CRM data, secrets.

4. Mandatory controls

AreaControl
AuthenticationMFA on GitHub, Google Cloud, Supabase, Stripe, Resend, Anthropic, domain registrar. Unique passwords from a password manager.
Product authSupabase Auth with middleware session refresh; BIZOS_AUTH_ENABLED on in production; passwords 8+ chars minimum.
Tenant isolationPer-tenant RLS on every table; no exceptions. A table without RLS does not ship (SOP-04).
TransportTLS everywhere (Let's Encrypt via Caddy); no plain-HTTP services.
SecretsNever in the repo, never in remote URLs, never in tickets or chat. Managed per SOP-09.
EndpointsFull-disk encryption, OS auto-update, screen lock. No tenant data stored locally beyond transient dev fixtures.
PaymentsCard data is entered only on Stripe-hosted surfaces; BizOS stores references, never PANs.
EmailSPF/DKIM/DMARC on sending domains (Resend).
AuditrecordEvent event bus writes C05 audit entries for cross-module actions; sign-offs and approval trails are append-only.

5. Prohibited

  • Disabling or bypassing RLS "temporarily".
  • Committing secrets or tokens, or embedding them in git remotes.
  • Testing against production tenant data without a specific, logged reason.
  • Direct production database edits outside a numbered migration or a logged, ticketed support action (SOP-07).
  • Calling real HMRC endpoints from any tax module (see POL-05 §6).

6. Review and enforcement

Breaches of this policy by the operator are recorded in the risk register (POL-11) with the corrective action taken — a one-person business still keeps the evidence trail an acquirer, insurer or enterprise customer will ask for. Security incidents are handled under POL-08 / SOP-05.

← All documents & policiesQuestions? hello@jonnyai.co.uk