Security & Governance

Security built into
the database layer.

YBNW One's security model does not rely on application-level guards that can be misconfigured or bypassed. Data isolation, access control, and audit logging are enforced at the PostgreSQL level — the lowest layer possible.

172RLS-protected tables
795named permissions
12predefined roles
AES-256encryption at rest

Multi-Tenant Isolation

Row-Level Security: isolation that cannot be bypassed.

Every table in the YBNW One database has a Row-Level Security policy filtering all data by workspace_id. This runs at the PostgreSQL execution layer — not in application code.

How RLS Works

Every table carries a workspace_id column. RLS policies are defined in PostgreSQL using CREATE POLICY statements. When a query runs, PostgreSQL automatically appends WHERE workspace_id = current_workspace_id() to every SELECT, INSERT, UPDATE, and DELETE. The application layer cannot override this — it executes before the application sees any rows.

Why App-Level Guards Are Not Enough

Application-level data filtering can be bypassed by bugs, misconfigured middleware, or direct database access. RLS policies cannot be bypassed by application code — they are enforced by the database engine regardless of how the query reaches the database. Even a query with no workspace filter gets the policy applied automatically.

172 Tables, All Protected

All 172 database tables across 188 migration files have RLS enabled. This covers every operational table (projects, invoices, employees, contacts, risks, audits, documents) and every junction and audit table. No table in the system is accessible without a valid workspace context.

Service Role Separation

Distinct database roles: anon (unauthenticated, no data access), authenticated (full RLS enforcement), and service_role (Edge Functions only, for specific server-side operations like webhook processing). Service role usage is audited and minimised to operations that structurally require it.

Access Control

795 named permissions. 12 predefined roles.

Every action maps to a named permission constant. Roles are collections of permissions. Nothing is accessible by default.

The 12 predefined roles

Administrator
Full access to all modules and settings. Manages users, roles, permissions, and workspace configuration. Only role that can modify other users' permissions.
Manager
Approval workflows (leave, expenses, POs), project oversight, department-level reporting. Cannot access payroll or HR sensitive records.
Finance Manager
Full access to invoices, budgets, GL, AP/AR, payroll visibility (not execution), cash flow, P&L, tax. Permissions: VIEW_ALL_INVOICES, MANAGE_BUDGETS, VIEW_FINANCIAL_REPORTS.
HR Manager
Employee records, recruitment, leave management, payroll execution, performance reviews, training. Permissions: MANAGE_EMPLOYEE_RECORDS, MANAGE_PAYROLL, MANAGE_RECRUITMENT.
Project Manager
All project modules: projects, tasks, milestones, resource planning, WBS, sprints, risk register. Can view project-level financial data. Cannot access payroll or HR.
Compliance Officer
Compliance tracker, internal audit, risk management, GDPR tools, whistleblowing cases, ESG reporting. Permissions: MANAGE_COMPLIANCE, MANAGE_AUDITS.
Team Lead
Manages tasks and projects within their team. Approves team leave and small expenses. Views team performance data. Subset of Manager permissions scoped to direct reports.
Employee
Submit expenses, request leave, log time, manage personal tasks, access permitted document cabinets, view assigned projects, use the knowledge base.
Contractor
Limited access to assigned projects and tasks only. Cannot view employee records, financial data, or HR information. Access automatically scoped to explicitly assigned items.
Support Agent
CRM contacts, support tickets, and knowledge base only. Permissions: MANAGE_SUPPORT_TICKETS, VIEW_CRM_CONTACTS. No financial, HR, or project access.
Viewer
Read-only access to non-sensitive modules: project status, permitted document cabinets, shared reports, knowledge base. Cannot submit, approve, or modify any record.
Custom Role
Administrators create custom roles by selecting any combination of the 795 named permissions. For specialist functions (Payroll Only, Audit Read-Only, CRM + Finance) that don't map to predefined roles.

Three-layer permission enforcement

Layer 1: Frontend

ProtectedRoute component wraps every route. Evaluates hasPermission(requiredPermission) against current user's role. Redirects to dashboard if check fails — the restricted page does not render at all.

Layer 2: API

Supabase Edge Functions validate the authenticated user's role before executing business logic. Server-side check is independent of the frontend — bypassing the UI does not grant API access.

Layer 3: Database

RLS is the final layer. Even if both frontend and API checks were bypassed (which cannot occur in normal operation), PostgreSQL still enforces workspace-level isolation at the query level.

Encryption

Data encrypted in transit and at rest.

In Transit: TLS 1.3

All browser-to-platform communication uses TLS 1.3. HTTPS enforced everywhere — no unencrypted HTTP connections permitted. HSTS headers prevent protocol downgrade attacks. Certificate managed and auto-renewed via Vercel's edge network.

At Rest: AES-256

All data stored in Supabase PostgreSQL is encrypted at rest using AES-256. Storage-level encryption managed by Supabase infrastructure on AWS, with AWS KMS for key management.

Sensitive Field Encryption

Specific PII and financial credential fields are encrypted at column level using pgcrypto before storage: employee bank details, vendor bank details, employee NI number, employee date of birth. Decrypted only when retrieved by an authenticated user with the required permission.

File Storage Encryption

Documents, receipts, CVs, contracts, and uploaded files stored in Supabase Storage with server-side AES-256 encryption. File access requires a signed URL generated by an authenticated API call — files are not accessible directly by URL without authentication. Signed URLs expire after a configurable window.

API Key Separation

Supabase anon key (safe to expose in frontend, restricted by RLS) and service role key (server-side only, never exposed to browser, injected as environment variable at Edge Function runtime — never in code) are strictly separated.

Stripe Payment Security

No card data ever touches the YBNW One platform — all payment data handled exclusively by Stripe. Stripe webhook payloads are verified using the Stripe-Signature header and a signing secret before any payload is processed. Stripe holds PCI DSS Level 1 certification.

Authentication

Who can access the platform, and how.

Supabase Auth + JWT

Authentication managed by Supabase Auth implementing JWT-based sessions. On login, a signed JWT is issued with a short expiry. The JWT is stored in an HttpOnly cookie (not localStorage) to prevent XSS access. Token refresh handled automatically by the Supabase client library before session expiry.

Multi-Factor Authentication

MFA available via TOTP using any standard authenticator app (Google Authenticator, Authy, 1Password, etc.). Workspace administrators can mandate MFA for all users. Enforcement checked at login — users without MFA enrolled cannot proceed past the login screen when enforcement is active.

Invitation-Only Access

New users cannot self-register. All workspace access requires an administrator invitation. Invitations are time-limited (72 hours), single-use, and tied to a specific email address. Expired or already-used invitation links result in a clear error.

Session Management

Sessions have configurable maximum age (default 8 hours standard, 2 hours privileged roles). Inactive sessions terminated after configurable idle timeout. Users can be force-signed-out by administrators. All active sessions visible to administrators.

Password Policy

Minimum 12 characters, must include uppercase, lowercase, number, and special character. Password reset via email link only. Reset links expire after 1 hour, single-use. Breached password detection warns users if password appears in known breach databases. Bcrypt hashing with configurable cost factor.

Login Audit Log

Every login attempt logged: email, timestamp, IP address, user agent, success/failure, MFA status. 5 failed attempts triggers 15-minute lockout. Workspace administrators can view full login history for any user. Unusual login patterns (new country, new device) generate alerts.

Audit Logging

Every action. Every user. Every timestamp.

The audit log is immutable and cannot be edited, cleared, or deleted by any user — including workspace administrators.

What is logged

Every record creation, update, and deletion. Every approval decision. Every permission change. Every login and logout. Every document access, download, and signature. Every AI query and response. Every configuration change. Every user invitation and deactivation.

Log entry fields

event_type, user_id, user_email, workspace_id, table_name, record_id, action (CREATE/UPDATE/DELETE/VIEW), old_values (JSONB snapshot), new_values (JSONB snapshot), ip_address, user_agent, created_at (UTC timestamp).

Immutability

Audit log records are written to a separate append-only table. No UPDATE or DELETE permission is granted on the audit log table to any role. Entries can only be inserted — never modified or deleted. Enforced at the database layer via write protection.

Search and export

Administrators search by user, date range, event type, table, and record ID. Export to CSV for external audit tools or regulatory submission. Searching the audit log itself creates an audit entry.

⏳ Retention: 7 years

Audit logs retained for a minimum of 7 years by default (configurable). Legal holds prevent deletion of specific records or date ranges required for litigation or regulatory review. Deletion certificates issued on data destruction.

Anomaly Alerts

Automatic alerts for: bulk data export (>500 records in one session), sensitive data access outside business hours, permission escalation events, 3+ failed MFA attempts, access from a previously unseen IP range. Delivered to workspace administrator by email and in-app notification.

GDPR & Data Protection

Built for UK and EU data protection law.

EU Data Residency

Platform hosted on Supabase infrastructure in the EU West (Ireland) AWS region (eu-west-1). All data — database records, file storage, and backups — remains within the EU. No transfers to non-EU regions for storage or processing without explicit consent. Satisfies UK GDPR Article 46 transfer requirements.

Data Processing Agreement

DPA available for all customers. Establishes YBNW Ltd as data processor under your instructions as data controller. Covers: processing purposes, data categories, security measures, sub-processor list, and deletion obligations on contract termination.

Right to Erasure

On contract termination, all workspace data is scheduled for deletion within 30 days. Deletion covers database records, file storage, and backups. Deletion certificate issued confirming date and scope. Individual employee records can be deleted within the platform in response to DSARs.

Article 30 Records

The Data Governance module includes a ROPA builder generating Article 30-compliant records for all processing activities: purpose, legal basis, data categories, data subjects, retention period, and security measures — ready for supervisory authority review.

DSAR & Breach Workflow

DSAR workflow manages the 30-day response clock from receipt. Steps: receipt confirmation, identity verification, data location search, response preparation, delivery, closure. The 72-hour breach notification clock is tracked separately in the GDPR Breach Register with ICO notification status.

Sub-Processors

Minimal sub-processors: Supabase (database and auth, Ireland), Vercel (hosting and Edge Functions, EU nodes), Stripe (payments, Stripe entity), AWS (underlying cloud via Supabase, eu-west-1). Full list with legal entities and processing locations in the DPA. 30 days' notice on material change.

Compliance Alignment

How YBNW One maps to major frameworks.

ISO 27001

RLS-enforced access control (A.9), AES-256 encryption (A.10), immutable audit logs (A.12), MFA (A.9.4), DPA and sub-processor management (A.15), incident response procedures (A.16), documented ISMS policies (A.5).

GDPR / UK GDPR

Data minimisation, purpose limitation, EU data residency, Article 30 ROPA, DSAR workflow (30-day clock), 72-hour breach notification, right to erasure on termination, DPA for all customers, lawful basis tracking.

SOC 2 Type II

Security (CC6): RLS, MFA, encrypted storage. Availability (A1): monitored uptime, PITR backups. Processing Integrity (PI1): audit trail, immutable log. Confidentiality (C1): workspace isolation, column encryption. Privacy (P1): GDPR controls.

Cyber Essentials (UK)

Boundary firewalls (Vercel WAF), secure configuration (pinned deps, no default credentials), access control (RBAC + RLS + MFA), malware protection (Vercel edge scanning), patch management (automated Dependabot + 24hr critical patch SLA).

HIPAA

Technical safeguards: access control (RBAC), audit controls (immutable log), transmission security (TLS 1.3), encryption at rest (AES-256). Administrative: workforce training records (L&D module). Business Associate Agreement (BAA) available on request.

PCI DSS (scoped)

No card data handled by YBNW One — Stripe processes all payment data. YBNW One is out-of-scope for PCI DSS except webhook processing. Stripe-Signature verification on all webhook payloads. Stripe holds PCI DSS Level 1 certification.

Security questions?

We answer security questions before you sign anything.

If your organisation requires a security questionnaire, penetration test evidence, DPA review, or architecture walkthrough — contact us and we will provide whatever your security team needs.

Contact Security Team Data Protection Policy