Privilege doesn’t expire
Neither does our encryption
A settlement agreement stays confidential for thirty years. Most legal software’s encryption is built to last ten. Lorne & Vale seals every document in post-quantum cryptography instead, so what’s intercepted today stays unreadable for all thirty.
Two locks, not one
Every document is sealed with a proven classical algorithm and a post-quantum one together. Both must fall before a file can be read.
Your key is yours alone
Each firm gets its own key pair, generated on first use. One firm’s key opens nothing belonging to another.
Erasure that is real
Destroy a firm’s key and its documents become unreadable everywhere at once, live storage and every backup, not just the copy you can find.
Proof you can check
Every action is chained and signed daily. An expert acting for your client can verify the whole history without taking our word for anything.
The attack that is
already happening
Nobody needs a quantum computer today to benefit from one tomorrow.
How it works
Encrypted traffic is cheap to capture and cheap to store. An adversary records it now, keeps it, and waits. When a sufficiently large quantum computer exists, everything in that archive opens at once, retroactively, including material that was perfectly safe on the day it was sent.
The European Commission considers such a machine plausible by 2040. Security agencies across Europe are not debating whether to migrate, but how fast.
Why it hits law firms hardest
Most industries encrypt data that stops mattering in a few years. A card number expires. A password gets rotated. Legal work does not behave that way.
The confidentiality you owe a client is measured in decades. The encryption protecting it should be too.
Sealed at every hop
Opened only where it must be
Four stages, each with its protection stated. No stage relies on the one before it holding. Open any stage below to see exactly what an attacker walks away with if that is the one that fails.
The file is sealed on the device before a single byte crosses the network. What travels is already ciphertext, so a compromised network sees nothing useful.
Nothing readable. What leaves your browser is already sealed under two independent locks, one classical and one post-quantum. Interception on the network gets ciphertext, the same ciphertext whether the network is a café hotspot or a nation-state’s backbone.
The envelope is opened in memory, only long enough to scan the file for malware and prepare the preview your team will read. It is never written to disk in the clear.
Nothing stored. This is the only stage where the document briefly exists unencrypted, and only in server memory, for the seconds a malware scan and preview take. It is never written to disk in the clear, so a server breach finds no plaintext file sitting there waiting.
The document is resealed under your firm’s own key, bound to your firm and to its exact storage location. A file copied elsewhere in the storage layer will not open, even with the right key.
Nothing that opens elsewhere. Every firm’s documents are sealed under a key unique to that firm and bound to its exact storage location. A stolen disk, a misconfigured bucket, even an entire cloud account, hands over files that will not open anywhere else, for anyone else.
Downloads and previews are sealed again on the way down, to single-use keys your browser generates for that one transfer and then discards.
Nothing reusable. Downloads and previews travel under a key your own browser generates for that one transfer and discards immediately after. Replay the same link tomorrow, and the key that opened it is already gone.
Every one of those has to fail for a document to end up in the wrong hands. None of them has to hold just because the one before it did. That is what defence in depth actually means, checked stage by stage rather than taken on faith.
Seal a secret,
right here
This is not a mock-up. Your browser is about to run real AES-256-GCM, the same symmetric cipher that seals every document on the platform. Nothing you type leaves this page.
Honest footnote: this bench runs the symmetric layer, AES-256-GCM, locally for the demonstration. In the product, the key itself is established through the hybrid X25519 + ML-KEM-1024 exchange described above, so no shared secret ever travels in the clear.
Give the attacker everything
Watch them get nowhere
Every document is sealed with a key drawn from a pool of combinations 78 digits long. Not 78 combinations. A number that takes 78 digits to write. Hand the attacker whatever you like below, the arithmetic does the rest.
Put another way: guessing the key on the first try is thousands of times less likely than winning the EuroMillions jackpot nine weeks in a row, with a single ticket each week.
A quantum computer changes the game for the old locks: it defeats the classical algorithm outright. That is the entire reason every document here carries a second lock, ML-KEM-1024, built on different mathematics and sized in the strongest category NIST publishes precisely to withstand that machine. The wall you just measured is the one that remains standing after the quantum computer has done its worst.
Based on the best attacks publicly known today, with every assumption rounded in the attacker’s favour. Nobody can promise the future, which is why there are two locks of different kinds, and why every seal records its algorithm, ready to be upgraded the day something stronger is published.
Two locks of
different kinds
Post-quantum algorithms are new. They have had years of scrutiny, not decades, and several early candidates were broken by ordinary computers before quantum ones ever arrived. Betting a client’s file on any single new algorithm would be careless.
So we do not. Every seal combines X25519, an elliptic-curve algorithm that has protected the internet for twenty years, with ML-KEM-1024, the post-quantum standard published by NIST. An attacker has to break both, and the two rest on completely unrelated mathematics. If one fails, your documents are still shut.
This is the approach European security agencies recommend during the transition, and it is the reason we chose it. France’s ANSSI, for example, insists on hybridisation wherever post-quantum protection is needed, and recommends it particularly for products meant to protect information well beyond 2030. That is a fair description of a law firm’s document store.
The highest tier published
ML-KEM comes in three strengths. We use the strongest, ML-KEM-1024, and sign our audit checkpoints with ML-DSA-87, its counterpart at the same level. Most deployments settle for the middle option because it is faster. On documents that must stay shut for decades, that trade is the wrong way round.
Built to be replaced
Every sealed file records which algorithm sealed it. When a stronger standard arrives, new documents move to it immediately while older ones stay readable under the algorithm that sealed them. No forced migration, no file left behind, no outage to change locks.
Neither lock has ever been broken. This simulates what happens if one someday is, not how easily that could happen.
Document: shut
Deleting a row is a promise
Destroying a key is a fact
When a client exercises their right to erasure, most software deletes a database row and hopes the backups follow. Nobody can prove what happened to the copy on last quarter’s backup tape.
Because every firm holds its own key, we can do something stronger. Destroy the key and every document sealed under it becomes permanently unreadable, in live storage and in every backup that exists, at the same instant. There is no copy to hunt down, because no copy can be opened. The record of the destruction stays, so the erasure itself is auditable.
What your DPO can put in writing
That the data is not merely deleted but cryptographically destroyed, that the destruction reaches backups without depending on their retention cycle, and that the act is timestamped in an audit trail they can verify independently. Few processors can offer the second point honestly. It is the one that usually gets asked about second.
The usual way: delete the row
What most software does when a client asks to be erased.
Our way: destroy the key
Every document is sealed under the firm’s key. Erasure destroys the key.
Verifiable without
trusting us
Every action in the platform is written to an append-only log, and each entry carries a cryptographic fingerprint of the one before it. Altering a single historical entry breaks every fingerprint that follows, which is exactly the property you want from a record that may one day be examined.
Once a day, the head of each firm’s chain is signed with three independent signature schemes at once: ML-DSA-87 and SLH-DSA, both post-quantum, and Ed25519, the classical scheme. Three different families of mathematics, so a weakness discovered in one does not invalidate the evidence.
The public halves of those signing keys are published inside the platform. An expert instructed by your client can take the log, take the published keys, and verify the entire history without any cooperation from us, and without us ever handing over a secret. An audit trail that only its author can verify is not evidence. This one is.
Each fingerprint you see is a genuine SHA-256 of the entry plus the fingerprint before it, computed by your browser this second. Change any entry and every fingerprint downstream stops matching. That is the whole mechanism, and it is why a rewrite cannot pass unnoticed.
The unglamorous half,
which matters more
Nobody will break ML-KEM-1024 to read your files. They will look for a missing permission check, a stolen password, or a forgotten test account. That is where most of the work goes.
Separation between firms
Every table carrying client data is protected at the database level, not by application code that could forget. One firm’s queries cannot reach another firm’s rows, and a test proving it runs on every single change we ship, across firms, non-members, and signed-out visitors alike.
Every route, checked
An automated check runs over the whole application on each change and fails the build if any route can reach client data without first establishing who is asking. Not a review that happened once, an invariant that holds on every deployment.
Two-factor authentication
Available to everyone, and enforceable across the whole firm by its owners. Partners can require it of every fee earner without needing our help.
Files treated as hostile
Uploads are size-bounded, type-checked, and scanned for malware before anyone can open them. Nothing is released to your team until it comes back clean.
What we do not
claim
This page is written for the person at your firm whose job is to say no. That person has read a lot of security pages and is looking for the sentence that is not quite true. Here is what we would rather tell you ourselves.
Stated plainly
This is not zero-knowledge encryption. Our servers open each document briefly in memory to scan it for malware and build the preview your team reads. A design where we could never open a file would rule both of those out. We think that trade is wrong for legal work, and we would rather describe it accurately than borrow a phrase that sounds stronger.
We use NIST-standardised algorithms. We are not FIPS certified. Implementing a standardised algorithm and holding a certification are different things, and only one of them is ours to claim.
Our approach follows ANSSI’s published recommendations on hybridisation. We are not ANSSI certified, and hold no SecNumCloud qualification.
No external penetration test or independent cryptographic review has been completed yet. Both are planned before we take on firms at scale. Until they are done, this page describes engineering we have tested ourselves, which is not the same as engineering a third party has tried to break.
Every claim above this box is something we can show you in the product or in the code. If your reviewer wants to go through it line by line, that is a conversation we enjoy.
Where enquiry data travels
Nothing more
Everything above this point is about documents your firm stores. Before a document ever exists, there is a smaller, earlier journey: the prospect’s enquiry, triaged by AI and routed through your own automation. Different data, different journey, different protections, stated with the same honesty.
Website form or connected inbox, whatever the hour.
n8n routes the enquiry under your firm’s own workflow: your rules, your storage destination, your recipients.
Administrative triage of a de-identified enquiry, reached only through a server-side proxy. The prospect’s name, email, phone, and company are replaced with neutral tokens before this hop; real details are restored only afterwards, inside your workflow.
The brief, score, and log land in Excel, Google Sheets, or the CRM your firm already uses.
A person at your firm reviews every brief before anything else happens.
What the AI sees
What it never sees
The one thing we do seal here, and why nothing else can be
Two hops in this journey sit outside our control entirely. The network path to the AI provider is ordinary TLS, negotiated by standard infrastructure, not the hybrid envelope described above: there is no lever in application code to change what a third party’s server supports. And the enquiry text itself cannot be encrypted under a Lorne & Vale key before that call, because the model has to read it in the clear to triage it. De-identification, replacing the prospect’s name, email, and phone with placeholders, is the real control on that hop, and it is a different mechanism from encryption entirely.
What we do control is the one place this data actually rests with us: the token map connecting each placeholder back to the real value. That map is now sealed under your firm’s own hybrid post-quantum key, the same X25519 + ML-KEM-1024 construction that protects your documents, bound to the specific enquiry so a stolen row cannot be reattached elsewhere. It is the only part of this pipeline post-quantum cryptography can honestly reach, and it is the part that matters most: it is what would let anyone reconstruct a prospect’s identity from a de-identified record.
What is collected,
and what happens to it
The intake form collects only the fields needed to classify, route, and log an enquiry: name, contact details, organisation, practice area, a short description of the matter, urgency, and preferred contact method. During a pilot the service collects no documents of any kind, including identity, medical, financial, or court papers.
Before the enquiry is sent to the AI provider, the prospect’s direct identifiers, their name, email address, phone number, and company, together with any email address or phone number appearing in the message text, are replaced with neutral tokens. The real details are restored only after the AI response, inside your workflow. Third-party names are retained so your conflict screening still works.
The de-identified enquiry is then sent to the AI provider for triage. Enquiry data sent through the provider’s API is excluded from AI model training by default, and is retained by the provider for a maximum of 30 days for abuse monitoring before deletion, unless the provider is legally required to retain it.
Each firm runs on its own workflow configuration, with its own routing rules, storage destination, and recipient list. Enquiry data is not pooled or shared across firms. Administrative access follows least privilege and is limited to named operators.
3 parties
Clear ownership
Secure the platform beneath
Model hosting, platform encryption, physical and infrastructure security, and the independent certifications that come with it.
Secures the application
Document encryption and key management, separation between firms, access control, sub-processor management, and incident notification.
Controls legal decisions
All legal advice and professional judgement, conflict checks, client acceptance, and privacy notices to clients.
The certifications,
attributed honestly
Seven independent checks stand behind the infrastructure your documents run on. Tap through them to see what each one actually lets your reviewer sign off on, not just the acronym on a badge.
Lorne & Vale runs its AI processing on OpenAI’s API. OpenAI’s infrastructure is independently audited against recognised security, privacy, and AI governance standards, and current certificates are published on the OpenAI Trust Portal.
What it verifiesAn independent US auditor tested OpenAI’s security, availability, and confidentiality controls in live operation over several months, not a policy binder reviewed once.
Why it matters to your firmType II is the version most vendor-risk questionnaires ask for by name. It shows the controls held up continuously, not that they existed on the day of the visit.
What it verifiesThe current edition of the world’s benchmark standard for an information security management system, independently audited and reissued roughly every three years, with surveillance visits in between.
Why it matters to your firmIt is the certificate your own case-management vendor, or your professional indemnity insurer, is most likely to already hold, so a reviewer can compare like with like.
What it verifiesCloud-specific security controls layered on top of ISO 27001, covering what’s unique to running on infrastructure someone else operates: shared responsibility, virtualisation, administrator access.
Why it matters to your firmYour documents sit on infrastructure Lorne & Vale does not operate. This is the standard written for exactly that arrangement, not a generic control set stretched to fit it.
What it verifiesA code of practice for protecting personal data specifically when a cloud provider is processing it on someone else’s instructions, rather than acting as its owner.
Why it matters to your firmYour clients’ personal data passes through this infrastructure. This is the standard written for that exact role, processor rather than controller, which is also how the DPA between your firm and Lorne & Vale describes it.
What it verifiesAn extension of ISO 27001 into privacy management, about as close as anything gets to a certifiable GDPR management framework.
Why it matters to your firmIt gives a DPO a paper trail that maps onto UK GDPR and EU GDPR obligations directly, rather than a generic security certificate someone has to translate into privacy terms by hand.
What it verifiesThe first international management-system standard written specifically for AI, covering how an organisation governs a model’s risk and behaviour across its lifecycle, not only its security.
Why it matters to your firmAlmost nothing your firm evaluates today can show this one yet. It answers the newest question in the room: who is governing the model, not just the servers underneath it.
What it verifiesA public registry, run by the Cloud Security Alliance, where cloud providers publish detailed control assessments against a framework built specifically for cloud services rather than a generic one.
Why it matters to your firmIt is built for specialists. If your firm’s IT reviewer wants to go beyond a certificate PDF, this is the document written for someone doing exactly that.
Descriptions above summarise the public scope of each standard, not a claim about this platform’s own controls. OpenAI’s current certificates and their exact scope are published on the OpenAI Trust Portal, linked above.
OpenAI’s infrastructure
The seven marks above, current on the OpenAI Trust Portal and re-verified on the cycle each one runs to, not just at the moment the account was opened.
Lorne & Vale, the company
The company is founder-operated today, and it applies every control described elsewhere on this page. No SOC 2 or ISO certificate of its own yet, and nothing here implies one. Independent certification of the company itself is on the roadmap as it grows.
Most vendors let a platform’s certifications imply more than they themselves have earned. We would rather draw the line exactly where it sits, so your reviewer never has to find it on their own.
Data protection,
by structure
Under the UK GDPR and EU GDPR, your firm is the data controller and Lorne & Vale is a data processor acting on your documented instructions. Where the AI provider processes enquiry data, it does so as a sub-processor. Retention periods are agreed with your firm. Lorne & Vale supports data-subject requests as processor and will notify your firm without undue delay on becoming aware of a personal-data breach affecting your data.
The pilot security pack
Prepared for your firm before go-live, so your reviewer signs off on documents, not promises:
On its way. The pack goes out from a founder, usually the same day.
Bring your hardest
security question
Fifteen minutes with a founder. If your reviewer wants to interrogate the cryptography, the key handling, or the separation between firms, bring them along. We would rather answer it now than in a questionnaire.