Security & Trust
iGPA handles student records, so security isn't a feature — it's the foundation. Here's how we protect your data, all the way through.
- In transit: TLS 1.2+ everywhere, with HSTS enforced.
- At rest: AES-256 disk encryption on our managed database, plus an additional layer of column-level encryption on personally identifiable information (PII).
- The PII encryption key is stored only in a server-side secret — never in client code, never written to logs.
- Every record is protected by database Row-Level Security (RLS) keyed to a non-spoofable identifier.
- One institution can never see another institution's data — the isolation is enforced by the database itself, not by application convention.
- Least-privilege access: production and PII access is limited to a small number of named system administrators on a need-to-know basis.
- Multi-factor authentication (MFA) is mandatory for all administrative access.
- Credentials are managed in 1Password; administrative endpoints use full-disk encryption (FileVault) and a 7-day patch SLA.
- Hosted on Supabase (managed PostgreSQL) running on Amazon Web Services in the United States.
- The database environment is within a SOC 2 Type II scope; the underlying AWS data centers provide physical security, redundant power and cooling, and 24×7 staffing.
- Static delivery is served via Netlify and Cloudflare with CDN and a web application firewall.
- We operate as a "school official" under FERPA and align with GDPR/UK GDPR principles where applicable.
- Data minimization by design; analytics use aggregated data.
- Bounded retention with defined deletion windows; data is collected only for the purposes described in our Privacy Policy.
- Users can access and update their data, and export it from the platform.
- Self-service account deletion cascades across every owned record and wipes the underlying identity.
- Every deletion is recorded — who, when, and a record snapshot — in an admin-only, access-restricted audit log.
- Documented business-continuity and disaster-recovery procedures: 4-hour RTO, 24-hour RPO, reviewed annually with failover testing.
- Managed backups plus point-in-time recovery.
- Real-time error and performance monitoring (with PII masked in session replays) and a public status page at status.internationalgpa.com.
- Every change passes required automated checks (linting, type-checking, tests, dependency vulnerability audit) before reaching production.
- Secure-by-design practices: parameterized queries, input sanitization, a Content-Security-Policy, and hardened database functions.
- Atomic, zero-downtime deploys.
- A documented incident-response process with defined triage, mitigation, and post-incident review.
- Breach notification commitments: for FERPA-protected data, affected institutions are notified immediately upon confirmation; where GDPR/UK GDPR applies, we assist with the 72-hour notification deadline.
We want iGPA to be usable by everyone, including people who rely on assistive technologies. Accessibility is part of how we design and build the product, not an afterthought.
Conformance status: iGPA is designed with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA in mind. We consider it partially conformant — built toward AA, but not yet fully verified by an independent audit.
Measures we take
- Semantic HTML with labeled, keyboard-operable form controls.
- Keyboard navigation across the core calculator and account flows.
- Attention to color contrast and visible focus states.
- Accessibility considered during design and code review.
Known limitations (being addressed)
- An internal review identified some color-contrast gaps that we are remediating.
- Not every flow has been verified for full keyboard-only operation (for example, drag-to-reorder in the course list).
- We have not yet completed a formal VPAT or third-party accessibility audit.
Feedback: if you encounter an accessibility barrier, email [email protected] or call 913-513-1525. We treat accessibility issues as bugs — we'll respond and work with you on an accessible alternative while we fix the underlying issue.
Last reviewed: May 2026.
We use a small set of trusted infrastructure providers, each bound by a data processing agreement. We use HighLevel for staff/marketing contacts only — no student data is stored there.
- Supabase — Database, authentication, hosting
- Stripe — Payments (no card data stored by us)
- Resend — Transactional email
- Sentry — Error & performance monitoring (PII-masked)
- Better Stack — Uptime monitoring & status page
- Netlify / Cloudflare — Static hosting, CDN, web application firewall
- Anthropic — AI transcript reading (Built-in engine only; US inference, zero data retention, no training)
The AI never converts a grade. It reads course rows off an uploaded transcript. The conversion itself stays deterministic, rule-based mapping, and the extracted values are shown for a person to confirm before anything is saved. Manual entry is always available.
Transcript reading is off until an institution's administrator turns it on and acknowledges the disclosure. Every change to that setting is written to an append-only audit record and confirmed to the administrator by email. Other staff can see what is enabled, but cannot change it.
The administrator chooses one of two engines. With the Built-in engine (provided by iGPA), the file is processed by Anthropic under iGPA's own account: inference pinned to the United States, zero data retention, no training on the data, and a prompt that asks for course rows only, never the student's name or date of birth. That cannot be switched on. Models are pinned to fixed versions and changed only after validation against a test set. With the institution's own AI API key, the file goes to the institution's Anthropic or OpenAI account under a key it supplies. It, too, reads course rows only by default; the administrator can separately choose to have the student's name, date of birth, city, and school read from the header to prefill the student card, a choice that is off by default, audited, and confirmed by email. Keys are stored encrypted and never sent to the browser.
In both cases the file passes through our infrastructure in memory only: never written to disk, never logged, never retained by us. Usage under the Built-in engine is capped per institution per month, and anonymous visitors of an embedded calculator are never processed under iGPA's account.
Found a security issue, or need detailed documentation for a vendor security review (e.g., a completed HECVAT or our Information Security Policy)? Email [email protected] . We share detailed security materials with institutions under assessment on request.