Security

Infrastructure

• Application hosting: The Covered platform is hosted on Vercel, which provides automatic scaling, DDoS protection, and a global edge network for low-latency delivery.
• Database: All persistent data is stored in Supabase with infrastructure located in the European Union, ensuring data residency within an adequate jurisdiction for UK data protection purposes.
• Redundancy: Database backups are taken at regular intervals with point-in-time recovery capability. Infrastructure is designed for high availability with automated failover.

Encryption

• In transit: All connections to Covered are encrypted using TLS 1.3. We enforce HTTPS across all endpoints and set HTTP Strict Transport Security (HSTS) headers.
• At rest: Data stored in our database is encrypted at rest using AES-256 encryption. Database backups are also encrypted.
• Payment data: Payment card details are handled exclusively by Stripe and Square, both of which are PCI DSS Level 1 certified. We never store, process, or have access to full card numbers.

Authentication

• Password hashing: User passwords are hashed using bcrypt with a sufficient work factor. We never store passwords in plain text.
• Two-factor authentication (2FA): We support time-based one-time passwords (TOTP) as a second authentication factor. We recommend all account administrators enable 2FA.
• Session management: Sessions use secure, HTTP-only cookies with short expiry times. Sessions are invalidated on password change and can be revoked by account administrators.

Access Controls

• Role-based access control (RBAC): The platform implements granular role-based permissions. Account owners can assign roles (e.g. manager, host, staff) that limit access to features and data appropriate to each role.
• Tenant isolation: Every venue operates in a logically isolated tenant. Row-level security policies enforce strict data separation, ensuring that one venue's data can never be accessed by another.
• Internal access: Access to production systems by Covered staff is restricted to authorised personnel, requires multi-factor authentication, and is logged for audit purposes. We follow the principle of least privilege.

Sub-Processors

We carefully vet all third-party services that process data on our behalf. Our current sub-processors are:

For full details on international transfers and safeguards, see our Privacy Policy and Data Processing Agreement.

Incident Response

We maintain an incident response procedure to detect, contain, and remediate security incidents. In the event of a personal data breach that is likely to result in a risk to individuals' rights and freedoms, we will notify the ICO within 72 hours and inform affected customers without undue delay, in accordance with Articles 33 and 34 of the UK GDPR.

Vulnerability Reporting

If you discover a security vulnerability in Covered, we ask that you disclose it to us responsibly:

• Email: hello@covered.technology
• Subject line: Security Vulnerability Report

Please include a description of the vulnerability, steps to reproduce it, and any supporting evidence. We will acknowledge reports within 2 business days and aim to provide a substantive response within 10 business days. We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to address it.

Compliance Roadmap

• SOC 2 Type I: We are planning a SOC 2 Type I audit to independently validate our security controls. Updates will be posted here as this progresses.
• Penetration testing: We conduct regular penetration tests and address any findings promptly.
• Dependency management: We use automated tools to monitor for known vulnerabilities in third-party dependencies and apply patches in a timely manner.

Known Platform Residuals

The following are characteristics of our hosting platform that are inherent to every application deployed on the same infrastructure. They are considered acceptable residual risk.

• Server: Vercel response header: The Server: Vercel header is emitted by the hosting platform and cannot be overridden via application configuration or middleware. The application layer does not leak framework details — X-Powered-By is removed, and all security headers (CSP, HSTS, COOP, CORP) are explicitly set.
• unsafe-inline in script-src: Next.js 14 App Router generates inline scripts for hydration data (React Server Components payload) that cannot be nonced. This is a known framework limitation. A per-request nonce is generated in middleware and applied where possible; browsers that support nonces ignore unsafe-inline when a nonce is present, so the effective policy on modern browsers is nonce-only. All other CSP directives are fully tightened.