Skip to content
Trust / Centre8 documents · Sheet 01 of 05 · Updated 29 Sep 2026
Trust centre

Everything a security review asks for, in one place.

Veil handles the most sensitive material an organisation holds, on behalf of a request it is legally obliged to answer. This page is where the documents, the posture and the honest status of our certifications live.

Documents

Public, current, and no request needed.

Every document below is published in full. None of it is behind a form.

Trust / Centre6 commitments · Sheet 02 of 05 · Updated 29 Sep 2026

Commitments

What we hold ourselves to.

Six commitments that decide how the product is built, each of them visible somewhere in the documents above.

  • Privacy by construction

    Uncertainty resolves to redaction, personal data never enters a log, and a purge destroys the key rather than only the rows.

  • Security

    Tenant isolation enforced by the database, short-lived single-object storage access, encryption in transit and at rest, and envelope encryption on the densest personal data.

  • European residency

    Database, storage, workers, web functions and model inference all inside the European Union, pinned rather than defaulted.

  • Verifiable output

    Every generated document is independently verified before release, by a component separate from the redaction itself, and anything that fails is withheld.

  • Responsible automation

    European model inference, stateless calls, no training on customer data, and human review of every flagged entity.

  • Accountability

    An append-only audit log covering transitions, decisions, downloads and configuration changes, exportable by the customer.

Trust / Centre4 standards · Sheet 03 of 05 · Updated 29 Sep 2026

Certifications

Where we actually are.

Certification status, stated plainly. Nothing on this list is implied, and nothing is described as achieved before it is.

  • GDPR

    EU General Data Protection Regulation

    Self-declared

  • ISO/IEC 27001

    Information security management system

    In progress, target 2027

  • SOC 2 Type II

    Security, availability and confidentiality controls

    On the roadmap

  • ISO/IEC 27701

    Privacy information management system

    On the roadmap

We would rather tell you where we actually are than imply a certificate we do not hold. Pritect Veil is a new product inside an established group, and the certification work runs at the group level. This page changes when the status changes, not before.

Trust / Centre10 questions · Sheet 04 of 05 · Updated 29 Sep 2026

Questions

What a security review usually asks.

Ten questions, in the order a data protection officer asks them, each answer ending in the page or the clause that makes it true.

Are you a controller or a processor?

Both, for different data. We are the controller for your account, our correspondence with you and our billing records, which the Privacy notice covers. We are your processor for everything inside the documents you upload, which the Data processing agreement covers. The split matters, so it is the first section of the Privacy notice, and it is also where you will find what happens to the personal data of third parties who appear in your documents and have no relationship with us at all.

Where does the data go?

Nowhere outside the European Union in the ordinary course. Database and object storage in Frankfurt, processing workers in Frankfurt, web functions pinned to Frankfurt, model inference at a European provider. Each of those is pinned at the deployment level rather than left on a default, so there is no region setting to get wrong. Clause 8.1 of the Data processing agreement makes it a term rather than a description, and the Sub-processor list names every party and where it runs.

Who else touches it, and how do we hear when that changes?

The Sub-processor list is published in full and it is complete: a third party that is not on it does not process customer personal data for this product. Every entry is bound by a written agreement imposing obligations no less protective than the ones in our agreement with you, and we stay liable to you for what they do. We give at least thirty days' notice before adding or replacing one, so there is time to object before the change takes effect. Every change is recorded in the change log at the end of that list and published to a feed any reader can watch without telling us anything about them.

Can you read our documents?

The personal data densest in identifiers is encrypted with AES-256-GCM before it reaches storage, under a key belonging to your case that is itself wrapped by a key belonging to your organisation, and a purge destroys the case key so that what was encrypted under it is unreadable from that moment, including in a backup. Some fields are outside that and we would rather say so than let you assume otherwise. The display name of each entity, which is the fullest spelling of a name, email address or identifier as it appeared and is what the review screen shows so that a reviewer can tell who is who across documents, is not yet encrypted, and encrypting it under the case key is planned. Others are deliberately outside it: the identifiers you declare for the data subject, the external reference you give a case, which may identify a person, the names of the files in a case and of any connected folder they came from, and the folded, lower-case form of a name or identifier that lets two spellings resolve to the same person. All of them are held by our database provider, Supabase, in Frankfurt, and deleted with the rows rather than shredded, so a database backup taken before the purge holds them for as long as that backup can be restored, which is seven days. As for people, clause 2.2 of the Data processing agreement is the commitment: our personnel do not read your documents in the ordinary course, the production credentials that could reach content are held by a small number of named individuals, and we tell you if we have had to access the content of a case and why. Behind that commitment there is now a control rather than only a policy. Before anyone on that list reaches your content they open an authorisation naming your organisation, the ground for it and an expiry that cannot exceed twenty four hours, and that authorisation is written to your own audit log the moment it is granted, so you learn about it from your records rather than from ours. It is written to a record we cannot edit or delete, which outlives your account if you close it. We are being exact about what that does and does not prove: the authorisation is what is recorded, not the reading itself, because the content is reached at our storage provider where our own software does not observe it. What it means is that an access without an authorisation on your audit log is a breach of this clause that you can find without asking us.

Do you train models on our documents?

No, and we do not permit our sub-processors to. Model calls are stateless: each call carries the passage it needs and returns a structured result, and nothing from one call is carried into the next. Both are commitments in clause 5.3 of the Terms of service, not only settings, and clause 5.3 of the Data processing agreement requires every sub-processor, by written contract, to meet data protection obligations no less protective than the agreement's own.

Who inside our organisation can see what?

Four roles: owner, admin, member and viewer. A state change is never a free-form write, because every transition goes through a function in the database that validates whether this member, in this role, may make it, which means a permission is enforced where the data is rather than in the interface in front of it. Storage is never browsable and holds no public object, so a file is reached only through a short-lived link to that one object issued after membership and role are re-checked. Multi-factor authentication is available to every member on every plan and an owner can require it across the organisation.

How do we prove afterwards what happened?

State transitions, entity decisions, bundle downloads, each opening of the unredacted excerpts a reviewer reads around an entity, and configuration changes are appended through a single writer and cannot be edited afterwards. Each entry is deleted six years after it is made. The record holds identifiers, counts, enumerated values and dates and never a document excerpt, which is what makes it something we can hand over rather than something we have to redact first. You export it yourself alongside your bundles, which is also how clause 3.2 of the Data processing agreement discharges our duty to assist you with a data subject's request, and clause 7.3 keeps the export available for 30 days after termination.

What happens if a redaction is missed?

Verification is designed to catch it before release, and a finding it cannot clear withholds the document rather than warning about it, so the ordinary path is that the document never reaches the bundle and the case page flags it before release. If a hit relates to a bundle already released, clause 6.4 of the Data processing agreement makes it a suspected personal data breach rather than an open question, and the clock in clause 6.1 starts: notification without undue delay and in any event within 48 hours of our becoming aware, whether or not you have asked. Deciding whether to tell a supervisory authority or the data subjects stays yours as controller, and clause 6.2 sets out what we owe you in order to make that decision.

How do we get it all back, and then get it deleted?

A case purges automatically at the end of the retention window you configure, which defaults to 30 days after release and is capped by your plan, and an unreleased case purges after 180 days with warnings beforehand. The purge removes the stored objects, the extracted document model and the entity mentions, and destroys the case key; what survives is a tombstone with no personal data in it, holding the reference, the dates, the counts and the quality summary. Closing your organisation removes what the account held rather than leaving it dormant, and your bundles and audit records stay exportable for 30 days under clause 11.4 of the Terms of service and clause 7.3 of the Data processing agreement.

What can you show us that is not your own word for it?

Three things, and then the limit of them. The controls page maps every measure we have to the control area of ISO/IEC 27001 and SOC 2 it sits in and names, for each one, the page or the clause that already states it, with a plain text version to paste into a questionnaire. The certification table on this page says where we actually are, and nothing on it is described as achieved before it is. Clause 4.1 of the Data processing agreement commits us to making the Article 28 information available, including the current version of every document in this trust centre, and to answering a reasonable security questionnaire once a year, while clause 4.2 gives you an audit right on thirty days' written notice, once in any twelve month period and more often if a supervisory authority requires it or a personal data breach has occurred. Everything published here needs no request at all. The limit is this: no external penetration test of this product has been carried out, so there is no report and no letter from anyone who is not us, and we would rather write that sentence than let the pages above imply otherwise.

Trust / CentreThree addresses · Sheet 05 of 05 · Updated 29 Sep 2026

Security enquiries

Ask a person.

Security questionnaires, a signed data processing agreement, sub-processor notifications, or anything this page does not answer.

White Label Consultancy AS, Fjordalleen 16, 0250 Oslo, Norway. Reported security issues are acknowledged within two business days, under our coordinated disclosure policy.

Pritect Veil / Get startedGet started · See pricing

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

Open a case, declare the subject, drop the documents in. Veil redacts, raises what it is not sure of, and shows you its working.