Security overview

Last reviewed: [DATE]

This document describes how Innorve Academy is built and protected. It separates what the system enforces from organizational controls that Innorve still has to confirm. Items marked [CONFIRM] are not yet verified.

At a glance

Architecture

  Browser (credit-union staff)
        |
        |  HTTPS only (TLS, HSTS)
        v
  Vercel: Next.js web application
  serverless functions, US region [VERCEL REGION]
        |
        |  queries run as the signed-in user
        |  (no database service key in the application)
        v
  Supabase: PostgreSQL + authentication
  AWS, US region [SUPABASE REGION]
  row-level security on every table holding institution data
        |
        |  sign-in codes and notifications
        v
  Email provider (planned: Resend) [CONFIRM before first pilot]
        |
        v
  User's work mailbox

• The web application is a Next.js application hosted on Vercel. Server code runs as serverless functions in a US region.
• The database and authentication run on Supabase: managed PostgreSQL in an AWS region in the United States.
• Source code is kept in a private GitHub repository. GitHub holds no customer data.
• The platform has no connection to any credit-union system. The evidence binder stores links only.

Tenant isolation

Each credit union is an "institution" in the platform. Isolation between institutions is enforced in layers:

1. Every institution-owned record carries an institution id.
2. Row-level security. PostgreSQL row-level security policies check the signed-in user's memberships and roles on every query.
3. Composite foreign keys. Child records reference their parent through both the record id and the institution id. A record cannot point at another institution's data.
4. Server-side authorization. Server code checks authorization again on every request and every export.
5. No service key in the application. The application holds no database service key. It always acts as the signed-in user, so database rules always apply to application traffic.
6. Automated tests. A test suite checks tenant isolation and role boundaries. Its acceptance tests include:
   • a user of institution A cannot read institution B's records;
   • a learner cannot read answer keys or unreleased feedback;
   • a sponsor sees aggregates only.

Limit to be aware of. People with administrative access to the Supabase project console act with database-owner privileges, which are not subject to row-level security. This access is limited to named Innorve personnel [CONFIRM names], protected by MFA [CONFIRM], and used only with a recorded justification [CONFIRM process]. See Access control.

Authentication and sessions

• Passwordless. Users sign in with a one-time link or a 6-digit code sent to their email. There are no passwords to store, leak or reuse.
• Mailbox control equals account control. Anyone who controls a user's mailbox can sign in as that user. The credit union's own email security (including its MFA) therefore protects sign-in to the platform.
• Invitation-based access. A person gets roles only by accepting an invitation, which happens when they sign 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.
• Session lifetime: [CONFIRM]

Authorization and roles

Access is role-based. A summary:

• 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. Database rules deny them learner drafts.

The full matrix is in Access control.

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.

Integrity controls

The platform is built so that training records cannot be quietly changed:

• Rubric totals are computed by the database.
• 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.

Encryption

• In transit: TLS for all traffic. HTTPS only, with HTTP Strict Transport Security (HSTS).
• At rest: stored data is encrypted by the providers. Supabase and Vercel encrypt stored data at rest. Innorve does not manage the encryption keys, and customer-managed keys are not offered.

Web application protections

The current build sends security headers on every response, including a Content-Security-Policy, HSTS, X-Content-Type-Options and a strict Referrer-Policy. [CONFIRM these remain in the production configuration]

The website uses 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.

Logging and monitoring

• Audit events record the actor id, institution id, action, record type, record id, version, timestamp and outcome. They never contain content. They are designed to survive institution deletion as references only, and are kept for 3 years.
• Exports are logged in the audit log, every time.
• Deletions of institutions and user accounts are logged in the audit log.
• Provider logs. Vercel and Supabase keep request and service logs, including IP addresses. [CONFIRM retention per provider plan]
• Alerting. [CONFIRM: what alerts are configured, who receives them and how often logs are reviewed]

Data minimization

• No member data, by design and by contract.
• No file uploads.
• Links, not documents, in the evidence binder.
• No AI model processes customer data.
• Free tools on the public website keep answers in the visitor's browser and send nothing unless the visitor submits a form.

Secure development

• Source code is in a private GitHub repository.
• Database access rules, integrity rules and deletion functions are defined as versioned database migrations in the repository.
• The automated test suite covers tenant isolation and role boundaries.
• The build check prevents restricted content from shipping in the application.
• Code review before production deployment: [CONFIRM]
• Dependency vulnerability scanning: [CONFIRM tool and cadence]
• Secret scanning on the repository: [CONFIRM]
• Separation of development and production: [CONFIRM that production data is never copied to development environments]

Organizational controls

These are not yet verified and must be confirmed by Innorve:

Independent assurance

• Innorve: no SOC 2 report, no ISO 27001 certification, and no independent penetration test yet. Planned penetration test date: [CONFIRM].
• Subprocessors: Vercel and Supabase publish their own independent reports, including SOC 2 reports, through their trust centers. See Subprocessors.

Reporting a vulnerability

Email [SECURITY CONTACT EMAIL]. Please do not test the platform's security without Innorve's written permission.