Data processing addendum

DRAFT for counsel review. Not yet adopted.

Innorve Academy: Data Processing Addendum (DPA)

Effective date: [EFFECTIVE DATE]

This Data Processing Addendum ("DPA") is entered into between:

• Innorve Inc., a company incorporated in [STATE OF INCORPORATION], with its registered address at [REGISTERED ADDRESS] ("Innorve"); and
• [CUSTOMER NAME], a credit union with its principal office at [CUSTOMER ADDRESS] ("Customer").

It forms part of the statement of work between Innorve and Customer for Innorve Academy (together with any later statements of work, the "Agreement").

Background

A. Innorve provides Innorve Academy, a hosted platform that trains credit-union staff on using and overseeing AI (the "Services").

B. The Services are designed to hold no member (consumer) information. Training cases are fictional. The data processed is about Customer's employees and other authorized users, and about Customer's training and pilot activity.

C. This DPA sets out how Innorve processes Customer Data on Customer's behalf.

1. Definitions

In this DPA:

• "Applicable Data Protection Law" means all US federal and state laws on privacy and data security that apply to a party's processing of Customer Data under the Agreement, which may include the California Consumer Privacy Act as amended (the "CCPA") [CONFIRM applicability].
• "Authorized User" means a person Customer (or Innorve at Customer's request) invites to use the Services, in any role: learner, reviewer, facilitator, sponsor or institution admin.
• "Customer Data" means all personal information and other data that Innorve processes on Customer's behalf in providing the Services, as described in Annex 1. It excludes Innorve's own business contact records and website leads, for which Innorve is a controller under its privacy notice.
• "Member Information" has the meaning given in section 5.
• "Personnel" means Innorve's employees and contractors.
• "Process" and "processing" mean any operation performed on data, such as collecting, storing, using, disclosing or deleting it.
• "RET-v1" means the retention schedule in Annex 4.
• "Security Incident" means any confirmed or reasonably suspected unauthorized access to, or acquisition, use, disclosure, alteration, loss or destruction of, Customer Data; or any cyberattack or exploitation of a vulnerability that disrupts the Services. [CONFIRM definition with counsel]
• "Subprocessor" means a third party that Innorve engages to process Customer Data.

2. Roles and scope

2.1 Customer is the controller. Customer decides the purposes of processing Customer Data. Where the CCPA applies, Customer is the "business" and Innorve is its "service provider".

2.2 Innorve is the processor. Innorve processes Customer Data only on Customer's documented instructions. The Agreement, this DPA and Customer's use and configuration of the Services (for example, inviting users and assigning roles) are Customer's instructions.

2.3 Unlawful instructions. Innorve will tell Customer promptly if it believes an instruction breaks Applicable Data Protection Law. Innorve may pause the affected processing until the instruction is confirmed or changed.

2.4 Processing details. Annex 1 describes the subject matter, duration, nature and purpose of processing, the categories of data and the categories of data subjects.

3. Customer obligations

Customer will:

1. have a lawful basis, and give any notices its employees need, for Innorve to process Customer Data under this DPA;
2. keep its list of Authorized Users and their roles accurate, and remove access promptly when a person leaves or changes role;
3. appoint at least one institution admin and a named incident contact (section 9.5);
4. comply with the member-data prohibition in section 5; and
5. control access to any document it links to from the Services. A link stored in the Services does not grant access to the linked document. Access is enforced in Customer's own system.

4. Innorve obligations

4.1 Purpose limitation. Innorve will process Customer Data only to provide, secure and support the Services, and as required by law.

4.2 Service provider terms. Where the CCPA applies [CONFIRM applicability], Innorve will not:

• sell or share Customer Data (as those terms are defined in the CCPA);
• retain, use or disclose Customer Data for any purpose other than the business purposes set out in the Agreement, including any commercial purpose other than providing the Services;
• retain, use or disclose Customer Data outside the direct business relationship between Innorve and Customer; or
• combine Customer Data with personal information it receives from other sources, except as the CCPA permits.

Innorve will comply with the CCPA obligations that apply to it, give Customer's personal information the level of privacy protection the CCPA requires, and notify Customer if it can no longer meet its obligations. Customer may take reasonable and appropriate steps to stop and remediate any unauthorized use of Customer Data.

4.3 No AI processing and no model training. Innorve will not send Customer Data to any AI model or AI provider, and will not use Customer Data to train or improve any AI model, without Customer's prior written agreement. The Services do not use any AI model to process Customer Data.

4.4 No marketing use. Innorve will not use Customer Data for its own marketing.

4.5 Confidentiality of personnel. Innorve will limit access to Customer Data to Personnel who need it to provide the Services. Each of them is bound by a written duty of confidentiality. [CONFIRM confidentiality agreements are in place] Innorve will train Personnel with access on their data protection duties. [CONFIRM]

4.6 Location. Innorve stores Customer Data in the United States. It will not move the storage of Customer Data outside the United States without Customer's prior written consent. [CONFIRM]

4.7 Legal requests. If a government authority or other third party requests Customer Data, Innorve will refer the request to Customer, unless the law prohibits this. If Innorve is legally required to disclose Customer Data, it will notify Customer first unless prohibited, and disclose only what is required.

5. Member-data prohibition

5.1 Prohibition. Customer will not submit, and will instruct its Authorized Users not to submit, any member information as defined in 12 CFR Part 748 and its Appendix A ("Guidelines for Safeguarding Member Information") [CONFIRM exact definition reference, including the cross-reference to the definition of nonpublic personal information] ("Member Information"), or any other nonpublic personal information about Customer's members or consumers, to the Services.

5.2 Why. The Services are designed to operate without Member Information. Training cases are fictional. Pilot workflow notes and observations are designed to record tasks, durations and quality flags only. The evidence binder stores links and status, not documents.

5.3 What Customer may enter. Customer may enter information about its own staff in their work roles (for example, the name of a workflow owner or authorizer), references to its internal approvals, and links to documents held in its own systems.

5.4 Accidental submission. If Customer or Innorve becomes aware that Member Information has been entered into the Services:

1. the party that becomes aware will notify the other promptly;
2. Innorve will help Customer identify the affected records and will delete or redact them on Customer's instruction; and
3. the parties will cooperate to decide whether the event needs to be treated under Customer's response program for unauthorized access to member information.

5.5 Innorve's duties continue. This prohibition does not reduce Innorve's duty to protect any data it holds, including any Member Information entered by mistake, under this DPA.

6. Security

6.1 Measures. Innorve will maintain the technical and organizational measures in Annex 2. These are designed to protect Customer Data against unauthorized or unlawful processing and against accidental loss, destruction or damage.

6.2 Changes. Innorve may update the measures over time. It will not reduce the overall level of protection for Customer Data during the term of the Agreement.

6.3 Customer's own controls. Customer is responsible for the security of its own email system, which controls sign-in to the Services, and for the systems and documents its Authorized Users link to.

7. Subprocessors

7.1 Authorization. Customer authorizes Innorve to use the Subprocessors listed in Annex 3.

7.2 Flow-down. Innorve will have a written agreement with each Subprocessor that includes data protection obligations appropriate to the service it provides. Innorve remains responsible to Customer for its Subprocessors' performance of those obligations.

7.3 Notice of changes. Innorve will give Customer at least 30 days' written notice before adding or replacing a Subprocessor. [CONFIRM] The notice will name the Subprocessor, its service, its location and the data it will process.

7.4 Objection. Customer may object on reasonable data protection grounds within the notice period. The parties will discuss the objection in good faith. If they cannot resolve it, Customer may end the affected part of the Services and receive a pro-rata refund of prepaid fees for the unused part. [CONFIRM]

7.5 Emergency replacement. If a Subprocessor must be replaced urgently for security or continuity reasons, Innorve may do so with shorter notice and will notify Customer as soon as possible. [CONFIRM]

8. Assistance

Innorve will give Customer reasonable help, taking into account the nature of the processing and the information available to Innorve, with:

1. requests from individuals to access, correct or delete their data. Innorve will pass on any request it receives directly and will not respond to it except on Customer's instructions;
2. Customer's due diligence and ongoing monitoring of Innorve as a third-party service provider, including under 12 CFR Part 748, Appendix A;
3. Customer's risk assessments relating to the Services; and
4. regulatory examinations. On Customer's request, Innorve will reasonably cooperate with information requests from NCUA or another regulator of Customer that relate to the Services. [CONFIRM scope]

9. Security incidents

9.1 Notice. Innorve will notify Customer of a Security Incident affecting Customer Data without undue delay and no later than 24 hours after becoming aware of it. [CONFIRM]

9.2 Why 24 hours. Customer may need to notify NCUA of a reportable cyber incident within 72 hours under 12 CFR 748.1(c). Where Customer relies on a third party, that 72-hour period can run from the third party's notice to Customer. [CONFIRM exact wording of 748.1(c)] Innorve's 24-hour commitment is intended to leave Customer time to make its own assessment. Whether an incident is reportable is Customer's decision.

9.3 Content. Innorve's notice will include what is known at the time, and Innorve will update Customer as more becomes known:

• a description of the incident, including when it happened and when Innorve became aware;
• the categories and approximate volume of Customer Data and Authorized Users affected;
• whether the Services were disrupted, and for how long;
• the likely consequences;
• the steps Innorve has taken or will take to contain and fix it; and
• a named contact for more information.

9.4 Cooperation. Innorve will take reasonable steps to contain, investigate and remediate the incident, will preserve relevant records, and will cooperate with Customer's investigation. Innorve will not notify Customer's members, employees or regulators about the incident on Customer's behalf without Customer's written approval, unless the law requires it.

9.5 Contacts. Customer will name an incident contact in the SOW. Innorve's incident contact is [INCIDENT CONTACT EMAIL], [INCIDENT CONTACT PHONE]. Customer should report suspected incidents to the same contact.

9.6 No admission. A notice under this section is not an admission of fault or liability.

10. Audit and information rights

10.1 Trust packet. Innorve will make its vendor due-diligence packet ("trust packet") available to Customer. The trust packet describes Innorve's security controls, data inventory, subprocessors, retention and deletion, incident response, access control, business continuity and use of AI. Innorve will update it at least once a year and when there is a material change. [CONFIRM]

10.2 Questionnaires. Innorve will answer Customer's reasonable written security and due-diligence questionnaires once a year, and when there is a material change or a Security Incident. [CONFIRM]

10.3 What Innorve does not have. Innorve does not currently hold a SOC 2 report or ISO 27001 certification, and has not yet had an independent penetration test. Where a Subprocessor makes its own independent audit report available (for example, a SOC 2 report), Innorve will tell Customer how to obtain it.

10.4 Reasonable audit. If the information in 10.1 to 10.3 does not reasonably satisfy Customer's oversight obligations, Customer (or an independent auditor bound by confidentiality) may audit Innorve's compliance with this DPA, subject to these conditions:

1. no more than once in any 12 months, except after a Security Incident or when a regulator of Customer requires it;
2. at least 30 days' written notice, with a proposed scope [CONFIRM];
3. during normal business hours and without unreasonable disruption;
4. remote review of documents and evidence first, with on-site review only if needed;
5. no access to other customers' data or to Innorve's confidential information unrelated to the Services; and
6. at Customer's cost, unless the audit finds a material breach of this DPA by Innorve. [CONFIRM]

10.5 Findings. Innorve will address any material finding within a reasonable time agreed with Customer.

11. Return and deletion

11.1 Export during the engagement. Authorized roles can export cohort records as CSV files (assessment records, observations and progress) at any time. Each export is recorded in the audit log.

11.2 At the end of the engagement. Customer may export its records before deletion. Innorve will delete Customer Data 90 days after the engagement ends, unless the Agreement says otherwise (RET-v1, Annex 4).

11.3 Earlier deletion. Customer may ask Innorve in writing to delete Customer Data, or an individual user account, earlier.

11.4 How deletion is done. Innorve platform staff delete data through audited database functions. Deleting an institution requires typing the institution's exact name. Deleting a user account requires typing the person's exact email address.

11.5 Backups. Deleted data can remain in database backups until those backups rotate out, up to 7 days. Innorve will not restore deleted Customer Data from a backup except to recover from an incident or error, and will then delete it again.

11.6 Audit references. Audit events are kept for 3 years after they are created. They contain references only (ids, action, record type, version, time and outcome), never content. They are designed to survive deletion of the institution, so that Customer and Innorve can show that deletion happened.

11.7 Confirmation. On request, Innorve will confirm deletion in writing. [CONFIRM]

11.8 Legal holds. Innorve may keep Customer Data longer only if the law requires it. It will tell Customer, keep protecting the data under this DPA, and delete it when the requirement ends.

12. Liability

Each party's liability under this DPA is subject to the limitations and exclusions of liability in the Agreement. [CONFIRM whether breaches of this DPA have a separate cap: [LIABILITY CAP]]

13. Term and termination

13.1 This DPA takes effect on the effective date and continues for as long as Innorve processes Customer Data.

13.2 Sections 5.5, 9, 10, 11 and 12 survive for as long as Innorve holds any Customer Data or audit reference relating to Customer.

14. General

14.1 Order of precedence. If this DPA conflicts with the Agreement on data protection, this DPA controls. [CONFIRM]

14.2 Changes in law. If a change in Applicable Data Protection Law requires a change to this DPA, the parties will negotiate an amendment in good faith.

14.3 Notices. Notices under this DPA must be in writing. Notices to Innorve go to [LEGAL NOTICES ADDRESS], with incident notices to [INCIDENT CONTACT EMAIL]. Notices to Customer go to the contacts named in the SOW.

14.4 Governing law. This DPA is governed by the law of [GOVERNING LAW], and disputes will be heard in [VENUE], unless the Agreement says otherwise. [CONFIRM]

Signatures

---

Annex 1: Details of processing

Categories of Customer Data:

1. Account data: email address and display name.
2. Access data: institution memberships and roles, invitations (email address, roles, inviter and expiry) and cohort enrollments, with any withdrawal reason and accommodation note.
3. Learning data: lesson progress, short reflections and practice attempts.
4. Submissions: lab and assessment submissions, free text only, versioned.
5. Review data: reviewer rubric scores, rationale and feedback. Feedback reaches the learner only when a reviewer releases it.
6. Pilot data: workflow boundaries, decisions, owner and authorizer names, authorization references, and task observations (durations and quality flags). Notes must contain no member data.
7. Oversight data: tabletop exercise decision logs and baseline counts drawn from Customer's own records. [CONFIRM these features are in the pilot release]
8. Evidence-binder data: status of elements E1 to E8, owner names, notes and links to documents that stay in Customer's own systems. No files are stored.
9. Audit events: actor id, institution id, action, record type, record id, version, timestamp and outcome. No content.
10. Technical data: sign-in records (including IP address and browser details), notification send records, and server request logs (including IP addresses) kept by Innorve's hosting and database providers.

Annex 2: Technical and organizational security measures

Measures marked [CONFIRM] are organizational controls that Innorve must confirm before this DPA is signed.

A. Architecture and hosting

• The web application runs on Vercel (serverless functions in a US region).
• The database and authentication run on Supabase: managed PostgreSQL in an Amazon Web Services region in the United States.
• Source code is kept in a private GitHub repository. GitHub holds no Customer Data.

B. Tenant isolation and access control

• Every institution-owned record carries an institution id.
• PostgreSQL row-level security enforces access on every query.
• Composite foreign keys prevent a record from pointing at another institution's data.
• Authorization is checked again in server code on every request and every export.
• The application holds no database service key. It acts as the signed-in user, so database rules always apply to application requests.
• Role-based access follows the role matrix in the trust packet. Learners see their own work and released feedback. Reviewers see submitted (not draft) work in their assigned institution or cohorts, and the answer keys. Facilitators see enrollment and activity status and released results, but not learner drafts. Sponsors see cohort aggregates with denominators, the binder status and the workflow results, but not individual drafts or detailed scores. Institution admins manage membership only. Innorve platform staff administer institutions and cohorts, and database rules deny them learner drafts.
• An automated test suite checks tenant isolation and role boundaries, including that a user of institution A cannot read institution B's records, that a learner cannot read answer keys or unreleased feedback, and that a sponsor sees aggregates only.
• Administrative access to the hosting and database provider consoles is limited to named Innorve personnel [CONFIRM names], protected by multi-factor authentication [CONFIRM], and used only with a recorded justification [CONFIRM process]. Console access with database-owner privileges is not subject to row-level security, which is why it is restricted this way.

C. Authentication and sessions

• Passwordless sign-in by email: a one-time link or a 6-digit code. No passwords are stored.
• Invitations are accepted only when the invited person signs in with the invited email address. Invitations expire after 30 days.
• Session cookies are HttpOnly, Secure and SameSite=Lax.
• Single sign-on is planned but not yet available.

D. Restricted content

• Answer keys and unseen assessments are stored only in the database behind role checks.
• They are never shipped in the web application's code or static files. A build check verifies this.

E. Integrity controls

• Rubric totals are computed by the database, not entered by hand.
• A pass requires every dimension to be scored, a total of at least 16 of 20, and no critical failure.
• Reviewers cannot assess their own work.
• Released assessments and submitted work are immutable. Revisions and appeals add new records.
• A recorded boundary breach in a pilot workflow cannot be erased.

F. Encryption

• All traffic uses TLS. The Services are HTTPS only, with HTTP Strict Transport Security (HSTS).
• Stored data is encrypted at rest by Supabase and Vercel.

G. Logging

• Audit events record the actor, action, record type, record id, version, time and outcome, without content.
• Every CSV export is logged as an audit event.
• Deletions of institutions and user accounts are logged as audit events.

H. Data minimization

• No member data by design and by contract (section 5).
• No file uploads. The evidence binder stores links, not documents.
• No AI model processes Customer Data.
• No advertising or analytics cookies and no third-party trackers.

I. Backup and recovery

• Automated daily database backups with 7-day retention. [CONFIRM plan before first pilot]
• Recovery targets are set out in the trust packet's business continuity document. [CONFIRM]

J. Personnel and organizational measures

• Confidentiality agreements for Personnel with access to Customer Data. [CONFIRM]
• Background checks for Personnel with production access. [CONFIRM]
• Security and privacy training for Personnel. [CONFIRM]
• A named person accountable for security: [SECURITY OWNER]. [CONFIRM]
• An incident response plan with named roles (see the trust packet). [CONFIRM names]

K. What Innorve does not yet have

• No SOC 2 report.
• No ISO 27001 certification.
• No independent penetration test yet.
• No cyber insurance on record.

Annex 3: Authorized subprocessors

Not subprocessors:

• GitHub holds Innorve's source code only. It holds no Customer Data.
• Google Fonts is contacted by a visitor's browser only when the visitor opens the public AI Obligations Navigator page. It receives no Customer Data from the platform.

Annex 4: Retention schedule (RET-v1)

[CONFIRM with counsel]