Security at Qapacity

The platform is served over HTTPS using TLS through our hosting provider, Vercel. Browsers are instructed to use HTTPS only (HTTP Strict Transport Security). Connections from the application to the managed database are encrypted.

Application data, including uploaded documents, is stored in a managed PostgreSQL service that encrypts data at rest.

Every action is checked on the server against the user’s role in their organisation — for example organisation administrator, technical lead, procurement, viewer, provider administrator or facility manager. Facility managers can only manage the facilities they are assigned to. Hiding a button is never the only control, and changing a URL does not bypass a permission check.

Significant actions — such as changes to requirements, access requests, facility information, verification states and document downloads — are recorded with the actor, time, affected record and, where relevant, the before and after values.

• Passwords are hashed with bcrypt; we never store them in readable form.
• Sessions are stored in the database and can be revoked. The session cookie is httpOnly, marked SameSite=Lax and sent only over HTTPS in production.
• Sign-in attempts are rate limited to slow down password-guessing.
• Sign-in responses are designed not to reveal whether an account exists.

Single sign-on for enterprise organisations is planned but not yet available.

Customer and provider organisations share infrastructure but not data. Queries for private information are scoped to the requesting user’s organisation, and access to shared records — such as an access request between a customer and a provider — is checked against both parties on every request. Requirements are private to the customer organisation by default.

Uploaded files have no public URLs. They are only served through an authorised download route that checks the user’s permission each time, records the download in the audit log and instructs browsers not to cache the file. File size and type are restricted on upload.

• Input to every form and server action is validated on the server.
• Security headers are set on every response, including protections against clickjacking, content-type sniffing and referrer leakage.
• Public forms, such as contact and correction submissions, are rate limited.

We rely on the backup and point-in-time recovery capabilities of our managed database provider. Documented restore testing and recovery objectives are part of the security programme still to be formalised.

If we become aware of a security incident affecting customer or provider data, we will investigate, contain it, notify affected organisations without undue delay and meet our obligations under UK data protection law, including notifying the Information Commissioner’s Office where required.

To report a vulnerability or concern, use the contact page, choose “General enquiry” and start your message with “Security”. Please do not include exploit details or personal data in the first message; we will arrange a suitable channel.

We collect only the information needed to provide the service. Facility profiles use institutional contact details rather than personal details of individual scientists, even where those appear elsewhere in public. When you send a request to a provider, you review exactly what will be shared first.