The measures, and the control area each one sits in.

A security questionnaire asks the same questions in the vocabulary of whichever framework the reviewer works from. This page is our answer to those questions once, in one table, with a plain text version underneath that you can paste into the questionnaire itself.

Read this first

What this page is, and what it is not.

This page is our own assessment of which control areas each measure addresses. It is not a certification and it is not an audit opinion. We hold no certification against either framework; where we are on that is stated in full on the trust centre, and that statement is the authoritative one. A mapping here is our reading, offered so that a reviewer working from a framework can find the measure that answers each area, and a reviewer is entitled to read it differently.

So the rows below say that a measure is aligned with a control area, and they say nothing stronger than that. The one word in this vocabulary that is ever accurate here belongs to the law rather than to a framework: the General Data Protection Regulation places an obligation on you as controller, and a measure below exists in part to help you stay compliant with the GDPR when you answer an access request. A framework identifier carries no such force. It is a pointer to where a reviewer should look.

Our certification status, in full

ISO/IEC 27001:2022: Annex A control references from the 2022 edition.
SOC 2, 2017 Trust Services Criteria: Criteria references from the 2017 criteria as revised in 2022.

Trust / Controls21 controls · Sheet 02 of 03 · Updated 29 Sep 2026

The measures

Every measure, stated where it already binds.

Every statement below is published somewhere else already, on the security overview or in a clause of a contract you can read in full. The last column says where, so you can cite the binding version rather than this page.

Each measure, the control areas it is aligned with, and where it is already stated
Measure	What we do	Aligned with	Stated in
Residency and tenant isolation	Every component that touches your documents runs in the European Union, pinned at the deployment level rather than left on a default, so there is no region setting to get wrong. Isolation between organisations is enforced by the database on every tenant table rather than by application code, which means a cross-organisation read is refused at the lowest layer rather than the highest.	ISO/IEC 27001A.5.23, A.8.3 SOC 2CC6.1	Data residency DPA Annex 2.1 DPA clause 8.1
Encryption and crypto shredding	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 TLS covers every hop in transit. A purge destroys the case key, so what was encrypted under it is unreadable from that moment wherever a copy of it survives, including in a backup. Some fields are outside this 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 this: 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 still holds them for as long as that backup can be restored, which is seven days.	ISO/IEC 27001A.8.24, A.8.10 SOC 2CC6.1, C1.2	Encryption and purge DPA Annex 2.2
Retiring an organisation key	The key that wraps your case keys can be retired and replaced, by the owner of your organisation, on request or on whatever cadence you set for yourself. Every case key is unwrapped under the old organisation key and wrapped again under the new one, in a single transaction that either completes or changes nothing at all, and no document, page or bundle is rewritten. We would rather be plain about what this is not: nothing is destroyed and nothing is recovered by it, no case key itself changes, and it is not a remedy for a breach of the data under those keys. What it gives you is that a copy of the old organisation key opens nothing once the rotation is done.	ISO/IEC 27001A.8.24 SOC 2CC6.1	Encryption and purge DPA Annex 2.2
Object access through single-object links	Storage is never browsable and holds no public object, and no listing token is issued at any time. Each file is reached through a short-lived link to that one object, issued by a server route that re-checks membership and role at the moment of issue. The lifetimes themselves are in Annex 2 of the data processing agreement rather than on this page, so a reader who needs the number has it in the version that binds us.	ISO/IEC 27001A.5.15, A.8.3 SOC 2CC6.1, CC6.3	Access control DPA Annex 2.3
Roles, and the doors a state change goes through	Four roles: owner, admin, member and viewer. A state change is never a free-form write. Every transition goes through a function in the database that validates whether this member, in this role, may make it, so a permission is enforced where the data is rather than in the interface in front of it.	ISO/IEC 27001A.5.15, A.5.18, A.8.2 SOC 2CC6.2, CC6.3	Access control DPA Annex 2.3
Multi-factor authentication	Multi-factor authentication is available to every member on every plan, and an owner can require it across the whole organisation, in which case a member without a verified factor is held at enrolment before reaching any case. Our own administrative console requires it unconditionally and cannot be reached without it. On the Business plan an organisation can also send its members through its own identity provider by SAML single sign-on, against a domain it has proved by DNS, and an owner can require it for everyone, in which case a member who signed in with a password is held at a sign-in page before reaching any case. Dual control is committed in the enterprise agreement and not yet released, and no row on this page claims it as a control we hold today.	ISO/IEC 27001A.5.17, A.8.5 SOC 2CC6.1	Access control DPA Annex 2.3
The append-only audit log, and its export	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 can export it with your bundles, and clause 7.3 keeps that available for 30 days after termination.	ISO/IEC 27001A.8.15, A.5.33 SOC 2CC7.2	Logging and audit DPA Annex 2.4 DPA clause 7.3
No personal data in application logs	Loggers accept identifiers, counts, enumerated values and durations, and nothing else. A value that is not one of those is replaced rather than shortened, so a rejected value never appears even partially, and the rule is applied automatically on every change rather than remembered by whoever writes the line. It is not a filter that makes unsafe logging safe. It is the last check on a line that should not have been carrying the value in the first place.	ISO/IEC 27001A.8.11, A.8.15 SOC 2C1.1	Logging and audit DPA Annex 2.4
Constrained egress from the component that reads documents	The component that handles document content has no general outbound network access. It reaches an explicitly allowed set of destinations and nothing else, extended only by a connector your organisation chooses to enable, and the allowance is checked on every hop of a redirect rather than only on the first request. This is a guard against an accident, a misconfiguration or a dependency that starts calling home. It is not exfiltration prevention, and we state its limit here rather than let it be read as a boundary it is not.	ISO/IEC 27001A.8.20, A.8.23 SOC 2CC6.6, CC6.7	Product integrity DPA Annex 2.6
Hostile input handling and fuzzing	Archive, email and office document parsers are treated as an attack surface rather than as a convenience: guards against malicious archives, a recursion depth cap, per-job memory and time budgets, and fuzzing that runs on every change with the inputs that have previously failed replayed first.	ISO/IEC 27001A.8.26, A.8.29 SOC 2CC7.1	Product integrity DPA Annex 2.6
Independent verification of every generated document	Every generated document is re-read and checked by a component that shares no code with the thing that redacted it, and the separation is enforced automatically in our build rather than maintained by convention, so a mistake in the redaction cannot pass its own check. A document the check cannot clear is withheld from the bundle rather than released with a warning attached, and withholding one document does not cost you the rest of the bundle.	ISO/IEC 27001A.8.27, A.8.29 SOC 2CC8.1	Product integrity DPA Annex 2.5
Detection health gates	A run whose detection quality falls below what the case needs stops the case, rather than completing quietly having found less than it should have. Failing closed is the rule everywhere in the product: there is no code path from an unattributed entity to disclosure, anywhere.	ISO/IEC 27001A.8.16, A.8.29 SOC 2CC7.2	Product integrity DPA Annex 2.5
The labelled corpus gate in continuous integration	Every change that could affect detection quality is measured against a labelled corpus before it can ship. A change that finds fewer of the planted third parties, or that starts removing the data subject, does not merge, and a person accepting the numbers is a required act rather than an automatic one.	ISO/IEC 27001A.8.29, A.8.32 SOC 2CC8.1	Product integrity DPA Annex 2.5
Retention and purge	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, so that you keep an accountability record of the disclosure you made.	ISO/IEC 27001A.8.10, A.5.34 SOC 2C1.2	Retention DPA clause 7.1 DPA clause 7.2
Closing an organisation	You can end the agreement by closing your account, and closing it removes what the account held rather than leaving it dormant. Your bundles and audit records stay exportable for 30 days under clause 11.4, and after that everything is deleted on the schedule the retention row above describes, unless a law requires us to keep something, in which case we tell you what and why.	ISO/IEC 27001A.5.11, A.8.10 SOC 2C1.2	Terms clause 11.1 Terms clause 11.4 DPA clause 7.3
Backup and recovery	The database is backed up daily, the backups can be restored for seven days, and they are held in the same region as the database itself, so recovering from one does not move personal data out of the European Union.	ISO/IEC 27001A.8.13, A.5.30 SOC 2A1.2	Data residency DPA Annex 2.6
Availability, and where it is reported	Availability of the web application is reported on Veil's own public status page at status.veil.pritect.ai, which covers this product and no other, hosted away from our own infrastructure so that it does not go down with the thing it reports on. A check calls the application and the page records whether it answered, which is the whole of what is automatic about it. Anything about the processing pipeline is posted there by a person, because no monitor watches a case through to release and a page implying one would be telling you something we do not know. And the page is an operational courtesy rather than a service level: clause 2.5 of the terms is explicit that there is no contractual uptime commitment unless one is separately agreed in writing, and clause 8.3 is the general form of the same position.	ISO/IEC 27001A.8.16, A.5.24 SOC 2CC2.3, CC7.2	Terms clause 2.5 Terms clause 8.3 Status page
Secure development and change control	Every change is reviewed before it merges, dependencies are scanned, and secrets are held in a managed store rather than in source control. The measures on this page that can be enforced by the build are enforced by the build rather than by a checklist: the dependency edge that keeps verification independent, the rule against writing a raw string into a logger, and the corpus gate all fail a change rather than warn about it.	ISO/IEC 27001A.8.25, A.8.28, A.8.32 SOC 2CC8.1	Product integrity DPA Annex 2.6
Incident response, and the breach clock	Clause 6.1 of the data processing agreement commits us to notifying you without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting your personal data. Clause A2.7 commits us to the written procedure behind it, which is where the moment awareness begins is defined and recorded, so the start of the clock is a fact in a record rather than somebody's recollection. Deciding whether to notify a supervisory authority or the data subjects is yours as controller under clause 6.3, and clause 6.2 sets out what we owe you in order to make that decision.	ISO/IEC 27001A.5.24, A.5.26 SOC 2CC7.3, CC7.4	If something goes wrong DPA clause 6.1 DPA Annex 2.7
Coordinated disclosure	There is a published policy saying what you may test, how to tell us what you found and what we do about it, and it is the written agreement that makes testing within its terms permitted rather than prohibited under clause 2.4 of the acceptable use policy. A report is acknowledged within two business days. Where a report shows that customer personal data has been exposed, the breach clock in the row above runs on its own, independently of anything else happening with the report.	ISO/IEC 27001A.5.24, A.6.8 SOC 2CC2.3, CC7.3	Coordinated disclosure policy Acceptable use policy clause 2.4
Sub-processor governance	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 data protection obligations no less protective than the ones in our own agreement with you, and we remain liable to you for what they do. We give at least thirty days' notice before adding or replacing one, and every change is recorded in the list itself and published to a feed that any reader can watch without telling us anything about them.	ISO/IEC 27001A.5.19, A.5.20, A.5.22 SOC 2CC9.2	Sub-processor list DPA clause 5.2 Change feed

Trust / ControlsOne block · Sheet 03 of 03 · Updated 29 Sep 2026

For the questionnaire

The same rows, as plain text.

One line per measure, with its control areas and the pages that state it. Copy it into the questionnaire rather than retyping it, so that what you send and what we publish are the same words.

Residency and tenant isolation. Every component that touches your documents runs in the European Union, pinned at the deployment level rather than left on a default, so there is no region setting to get wrong. Isolation between organisations is enforced by the database on every tenant table rather than by application code, which means a cross-organisation read is refused at the lowest layer rather than the highest. Aligned with: ISO/IEC 27001:2022 A.5.23, A.8.3; SOC 2, 2017 Trust Services Criteria CC6.1. Stated in: Data residency https://veil.pritect.ai/security#residency; DPA Annex 2.1 https://veil.pritect.ai/trust/dpa#sA2-A2-1; DPA clause 8.1 https://veil.pritect.ai/trust/dpa#s8-8-1.
Encryption and crypto shredding. 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 TLS covers every hop in transit. A purge destroys the case key, so what was encrypted under it is unreadable from that moment wherever a copy of it survives, including in a backup. Some fields are outside this 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 this: 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 still holds them for as long as that backup can be restored, which is seven days. Aligned with: ISO/IEC 27001:2022 A.8.24, A.8.10; SOC 2, 2017 Trust Services Criteria CC6.1, C1.2. Stated in: Encryption and purge https://veil.pritect.ai/security#encryption; DPA Annex 2.2 https://veil.pritect.ai/trust/dpa#sA2-A2-2.
Retiring an organisation key. The key that wraps your case keys can be retired and replaced, by the owner of your organisation, on request or on whatever cadence you set for yourself. Every case key is unwrapped under the old organisation key and wrapped again under the new one, in a single transaction that either completes or changes nothing at all, and no document, page or bundle is rewritten. We would rather be plain about what this is not: nothing is destroyed and nothing is recovered by it, no case key itself changes, and it is not a remedy for a breach of the data under those keys. What it gives you is that a copy of the old organisation key opens nothing once the rotation is done. Aligned with: ISO/IEC 27001:2022 A.8.24; SOC 2, 2017 Trust Services Criteria CC6.1. Stated in: Encryption and purge https://veil.pritect.ai/security#encryption; DPA Annex 2.2 https://veil.pritect.ai/trust/dpa#sA2-A2-2.
Object access through single-object links. Storage is never browsable and holds no public object, and no listing token is issued at any time. Each file is reached through a short-lived link to that one object, issued by a server route that re-checks membership and role at the moment of issue. The lifetimes themselves are in Annex 2 of the data processing agreement rather than on this page, so a reader who needs the number has it in the version that binds us. Aligned with: ISO/IEC 27001:2022 A.5.15, A.8.3; SOC 2, 2017 Trust Services Criteria CC6.1, CC6.3. Stated in: Access control https://veil.pritect.ai/security#access; DPA Annex 2.3 https://veil.pritect.ai/trust/dpa#sA2-A2-3.
Roles, and the doors a state change goes through. Four roles: owner, admin, member and viewer. A state change is never a free-form write. Every transition goes through a function in the database that validates whether this member, in this role, may make it, so a permission is enforced where the data is rather than in the interface in front of it. Aligned with: ISO/IEC 27001:2022 A.5.15, A.5.18, A.8.2; SOC 2, 2017 Trust Services Criteria CC6.2, CC6.3. Stated in: Access control https://veil.pritect.ai/security#access; DPA Annex 2.3 https://veil.pritect.ai/trust/dpa#sA2-A2-3.
Multi-factor authentication. Multi-factor authentication is available to every member on every plan, and an owner can require it across the whole organisation, in which case a member without a verified factor is held at enrolment before reaching any case. Our own administrative console requires it unconditionally and cannot be reached without it. On the Business plan an organisation can also send its members through its own identity provider by SAML single sign-on, against a domain it has proved by DNS, and an owner can require it for everyone, in which case a member who signed in with a password is held at a sign-in page before reaching any case. Dual control is committed in the enterprise agreement and not yet released, and no row on this page claims it as a control we hold today. Aligned with: ISO/IEC 27001:2022 A.5.17, A.8.5; SOC 2, 2017 Trust Services Criteria CC6.1. Stated in: Access control https://veil.pritect.ai/security#access; DPA Annex 2.3 https://veil.pritect.ai/trust/dpa#sA2-A2-3.
The append-only audit log, and its export. 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 can export it with your bundles, and clause 7.3 keeps that available for 30 days after termination. Aligned with: ISO/IEC 27001:2022 A.8.15, A.5.33; SOC 2, 2017 Trust Services Criteria CC7.2. Stated in: Logging and audit https://veil.pritect.ai/security#logging; DPA Annex 2.4 https://veil.pritect.ai/trust/dpa#sA2-A2-4; DPA clause 7.3 https://veil.pritect.ai/trust/dpa#s7-7-3.
No personal data in application logs. Loggers accept identifiers, counts, enumerated values and durations, and nothing else. A value that is not one of those is replaced rather than shortened, so a rejected value never appears even partially, and the rule is applied automatically on every change rather than remembered by whoever writes the line. It is not a filter that makes unsafe logging safe. It is the last check on a line that should not have been carrying the value in the first place. Aligned with: ISO/IEC 27001:2022 A.8.11, A.8.15; SOC 2, 2017 Trust Services Criteria C1.1. Stated in: Logging and audit https://veil.pritect.ai/security#logging; DPA Annex 2.4 https://veil.pritect.ai/trust/dpa#sA2-A2-4.
Constrained egress from the component that reads documents. The component that handles document content has no general outbound network access. It reaches an explicitly allowed set of destinations and nothing else, extended only by a connector your organisation chooses to enable, and the allowance is checked on every hop of a redirect rather than only on the first request. This is a guard against an accident, a misconfiguration or a dependency that starts calling home. It is not exfiltration prevention, and we state its limit here rather than let it be read as a boundary it is not. Aligned with: ISO/IEC 27001:2022 A.8.20, A.8.23; SOC 2, 2017 Trust Services Criteria CC6.6, CC6.7. Stated in: Product integrity https://veil.pritect.ai/security#integrity; DPA Annex 2.6 https://veil.pritect.ai/trust/dpa#sA2-A2-6.
Hostile input handling and fuzzing. Archive, email and office document parsers are treated as an attack surface rather than as a convenience: guards against malicious archives, a recursion depth cap, per-job memory and time budgets, and fuzzing that runs on every change with the inputs that have previously failed replayed first. Aligned with: ISO/IEC 27001:2022 A.8.26, A.8.29; SOC 2, 2017 Trust Services Criteria CC7.1. Stated in: Product integrity https://veil.pritect.ai/security#integrity; DPA Annex 2.6 https://veil.pritect.ai/trust/dpa#sA2-A2-6.
Independent verification of every generated document. Every generated document is re-read and checked by a component that shares no code with the thing that redacted it, and the separation is enforced automatically in our build rather than maintained by convention, so a mistake in the redaction cannot pass its own check. A document the check cannot clear is withheld from the bundle rather than released with a warning attached, and withholding one document does not cost you the rest of the bundle. Aligned with: ISO/IEC 27001:2022 A.8.27, A.8.29; SOC 2, 2017 Trust Services Criteria CC8.1. Stated in: Product integrity https://veil.pritect.ai/security#integrity; DPA Annex 2.5 https://veil.pritect.ai/trust/dpa#sA2-A2-5.
Detection health gates. A run whose detection quality falls below what the case needs stops the case, rather than completing quietly having found less than it should have. Failing closed is the rule everywhere in the product: there is no code path from an unattributed entity to disclosure, anywhere. Aligned with: ISO/IEC 27001:2022 A.8.16, A.8.29; SOC 2, 2017 Trust Services Criteria CC7.2. Stated in: Product integrity https://veil.pritect.ai/security#integrity; DPA Annex 2.5 https://veil.pritect.ai/trust/dpa#sA2-A2-5.
The labelled corpus gate in continuous integration. Every change that could affect detection quality is measured against a labelled corpus before it can ship. A change that finds fewer of the planted third parties, or that starts removing the data subject, does not merge, and a person accepting the numbers is a required act rather than an automatic one. Aligned with: ISO/IEC 27001:2022 A.8.29, A.8.32; SOC 2, 2017 Trust Services Criteria CC8.1. Stated in: Product integrity https://veil.pritect.ai/security#integrity; DPA Annex 2.5 https://veil.pritect.ai/trust/dpa#sA2-A2-5.
Retention and purge. 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, so that you keep an accountability record of the disclosure you made. Aligned with: ISO/IEC 27001:2022 A.8.10, A.5.34; SOC 2, 2017 Trust Services Criteria C1.2. Stated in: Retention https://veil.pritect.ai/security#retention; DPA clause 7.1 https://veil.pritect.ai/trust/dpa#s7-7-1; DPA clause 7.2 https://veil.pritect.ai/trust/dpa#s7-7-2.
Closing an organisation. You can end the agreement by closing your account, and closing it removes what the account held rather than leaving it dormant. Your bundles and audit records stay exportable for 30 days under clause 11.4, and after that everything is deleted on the schedule the retention row above describes, unless a law requires us to keep something, in which case we tell you what and why. Aligned with: ISO/IEC 27001:2022 A.5.11, A.8.10; SOC 2, 2017 Trust Services Criteria C1.2. Stated in: Terms clause 11.1 https://veil.pritect.ai/trust/terms#s11-11-1; Terms clause 11.4 https://veil.pritect.ai/trust/terms#s11-11-4; DPA clause 7.3 https://veil.pritect.ai/trust/dpa#s7-7-3.
Backup and recovery. The database is backed up daily, the backups can be restored for seven days, and they are held in the same region as the database itself, so recovering from one does not move personal data out of the European Union. Aligned with: ISO/IEC 27001:2022 A.8.13, A.5.30; SOC 2, 2017 Trust Services Criteria A1.2. Stated in: Data residency https://veil.pritect.ai/security#residency; DPA Annex 2.6 https://veil.pritect.ai/trust/dpa#sA2-A2-6.
Availability, and where it is reported. Availability of the web application is reported on Veil's own public status page at status.veil.pritect.ai, which covers this product and no other, hosted away from our own infrastructure so that it does not go down with the thing it reports on. A check calls the application and the page records whether it answered, which is the whole of what is automatic about it. Anything about the processing pipeline is posted there by a person, because no monitor watches a case through to release and a page implying one would be telling you something we do not know. And the page is an operational courtesy rather than a service level: clause 2.5 of the terms is explicit that there is no contractual uptime commitment unless one is separately agreed in writing, and clause 8.3 is the general form of the same position. Aligned with: ISO/IEC 27001:2022 A.8.16, A.5.24; SOC 2, 2017 Trust Services Criteria CC2.3, CC7.2. Stated in: Terms clause 2.5 https://veil.pritect.ai/trust/terms#s2-2-5; Terms clause 8.3 https://veil.pritect.ai/trust/terms#s8-8-3; Status page https://status.veil.pritect.ai.
Secure development and change control. Every change is reviewed before it merges, dependencies are scanned, and secrets are held in a managed store rather than in source control. The measures on this page that can be enforced by the build are enforced by the build rather than by a checklist: the dependency edge that keeps verification independent, the rule against writing a raw string into a logger, and the corpus gate all fail a change rather than warn about it. Aligned with: ISO/IEC 27001:2022 A.8.25, A.8.28, A.8.32; SOC 2, 2017 Trust Services Criteria CC8.1. Stated in: Product integrity https://veil.pritect.ai/security#integrity; DPA Annex 2.6 https://veil.pritect.ai/trust/dpa#sA2-A2-6.
Incident response, and the breach clock. Clause 6.1 of the data processing agreement commits us to notifying you without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting your personal data. Clause A2.7 commits us to the written procedure behind it, which is where the moment awareness begins is defined and recorded, so the start of the clock is a fact in a record rather than somebody's recollection. Deciding whether to notify a supervisory authority or the data subjects is yours as controller under clause 6.3, and clause 6.2 sets out what we owe you in order to make that decision. Aligned with: ISO/IEC 27001:2022 A.5.24, A.5.26; SOC 2, 2017 Trust Services Criteria CC7.3, CC7.4. Stated in: If something goes wrong https://veil.pritect.ai/security#incident; DPA clause 6.1 https://veil.pritect.ai/trust/dpa#s6-6-1; DPA Annex 2.7 https://veil.pritect.ai/trust/dpa#sA2-A2-7.
Coordinated disclosure. There is a published policy saying what you may test, how to tell us what you found and what we do about it, and it is the written agreement that makes testing within its terms permitted rather than prohibited under clause 2.4 of the acceptable use policy. A report is acknowledged within two business days. Where a report shows that customer personal data has been exposed, the breach clock in the row above runs on its own, independently of anything else happening with the report. Aligned with: ISO/IEC 27001:2022 A.5.24, A.6.8; SOC 2, 2017 Trust Services Criteria CC2.3, CC7.3. Stated in: Coordinated disclosure policy https://veil.pritect.ai/trust/disclosure; Acceptable use policy clause 2.4 https://veil.pritect.ai/trust/acceptable-use#s2-2-4.
Sub-processor governance. 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 data protection obligations no less protective than the ones in our own agreement with you, and we remain liable to you for what they do. We give at least thirty days' notice before adding or replacing one, and every change is recorded in the list itself and published to a feed that any reader can watch without telling us anything about them. Aligned with: ISO/IEC 27001:2022 A.5.19, A.5.20, A.5.22; SOC 2, 2017 Trust Services Criteria CC9.2. Stated in: Sub-processor list https://veil.pritect.ai/trust/subprocessors; DPA clause 5.2 https://veil.pritect.ai/trust/dpa#s5-5-2; Change feed https://veil.pritect.ai/trust/subprocessors/feed.xml.

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.

Get started See pricing