Data Processing Addendum

Between:

Roiva LLC, a Minnesota limited liability company ("Roiva", "Processor"), and
the customer that has entered into the Agreement with Roiva ("Customer", "Controller"),

each a "Party" and together the "Parties".

This Data Processing Addendum (the "DPA") forms part of, and is governed by, whichever of the following is in force between the Parties (the "Agreement"): the Roiva Master Subscription Agreement; the Roiva Readout Terms published at roiva.ai/readout-terms, with the Readout Order Form that incorporates them; or, for an account with no signed order form, the Roiva Terms of Use. It applies to Roiva's Processing of Customer Personal Data on behalf of Customer in the course of providing the Roiva service (the "Service"). Capitalized terms not defined here have the meaning given in the Agreement or, failing that, in Applicable Data Protection Law.

How this DPA is concluded. Roiva has signed this DPA in advance. It binds both Parties, without a further signature, when Customer signs an order form that incorporates it by reference, from that order form's effective date. Customer may also countersign a copy and return it to security@roiva.ai, for example to complete Annex IV. The version that applies is the one published on the date it binds; a later version applies only if Customer agrees to it in writing, except for changes to Annex III, which follow §7. When the Agreement changes from the Readout Terms to the Master Subscription Agreement, this DPA continues without interruption and covers the Customer Personal Data already in the Service.

1. Definitions

"Applicable Data Protection Law" means, as applicable to the Processing: the EU General Data Protection Regulation 2016/679 ("GDPR"); the UK GDPR and Data Protection Act 2018 ("UK GDPR"); the California Consumer Privacy Act as amended by the CPRA ("CCPA"); and any other privacy or data protection law of a jurisdiction whose residents' personal data is Processed through the Service.
"Customer Personal Data" means Personal Data Processed by Roiva on behalf of Customer under the Agreement, as further described in Annex I.
"Sub-processor" means any third party engaged by Roiva to Process Customer Personal Data, as listed in Annex III.
"Personal Data", "Controller", "Processor", "Data Subject", "Processing", "Personal Data Breach" and "Supervisory Authority" have the meanings given in the GDPR (or, where the UK GDPR applies, the UK GDPR equivalents).
"Standard Contractual Clauses" or "SCCs" means the standard contractual clauses for the transfer of personal data to third countries adopted by Commission Implementing Decision (EU) 2021/914.
"UK Addendum" means the International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner's Office (B.1.0, in force 21 March 2022).

2. Roles and scope

2.1 In Processing Customer Personal Data, Customer is the Controller and Roiva is the Processor. Where Customer itself is a processor acting on behalf of a third-party controller, Roiva acts as a sub-processor and Customer represents that it has the authority to instruct Roiva accordingly on that controller's behalf.

2.2 For the purposes of the CCPA, Roiva is a "service provider" to Customer. Roiva does not "sell" or "share" (as those terms are defined in the CCPA) Customer Personal Data, and Roiva does not retain, use, or disclose Customer Personal Data for any purpose other than the specific business purpose of providing the Service to Customer as set out in the Agreement, except as permitted by the CCPA.

2.3 Roiva's own Processing of Personal Data of Customer's employees and users for account administration, billing, security, and product improvement — described in the Roiva Privacy Policy — is carried out as a controller and is outside the scope of this DPA.

3. Customer instructions

3.1 Roiva will Process Customer Personal Data only on documented instructions from Customer, including (a) the instructions set out in the Agreement and this DPA; (b) instructions Customer issues by configuring the Service (for example, choosing which integrations to connect, which users to invite, which data to upload, whether to issue MCP access tokens or reporting tokens, and whether to add a reporting delivery destination); and (c) any additional written instructions Customer provides.

3.2 If Roiva believes an instruction infringes Applicable Data Protection Law, Roiva will inform Customer without undue delay. Roiva is not obliged to follow that instruction unless and until the apparent conflict is resolved.

3.3 If Roiva is required by EU, Member State, UK, or other applicable law to Process Customer Personal Data otherwise than on Customer's instructions, Roiva will inform Customer of that legal requirement before Processing, unless the law prohibits such notification on important grounds of public interest.

3.4 MCP access. Where Customer's administrator issues an MCP access token, Customer instructs Roiva to return Customer Data, read-only, to the AI client that presents the token. That client, and the AI provider behind it, are selected and engaged by Customer; they are not Sub-processors of Roiva, and they Process the data they receive under Customer's own agreement with them. Roiva's obligations under this DPA apply to that Customer Data until Roiva delivers it to the client.

3.5 Reporting tables. Where Customer's administrator turns on the reporting tables, Customer instructs Roiva to prepare, each day, a copy of Customer Data in the form of the reporting tables described in the Documentation, and: (a) where Customer's administrator issues a reporting token, to return those tables, read-only, to the client that presents the token; (b) where Customer's administrator adds a delivery destination, to write those tables to the storage location Customer designates, through access Customer grants and can withdraw; and (c) where Customer's administrator turns on the weekly full-account export for a delivery destination, to write a full export of Customer Data, as described in the Documentation, to that storage location once a week through the same access. The client, the storage location, and any service Customer uses to read or load the tables (such as a data warehouse or business intelligence tool) are selected and controlled by Customer; they are not Sub-processors of Roiva, and they Process the data under Customer's own arrangements. Roiva's obligations under this DPA apply to that Customer Data until Roiva delivers it to the client or writes it to the storage location. Roiva deletes its own copies of the reporting tables as the Documentation describes, and keeps no copy of a weekly full-account export once it is written.

3.6 Configuration and data entry by Roiva personnel. Where Customer asks Roiva to configure its account or to enter data in it on Customer's behalf — during a 30-Day ROI Readout, or as part of implementation — Customer instructs Roiva to Process Customer Personal Data for that purpose, through Roiva personnel whom Customer invites as users of its account and may remove at any time. Those personnel act only within Customer's account. Each entry they make is recorded in the account's audit log under their own name. They will not approve values, record decisions on Customer's initiatives, or change who may approve either, and Roiva will not ask for or accept credentials to Customer's systems in order to do this work. This is distinct from the administration tools described in Annex II, which Roiva uses for support and operations.

4. Data subject rights and assistance

4.1 The Service provides Customer with self-service tools that allow Customer to fulfill most Data Subject rights requests without Roiva's intervention. In particular:

(a) Erasure of an individual user (GDPR Art. 17 / CCPA right to delete): the user can permanently delete their own sign-in identity from Profile → Security → Delete account. This removes credentials, two-factor secret, assistant chat history, notifications, and personal activity, and removes the user from every account they were a member of.
(b) Erasure of a workspace account (Owner only): an Owner can permanently delete the workspace from Settings → Account → Delete account. This removes the workspace and every initiative, value entry, integration, document, and report contained in it.
(c) Access and portability: Customer administrators can export reports and underlying data from the Service prior to deletion, including every document attached to an initiative, as a single archive with a manifest. Customer is responsible for retaining its own copy of records it is required by law to preserve (see §9).

4.2 Both flows in §4.1(a) and §4.1(b) are irreversible. Following a deletion, Roiva retains a single audit-log entry recording that the deletion occurred — the date of deletion, an aggregate count of the objects destroyed, and, for user deletions, a one-way SHA-256 hash of the user's email address — and no other Personal Data of the deleted Data Subject, except in database backups until they expire under §4.3. This audit entry keeps the deletion itself auditable and is the minimum data Roiva can retain to evidence that an erasure request was honored.

4.3 Database backups. Roiva's database backups are encrypted and are deleted automatically thirty (30) days after they are taken. Customer Personal Data deleted from the Service's database, including by the flows in §4.1(a) and §4.1(b) and under §9, remains in those backups until they expire. Roiva does not access or use a backup except to restore the Service after a failure, a loss of data or a Personal Data Breach, or to test that backups can be restored, and never to recover the data of a single customer or user. If Roiva restores the Service from a backup, it repeats, as part of that restoration, every deletion under §4.1(a), §4.1(b) and §9.2 made after the point in time the Service is restored to.

4.4 To the extent Customer cannot fulfill a Data Subject request using the Service's self-service tools, Roiva will, taking into account the nature of the Processing, provide reasonable assistance by appropriate technical and organizational measures. Customer will reimburse Roiva for any disproportionate cost of providing assistance that goes materially beyond the self-service tools.

4.5 If Roiva receives a Data Subject request that relates to Customer Personal Data, Roiva will, unless legally prohibited, promptly direct the Data Subject to Customer and notify Customer.

5. Confidentiality

Roiva ensures that personnel authorized to Process Customer Personal Data are under a duty of confidentiality (whether contractual or statutory) and have received appropriate training on the handling of Personal Data.

6. Security

6.1 Roiva implements and maintains the technical and organizational measures set out in Annex II to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of Processing.

6.2 Customer acknowledges that the measures in Annex II are subject to technical progress and development. Roiva may update them from time to time provided that the updated measures do not materially diminish the protection of Customer Personal Data.

7. Sub-processors

7.1 Customer provides Roiva with general written authorization to engage Sub-processors. The current list of Sub-processors is set out in Annex III and is also reflected in §5 of the Roiva Privacy Policy.

7.2 Roiva will notify Customer of any intended addition or replacement of a Sub-processor at least ten (10) days in advance by updating the Privacy Policy and, where Customer has provided a notice email address in Annex IV, by emailing that address. Customer may object on reasonable data-protection grounds within ten (10) days of notification. If the Parties cannot resolve the objection in good faith, Customer may, as its sole and exclusive remedy, terminate the affected portion of the Service on written notice; fees already paid for the unused period of the affected portion will be refunded pro-rata.

7.2.1 Where a Sub-processor must be added or replaced urgently to preserve the security, availability or continuity of the Service — including in response to a security incident, a Sub-processor's insolvency or cessation of service, or a Sub-processor's material change to its own terms — Roiva may make the change before giving the notice required by §7.2, and will notify Customer as soon as reasonably practicable afterwards. Customer's objection rights and remedy under §7.2 apply from the date of that notification.

7.3 Roiva will impose on each Sub-processor data-protection obligations that are substantially the same as, and no less protective than, those set out in this DPA, and will remain liable to Customer for the acts and omissions of its Sub-processors as if they were its own.

8. International data transfers

8.1 Customer acknowledges that Roiva and its Sub-processors are located in, and Process Customer Personal Data in, the United States. Where Customer Personal Data originating in the European Economic Area, the United Kingdom, or Switzerland is transferred to Roiva or a Sub-processor in a country that is not the subject of an adequacy decision under Applicable Data Protection Law, the transfer is governed as follows:

(a) EEA transfers: the SCCs are incorporated by reference into this DPA and apply as follows — Module Two (Controller to Processor) where Customer is a controller, and Module Three (Processor to Processor) where Customer is itself a processor. The optional docking clause applies. In Clause 7, the optional docking clause applies. In Clause 9, Option 2 (general written authorisation) applies, with the time period specified in §7.2 of this DPA. In Clause 11, the optional language is excluded. In Clause 17, the governing law is the law of Ireland. In Clause 18, the forum is the courts of Ireland. Annexes I, II, and III of the SCCs are populated by the correspondingly numbered Annexes of this DPA.
(b) UK transfers: the UK Addendum applies to the SCCs as incorporated under §8.1(a), with the tables of the UK Addendum populated by the corresponding sections of this DPA. Either Party may end the UK Addendum as set out in §19 of the UK Addendum.
(c) Swiss transfers: the SCCs apply with the modifications set out in the Swiss Federal Data Protection and Information Commissioner's guidance of 27 August 2021, including reading references to GDPR as references to the Swiss Federal Act on Data Protection where applicable, and references to Member State law as references to Swiss law.

8.2 The Parties agree that the warranties, audit, and assistance commitments of this DPA, together with the security measures in Annex II, are intended to provide essentially equivalent protection for Customer Personal Data transferred outside the EEA / UK / Switzerland.

9. Retention and deletion

9.1 During the term of the Agreement, Customer can delete Customer Personal Data at any time using the self-service tools described in §4.1.

9.2 Upon termination or expiry of the Agreement, Roiva will, at Customer's choice, return or delete all Customer Personal Data, except to the extent applicable law requires storage of any Personal Data. Customer must make any return-versus-deletion election in writing within thirty (30) days of termination; absent such election, Roiva will delete the data.

9.3 Financial records held in the workspace. Customer Personal Data that takes the form of financial records held inside Customer's workspace (accounting periods, journal entries, allocation rules, value entries, and similar records) is deleted together with the rest of the workspace when an erasure or termination occurs. Customer is responsible for exporting any such records it is required to retain under tax, audit, or other applicable law prior to initiating deletion or termination. The Parties have considered Article 17(3) GDPR and agree that Customer's opportunity to export prior to deletion is the appropriate balance between Customer's erasure rights and any financial-records retention obligations Customer is itself subject to. Roiva's own books and records relating to the commercial relationship with Customer (invoices, payment records, contract documents) are retained separately under the retention periods required by applicable tax and corporate law and are outside the scope of this §9.

9.4 The single audit-log entry described in §4.2 is not "Customer Personal Data" for the purposes of §§9.1 and 9.2 once deletion has occurred, because it contains no plaintext identifier and is retained under Roiva's legitimate interest in evidencing that erasure requests were honored.

9.5 Deletion under this §9 is subject to §4.3: deleted Customer Personal Data remains in Roiva's encrypted database backups until they expire, thirty (30) days after they are taken, and §4.3 governs their use and any restoration.

10. Personal Data Breach notification

10.1 Roiva will notify Customer without undue delay, and in any event within seventy-two (72) hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data. Notification will be sent to the security contact in Annex IV or, in the absence of one, to the Customer billing contact, and will include the information set out in Article 33(3) GDPR to the extent then known.

10.2 Roiva will cooperate with Customer and provide reasonable assistance in investigating, mitigating, and where required notifying the relevant Supervisory Authority and Data Subjects of the Breach. A notification by Roiva under this §10 is not an acknowledgment of fault or liability.

11. Audits and information

11.1 On reasonable written request, and no more than once per twelve-month period (except where required by a Supervisory Authority or following a Personal Data Breach affecting Customer), Roiva will make available to Customer the information necessary to demonstrate compliance with this DPA. This information will be provided primarily by:

(a) the public Roiva Security overview;
(b) the public Roiva Trust Center, through which Customer may request access to Roiva's written security policies; and
(c) on request and under NDA, Roiva's then-current third-party audit reports (e.g. the SOC 2 Type 2 report once issued, and the penetration test letter of attestation once the test has run) and responses to Customer's standard security questionnaire.

11.2 To the extent the information in §11.1 is not sufficient to demonstrate compliance, Customer may, on at least thirty (30) days' written notice and at its own expense, conduct an on-site audit during normal business hours, subject to reasonable confidentiality, security, and scope safeguards. Customer may not engage an auditor who is a competitor of Roiva.

12. Liability

The liability of each Party under or in connection with this DPA is subject to the limitations and exclusions of liability in the Agreement. Nothing in this DPA limits or excludes any liability that cannot be limited or excluded under Applicable Data Protection Law.

13. Order of precedence

In the event of any conflict between this DPA, the Agreement, and the SCCs (as incorporated by §8), the order of precedence is: (i) the SCCs; (ii) this DPA; (iii) the Agreement.

14. Term and termination

This DPA takes effect on the later of (a) the Effective Date and (b) the date Roiva first Processes Customer Personal Data, and continues for as long as Roiva Processes Customer Personal Data under the Agreement. The provisions of §§9, 10, 11, 12, and 13 survive termination of this DPA.

15. Governing law and jurisdiction

Except as provided in Clause 17 of the SCCs (as incorporated by §8.1(a)), this DPA is governed by, and construed in accordance with, the governing law and jurisdiction provisions of the Agreement.

Annex I — Description of the Processing

Categories of Data Subjects

Customer's employees, contractors, and agents who are invited as users of the Service.
Individuals whose details are contained in records uploaded or synced into the Service by Customer (e.g. integration data from Customer's CRM, support, or finance systems, and documents attached to initiatives, such as the personnel of a counterparty named in a statement of work or contract).

Categories of Personal Data

Identification and contact data: name, work email address, organization, job title.
Authentication data: hashed password, TOTP secret (encrypted), mobile number (encrypted, only for a user who chooses text-message sign-in codes), SSO subject identifier.
Usage data: pages visited, actions taken in the Service, IP address, browser type, audit-log records of who-did-what.
Configuration data: roles, permissions, account settings, notification preferences.
Integration data: data Customer chooses to sync from third-party systems (CRM, support, finance) for the purpose of computing initiative value.
Initiative documents: files Customer's users upload to initiatives, and links and titles they add in place of a file (such as business cases, review decks, statements of work and contracts), any Personal Data those files contain, and who added each one and when.
Assistant interaction data: messages Customer's users send to the Roiva Assistant and the model's responses.
MCP access data: the name of each MCP access token, the user who issued it, and an audit-log record of each tool call an AI client makes with it.
Reporting data: the reporting tables built from the categories above (initiatives, costs, approved value and its inputs, approvals, budgets, decisions and AI spend, including the names of the users who recorded or approved them and free text they wrote), the name of each reporting token and the user who issued it, each delivery destination, and audit-log records of each build, read and delivery.

Special categories of Personal Data

None intended. Customer agrees not to upload special-category data (Art. 9 GDPR) or US Sensitive Personal Information (CCPA) to the Service.

Frequency of the transfer

Continuous, for the duration of the Agreement.

Nature and purpose of the Processing

Hosting and provision of the Service; authentication and authorization; computing and displaying ROI metrics for AI initiatives; storing and serving the documents Customer attaches to initiatives; configuring Customer's account and entering data in it on Customer's instruction (§3.6); sending transactional emails; responding to support requests; security monitoring and incident response.

Duration of Processing

For the duration of the Agreement, plus the deletion / return period in §9 and the thirty (30) days until database backups expire (§4.3).

Competent Supervisory Authority (SCCs Clause 13)

For EEA transfers: the Irish Data Protection Commission, as Customer's Annex I.C entry, unless Customer is established in another EU Member State in which case its lead authority.
For UK transfers: the UK Information Commissioner's Office.

Annex II — Technical and organizational security measures

Roiva implements the following measures. This Annex summarizes the controls that are most relevant to the protection of Customer Personal Data. Roiva's written security policies can be requested through the Roiva Trust Center (§11.1(b)).

Encryption

TLS 1.2+ for all data in transit; HSTS enabled in production; HTTP automatically redirected to HTTPS.
Application-level AES-256 encryption, in addition to disk encryption, of the secrets and identifiers held on Customer's behalf: integration OAuth tokens and API keys, IdP OAuth client secrets, SAML SP private keys, users' TOTP secrets, and the mobile numbers used for text-message sign-in codes.
Database disk encryption at rest at the hosting provider.
The background job queue and application cache run on Amazon ElastiCache, encrypted at rest and in transit, with no public endpoint: they are reachable only from inside Roiva's private network.
Files uploaded to the Service are stored in Amazon S3 in the United States with server-side encryption at rest.

Access control and authentication

Email + password authentication with bcrypt hashing.
Optional two-factor authentication for end users, by authenticator app (TOTP) or by text-message code, with single-use backup codes.
Sign-in through Google or Microsoft, or through the Customer's own identity provider (Okta or Microsoft Entra ID over OAuth, or SAML 2.0).
Sign-up is gated: visitors without a valid pre-authorized context (OAuth context, completed assessment, invitation token, or signed unlock link) cannot create an account.
Every request from the Customer's users requires an active membership in the Customer's account. A member who is removed or suspended, or a user Roiva deactivates, loses access on their next request.
Role-based access policies govern account settings, approvals, finance period close and allocation rules, and integration management.
Documents attached to initiatives are served only to a signed-in member whose role permits it, through storage links that expire after five minutes. Statements of work and contracts are visible only to Customer's owners and admins and to the approvers designated on that initiative.
External auditor access links are stored as a one-way SHA-256 digest only; the underlying token is shown once at creation and cannot be retrieved again. If the token is lost, the Customer administrator regenerates a new one.
MCP access tokens, which let an AI client chosen by Customer read, but never change, Customer Data, are issued only by Customer administrators, stored as a one-way SHA-256 digest and shown once, and expire within one year. A token acts with the issuing user's membership and stops working when that user is removed or suspended, when the token is revoked, or when Customer's plan no longer includes MCP access.
Reporting tokens are issued, stored and ended in the same way, and read only the reporting tables. Where Customer adds a delivery destination, Roiva writes to it by assuming a role Customer creates, which is conditioned on an identifier unique to that destination and limited to adding files in one folder; Roiva stores no credential of Customer's for it. Each set of reporting tables is checked against Roiva's own reports before it is released, and Roiva's copies are deleted after fourteen days, except the most recent while the reporting tables are turned on. A weekly full-account export goes to a destination only where an administrator turns it on for that destination, every Owner is notified when it is turned on or off, and Roiva keeps no copy once it is written.

Logging and monitoring

Application audit log of security-relevant events (authentication, role changes, integration connections, value approvals, MCP tool calls, reporting builds, reads and deliveries, opening a document attached to an initiative, admin actions), retained in an append-only structure.
Error tracking, infrastructure monitoring, and uptime monitoring through the Sub-processors listed in Annex III.

Application security

Content Security Policy with nonce-locked script-src (no 'unsafe-inline' / 'unsafe-eval') and frame-ancestors 'none'.
Uploaded documents are limited to PDF, office, text and image types, identified from each file's content rather than its name, and to 25 MB, and are delivered as downloads rather than rendered in the browser.
Uploaded documents are scanned for malware on arrival by Amazon GuardDuty, in an isolated environment AWS operates in the same region as the stored file; a file found to contain malware is not delivered to anyone.
Dependency vulnerability scanning on every pull request (brakeman, bundler-audit, importmap audit); Dependabot enabled.
Code review required for all changes; production deploys via Kamal with secrets injected at runtime from a managed secret store, never committed.

Data segregation

Multi-tenant database: Customer Data is stored alongside other customers' data and separated logically by account.
Requests from the Customer's users reach only the Customer's account: records are loaded through that account, and any record a request refers to must belong to it or to Roiva's read-only shared library of metrics and formulas. One customer's users cannot read or change another customer's Customer Data.
Roiva's internal administration tools, available only to Roiva personnel designated as platform administrators, can access Customer Data across accounts for support and operations.
When Roiva personnel use these tools to enter a Customer's account and work inside it, for example to provide support, the visit is recorded in that account's audit log.

Personnel

All Roiva personnel with production access are bound by confidentiality obligations.

Backup and resilience

Encrypted, automated database backups on Amazon RDS, with point-in-time restore, kept for thirty (30) days and then deleted automatically. Their use and restoration are limited as set out in §4.3.
Production runs on AWS in the United States.

Physical security

Roiva operates no data centers or server rooms, and no Customer Personal Data is held on physical media or at any Roiva address. Roiva's registered address is for correspondence and notices; no Service infrastructure operates there and no Customer Personal Data is held there.
Physical access control for the infrastructure the Service runs on — data center access, environmental controls, media handling and the destruction of decommissioned storage hardware — is provided by Amazon Web Services and is covered by its own independent audit reports and certifications, which Roiva obtains and reviews at least annually.
Storage is encrypted at rest, so hardware leaving the hosting provider's estate does not carry readable Customer Personal Data.
Roiva's personnel work remotely on devices with whole-disk encryption, an automatic screen lock, and remotely revocable access to Roiva systems; a lost or stolen device is treated as a security incident and its access is revoked before anything else.

Deletion

Self-service erasure for both user identities and workspace accounts (see §4.1). Both flows are hard-delete; only the single audit-log entry described in §4.2 is retained, and database backups hold the deleted data until they expire (§4.3).

Annex III — List of Sub-processors

Sub-processor	Purpose	Location
Amazon Web Services, Inc.	Cloud infrastructure, compute, storage, managed database, backups, background job queue and cache, outbound email, text-message sign-in codes	United States
Stripe, Inc.	Payment processing and billing	United States
Functional Software, Inc. (Sentry)	Error monitoring and crash reporting	United States
Anthropic, PBC	Large-language-model inference for the Service's AI features: the in-app Assistant, initiative estimates, template recommendations, and reading documents Customer's users upload to initiatives; inputs are not used to train models	United States
PostHog, Inc.	Product and usage analytics for the marketing site and the signed-in application	United States

Google Analytics 4 is used for aggregate usage measurement and does not Process Customer Personal Data within the meaning of this DPA; it is disclosed in the Privacy Policy for completeness.

HubSpot is used for demo scheduling on Roiva's public booking page, before any customer relationship exists. Roiva acts as controller for that Processing, which falls outside the scope of this DPA under §2.3; it is disclosed in the Privacy Policy for completeness.

PostHog does Process Customer Personal Data: in addition to consent-gated in-browser analytics, Roiva sends a limited set of server-side product events identifying the User by email address, together with account identifier and account name.

This list is current as of the Effective Date. The authoritative list is maintained in §5 of the Privacy Policy; updates are made in accordance with §7.2 of this DPA.

Annex IV — Customer contacts

Customer may name a data protection contact, a security incident notification address and a sub-processor change notification address by writing to security@roiva.ai, or by completing this Annex in a countersigned copy.

Any contact not named defaults to the users holding the Owner role on Customer's Roiva account, as shown in Settings → Members. Customer may change those roles at any time, or name a different address by writing to security@roiva.ai.

Roiva's data protection and security contact is security@roiva.ai.

Signatures

Signed in advance for Roiva LLC by Luke Wilcox, Founder.

Customer accepts this DPA by signing an order form that incorporates it by reference, as "How this DPA is concluded" describes, or by countersigning a copy and returning it to security@roiva.ai.