Trust and vendor file Incident response
Incident response
Last reviewed: [DATE]
This document describes how Innorve responds to a security incident affecting Innorve Academy, and when and how a credit-union customer will be told.
Status. This plan has not yet been exercised in a tabletop test. [CONFIRM date of first exercise] The notification commitment below is proposed in the draft DPA and is not yet adopted. [CONFIRM]
What counts as a security incident
A security incident is any confirmed or reasonably suspected:
- unauthorized access to, or acquisition, use, disclosure, alteration, loss or destruction of, customer data; or
- cyberattack or exploitation of a vulnerability that disrupts the platform.
Examples:
- a user reads another institution's records;
- a sign-in link or code is intercepted and used;
- a provider console account is compromised;
- a subprocessor reports a breach affecting Innorve's data;
- answer keys or unseen assessments are exposed;
- member data is found in the platform (it should never be there; see below).
Notification commitment
Innorve will notify the affected credit union without undue delay, and no later than 24 hours after becoming aware of a security incident affecting its data. [CONFIRM]
Why 24 hours: the credit union's own clock
Under 12 CFR 748.1(c), a federally insured credit union must notify NCUA of a reportable cyber incident as soon as possible and no later than 72 hours after it reasonably believes one has occurred. Where the credit union relies on a third party, the 72 hours can run from when the third party notifies the credit union. [CONFIRM exact wording with counsel]
A 24-hour vendor notice is designed to leave the credit union time to assess the incident and decide whether it is reportable. Whether an incident is reportable to NCUA is the credit union's decision, not Innorve's. Innorve will give the credit union the facts it needs to decide.
Because the platform is designed to hold no member information, an incident is not expected to involve member data. If member information was entered by mistake and is affected, the credit union may also need to act under its own response program for unauthorized access to member information (12 CFR Part 748, Appendix B). [CONFIRM]
What the notice contains
The first notice contains what Innorve knows at the time. Updates follow as facts become clear.
- What happened, when it started and when Innorve became aware.
- Which institutions, users and data categories are affected, with approximate numbers.
- Whether the platform was disrupted, and for how long.
- The likely consequences.
- What Innorve has done and will do to contain and fix it.
- A named Innorve contact.
Innorve will not notify a credit union's members, employees or regulators on its behalf without its written approval, unless the law requires it.
Roles
| Role | Responsibility | Person |
|---|---|---|
| Incident lead | Declares the incident, owns the timeline, makes decisions, approves customer notices | [INCIDENT LEAD] |
| Technical lead | Investigates, contains, preserves evidence, restores service | [TECHNICAL LEAD] |
| Communications lead | Sends and tracks customer notices and updates; single point of contact for customers | [COMMUNICATIONS LEAD] |
| Counsel | Advises on legal obligations and notice wording | [COUNSEL] |
| Backup for each role | Covers absence | [CONFIRM] |
Innorve is a small team. One person may hold more than one role, but the incident lead must make sure the 24-hour notice goes out even if investigation is still under way. [CONFIRM]
Incident contact: [INCIDENT CONTACT EMAIL], [INCIDENT CONTACT PHONE]. Credit unions should report suspected incidents to the same contact. Each credit union names its own incident contact in its statement of work.
Phases
1. Prepare
- Keep this plan, the contact list and each customer's incident contact current.
- Keep provider console access limited to named personnel with MFA. [CONFIRM]
- Subscribe to Vercel, Supabase and email provider status and security notices. [CONFIRM]
- Run a tabletop exercise of this plan at least once a year. [CONFIRM]
2. Detect and report
Incidents may be detected through:
- reports from users, credit unions or security researchers;
- notices from subprocessors;
- unusual activity in the audit log (for example, unexpected exports or deletions);
- provider logs and alerts [CONFIRM what alerting is configured];
- a failed tenant-isolation or role-boundary test that reveals a real exposure.
Anyone at Innorve who suspects an incident reports it to the incident lead immediately. The time Innorve becomes aware is recorded, because the 24-hour notice runs from it.
3. Assess
The incident lead decides quickly:
- Is this a security incident?
- Which institutions and data are affected?
- Is it still happening?
- How severe is it?
| Severity | Examples | Customer notice |
|---|---|---|
| High | Cross-institution data exposure; compromised console account; data loss | Within 24 hours of awareness |
| Medium | Suspected but unconfirmed exposure; a single account taken over | Within 24 hours of awareness |
| Low | Blocked attack with no data access; availability issue with no data impact | In the next routine update, or sooner if the credit union's operations are affected [CONFIRM] |
When in doubt, treat the incident as affecting the customer and notify.
4. Contain
Typical steps, depending on the incident:
- revoke sessions and remove affected memberships or invitations;
- rotate keys and provider credentials;
- disable an affected feature or put the platform into maintenance;
- block abusive traffic at the hosting layer;
- ask the subprocessor to act, where the issue is in its service.
5. Notify
- Notify each affected credit union within 24 hours of awareness. [CONFIRM]
- Send updates at agreed intervals until the incident is closed. [CONFIRM interval]
- Coordinate with counsel on any other notices the law requires.
6. Eradicate and recover
- Fix the root cause.
- Restore data from backup if needed. Backups are daily and kept for 7 days. [CONFIRM plan before first pilot]
- Confirm isolation and role-boundary tests pass before reopening the platform.
7. Review
Within [CONFIRM] business days of closing the incident:
- write a post-incident review: timeline, root cause, impact, what worked and what did not;
- record corrective actions with owners and dates;
- share a summary with affected credit unions on request.
Records
Innorve keeps an incident record for each incident, including:
- the time Innorve became aware, and the time each credit union was notified;
- the people involved and decisions made, with reasons;
- evidence preserved (logs, audit events, provider reports);
- customer notices and updates sent;
- the post-incident review and corrective actions.
Incident records are kept for [CONFIRM: at least 3 years]. The platform's audit events are kept for 3 years and hold references only, so they can support an investigation without containing training content.
Member data found in the platform
Member data should never be in the platform. If it is found:
- Treat it as a security incident and follow this plan.
- Tell the credit union within 24 hours. [CONFIRM]
- With the credit union's instructions, identify and delete or redact the affected records.
- Help the credit union decide whether its own response program applies.