Security overview

Clinstead is engineered for GxP-grade use from the schema up. Security is not a layer we add at the end — it is built into the canonical data model, the runtime, and the operational practices that surround them. This document summarises the controls we run today.

For pre-sales or audit conversations, we maintain a customer compliance pack including SOC 2 Type II report, ISO 27001 statement of applicability, penetration test summary, and a populated CAIQ. Request access at security@clinstead.com.

Each customer environment runs in its own logically isolated tenant. Enterprise plans can elect a dedicated VPC with no shared tenancy. We use immutable infrastructure managed via infrastructure-as-code; production changes go through review and CI gating before deployment.

The platform is multi-region with EU, US, UK, and ANZ residency options. Study data binds to a region at study creation time and never leaves it without an explicit customer-initiated transfer.

Data is encrypted in transit and at rest by default:

• In transit:TLS 1.3 for all public-facing and inter-service traffic. We disable legacy ciphers and pin to modern suites only. HSTS is enforced.
• At rest: AES-256-GCM at the storage layer. Customer-managed encryption keys (CMEK) are available on Enterprise.
• Backups: encrypted with separate keys, stored in a region matching the source.
• Secrets: rotated regularly and stored in a dedicated secrets manager with audited access.

Customer users authenticate via SAML 2.0 / OIDC SSO against your identity provider (Okta, Azure AD, Google Workspace, Ping, and others). Service accounts and API tokens are scoped to the principle of least privilege and rotated on a defined cadence.

All administrative access at Clinstead requires hardware-backed MFA (WebAuthn / FIDO2). Production access is just-in-time, audited, and reviewed quarterly. There are no shared admin accounts.

Electronic signatures are designed into regulated workflows throughout the platform, with reason-for-change captured at the field level and audit-aware provenance on every signed action.

The canonical model carries an immutable audit trail across every entity: who, what, when, from where, and a reason-for-change where applicable. Audit records are append-only and exportable in machine-readable form for inspections.

Snapshots are deterministic. Any audit pack or data export from the platform can be reproduced at any historical point in time, so inspectors and sponsors can verify that what they reviewed last month is exactly what we reproduced today.

Customer Data is segmented by tenant and by study. Within a tenant, studies can be further scoped by region, role, and need-to-know.

For data transfers outside the chosen residency region, Clinstead relies on UK IDTA / EU SCCs as appropriate. We do not sub-contract storage of regulated Customer Data outside the customer-selected region without explicit written instruction.

We run continuous monitoring across infrastructure, application, and access layers. Telemetry is centralised in a dedicated security data lake with defined alerting thresholds for:

• Anomalous authentication patterns (impossible travel, brute force);
• Privilege escalation attempts;
• Unusual data egress volumes;
• Configuration drift from infrastructure-as-code;
• Dependency CVEs in deployed services (SBOM-driven).

High-severity alerts page on-call security engineers 24/7.

We run independent penetration tests at least annually and after material architectural change. Findings are tracked to remediation with severity-based SLAs:

• Critical — patched within 24 hours;
• High — patched within 7 days;
• Medium — patched within 30 days;
• Low — bundled into the next routine release.

Continuous SAST, DAST, and dependency scanning run in CI. We maintain an SBOM for every deployed service.

Our IR process is run by a named security lead and exercised at least twice a year. In the event of a confirmed security incident affecting Customer Data, we notify affected customers without undue delay and within 72 hours of establishing the facts — sooner where the impact is high.

Customers receive a written incident report including timeline, impact, root cause, and remediation, plus any regulatory notifications we have filed.

We back up production data continuously with point-in-time recovery. Backups are tested via automated restore at least monthly. Our production target is:

• RPO — < 5 minutes for transactional data;
• RTO — < 4 hours for full regional failover;
• Validated uptime — 99.95% rolling 12 months.

A disaster recovery exercise is performed at least annually and documented for audit.

All Clinstead personnel undergo background checks where lawful, sign confidentiality agreements before access, and complete security and GxP-awareness training on joining and annually thereafter. Access is provisioned on first day only with explicit justification, and revoked the same day on leaving.

Clinstead does not currently hold third-party certifications. The platform is being built with the operating discipline that regulated clinical research environments expect, with the following frameworks informing the architecture:

• 21 CFR Part 11 — electronic records and signatures;
• ICH E6(R3) — Good Clinical Practice;
• UK GDPR / EU GDPR and HIPAA where applicable to participant data;
• SOC 2 Type II — pursued ahead of broader commercial availability.

Specific attestations and certifications will be communicated when achieved.

We welcome security research from the community. Report suspected vulnerabilities to security@clinstead.com. We commit to:

• Acknowledge receipt within one business day;
• Provide a triage update within five business days;
• Not pursue legal action against good-faith researchers who follow this policy;
• Credit reporters publicly where they wish to be credited.

Please do not access, modify, or exfiltrate data beyond what is necessary to demonstrate the issue.

Security questions, audit packs, or assurance materials: security@clinstead.com.