Skip to content
Pritect Veil
Get started
Data flow

Follow one document from upload to purge.

The security overview states what we commit to. This page puts those commitments in order, along the path a single document actually takes, so a data protection officer can complete a record of processing without booking a call.

The path

Eight points, and what exists at each one.

The same eight steps the data processing agreement describes as the nature of the processing. Read down the rail for the shape, then read the guarantees below it.

  1. Upload

    You open a case, declare who the data subject is, and add the documents you hold.

    What exists here
    Your original files, and the identifiers you declared for the data subject.
    Who can read it
    Members of your organisation whose role allows it. No one else, at any layer.

  2. Extraction

    Model involved

    The text is read out of each file. Archives are expanded and email attachments become documents of their own.

    What exists here
    A structured reading of the document text, encrypted before it is stored, alongside the original.
    Who can read it
    The component that processes documents. Your browser is never given any of it.

    Only where a scan carries no text layer. The page images go to the European model provider for recognition, and the recognised text is never written to a log.

  3. Detection

    Model involved

    The text is searched for personal data, by rule for structured identifiers and by model for the rest.

    What exists here
    Passages of your document text, in flight to the model provider and back.
    Who can read it
    The European model provider, for the duration of the call and no longer. It receives text and returns structure.

    This is the point where the model is involved. It receives passages of document text under the processing agreement, retains nothing, and never receives your case, document or account identifiers.

  4. Decision

    Every mention across every document in the case resolves to one person, and each person gets one decision.

    What exists here
    An entity for each person found, with the surfaces that led to it, encrypted under the case key.
    Who can read it
    Your operators, on the review screen. One row per person, not one row per redaction.

  5. Regeneration

    A new document is generated, containing only the text Veil decided to release.

    What exists here
    A newly generated document. Your original is untouched, where it has been all along.
    Who can read it
    Nobody yet. Nothing generated here is downloadable before the next step clears it.

  6. Verification

    Can withhold

    Every generated document is re-read by a separate component and checked against the decisions.

    What exists here
    The generated documents, and the result of the check on each one.
    Who can read it
    The verifying component, which shares no code with the thing that did the redacting.

  7. Bundle

    What cleared the check is packaged, and the case is yours to release.

    What exists here
    The redacted documents, an index of the case, and a report on how the case ran.
    Who can read it
    Members of your organisation whose role allows a release, through the same one-off links.

  8. Purge

    The case expires on the clock you set, and what is left holds no personal data.

    What exists here
    A tombstone: the case reference, the dates, the counts and the quality summary.
    Who can read it
    You, for your own accountability record. There is nothing else left to read.
The artifact that is never made

At no point on that path is there a redacted copy of your original.

In-place redaction produces one: a file with a rectangle over a name, and the name still under it. Veil never makes that file, at any stage, not even briefly. Your original stays exactly as you uploaded it and the output is a new document generated from the text alone, so there is no version of your document with something hidden inside it for anyone to find later.

In-place redactionNever made here

The panel was a name with a rectangle drawn over it and myself.

Drawn over. The characters are still in the file, underneath the rectangle.

Born-redacted renderWhat you receive

The panel was [third party b] and myself.

Generated. A different document, holding only what was released.

Stage by stage

What we commit to at each point.

Every sentence below is a commitment stated somewhere else already, on the security overview or in a published contract. The links say where, so you can cite the binding version rather than this page.

01

Upload

You open a case, declare who the data subject is, and add the documents you hold.

  • Your originals are read only for the life of the case. Veil never edits a document you uploaded, so nothing that happens later can damage the copy you already hold.
  • Storage is never browsable and holds no public object. Each file is reached through a short-lived link to that one object, issued by a route that re-checks membership and role at the moment of issue.
  • Isolation between organisations is enforced by the database rather than by application code, so a cross-organisation read is refused at the lowest layer rather than the highest.
Stated inAccess controlDPA Annex 2.1 and 2.3
02

Extraction

The text is read out of each file. Archives are expanded and email attachments become documents of their own.

  • No part of this runs in your browser and no document is copied to a laptop to be worked on. You can close the tab, and a case of several hundred documents still finishes.
  • The personal data densest in identifiers is encrypted before it reaches storage, under a key belonging to your case.
  • Archive, email and office document parsers are treated as an attack surface rather than as a convenience, with guards, budgets and fuzzing in continuous integration.
Stated inEncryption and purgeProduct integrityDPA Annex 2.2 and 2.6
03

Detection

The text is searched for personal data, by rule for structured identifiers and by model for the rest.

  • Inference happens at a European provider, under a processing agreement, and nothing is retained afterwards. Your documents are not used to train a model, ours or anyone else's, and that is a contractual commitment rather than a setting.
  • No case, document or account identifier travels with the content, so the provider is given text to read and nothing to file it under.
  • The call itself is recorded as counts and durations. The prompt, the completion and any recognised text are never written to a log.
Stated inData residencyLogging and auditSub-processors
04

Decision

Every mention across every document in the case resolves to one person, and each person gets one decision.

  • Anyone who cannot be attributed to the data subject you declared is redacted, then raised for a person to decide. There is no path anywhere in the product from unknown to disclosure.
  • Turning a redaction into a disclosure takes either a match against the identifiers you declared or an explicit human attestation, and the attestation is written to an audit record that cannot afterwards be edited or deleted. On the enterprise plan it also takes a second approver.
  • One field is deliberately not encrypted: the folded, lower-case form of a name or identifier that lets the system recognise two spellings as the same person. Encrypting it would either break that matching or leak the same information anyway, and we would rather say so here than let you assume otherwise.
Stated inEncryption and purgeAccess controlDPA Annex 2.3 and 2.5
05

Regeneration

A new document is generated, containing only the text Veil decided to release.

  • Nothing is drawn over and nothing is deleted in place. What is not on the page is not in the file, so the leak vectors that come with editing a document in place stop applying by construction rather than by care.
  • A redacted person becomes a stable typed placeholder rather than a black rectangle, so the narrative still reads and the same person reads as the same person across the whole case.
  • Each source document produces its own output, which is what makes it possible to withhold one file without costing you the rest of the bundle.
Stated inHow the output is madeDPA Annex 1.1
06

Verification

Every generated document is re-read by a separate component and checked against the decisions.

  • The check that clears a document is not the thing that redacted it, and the separation is enforced automatically in our build rather than maintained by convention. A mistake in the redaction cannot pass its own check.
  • A document the check cannot clear is withheld and the case stops, rather than being released with a warning attached. Withholding one document does not cost you the rest of the bundle, and the reason is stated in language you can act on.
  • If such a finding ever relates to a bundle you have already released, we treat it as a suspected personal data breach and notify you on the clock in the data processing agreement.
Stated inProduct integrityDPA clause 6.4DPA Annex 2.5
07

Bundle

What cleared the check is packaged, and the case is yours to release.

  • The bundle carries a manifest, so every source document you gave us is accounted for: the output it produced, or the fact that it was withheld and why.
  • Every page of every output carries the case reference, the document identifier, the page number and the time it was generated, so a page can be placed back in its case a year later.
  • A download is counted and written to the audit record, along with the release decision behind it and the person who made it.
Stated inLogging and auditDPA Annex 2.4
08

Purge

The case expires on the clock you set, and what is left holds no personal data.

  • Retention is a setting on your side, capped by your plan, not a support ticket. A released case purges on schedule and an unreleased one purges too, with warnings first.
  • The purge destroys the key belonging to the case as well as the rows. Everything encrypted under it is unreadable from that moment, wherever a copy of it survives, including in a backup.
  • The folded matching form named under Decision is deleted with the rows rather than made unreadable, so a backup taken before the purge still holds that one form until the backup itself expires.
Stated inRetentionEncryption and purgeDPA clause 7
What leaves the European Union

Nothing on this path leaves the European Union.

Every point on the rail above runs inside the Union: the database and the object storage, the components that process documents, the web functions, and the model inference. It is pinned at each one rather than defaulted, and there is no region setting for anyone to get wrong, because there is only one region. We do not transfer your material to a third country without your prior written authorisation.

The component by component list
What we never see

The list, stated rather than implied.

  • Our people do not read your documents. Access to document content in production takes an explicit, time-bound authorisation, is available to a small named group, and leaves an audit record. If we have had to use it, we tell you, and why.
  • No document content reaches a log. Loggers accept identifiers, counts, enumerated values and durations, and the property is enforced automatically on every change rather than remembered by whoever writes the line.
  • The model provider never receives a case, document or account identifier alongside your content, and retains nothing after the call.
  • Nothing you upload trains a model, ours or a sub-processor's.
  • Billing never receives document content of any kind.
  • Your browser is never given a key that could read another organisation's material, because the components holding those keys are not the ones your browser talks to.
What you get back

Four things, and the fourth outlives the case.

  • The redacted documents

    One output for each source document, generated rather than edited, each page stamped with the case reference, the document identifier, the page number and the generation time.

  • The manifest

    An index of the case: every source document, the output it produced, and for anything withheld, the reason, in language you can act on.

  • The quality report

    How the case actually ran, for your own file, including the versions of everything that made a decision in it.

  • The tombstone, after the purge

    The case reference, the dates, the counts and the quality summary, with no personal data in it, so you keep an accountability record of the disclosure you made after the material behind it is gone.

Honest scope

Where this path does not finish the job on its own.

The guarantees above hold for identifiable personal data in machine-readable text and in clean recognition of a scan. Three things sit outside that, and we would rather name them here than let you find them in a bundle.

  • Purely indirect identification

    The colleague who broke his leg skiing is identifiable to a reader who was there, and no detector resolves that. Veil surfaces this class for a person to decide instead of pretending to settle it.

  • Degraded scans and handwriting

    Where recognition confidence collapses, the pages are flagged and the case is held. Nothing passes through quietly because it was hard to read.

  • Original page imagery

    Output is generated from extracted text, so scans and signatures are not reproduced as imagery in the first version, and the bundle says so on the page rather than leaving you to notice.

All three are redacted first and raised second. None of them is resolved by guessing, and none of them reaches a bundle because nobody looked. We do not claim that any system removes everything, and we would not ask you to believe it of this one.

Your next access request does not have to eat a week.

Open a case, declare the subject, drop the documents in. Veil does the rest and shows you its working.

Get startedSee pricing