Data Processing
Agreement.

1. Parties, Scope and Precedence

1.1 Parties

This Data Processing Agreement ("DPA") is entered into between Vivid Risk Limited, a private company limited by shares incorporated in Ireland under company registration number 818204, having its registered office at 15 The Meadows, Portlaoise, Co. Laois, Ireland ("Vivid Risk", "Processor"), and the customer identified in the Terms of Service ("Customer", "Controller").

1.2 It applies automatically

This DPA is incorporated into and forms part of the Vivid Risk Terms of Service, and applies from the moment the Customer accepts those Terms. No separate signature is required. A countersigned copy is available on request at support@vividrisk.ai.

1.3 Precedence and definitions

Where this DPA conflicts with the Terms of Service on the processing of Personal Data, this DPA prevails. Terms used but not defined here have the meaning given in Regulation (EU) 2016/679 ("GDPR"). "Customer Personal Data" means Personal Data contained in Customer Content, as that term is defined in the Terms of Service.

1.4 Which role Vivid Risk holds, and when

Neither the Terms of Service nor the Privacy Policy allocated these roles before this DPA existed, which is what made the gap easy to miss. Vivid Risk is:

• Controller of account data — the account holder's name, email address, sign-in records and billing details — which it processes for its own purposes of providing and charging for the Service. That processing is described in the Privacy Policy and is not governed by this DPA.
• Processor of Customer Personal Data — everything the Customer enters into the product about its own organisation, its staff, its suppliers and its incidents.
• Sub-processor where a partner practice administers a workspace on behalf of its own client. In that case the partner is the Processor, the partner's client is the Controller, and clause 6 applies to Vivid Risk in that capacity.

2. Subject-matter, Duration, Nature and Purpose

Required by Article 28(3) to be set out in writing.

• Subject-matter and purpose. Vivid Risk processes Customer Personal Data solely to provide the Service: a cloud-based compliance self-assessment, risk scoring, evidence register and governance platform.
• Nature of the processing. Collection, storage, organisation, retrieval, consultation, use, transmission to the sub-processors listed in Annex 2, erasure and destruction — all by automated means.
• Duration. For the term of the Terms of Service, and thereafter only as clause 8 permits.
• Categories of data subject and types of Personal Data. Set out in Annex 1.

3. Processing on Documented Instructions — Art. 28(3)(a)

3.1 Instructions

Vivid Risk processes Customer Personal Data only on the Customer's documented instructions, including as to transfers to a third country. The Terms of Service, this DPA and the Customer's use of the Service's own features constitute the Customer's complete documented instructions at the date of this DPA.

3.2 Unlawful instructions

Vivid Risk notifies the Customer if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection law, unless prohibited from doing so.

3.3 No training of AI models

Vivid Risk does not use Customer Personal Data to train or fine-tune any machine-learning model, and does not permit any sub-processor to do so. Where the Service submits Customer Content to a generative model, it does so under Google Cloud Service Specific Terms §18 (Training Restriction), which prohibits such use absent the customer's permission or instruction. Vivid Risk gives neither.

4. Confidentiality — Art. 28(3)(b)

Vivid Risk ensures that persons authorised to process Customer Personal Data are bound by an obligation of confidentiality, whether by contract of employment, contract for services, or statutory duty, and that the obligation survives the end of their engagement.

Access to Customer Personal Data in production is limited to those personnel who require it to provide, secure or support the Service.

5. Security — Art. 28(3)(c) and Art. 32

Vivid Risk implements the technical and organisational measures set out in Annex 3, which is an accurate description of the measures in place at the date of this DPA and not a statement of intent.

Annex 3 is a complete statement of those measures, and Part 4 of it names the assurances Vivid Risk does not hold. Article 32 asks for measures appropriate to the risk, and a schedule listing only strengths cannot be assessed against that standard.

Vivid Risk may update the measures in Annex 3 provided the level of protection is not reduced.

6. Sub-processors — Art. 28(2), Art. 28(3)(d) and Art. 28(4)

6.1 General authorisation

The Customer grants Vivid Risk general written authorisation to engage sub-processors, subject to this clause.

6.2 The current list

The sub-processors engaged at the date of this DPA are set out in Annex 2 and published at vividrisk.ai/subprocessors. Both name each service separately rather than each vendor, because a single vendor's services differ in where they process and what commitments attach to them.

6.3 Flow-down and liability

Vivid Risk imposes on each sub-processor, by written contract, data protection obligations no less protective than those in this DPA, and remains fully liable to the Customer for the performance of each sub-processor's obligations.

6.4 Notice of change, and the right to object

Vivid Risk gives the Customer at least thirty (30) days' prior notice of any intended addition or replacement of a sub-processor, by email to the account's registered address, and updates the register at the same time. The Customer may object on reasonable data protection grounds within that period. If Vivid Risk cannot accommodate the objection, the Customer may terminate the affected part of the Service and receive a pro-rata refund of fees paid for the unused remainder of the then-current term.

7. Assistance — Art. 28(3)(e) and Art. 28(3)(f)

7.1 Data subject rights

Taking into account the nature of the processing, Vivid Risk assists the Customer by appropriate technical and organisational measures, insofar as possible, in fulfilling its obligation to respond to requests under Chapter III GDPR. The Service provides the Customer with direct access to, correction of, export of and erasure of Customer Personal Data; where a request cannot be satisfied through those features, Vivid Risk assists on request.

7.2 Personal data breach

Vivid Risk notifies the Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data, and provides the information reasonably available to it to enable the Customer to meet its own obligations under Articles 33 and 34.

7.3 What "becoming aware" means here, and why no fixed window is offered

Vivid Risk operates no continuous security monitoring, no intrusion detection and no on-call rota; Annex 3 Part 4 says so. "Becoming aware" therefore means actual knowledge, whether from a sub-processor's notification, a report reaching us from outside, or our own observation. A fixed notification window is deliberately not offered, because a window we cannot detect within is a window we would breach. The Customer should factor this into its own Article 33 planning rather than rely on a number we could not keep.

7.4 Impact assessments and prior consultation

Vivid Risk provides the Customer, on request, with the information in Annexes 1 to 3 and such further information in its possession as the Customer reasonably requires for a data protection impact assessment under Article 35 or prior consultation under Article 36.

8. Deletion and Return — Art. 28(3)(g)

8.1 On termination

At the Customer's choice, Vivid Risk deletes or returns all Customer Personal Data on termination of the Service, and deletes existing copies, save to the extent Union or Member State law requires storage.

8.2 Return

Return is by the Service's own export, which produces the Customer's records including the evidence files it has uploaded.

8.3 Deletion

Deletion is on written request and is performed across every collection classified as erasable in Vivid Risk's subject-data registry. Vivid Risk operates no automated deletion schedule; Customer Personal Data persists until erased on request.

8.4 What is retained, and why

The records Vivid Risk retains after deletion, and the legal basis for each, are set out in Annex 3 Part 3. The Customer is told what was retained rather than being given a report that erasure was complete. Article 17(3) permits the retention; it does not permit staying silent about it.

9. Audit and Information — Art. 28(3)(h)

9.1 Information

Vivid Risk makes available to the Customer all information necessary to demonstrate compliance with Article 28, including Annexes 1 to 3 and its published sub-processor register.

9.2 Audit

Vivid Risk allows for and contributes to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer, on thirty (30) days' prior written notice, no more than once in any twelve-month period except following a Personal Data Breach, during business hours, at the Customer's cost, subject to confidentiality, and provided the auditor is not a competitor of Vivid Risk.

9.3 There is no report offered in lieu

Vivid Risk holds no SOC 2 report, no ISO/IEC 27001 certification and no third-party penetration test report, and therefore offers none in place of an audit. The inspection right in clause 9.2 is real for that reason.

10. International Transfers

10.1 Where processing happens

The processing location of each sub-processor, and the Chapter V transfer mechanism where one applies, are set out in Annex 2.

10.2 No residency is promised

Vivid Risk does not offer EU data residency and this DPA does not commit to it. Of the services in Annex 2, the Firestore database, the evidence file store, the application servers and the Gemini models carry an EU processing location or commitment. Firebase Authentication has no region that can be selected and Google publishes no data-location commitment for it. Stripe and Resend process in the United States. The Customer must assess its own Chapter V position on the facts in Annex 2 rather than on any assurance of residency, because none is given.

10.3 Mechanism

Where a transfer to a third country occurs, it is made under the mechanism named for that service in Annex 2.

Annex 1 — Categories of Data Subject and Types of Personal Data

Categories of data subject

• The Customer's own personnel — account holders, invited team members, assessment respondents, and the named owners of controls, incidents and tickets.
• The Customer's suppliers' personnel — named contacts recorded in the vendor and third-party registers.
• Individuals named in incident and vulnerability records — whoever the Customer records as involved in, reporting, or handling an event.
• Individuals named in evidence files — whoever appears in a document the Customer uploads, which is governed by the Customer's own choice of what to upload.
• Where a partner administers the workspace, the partner's client's personnel — the same categories, one level down the chain.

Types of Personal Data

• Identity and contact data — name, work email address, job role, organisation.
• Authentication data — user identifier, sign-in timestamps, federated provider identity.
• Assessment content — questionnaire answers about the Customer's organisation, which may name individuals as control owners.
• Evidence files and their metadata — whatever the Customer uploads, plus filename, size, type and uploader.
• Incident, vulnerability and CRA reporting records — descriptions, dates, affected products, and what the Customer recorded filing.
• Supplier and third-party register records — vendor contacts, contract details, ICT service classifications.
• Support tickets and their message threads — whatever the Customer writes.
• Audit log entries — actor identifier, email, role, operation, timestamp and tenant.
• Billing records — invoice records and promotional code redemptions.
• Telemetry events — product usage events keyed to a user identifier.

No special category data (Article 9) and no criminal offence data (Article 10) are required by the Service. The Customer may nevertheless place such data into a free-text field or an uploaded evidence file, and remains the Controller of that choice.

Annex 2 — Sub-processors

Rows are per service rather than per vendor, because a single vendor's services differ in where they process and what commitments attach to them. This is the same register published at vividrisk.ai/subprocessors.

What the two United States sub-processors actually receive

• Stripe receives the account email address and a metadata object of user identifier and plan tier, plus the partner organisation identifier on the partner upgrade path. Card details pass from the Customer's browser to Stripe and never reach Vivid Risk's servers.
• Resend receives the recipient address and, where a template repeats a submitted form back, the name, company and framework interest the sender typed.

Neither receives assessment answers, evidence files, vendor records or incident records.

Annex 3 — Technical and Organisational Measures

Part 1 — Measures in place

• Access control and tenant isolation. Every privileged server route requires a verified identity token, and the caller's identity is taken from the token rather than from the request body. Logical separation between customer workspaces is enforced in database security rules, not by client-side filtering. Partner practice membership and department scoping are enforced in the same rules, as are plan limits on stored records.
• Encryption. Data is encrypted in transit and at rest by Google Cloud; Vivid Risk operates no datacentre and no encryption stack of its own. Stored third-party integration refresh tokens are additionally sealed with AES-256-GCM under a key held in a managed secret store, and the affected operation refuses rather than proceeding unprotected if the key is absent or the wrong length.
• Evidence file access. Files are served only through short-lived pre-signed URLs — five minutes to read, fifteen minutes to write.
• Integrity. Exported assessment reports are chained with HMAC-SHA256, so a later export is verifiable against the earlier one. The audit log is append-only: the security rules grant create and read and provide no update or delete path, and the actor on each entry is pinned to the caller's own authentication token and role rather than asserted by the writer.
• Verified data location. The evidence storage bucket's location is read from the bucket's own metadata before any upload URL is issued, and a bucket outside the EU is refused — the location is verified rather than taken from configuration. The AI backend refuses a partial configuration and refuses the global endpoint, so inference cannot silently leave the configured region.
• Secure development and deployment. Every deployment is gated on a typecheck and the full static-analysis suite, so an image that fails its own tests is never pushed to the registry. Dependencies install from a committed lockfile in both the test gate and the image.
• Personnel. Bound by confidentiality as set out in clause 4.

Part 2 — Assistance and data subject rights tooling

• A single subject-data registry classifies every collection in the product, and the export and erasure endpoints and the administrative console all read from it — so no route carries its own list that could go quietly incomplete.
• Export is fail-open: everything not classified as non-personal is included.
• Erasure is fail-closed: only collections classified as erasable are deleted, and anything else is reported to an operator to handle by hand.
• Erasure runs only after the target's email address is retyped and matched exactly, and is refused outright where the subject owns a partner practice, because what would be deleted is other people's records.
• An administrative erasure is refused if it cannot first be recorded in the audit log.

Part 3 — Records retained after erasure, and the basis for each

• Invoices and promotional code redemptions — tax law retention.
• Audit log entries — Article 5(2) accountability. Deleting them would let a person erase the record of their own actions.
• Report chain links — deleting a link breaks the integrity property of every later report.
• Managed client organisational records — the record belongs to the partner practice rather than to the individual, so the individual is unassigned rather than the record deleted.

Part 4 — What Vivid Risk does not have

Stated because Article 32 requires measures appropriate to the risk, and a Controller cannot assess that against a list of strengths alone.

• No SOC 2 report, no ISO/IEC 27001 certification, no third-party penetration test.
• No continuous security monitoring, intrusion detection, SIEM or on-call rota. Clause 7.3 is written to match this rather than around it.
• No automated data retention or deletion schedule. Data persists until erased on request.
• No Data Protection Officer appointed.
• No formal information security management system, and no documented, tested incident response plan.
• Role separation below the system administrator role is enforced in the user interface only, not in the database security rules. Tenant isolation, partner membership and plan limits are enforced in the rules; role separation is not.
• No published vulnerability disclosure route and no bug bounty programme. There is no security.txt, no advertised security contact and no named assessor; a researcher would have to use the general support address. This is named specifically because receiving and acting on outside vulnerability reports is a control the product itself asks customers about, and we do not hold it.

11. Liability, Term and Contact

11.1 Liability

Each party's liability under this DPA is subject to the limitations and exclusions in the Terms of Service.

11.2 Term

This DPA takes effect when the Customer accepts the Terms of Service and continues for as long as Vivid Risk processes Customer Personal Data.

11.3 Governing law

This DPA is governed by the laws of Ireland, and the courts of Dublin have exclusive jurisdiction, consistent with section 8 of the Terms of Service.

11.4 Contact

• Data protection and DPA enquiries: support@vividrisk.ai
• A countersigned copy, or a Customer's own DPA template for review: the same address.