Executive summary
EvidenceVault is a long-term, immutable storage platform for closed-case digital forensic evidence, built and operated in the United Kingdom by EvidenceVault. It is designed around one core promise: the evidence you put in today is guaranteed to be the same evidence you retrieve in seven, ten or twenty years' time.
Three commitments make that promise hold:
- Azure UK South only. All bytes — evidence, backups and metadata — live in the Azure UK South (London) region. Evidence is stored locally redundant by default: three copies inside one datacentre. Geo-redundant storage, which would place a copy in the UK West paired region, is available by agreement and is a conversation to have with us rather than a default. Nothing is replicated overseas, ever.
- UK-cleared personnel only. Every engineer with production access holds active SC clearance and NPPV3 police vetting. There is no offshore support.
- Mathematical immutability. Sealed items are stored on write-once blob storage with customer-managed encryption keys. Mutation is not policy-blocked — it is technically impossible.
Data sovereignty
EvidenceVault runs entirely on Microsoft Azure UK regions. The platform topology is:
Single-region operation is the default, and a deliberate sovereignty decision rather than a cost compromise. The geo-redundant option does not change that: its second copy is in UK West, and no option we offer places your evidence outside the United Kingdom.
Personnel & vetting
We recognise that for an organisation holding digital evidence, who has hands on the production environment matters as much as how the environment is built. EvidenceVault is operated by a small UK team under the following non-negotiable rules:
- Production access requires both SC clearance and NPPV3. No exceptions, no temporary uplift accounts, no contractor bypass.
- No offshore engineering. All design, development, operations and customer support are performed by UK-resident, UK-cleared personnel.
- No production access for sales, marketing or commercial staff.
- Annual re-vetting with mandatory disclosure of any change in clearance status.
Encryption & key management
Immutability & integrity
Sealed evidence is written to Azure Blob Storage with version-level immutabilityenabled on the container and a time-based retention policy applied to each individual object, set from that item's retention schedule. Azure enforces it, not our application: a delete attempted before the expiry date is refused by the storage platform itself, including for an identity holding full delete rights.
A retention policy on evidence has to be answerable to the case. When a case is delayed in court the retention period must be extended; when a case concludes with no further action, or an engagement ends and you instruct us to destroy your evidence, it must be possible to destroyit. Azure offers two modes for a time-based policy and no third. Which mode your evidence is written in is your organisation's choice at onboarding, whichever storage you use, and the default is the one that permits both: Azure's Unlocked mode.
Under either mode the evidence cannot be altered or overwritten while its policy stands, and the SHA-256 on your custody chain proves its integrity independently of both. Unlocked changes exactly one thing: a holder of the storage role that sets the policy can also remove it, and on every storage account that role is held by the platform's own identity, because applying the policy when an exhibit is sealed needs the same permission. It is a power over the policy, not over the evidence: it gives nobody the ability to read what is stored. It is exercised on two occasions only, both at your instruction, and every change to a retention date is written to your audit log with the actor, the previous date and the reason.
- When your engagement ends and you instruct us to destroy your evidence. This is a ceremony run by named platform engineers with privileged access to the Azure subscription, and it produces a destruction certificate.
- When a case concludes with no further action. Your own tenant admin records this in the portal against the case, typing its reference and a reason. Nothing is removed at that moment: the disposal is scheduled after a grace period, the case shows as awaiting disposal, and the decision can be cancelled until then. When the time comes, the platform removes each exhibit's retention policy and the exhibit, and writes one audit entry per exhibit and one for the case, each attributed to the admin who decided. Nobody at EvidenceVault is involved and nobody at EvidenceVault can start it.
A case going to court has its own brake. Your tenant admin can place a legal hold on a case, which marks every exhibit so that the storage platform refuses to delete it whatever its retention date, and the portal refuses to record no further action against the case, until the hold is released. Placing and releasing are both reasoned and written to your audit log.
If you would rather that early destruction did not exist at all, choose Locked mode at onboarding. Under Locked nobody can shorten or remove a policy before its date: not you, not EvidenceVault, not Microsoft, and our own destruction tooling refuses it. Retention can still be extended when a case is delayed. The trade is the one you would expect: a no-further-action decision is honoured in the only way it can be, each exhibit deferred to its own retention date with the deferral recorded, and on leaving the platform your evidence is exported rather than deleted, so a customer-owned account keeps paying for storage until the last exhibit expires. Said plainly: under Unlocked, on your own storage account, your own subscription owner can also destroy evidence early outside the platform; that is your power over your evidence, and a disposal made that way is in Azure's logs rather than on the custody chain.
Integrity is verified at three points:
- Ingest hash. SHA-256 computed on the practitioner's workstation before upload.
- Storage layer hash. Azure Blob Storage's MD5 + content-integrity checks on every read.
- Verification on sealing and on retrieval. The server independently re-computes SHA-256 from the stored object when the exhibit is sealed, and any mismatch quarantines it rather than admitting it to the archive. Every download recomputes the hash in the browser and checks it against the value recorded at ingest, with a copyable integrity manifest for case notes.
Audit & observability
Every state-changing action on the platform is recorded in an append-only, hash-chained audit log, which your tenant admin can verify and export at any time.
The audit log captures:
- Every ingest — the hash recorded at upload, the hash the server independently computed on sealing, and any mismatch between them
- Every download, naming the officer, the exhibit and the time
- Every retrieval request and approval, recording the requesting and approving officers separately
- Every retention extension and every mid-life case review, with the reason and the approver
- Every key operation — rotation, disable and re-enable
- Every disposal event, whether performed by an administrator or by automatic expiry
- Every break-glass request and approval
- Every refusal by your network access policy, including the source address
Access control & SSO
EvidenceVault signs your users in with your organisation's own Microsoft Entra ID. Who gets access, and at what level, is decided in your directory by your IT team through the security groups they already manage — so an officer who joins, moves or leaves is added and removed the same way as for every other system you run. We hold no separate user list and there is no account for us to forget to close.
Multi-factor authentication is required, and it is yours. We do not add a second login of our own: whatever your officers already use — a security key, an authenticator app — carries straight through to EvidenceVault unchanged.
Resilience & disaster recovery
Incident response
- Integrity drift (P1). An object's recomputed SHA-256 does not match the hash recorded for it. It is never presented to you as archived: the platform moves it to a quarantine container automatically, writes the event to your audit log, and flags the exhibit in your portal so your tenant admin can close it and re-ingest from the original. The quarantined copy is retained for investigation rather than deleted.
- Personnel access incident (P1). Production access revoked immediately; written notice within 1 hour; full root-cause analysis within 5 working days.
Accreditations & standards
- ISO/IEC 27001 — implementation under way — we are working towards certification and are not yet certified
- Cyber Essentials Plus — annual recertification
- NCSC Cloud Security Principles — alignment statement against all 14 principles available on request
- UK GDPR & DPA 2018 — DPIA and ROPA available on request
- Public-sector frameworks — not currently listed on a framework. We intend to apply when G-Cloud 15 opens; until then we contract directly or through a framework your organisation already holds
- OFFICIAL — the platform is built for evidence classified OFFICIAL. Handling caveats such as SENSITIVE are set by each customer against its own policy, and the per-case classification is yours to choose at ingest
Contractual commitments
Several commitments described in this brief are written contractual terms in our standard customer agreement:
- Data shall remain within the Azure UK South region at all times.
- All personnel with production access shall hold active SC and NPPV3.
- EvidenceVault shall hold no escrow or master key capable of decrypting customer evidence.
- Sealed evidence shall not be mutated or deleted by EvidenceVault outside the customer's published retention schedule, save on the customer's own written instruction — for example on termination, where the customer requires the platform to be emptied. Any such destruction is carried out to a documented procedure and certificated to the customer.
- Notification of any P1 personnel-access incident within one hour, and of any P1 integrity incident affecting the customer's evidence within one working day of detection.