All legal documents

Security Statement

The controls that actually exist. Written so a customer's DSPT assessor can use it.

Version 1.0 · Effective 6 August 2026 · Last updated 6 August 2026

This describes measures in place, not aspirations. Where something is planned rather than done it says so, because a security statement that overstates is worse than none — it is a misrepresentation a customer relies on, and the moment it is discovered every other claim in it becomes worthless.

One section below carries an explicit 'not yet in place' note. It is there deliberately.

1. Access control

  • Every table carries row-level security. A signed-in user's queries are scoped to their own organisation by the database itself, not by application code that could forget.
  • Administrative and sales consoles check membership server-side on every route. Hiding a menu item is not access control and is not relied on.
  • Service-role credentials are held server-side only and are never exposed to the browser.
  • Sessions time out after inactivity, and the number of simultaneous sessions per account is capped. Account holders can see their signed-in devices and end them.

2. Data protection in transit and at rest

  • TLS in transit throughout, with HTTP Strict Transport Security.
  • Encryption at rest on the database and on file storage, managed by our infrastructure providers.
  • A Content Security Policy and the associated security headers are set on every response.
  • Passwords are stored only as salted bcrypt hashes by our authentication provider. We never see them.
  • Exported PDFs are encrypted with permissions that permit printing and prevent copying and alteration, and carry a licence reference.

3. Resilience and backup

  • The database platform takes automated daily backups as standard.
  • A separate encrypted backup is taken nightly and held outside the database platform's account, so that compromise of that account cannot destroy the means of recovery. It is encrypted with AES-256 using a passphrase held in neither system.
  • Every backup run restores itself into a scratch database and counts the tables and rows that arrive. A run that restores less than expected fails and raises an alert. An untested backup is a belief rather than a control, so the test is part of the job that makes it.
  • A written restore procedure exists, including credential rotation and what to tell customers about the recovery point.
  • Infrastructure is defined in code and the application can be redeployed from the private repository at any commit.

Two things not yet true, stated rather than implied. Point-in-time recovery is not enabled, so the current recovery point is up to 24 hours old rather than the one hour we are aiming for. And uploaded evidence files are not covered by the off-platform backup — the database rows that reference them are, the files are not. Both are being addressed. A customer whose governance depends on either should ask us for the current position rather than relying on this paragraph.

4. Monitoring and response

  • Application errors are captured, grouped by fault rather than by occurrence, and written to a queue that is triaged. Personal data — names, email addresses, telephone numbers and identifiers — is stripped before an error is stored.
  • A new fault, or any fatal one, alerts the director immediately. Repeat alerts for the same fault are limited to one an hour, so an incident is reported once rather than thousands of times.
  • Rate limiting is applied to public and expensive endpoints, enforced in the database so the limit holds across every server instance rather than per instance.
  • Authentication, session, export and administrative actions are logged, and export volumes are monitored for extraction patterns — an account pulling hundreds of documents in an hour is slowed and reviewed rather than silently permitted.
  • Hosting and database platform logs are retained and reviewable.

Report a vulnerability to hello@careshieldcompliance.co.uk. We will acknowledge within 2 working days and keep you informed.

5. People and process

  • Access to production is limited to those who need it and is removed when a role ends.
  • Multi-factor authentication is used on the infrastructure, repository and payment accounts.
  • The source code is held in a private repository under access control.
  • Changes are reviewed, typechecked, tested and built before deployment.
  • Everyone with access is bound by confidentiality obligations that survive their engagement.

6. Certification — stated honestly

We are not currently certified to ISO 27001 or Cyber Essentials, and we do not hold an NHS Data Security and Protection Toolkit submission of our own. We will not imply otherwise on a tender response. What we provide is this statement, our Data Processing Agreement and our sub-processor list, which customers completing their own DSPT can use as supplier evidence. Cyber Essentials is the sensible next step and is planned. Ask hello@careshieldcompliance.co.uk for the current position before relying on it.

Care Shield Compliance is a division of Africa Procurement Group Ltd, registered in England and Wales, company number 10553435. Registered office: Devonshire House, One Mayfair Place, London, England, W1J 8AJ. Questions about this document: hello@careshieldcompliance.co.uk.