Trust Center

Last reviewed: August 3, 2026 · Reviewed quarterly

Everything a school, district, or university needs to evaluate iVenza: how we handle student data, the security controls we operate, who our sub-processors are, how long we keep things, and the agreement we sign. Where we do not yet have something a procurement office will ask for, this page says so plainly rather than leaving you to find out in a follow-up call.

1. The due-diligence package

These are the documents institutions ask us for. Public ones are linked. The rest we send to a named institutional contact, normally within two business days, and we do not require an NDA to release them.

Published

• Sub-processor register

  Available

  Every third party that touches personal data, what it processes, and whether it is core or optional.

• Data retention schedule

  Available

  What we keep, for how long, what survives account deletion, and why.

• Accessibility conformance

  Available

  WCAG 2.2 AA audit results and our documented exceptions, for ADA Title II review.

• Parents' Bill of Rights

  Available

  Required by New York Education Law 2-d. We publish it for every state.

• Privacy Policy

  Available

  What we collect, how it is used and shared, and your rights.

• Vulnerability disclosure

  Available

  Our public VDP, scope, safe harbor, and a 3-business-day acknowledgment commitment.

Sent on request

• Data Privacy Agreement

  Available

  K-12 and higher-education variants. If your district uses the SDPC National DPA, we would rather sign yours.

• Data map

  Available

  Formal inventory: category, purpose, storage location, who can access it, retention, sub-processor.

• Completed HECVAT / K-12 CVAT

  Available

  Prepared answers for the current unified HECVAT, including the privacy, AI and accessibility sections.

• Incident response plan

  Available

  Severity model, response steps, and our breach notification clocks.

• State compliance matrix

  Available

  Per-state requirements and artifacts. Florida, California, Illinois, New York and Texas are mapped.

2. Regulatory posture

Which regulations apply to an iVenza deployment, and where we stand on each.

3. Security

The design principle worth understanding: authorization is enforced in the database, not in application code. Every table carries row-level security policies, so a compromised or modified client cannot read data it is not entitled to. This is the control that does the most work in a multi-tenant system holding minors' data.

Data minimization, by architecture

iVenza is offline-first. The mobile app's primary store is a local database on the device, and most of the product works with no network and no account at all. Data moves to our servers only for a signed-in account that syncs. The practical effect is that a meaningful amount of athlete data never leaves the device, which is a stronger minimization story than a policy promise.

4. Student data handling

School-managed mode

An organization we mark as school-managed runs under a different set of rules, and they are enforced on our servers rather than hidden in the app. For a student in that organization we switch off marketing drips on every channel, public leaderboards, referral and friend-finding, third-party account linking, and outbound AI unless your institution approves the provider. Transactional messaging - practice reminders, schedule changes, waiver prompts - is deliberately untouched, because suppressing it would break the thing the student is there to use. The institution can direct export and deletion of its record and receives a written certificate, its own retention clock applies, and every administrative action is logged to that organization's security history.

What we will never do

• No advertising. We run none, and we integrate no advertising network or SDK.
• No selling personal data. Ever, and the prohibition survives an acquisition.
• No commercial profiling of students for any purpose other than delivering the service.
• No third-party analytics SDK. Product analytics are first-party tables in our own database, with a user-facing opt-out and a global kill switch.
• No training AI models on your data. See below.

Artificial intelligence

Some optional features use Anthropic to turn something a user submitted into structured data or a draft - filling in a workout from a photo, reading a timetable off a PDF, drafting a message a coach then edits and sends. The specifics procurement asks about:

• Content is sent only when a user explicitly invokes an AI feature. There is no background or bulk transmission of student data.
• Submitted content is not used to train models.
• Calls are made server-side from our own functions; the app never calls the provider directly.
• There is no automated decision-making about a student. Output is drafting assistance a human reviews.
• In a school deployment, AI is off unless your institution turns it on. Approving our AI provider is a per-institution setting that defaults to off, so a student's content reaches no AI provider until the agreement names it. This is enforced on our servers, not just hidden in the app.

Rights and deletion

Access, export, correction and deletion are self-service in the app. Under a school agreement, requests route through the institution, and the institution can direct deletion of an individual student or of all its data at any time, and at contract end. In higher education, students 18 and over hold FERPA rights directly, so we serve those requests to the student rather than to a parent. Full detail is in the retention schedule.

5. What we do not have yet

Every vendor has a version of this list. Most do not publish it. We would rather you evaluate us on an accurate picture than discover these in week three of a review.

6. Incidents

We notify an affected institution of a confirmed or reasonably suspected breach of student data without unreasonable delay and no later than 72 hours after discovery, and sooner where state law requires it - 7 calendar days for New York educational agencies under Education Law 2-d, and per statute in Illinois. The notice states what happened, when it was found, which categories and records were involved, what we did, and who to call.

Stated honestly: response is carried by a small team, external counsel is not on retainer, and the plan has not yet been tabletop-tested. The full plan is available on request. To report something now, use the vulnerability disclosure page or email help@susos.co.

7. How this stays current

A trust page that quietly goes stale is worse than none, so keeping this one accurate is part of our engineering process rather than a calendar reminder. This page and its supporting documents are reviewed quarterly, and additionally whenever a sub-processor changes, a new data category is collected, a security control changes, a major interface release ships, we enter a new state, or an incident occurs. An automated check in our build pipeline fails the build if the published sub-processor list drifts out of step with our Privacy Policy, so that particular page cannot silently go stale.