Trust Centre How we protect your data
Security
Encryption, access control, 2FA, audit chain, rate limiting, and the architecture choices that keep patient content out of Cogent's own reach.
This document summarises the technical and organisational measures Cogent Clinic uses to protect customer data and support safe use of the service. It is deliberately kept at the level of posture and commitment rather than implementation detail, and procurement reviewers with a specific control-mapping requirement can request the internal security document under NDA.
1. Security approach
Cogent Clinic is designed around three commitments held together: the clinician is the author of record on every output, patient-identifying content never leaves the clinician's browser in the clear, and the whole system runs inside the United Kingdom.
A central design principle is that patient-identifying details are replaced with placeholders in the clinician's browser before any content is transmitted, with the mapping between those placeholders and the real names held on the clinician's device, encrypted under a key derived from their account password, and never stored on Cogent's infrastructure. The effect is that the personal data reaching the application, the AI inference service, and any sub-processor is materially reduced from what a generic AI scribe would handle.
2. Hosting and data residency
- Application hosting, database, AI inference, secrets, scheduled jobs, and backups all run inside the United Kingdom.
- The live speech-to-text service used for session transcription runs in the European Union, with audio streamed browser-direct to the provider rather than transiting Cogent's infrastructure, and Cogent Clinic Ltd has opted out of the provider using customer audio or transcripts for any model training, benchmarking, or de-identified model development via the provider's documented opt-out process.
- Clinician-initiated handwritten-note extraction (PDF, JPEG, or PNG uploaded by the clinician to seed a draft) sends the file bytes to the same UK-hosted AI inference service (Bedrock in AWS eu-west-2) for text extraction. Files are not retained as uploaded source files; the returned extracted text passes through the standard tokenisation review gate before reaching the drafting model.
- No cross-border transfers of clinical content at rest, with everything stored inside the UK.
- UK GDPR transfers for the live transcription stream are covered by the UK Addendum to the EU SCCs.
- A handful of operational sub-processors (transactional email, error tracking, product analytics) sit inside the EU, with no clinical content payloads sent to them.
3. Authentication and access control
- Time-based one-time-password (TOTP) two-factor authentication is mandatory on every clinician account, enforced at the server rather than only in the UI.
- Strong password hashing with a sensible minimum length.
- Sessions are short-lived and rotated.
- Rate limits apply per user to sign-in, sign-up, password reset, and 2FA verification.
- Production access is scoped to named, least-privilege roles, with administrative access limited and reviewable.
4. Encryption
- Strong encryption in transit and at rest, with the specific algorithms held in the internal security document available to procurement reviewers under NDA.
- The clinician's placeholder map is encrypted client-side under a key derived from the account password, with the key never transmitted and the session-scoped cache cleared on sign-out.
- Session transcripts captured through the in-browser transcription feature are encrypted client-side before upload, and Cogent holds ciphertext only.
5. Logging, audit, and monitoring
- An append-only audit log of generation, account, and billing events runs with a cryptographic hash chain that breaks under any tampering.
- A nightly job verifies the chain and alerts on any break.
- Every AI output is scanned server-side for identifier leakage, with anything that looks like a leak held for review rather than shown as clean.
- A client-side round-trip validator against the placeholder map forces clinician review before any draft can be signed off when a new identifier is detected.
- Error tracking captures metadata only, with scrubbing rules stripping draft bodies, chat messages, transcripts, and structured-field content before transmission.
6. Runtime integrity
- Per-user generation rate limits.
- A per-user daily spend cap on AI inference calls that hard-blocks further generation if reached.
- Output-side pattern detection for raw identifiers (NHS numbers, phone numbers, email addresses, postcodes).
- Idempotent payment-webhook processing so retries cannot double-charge or double-credit.
7. Data retention and deletion
- Retention periods are defined by data category in the retention schedule.
- Drafts are retained by default and deletable by the clinician at any time.
- Session transcripts are held as encrypted ciphertext that Cogent cannot read, retained until the clinician deletes them, with account or folder deletion cascading to them.
- Account deletion triggers a soft-delete grace period followed by a hard-delete sweep.
- Backups are kept on a short rolling window, with a documented and rehearsed restore drill.
8. Sub-processor management
- Sub-processors are documented in the customer-facing register.
- Material changes (new processor, removal, region change) are communicated to customers in advance and logged internally.
- Each sub-processor is bound by a written data-processing agreement.
9. Incident response
- A documented incident response plan covers triage, containment, investigation, notification, and post-incident review.
- Notifiable personal-data breaches are assessed against UK GDPR notification thresholds.
- Customers are notified without undue delay where a notifiable breach affects them.
10. Customer responsibilities
Security is a shared surface, and customers are responsible for:
- using the service only where appropriate for their clinical setting and regulatory position,
- reviewing every AI-generated output before incorporating it into a clinical record,
- protecting their account credentials and their device,
- ensuring any staff with access are appropriately authorised and trained,
- maintaining their own local endpoint and record-security controls.
11. Current status
This document is a summary kept aligned with the DPIA, retention schedule, incident response plan, privacy policy, and sub-processor register. Procurement reviewers with a specific control-mapping requirement can request the internal security-control document under NDA.