← All policies

Access Control Policy

1. Purpose

To ensure that access to the Company's information and information-processing systems is restricted to authorised individuals, granted on the principle of least privilege, and revoked promptly when no longer required.

2. Scope

Applies to:

• all production systems used to deliver Cadences.work (Vercel, Supabase, OpenAI, Postmark, GitLab, domain registrar, email);
• the source-code repository and CI/CD;
• internal tools (password manager, billing, accounting);
• the application's role-based access control (RBAC) layer that governs customer-side access to customer data;
• physical access to the founder's workstation;
• any future personnel, contractors, or third-party advisors with access to the above.

3. Roles and responsibilities

4. Identification and authentication

4.1 Unique identification

Every individual with access to a Company system shall use an account uniquely tied to that individual. Shared accounts are prohibited except for break-glass administrative accounts (none currently exist) which must be tightly controlled, password-vaulted, and audit-logged.

4.2 Authentication factors

Multi-factor authentication is required on every account that has access to:

• production data (Supabase production project);
• production deployments (Vercel project);
• source code with deploy capability (GitLab);
• domain registrar and email;
• the Company's password manager;
• any account where loss of credentials would cause material harm.

The enforced second factor is TOTP via Google Authenticator, backed by Google 2-Step Verification on the Director's Google Workspace identity. Where a sub-processor permits Google SSO (e.g. Vercel, GitLab), the Google account's 2SV becomes the second factor by inheritance — so any factor uplift on the Google account (e.g. enabling a Google Account passkey) propagates to those services.

Acceptable second factors, in descending order of preference:

1. FIDO2 / WebAuthn (e.g. a passkey on the Director's Google account, or a security-key authenticator) — preferred where the platform offers it without separate hardware.
2. TOTP (Google Authenticator, 1Password, Authy).
3. Google 2-Step Verification "Google Prompt" on the Director's Google account, where the upstream service authenticates via Google SSO.

Not acceptable as the sole second factor: SMS, email-based codes, or recovery codes (recovery codes are stored in the password manager as backup, not used as primary).

The Company has assessed the cost/benefit of a dedicated FIDO2 hardware-token rollout (e.g. YubiKey 5) for a one-person organisation and concluded that the controls above provide an adequate equivalent at lower operational complexity. If the Company engages additional personnel with production access, hardware tokens will be re-evaluated.

4.3 Passwords

Passwords for Company-owned accounts shall:

• be unique per system (no reuse across services);
• be at least 16 characters long;
• be generated by the password manager;
• be stored only in the Company's password manager (1Password / Bitwarden), never in browser autofill, code, plain-text files, or notes apps;
• be rotated immediately on any suspicion of compromise.

4.4 Customer-side authentication

End-user sign-in is passwordless by default:

1. The user enters their work email on /login.
2. If the user's email domain belongs to a tenant with SAML or OIDC SSO configured, the user is redirected to that identity provider; authentication, MFA, and conditional-access policies are enforced at the IdP.
3. Otherwise, Supabase Auth issues a single-use magic link / email OTP to the user's address. The link is short-lived and bound to one redemption.

Cadences does not currently expose end-user password sign-in. Where Supabase Auth retains password material for legacy reasons, it is hashed with bcrypt.

Session and token defaults applied through supabase/config.toml:

• magic-link / OTP expiry: 1 hour;
• session refresh-token rotation enabled;
• session timeout (timebox) target: 24 hours;
• inactivity timeout target: 8 hours;
• session access tokens are JWTs signed by Supabase Auth using ECDSA P-256 (ES256); the application verifies every authenticated request locally against the public JWKS, so session validity does not depend on a per-request callback to the auth server. See Cryptography Policy §4.4.

If the Company opens an end-user password fallback in future, the following minimums apply on the day password sign-in is enabled: minimum length 12 characters, complexity lower_upper_letters_digits, hashing bcrypt, MFA available via Supabase TOTP.

5. Authorisation

5.1 Least privilege

Access shall be granted at the lowest level of permission necessary for the role. Administrative privileges are granted only when the role demands it and only for the duration required.

5.2 Role-based access control (application)

The application implements RBAC with the following customer-side roles: EMPLOYEE, MANAGER, HR, ADMIN. Each role's permissions are defined in code and enforced by application authorisation logic and Supabase Row-Level Security policies. Role assignments are managed by customer administrators within their own organisation.

5.3 Need-to-know

Access to Customer Personal Data by Cadences personnel is limited to what is strictly necessary for the legitimate operation, support, or troubleshooting of the service, and shall be logged in the application audit log (see Information Security Policy §9).

6. Account lifecycle

6.1 Current state — one-person organisation

The Company has one director and no other personnel. The Director's accounts on Company systems were provisioned at company formation. No joiner, mover, or leaver events have occurred.

The Director's access is reviewed quarterly under §8, against the MFA & Admin-Account Audit Checklist, to confirm that:

• access to each system is still required;
• the level of privilege is still appropriate;
• MFA is active with an acceptable factor;
• recovery paths (Google account 2SV backup codes, password-manager emergency-access kit, billing details) are intact.

The EU Representative is not subject to this lifecycle — they have no Company accounts; their relationship is governed by the EU Representative Mandate and is reviewed under Vendor Management Policy §8.

6.2 Joiner / Mover / Leaver — procedures for any future engagement

If the Company engages additional personnel (employees, contractors, interns, or advisors needing access), the following procedures apply.

Joiner

• Account creation only after a signed Confidentiality Agreement and acknowledgement of this Policy, the Information Security Policy, and the Acceptable Use Policy.
• Access provisioned to the minimum systems required for the role.
• MFA enforced on day one.
• Hardware key issued where production access is granted.
• Onboarding checklist recorded in HR.

Mover

• Access reviewed within 5 business days of role change.
• Permissions no longer needed are revoked.
• Permissions newly needed are granted under the joiner approval procedure.

Leaver

• All access revoked on the same business day as the departure (or earlier where the departure is involuntary).
• Hardware and Company-owned devices returned.
• Email forwarding configured per business need; mailbox preserved per retention policy.
• Final password rotation on any shared system the leaver may have known credentials for.

7. Privileged access management

Production-critical accounts (Director's GitLab owner, Vercel team owner, Supabase project owner, domain registrar) are protected with TOTP MFA and, where the service supports Google SSO, by Google Workspace 2-Step Verification on the Director's Google identity. Credentials are stored in the password manager with a separate vault from day-to-day credentials. Recovery codes are sealed in the password manager's "emergency kit" and a hard copy is kept in a fireproof safe at the Director's residence.

8. Periodic access review

Access to all systems is reviewed quarterly by the Director using the MFA & Admin-Account Audit Checklist. The review covers:

• whether each account is still needed;
• whether the level of privilege is still appropriate;
• whether MFA is still active and using an acceptable factor;
• whether any inactive accounts (>90 days) should be deactivated;
• whether any third party (former contractor, external advisor) retains access that should be revoked.

The output is recorded in the audit register with a sign-off date.

9. Logging and monitoring

Access to systems is logged at three levels:

• Sub-processor logs: Vercel, Supabase, GitLab, etc. retain access logs per their platform defaults; these are reviewed during incidents and on a sample basis quarterly.
• Application audit log: an application-level audit log of every read, write, export, or deletion of Customer Personal Data is being introduced in 2026 with a minimum retention of 365 days. Until it is in place, Vercel and Supabase platform logs provide the access record.
• Authentication events: Supabase Auth records sign-ins, failures, and MFA events; reviewed for anomalies during incidents.

Suspicious access patterns trigger the Incident Management Policy.

10. Compliance and references

This Policy aligns with:

• ISO/IEC 27001:2022 Annex A: A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3, A.8.5
• GDPR Articles 25 (data protection by design and by default) and 32 (security of processing)
• Singapore PDPA — Protection Obligation (Section 24)

Operational artifacts: MFA & Admin-Account Audit Checklist.

11. Version history