OizyOS is engineered against ISO 27001 and SOC 2 Type II from the architecture up — multi-tenant isolation at the database layer, immutable audit logging, posture-gated privileged actions, PII encryption at rest. The current state of every control is below, with file paths so you can verify in the source.
Every phase of the platform is built against the ISO 27001 control set. Stage 1 audit-readiness is the next compliance milestone — we maintain control evidence per area below and welcome external review of any control.
Controls map to the SOC 2 Trust Services Criteria (CC6, CC7, C1, AP2). When a customer engagement requires SOC 2 Type II, we can begin a formal observation period without architectural change.
Data minimisation, retention limits, right-to-erasure flows, and tenant-controlled data export are first-class controls. PII scrubbing applies to logs, LLM context, and exports.
Each control area below names the ISO and SOC criteria it maps to, the implementation approach, and the file paths in the codebase that serve as evidence. Welcome to verify any of them under NDA.
Role-based access control with eight tiers (agent → super_admin). Every API route is authenticated via a centralised `withAuth` wrapper that enforces session, role, and security posture before any handler runs.
Tenants are isolated at the database level via Postgres Row Level Security. Tenant context is resolved from subdomain in middleware before the request reaches any handler. Cross-tenant queries are not possible without explicit service-role escalation.
Every mutating action writes to an immutable audit log: actor, action, entity, timestamp, IP address, request ID. Audit-write failures halt the operation rather than continuing silently. PII patterns (email, phone, ID) are scrubbed from log output before serialisation.
Application secrets live in environment variables and the encrypted `connector_configs` table. Service-role keys are isolated to server-side code paths and never exposed to the browser. Magic-link OTP, password reset, and session JWTs are issued by the upstream identity provider (Supabase Auth).
TLS 1.2+ enforced everywhere. HSTS preload, Content Security Policy with origin allowlist (Supabase, Twilio, Anthropic, OpenAI), X-Frame-Options SAMEORIGIN, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy restricting camera and geolocation. CSP currently allows inline scripts/styles — migration to nonce-based CSP is planned.
Every API endpoint validates request bodies with Zod schemas before reaching business logic. Database queries use parameterised statements — never string interpolation. CSV exports and imports are sanitised against formula injection.
Three security postures (SELF_SERVICE, TRUSTED_WORK, BUILDER) govern access to sensitive operations. Elevation to TRUSTED_WORK requires MFA-backed session tokens for sustained access. Privileged operations (PII unlock, data exports) require explicit step-up authentication with a separate token, IP allowlist, and rate-limited unlock window.
PII columns (analyst identities, customer identifiers) are encrypted with AES-256-GCM at rest. Encryption keys are managed via Supabase Vault. Backups inherit the same encryption posture; backup restoration is verified on a schedule.
We can provide the following on request, under NDA: