KudoTapper

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.