Security Whitepaper

Security Whitepaper

Version: 1.0 · Owner: Pocket PMO Ltd · Approval status: Approved · Review date: annually

Executive summary

Pocket PMO is a UK-run, GDPR-aligned SaaS with a defence-in-depth security architecture built on managed cloud infrastructure. Authoritative customer and project state is stored in a managed Postgres database that enforces multi-tenant isolation via Row Level Security. The browser keeps limited preferences, offline state and public-tool use counters; these are not authoritative project records. AI features are approval-first and cannot mutate customer data or communicate externally without a human commit.

Pocket PMO is not certified to SOC 2 or ISO 27001 today; both are on the roadmap. Cyber Essentials is the first certification target. This whitepaper describes the technical and organisational controls that are in place regardless of certification status.

Architecture

Client (browser / PWA) → Managed edge functions (Deno on Supabase) → Managed Postgres (Row Level Security)

• The client is a static SPA delivered from Lovable hosting. Static assets are served over TLS 1.3.
• The client authenticates against the managed auth provider (email/password + optional Google/Apple/SAML).
• Every request against customer data goes through Row Level Security; the JWT identifies the user, RLS policies decide access, and every business table has explicit GRANT statements.
• Edge functions handle side-effects: payment, email, AI, integrations. Server-only secrets live in the platform vault.
• AI requests fan out from edge functions to the Lovable AI Gateway; LOVABLE_API_KEY never leaves the server.

Key controls (technical)

• Tenant isolation: Row Level Security is on for every business table. Access is scoped by organisation membership and role. Roles are held in user_roles and evaluated with a SECURITY DEFINER helper to avoid recursive RLS. Roles are never stored on profiles.
• Authentication and MFA: managed auth provider; email/password (with HIBP check), Google, Apple, SAML SSO on request; TOTP MFA.
• Session policy: 30-minute inactivity timeout with a 5-minute warning banner.
• Rate limits: applied to authentication, public forms, and AI endpoints; recorded in rate_limits.
• Public AI tool boundary: the unauthenticated RAID extractor accepts only visitor-pasted notes, has no customer-data read path or workspace write path, and is protected by input, browser-use and IP limits.
• Encryption: TLS 1.3 in transit; AES-256 at rest at the managed Postgres storage layer.
• Audit trail: audit_logs and per-domain change tables; RLS-restricted to organisation admins and platform admins.
• Approval-first AI: [DRAFT] suggestions are never auto-committed or auto-sent.
• Public forms: separate endpoints, rate-limited, scoped write.
• Webhooks: outbound signed with HMAC-SHA256; inbound (Stripe, Resend) verified by signature.
• API access: JWT + OAuth2 PKCE; scoped API keys with api_usage tracking.

Key controls (operational)

• Migrations are peer-reviewed and executed via the platform's migration tool.
• Secrets are managed in the platform vault and rotated at least every 12 months and on the offboarding of any individual with access (S-02).
• Impersonation by platform admins is logged with a reason (admin_impersonation_sessions).
• Error monitoring via Sentry when enabled.
• Incident response as described in the Incident Response Policy.

Known limitations (published deliberately)

• No SOC 2, ISO 27001 or Cyber Essentials certification at this time; SOC 2 and ISO 27001 are on the roadmap. Cyber and professional-indemnity insurance details are available under NDA.
• No contractual uptime SLA at this time.
• Independent penetration test — owner-confirmation S-01.

References

• Enterprise Architecture Overview (/trust/documents/architecture-overview).
• Sub-Processor Register (/trust/subprocessors).
• Information Security Policy.
• Incident Response Policy.

Owner confirmation required

• S-01, S-02, S-08, H-01, H-02, H-03, A-01, A-02, A-03.

Document history