Vendor questionnaire answers

Last reviewed: [DATE]

These are direct answers to questions that commonly appear in credit-union vendor due-diligence questionnaires, including SIG-Lite style questionnaires and NCUA-style third-party reviews. Where the honest answer is "No" or "Not yet", we say so and name the evidence that exists instead.

Items marked [CONFIRM] are not yet verified. Treat them as open until Innorve confirms them in writing.

A. Company and governance

A1. What is the legal name and address of the vendor? Innorve Inc., incorporated in [STATE OF INCORPORATION], registered address [REGISTERED ADDRESS].

A2. What service are you providing? Innorve Academy: a hosted platform that trains credit-union staff on using and overseeing AI. It includes the 30-day Team Pilot and the Oversight program. It is contracted through a statement of work (SOW) plus a data processing addendum (DPA).

A3. Who is accountable for information security? [SECURITY OWNER]. [CONFIRM]

A4. Do you have a written information security program or policy set? [CONFIRM]. What exists today: this trust packet, which documents the controls in place, and the draft DPA with its security annex.

A5. Do you have a SOC 2 report? No. Compensating evidence:

• the subprocessors' own SOC 2 reports (Vercel and Supabase), covering the hosting and database infrastructure;
• the automated tenant-isolation and role-boundary test suite;
• the content-free audit log;
• this trust packet and the right-to-audit clause in the draft DPA.

A6. Are you ISO 27001 certified, or do you hold any other security certification? No. Innorve holds no security certification.

A7. Have you had an independent penetration test? Not yet. Planned date: [CONFIRM]. Compensating evidence: the automated test suite checks tenant isolation and role boundaries (for example, a user of institution A cannot read institution B's records), and a build check verifies that answer keys and unseen assessments never ship in the application code.

A8. Do you carry cyber liability insurance? No policy on record. [CONFIRM whether a policy will be obtained, and when]

A9. Have you had a security incident in the last three years, or are you subject to litigation or regulatory action that could affect the service? None known. [CONFIRM]

A10. Can you provide financial statements or customer references? [CONFIRM what Innorve will share]

B. Personnel

B1. Do personnel with access to customer data undergo background checks, receive security and privacy training, and sign confidentiality agreements?

• Background checks: [CONFIRM]
• Security and privacy training: [CONFIRM]
• Confidentiality agreements: [CONFIRM]

B2. Where are personnel with access to production systems located? [CONFIRM country or countries]

C. Data

C1. What credit-union data will you hold? Staff training data only: work email and display name, roles, cohort enrollments, lesson progress and reflections, practice attempts, free-text lab and assessment submissions, reviewer scores and feedback, pilot workflow records and observations, oversight records, and evidence-binder status with links. See Data inventory and flows.

C2. Will you hold member (consumer) nonpublic personal information? No. The platform is designed to hold no member names, account numbers or member records. Training cases are fictional. The draft DPA prohibits the credit union from submitting member information, and requires notice and deletion if any is entered by mistake.

C3. Can users upload files? No. The platform has no upload feature. The evidence binder stores links to documents that stay in the credit union's own systems. A link does not grant access; the credit union's system enforces access.

C4. Where is data stored, processed and accessed? Stored and processed in the United States: database and authentication on Supabase (AWS, US region [SUPABASE REGION]); web application on Vercel (US region [VERCEL REGION]); email provider in the United States [CONFIRM before first pilot]. Location of personnel with production access: see B2.

C5. Is data encrypted in transit and at rest? Yes. In transit: TLS for all traffic, HTTPS only, with HSTS. At rest: encrypted by the providers (Supabase and Vercel). Innorve does not manage the encryption keys, and customer-managed keys are not offered.

C6. How is our data separated from other customers' data? Every institution-owned record carries an institution id. PostgreSQL row-level security enforces access on every query. Composite foreign keys stop a record from pointing at another institution's data. Server code checks authorization again on every request and export. The application holds no database service key. An automated test suite checks isolation.

C7. Do you sell, share or use our data for other purposes? No. Customer data is used only to provide the service. It is not sold, not used for marketing and not used to train AI models.

C8. How long do you keep our data? Under the proposed RET-v1 schedule [CONFIRM]: institution data is deleted 90 days after the engagement ends unless the contract says otherwise; audit events (references only) are kept 3 years; backups rotate within 7 days. See Retention and deletion.

C9. How do we get our data back, and how is it deleted at the end of the contract? Authorized roles can export cohort CSV files (assessment records, observations, progress) at any time; each export is logged. After the engagement, Innorve platform staff delete the data through audited database functions that require typing the institution's exact name (or the person's exact email for a user account). Deleted data can remain in backups for up to 7 days. Written confirmation of deletion is available on request. [CONFIRM]

C10. Do you use subprocessors, and will you notify us of changes? Yes: Vercel (hosting), Supabase (database and authentication) and an email provider (planned: Resend) [CONFIRM before first pilot], all in the United States. GitHub holds source code only and no customer data. The draft DPA proposes at least 30 days' written notice of changes, with a right to object. [CONFIRM] See Subprocessors.

D. Access control and authentication

D1. How do users authenticate, and how are sessions protected? Passwordless email sign-in: a one-time link or a 6-digit code. No passwords are stored. Session cookies are HttpOnly, Secure and SameSite=Lax. Session lifetime: [CONFIRM].

D2. Do you support MFA or SSO for users? Not yet. There is no separate second factor. Sign-in relies on control of the user's work mailbox, which the credit union protects with its own controls. Single sign-on is planned but not yet available. [CONFIRM target date]

D3. Is access role-based? Yes. Roles are learner, reviewer, facilitator, sponsor and institution admin, plus Innorve platform staff. See the role matrix in Access control.

D4. Who at Innorve can see our data? Innorve platform staff administer institutions and cohorts through the application, and database rules deny them learner drafts. Personnel with provider-console access can reach all stored data; this is limited to named people [CONFIRM] and used only with a recorded justification [CONFIRM process].

D5. Is MFA enforced on administrative and provider accounts? [CONFIRM for Vercel, Supabase, GitHub, the email provider and the domain registrar]

D6. How are user accounts provisioned and removed? By invitation to a work email, accepted when the person signs in with that address. Invitations expire after 30 days. Institution admins manage membership and roles, and role changes are audited. The credit union reviews its own user list; Innorve can supply it on request.

E. Application security and change management

E1. Describe your secure development practices. Source code is in a private GitHub repository. Database access rules and integrity rules are versioned migrations in the same repository. An automated test suite checks tenant isolation and role boundaries. A build check prevents answer keys and unseen assessments from shipping in the application code. Not yet confirmed: code review before deployment [CONFIRM]; dependency vulnerability and secret scanning, with tool and frequency [CONFIRM]. No independent penetration test yet (see A7).

E2. Are development and production environments separated? Is production data used in testing? [CONFIRM separation, and that production data is never copied to development or test environments]

E3. What web-application protections are in place? HTTPS only with HSTS, and security headers including a Content-Security-Policy. [CONFIRM they remain in production] There are no file uploads, which removes a common attack path.

E4. How do you protect the integrity of training and assessment records? Rubric totals are computed by the database. A pass requires every dimension scored, 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 cannot be erased.

F. Logging and monitoring

F1. Do you keep audit logs, and can we see ours? Yes. Audit events record actor id, institution id, action, record type, record id, version, timestamp and outcome. They never contain content. Every export and every deletion is logged. Audit events are kept for 3 years and survive institution deletion as references only. In the current build, your institution's admins and facilitators can read its audit events. [CONFIRM]

F2. Do you monitor for security events and alert on them? [CONFIRM what alerting is configured and who responds]

G. Incident response

G1. Do you have an incident response plan? Yes, documented in Incident response. It has not yet been exercised in a tabletop test. [CONFIRM date]

G2. How quickly will you notify us of an incident, and who is the contact? Without undue delay and no later than 24 hours after Innorve becomes aware of a security incident affecting your data. [CONFIRM] This is intended to leave you time within your own 72-hour NCUA notification window under 12 CFR 748.1(c). Contact: [INCIDENT CONTACT EMAIL], [INCIDENT CONTACT PHONE].

H. Business continuity

H1. Do you back up our data? Yes. Automated daily database backups, kept 7 days. [CONFIRM plan before first pilot] Restore testing: [CONFIRM].

H2. What are your RPO and RTO? Proposed targets, not yet tested: RPO [RPO] (up to 24 hours, from daily backups); RTO [RTO]. [CONFIRM]

H3. What happens if a provider fails? The platform depends on Vercel, Supabase and the email provider. Sign-in depends on email; users with an active session can keep working, and there is a planned fallback to a standby email provider [CONFIRM]. See Business continuity.

H4. Is the service critical to member operations? No. It is a training platform. It is not member-facing and has no connection to the core or any other credit-union system. Your own policy decides its classification.

I. AI

I1. Does the service use AI to process our data, or use our data to train AI models? No. No AI model processes customer data in this version. Nothing in the platform sends data to an AI provider. Customer data is not used to train AI models.

I2. Was AI used to create the course content? Yes. Course materials were drafted with AI assistance and are reviewed by people. Practitioner review is in progress. See AI use statement.

J. Contract, compliance and other

J1. Will you sign a data processing addendum? Yes. A draft DPA is available and is being finalized with counsel.

J2. Do you give us a right to audit? Yes, proposed. The draft DPA provides the trust packet, annual questionnaire responses and a reasonable-audit clause (once a year, with notice, remote first). [CONFIRM]

J3. Will you cooperate with NCUA examiners? Yes, proposed. The draft DPA commits Innorve to reasonably cooperate with regulator information requests relating to the service, on the credit union's request. [CONFIRM scope]

J4. Does the service provide legal advice, certify compliance or grant credentials? No. The academy teaches about laws and guidance and labels each source by type. It does not provide legal advice, certify compliance or predict exam outcomes. It is not endorsed by NCUA or any regulator. Assessment results are reviewer judgements for training purposes, not employment decisions or professional credentials. Course completion does not grant authority to use AI at the credit union.

J5. Is the platform accessible? The target is WCAG 2.2 level AA, tested with automated (axe) and manual testing. Conformance: [CONFIRM after audit]. See the accessibility statement.

J6. Does the website use tracking or analytics cookies? No. No advertising or analytics cookies and no third-party trackers. The one third-party resource is Google Fonts, loaded by the static AI Obligations Navigator page.