Security
KudoTapper protects a shared, isolated database of minors' records. Security isn't a setting here — it's the architecture.
Last updated: July 18, 2026
Data minimization by default
The strongest protection for student data is not collecting it. KudoTapper stores only a first name, last initial, an optional class and school ID, an NFC card’s random ID, and a points balance. There are no student emails, birthdates, addresses, photos, or logins to protect, because we never collect them.
Tenant isolation
Every school and district is a separate tenant. Access is enforced in the database itself with row-level security keyed to a user’s school and role — designed to prevent one school from reading or writing another school’s data even if the application layer had a bug. Isolation is verified with automated tests.
Least-privilege access
KudoTapper accounts are staff-only and invite-only; there is no public sign-up and no student login. Roles (district administrator, school administrator, teacher) scope what each person can see and do, and privileged actions are checked on the server on every request, not just hidden in the interface.
Encryption & hosting
Data is encrypted in transit (TLS) and at rest. The platform runs on established cloud infrastructure (Supabase and Vercel), and student data is stored in the United States. Staff passwords are stored only as salted hashes.
Kiosk safety
The student store kiosk is attended by staff and locked in software with a signed, server-enforced lock and a staff exit PIN, so a reload or navigation can’t drop a student into the staff app. On the tablet, kiosk mode is paired with the device’s own guided-access / screen-pinning lock. Students interact only by tapping a card that carries a random ID — no personal data lives on the card.
Integrity & auditing
The points ledger is append-only: awards, spends, and corrections are recorded as immutable entries, balances are updated atomically to prevent double-spends, and sensitive administrative actions are written to an audit log. Point movement is validated on the server against each school’s policy limits.
Operational practices
We apply secure-by-default engineering: input validation, rate limiting on sensitive endpoints, fail-closed cost and access controls, dependency and code review before changes ship, and no third-party advertising or analytics trackers on student data.
Breach notification
If we confirm a security breach affecting a School’s student data, we notify the affected School without undue delay and no later than 72 hours after confirmation, describe what happened and what data was involved, and cooperate with the School’s investigation and its own notification obligations. See our Privacy Policy for details.
Reporting a vulnerability
We welcome responsible disclosure. If you believe you’ve found a security issue, please email security@arringtonis.com with details and steps to reproduce, and give us a reasonable chance to investigate before public disclosure. Please do not access or modify data that isn’t yours while testing.
