Security & Data Policy

AL Performance Ltd — ALP Platform (app.alperformance.co.uk)

Last updated: March 2026 · Version 1.0

1. Overview

The ALP Platform is an internal business application operated by AL Performance Ltd for managing contact centre audits, client relationships, project tracking, ticketing, knowledge management, training, and time tracking. This policy documents the security controls, data handling practices, and privacy measures in place across the platform.

2. Platform Architecture

2.1 Infrastructure

2.2 Content Security Policy

The platform enforces a Content Security Policy (CSP) via HTTP headers that restricts script sources, style sources, connection endpoints, and frame embedding. Only trusted CDNs (jsdelivr, cloudflare, quilljs, Google Fonts) are permitted for external resources.

3. Authentication & Session Management

3.1 Authentication Method

• All users authenticate via email and password through Supabase Auth
• Passwords are hashed using bcrypt (handled by Supabase — never stored in plaintext)
• New users are created via admin invitation only — there is no public self-registration
• Invited users receive a secure link to set their password

3.2 Session Management

• Sessions are managed via JWT tokens issued by Supabase Auth
• Tokens are stored in the browser and automatically refreshed
• An inactivity timeout of 2 hours is enforced — users are automatically signed out after 2 hours of no interaction (clicks, keystrokes, scrolling, touch)
• On sign-out, all cached session data and authentication tokens are cleared from the browser
• Each page verifies the session on load — unauthenticated requests are redirected to the login page

3.3 Multi-User Isolation

• Each authenticated user is identified by their unique Supabase Auth ID
• Sidebar user displays, activity logs, time entries, and notifications are resolved against the authenticated user's identity
• Google Calendar tokens are stored per-user — each user connects and sees only their own calendar

4. Authorisation & Role-Based Access Control

4.1 Role Hierarchy

4.2 Permission Groups

4.3 Database-Level Security

PostgreSQL Row Level Security (RLS) is enabled on all tables. Policies require auth.role() = 'authenticated' for all read and write operations. Unauthenticated requests receive zero data.

5. Data Storage & Encryption

5.1 Data at Rest

• All platform data is stored in Supabase PostgreSQL (hosted on AWS)
• Database storage is encrypted at rest using AES-256 (managed by Supabase/AWS)
• Audit project data (form entries, VCC configurations, findings, reports) is stored as JSONB in the audits table
• File uploads in the Knowledge Base are stored within the database (planned migration to Supabase Storage for object-level encryption)

5.2 Data in Transit

• All connections use HTTPS/TLS 1.2+ — enforced by both Netlify and Supabase
• WebSocket connections to Supabase use WSS (encrypted WebSocket)
• API calls to Five9, Anthropic, and Google are proxied through Netlify Functions over HTTPS

5.3 Browser-Side Caching

• A localStorage cache is used for fast initial page rendering
• Cache is cleared on sign-out to prevent data leakage between users
• Sensitive credentials (Five9 passwords, API keys) are never stored in localStorage
• Google Calendar OAuth tokens are stored in Supabase (server-side), not in the browser

6. Third-Party Integrations

6.1 Five9 VCC Integration

• Connects via the Five9 Admin SOAP API using Basic Authentication
• Credentials are entered per-session and not persisted to any storage
• All API calls are proxied through a Netlify Function — credentials never reach the browser's network tab
• Data extracted: campaign configurations, skills, dispositions, IVR scripts, contact fields, domain metadata, reports
• Extracted data is stored within the audit project only — not shared across audits

6.2 Google Calendar Integration

• Uses OAuth 2.0 with offline access for token refresh
• Scopes requested: calendar, calendar.events, email, profile
• OAuth consent screen is configured as Internal (Google Workspace) — only organisation members can connect
• Refresh tokens are stored in the google_tokens table with RLS — each user can only access their own tokens
• Token refresh is handled server-side via Netlify Functions
• Users can disconnect at any time, which deletes their stored tokens

6.3 Anthropic Claude AI

• Used for audit report generation and Five9 report data analysis
• API key is stored as a Netlify environment variable — never exposed to the browser
• All Claude API calls are proxied through a Netlify Function
• Data sent to Claude includes audit findings and anonymised configuration data
• Anthropic's data retention policy applies — refer to Anthropic Privacy Policy

6.4 Supabase

• Hosted in AWS EU region
• SOC 2 Type II compliant
• Automated daily backups with point-in-time recovery
• Refer to Supabase Security for infrastructure-level controls

7. Data Handling & Retention

7.1 Data Categories

7.2 Retention

• Data is retained for the duration of the client engagement plus any agreed retention period
• Audit data can be deleted by the audit owner at any time via the dashboard
• User accounts can be removed by an administrator, which unassigns their tasks and tickets
• Google Calendar tokens are deleted when a user disconnects or when their account is removed

7.3 Data Export

• Administrators can export all platform data via the Admin panel (JSON format)
• Audit reports can be exported as DOCX documents
• Five9 report data can be exported as CSV

8. Client Data Protection

• Five9 credentials are provided by the client and used only for the duration of the audit session
• Extracted VCC configuration data (campaigns, skills, dispositions) does not contain end-customer PII
• Five9 reports (call logs, agent stats) may contain agent names and call metadata — these are stored within the encrypted audit payload
• Mystery shop test data uses dedicated test numbers and names as documented in the audit methodology
• All client data is isolated within individual audit projects and is not shared between audits or clients

9. Network & Transport Security

• HTTPS enforced on all connections — Netlify provides automatic SSL certificates via Let's Encrypt
• HSTS headers are set to prevent downgrade attacks
• X-Frame-Options: DENY prevents clickjacking
• X-Content-Type-Options: nosniff prevents MIME type sniffing
• Content Security Policy restricts script/style/connection sources to trusted domains only
• CORS on serverless functions is restricted to alpplatform.netlify.app
• Five9 API calls use Basic Auth over HTTPS proxied through server-side functions

10. Audit Trail & Monitoring

• User sign-in events are logged by Supabase Auth with timestamps and IP addresses
• The activity_log table records key platform actions
• All data records include created_at and updated_at timestamps
• Notification system tracks task assignments, ticket updates, SOP publications, and mentions
• Netlify provides function invocation logs and deployment audit trails
• Supabase provides database query logs and auth event logs via the dashboard

11. Incident Response

In the event of a suspected security incident:

1. Identify — determine the nature and scope of the incident
2. Contain — revoke affected credentials, disable compromised accounts, rotate API keys
3. Investigate — review Supabase auth logs, Netlify function logs, and activity trail
4. Notify — inform affected users and clients within 72 hours where personal data is involved
5. Remediate — deploy fixes, update security controls, document lessons learned

12. User Responsibilities

• Use a strong, unique password for your ALP Platform account
• Do not share your login credentials with anyone
• Lock your device when stepping away — the platform will auto-sign out after 2 hours of inactivity
• Report any suspicious activity or potential security issues immediately
• Do not store client credentials (e.g. Five9 passwords) outside the platform
• When conducting mystery shops, use dedicated test numbers as per the audit methodology
• Do not export client data to personal devices or unsecured storage

13. Regulatory Compliance

13.1 UK GDPR

The platform processes personal data (user accounts, client contact details) in accordance with UK GDPR principles. AL Performance Ltd is the data controller. Supabase (data processor) maintains SOC 2 compliance and stores data on encrypted AWS infrastructure.

13.2 Data Processing

• Personal data is processed on the lawful basis of legitimate interest (business operations) and contractual necessity (client audit engagements)
• Data subjects can request access to, correction of, or deletion of their personal data by contacting the platform administrator
• No personal data is sold or shared with third parties for marketing purposes

13.3 Ofcom / Contact Centre Compliance

The audit tool includes built-in checks for Ofcom compliance (call abandonment rates, CLI/ANI presentation, silent call thresholds). These checks analyse configuration data only — no live calls are intercepted or recorded by the platform.

14. Contact & Reporting

For security concerns, data requests, or policy questions:

• Email: info@alperformance.co.uk
• Platform Admin: Use the Admin panel to manage users and permissions
• Security Issues: Report immediately to a platform Owner or Admin