Skip to content
ClaimCore

Security

Claims data is the sensitive kind.

A motor claim carries a name, an address, a date of birth, bank details, medical detail and a signature. Here is how ClaimCore handles it — including what is not built yet.

In place today

What the architecture actually enforces.

Permissions checked server-side, every time

A central permission matrix is the single source of truth, and it is enforced on the server for every action — never by hiding a button. Hiding UI is a courtesy; the check is what stops it.

Ownership checked, not assumed

Claim-scoped actions verify that the row being acted on belongs to the claim being acted on, in the same query. Knowing an identifier does not grant access to what it names.

An append-only activity trail

Every mutation records who did it, what changed and when, against the claim it belongs to. Signature events additionally record IP and user agent.

Tamper-evident signatures

Each sealed document carries a certificate page: signer, email, method, IP, the timestamps for sent, opened and signed, the exact consent wording agreed, and a SHA-256 of the document. Signing links are single-use and expire.

Credential protection

Passwords are hashed with bcrypt. Failed sign-ins are counted durably against the account and lock it for escalating periods, so the limit is real rather than per-server. An unknown address costs the same time as a known one, so sign-in cannot be used to discover who has an account.

Hardened by default

HSTS, a strict content security policy, framing denied, MIME sniffing off, a restrictive referrer policy. Uploads are typed from their actual bytes rather than what the browser claimed, and anything not a PDF or image is served as a download rather than rendered. Production refuses to start carrying development secrets.

Private storage

Documents live in private object storage. The database holds keys, never public URLs, and files are streamed only to an authorised, authenticated request.

Subject access

A UK GDPR data subject access export assembles everything held about an individual, including the original intake submission as it was received.

Not yet

What we have not built.

A security page listing only strengths is the least useful document a vendor can publish. These are the gaps, as of today.

Multi-factor authentication

Not available. Microsoft Entra single sign-on is supported, so organisations using Microsoft 365 can enforce MFA at the identity provider today. Native MFA is planned.

Database-level tenant isolation

Isolation is currently enforced in the application. Postgres row-level security, so the database refuses a cross-tenant read even if the application asks for one, is in build and is a prerequisite for us onboarding a second organisation.

Field-level encryption

Everything is encrypted in transit and at rest at the storage layer. On top of that, the two columns holding what a claimant types into the public claim form — including a national insurance number, a date of birth and injury detail — are separately encrypted with AES-256-GCM under a key held outside the database, with rotation supported.

What that protects against is a stolen backup, a leaked replica, or someone with database access and no business reading a claimant’s medical history. It does not protect against a compromised application server, because the key is there. We would rather say that than imply more.

Ordinary columns — names, registrations, dates — stay readable, because a claims system whose lists cannot be searched or sorted is not one anybody can work in.

Certifications and testing

No ISO 27001, no Cyber Essentials, no SOC 2, and no third-party penetration test yet. Where a buyer needs one, we would rather agree a timeline than claim a badge.

The public claim form

It collects date of birth, national insurance number and injury detail — special-category data. The firm’s own privacy notice is shown in full on the form, and the exact text, its version, the time, the IP and the user agent are stored with the submission. The lawful basis stated is Article 9(2)(f), not consent.

Retention and erasure

Subject access export, a per-firm retention period, a review list of closed claims past it, and a real erasure that destroys every stored file and overwrites the personal data while leaving the financial record a firm is required to keep. Nothing is ever deleted on a timer — a date passing prompts a review, and the erasure is a deliberate, reference-confirmed, audited act.

Session revocation

Immediate. Every request re-reads whether the account is active, whether the firm is active, and what role the person holds — so deactivating somebody, suspending a firm or taking a role away takes effect on their next click rather than when their token expires. Multi-factor authentication is not built.

Questions procurement asks

Is ClaimCore ISO 27001 or Cyber Essentials certified?

No. Neither certification has been obtained, and we will not imply otherwise. If a certification is a procurement requirement for you, tell us during the demo and we will be straight about the timeline rather than the aspiration.

Where is our data held?

The application and its PostgreSQL database run in a UK region, and stored documents sit in UK or EU object storage. Nothing is replicated outside the UK or EEA by default.

Who can see a document?

Document and attachment reads are scoped to the organisation that owns them and checked on every request. Holding a document identifier is not enough to retrieve it — the request has to come from a signed-in user of the organisation the document belongs to, with a role permitted to view claims.

Can we get our data out?

Yes. There is a data subject access export that assembles everything held about an individual — their record, vehicles, every claim and its full history, documents, signatures and the original intake submission. It is built for UK GDPR subject access requests, and it is equally the answer to "can we leave".

Do you use our data to train AI?

There is no AI in the product today. When there is, tenant data will not be used to train shared models, and that will be in the contract rather than only on this page.

If you have a security questionnaire, send it with your demo request and we will complete it properly. Book a demo.

Ask us the hard questions.

Bring your security team to the demo. We would rather answer a difficult question now than a procurement objection three months in.