Skip to content
Sign inStart free trial

Security

Security. How we protect your data.

Protecting your data is fundamental to everything we build. This page outlines the security measures we have in place to safeguard the Covered platform and the data entrusted to us.

Infrastructure

  • Application hosting

    The Covered platform runs on a managed cloud hosting platform with HTTPS on every endpoint.

  • Database

    All persistent data is stored in a managed database with infrastructure located in the European Union, ensuring data residency within an adequate jurisdiction for UK data protection purposes.

Encryption

  • In transit

    All connections to Covered are encrypted using TLS 1.2 or higher, and use TLS 1.3 wherever the browser supports it. 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. Our 6-hourly interim copy of the database is made by a job that runs on GitHub’s servers and is encrypted there before it is stored, so stored copies are encrypted. Copies made before we added this encryption were not, and expire within 7 days of being made.

  • 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. A session lasts 30 days and is renewed while it is in use. 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.

  • Venue data separation

    Every venue’s data is kept separate by application-level venue scoping on every query, with database row-level security as a second layer.

  • Internal access

    Access to production systems by Covered staff is restricted to authorised personnel and is logged for audit purposes. We follow the principle of least privilege.

Sub-processors

The third-party services that process data on our behalf, what each one does and where it is based are listed in one place, in our Privacy Policy and our Data Processing Agreement. Payment card details go only to Stripe or Square.

For the list, and for 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:

Subject line
Security Vulnerability Report

Please include a description of the vulnerability, steps to reproduce it, and any supporting evidence. We will acknowledge your report and keep you updated while we investigate. 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.

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.

  • The Server response header

    The Server 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.