Security

• In transit

  TLS 1.2 or higher on every connection between student phones, the LockedIn API and the dashboard.

• At rest

  AES-256 for all student data in databases and backups.

• On the phone

  Sign-in credentials stay in the phone’s own secure storage. On Android, the app’s credentials, the campus boundary and any queued reports are encrypted, and a store that has been corrupted or tampered with is deleted and recreated encrypted, never left in plain text.

• Passwords

  Hashed, never stored in plain text.

• Schools

  Role-based access controls. A school administrator sees only their own school’s students; a district administrator sees only the schools in their district, as the district sets it up. No one at one school can see another school’s data.

• Students

  A student sees only their own compliance status, in the app.

• LockedIn staff

  Only the few people who run the service, on least privilege. Each signs a confidentiality agreement, passes a background check, and is trained on privacy and security when they join and every year after. Access is revoked immediately when someone leaves.

• Sign-in

  Multi-factor authentication is required for all administrative and infrastructure access. Sessions time out and tokens expire, and a step-up code issued for a sensitive action, like an export, works only for that action.

• Audit log

  Every access to student data is logged, and the logs are kept and reviewed regularly.

Render’s own providers (Amazon Web Services, Google Cloud Platform, Cloudflare and ClickHouse) are covered by Render’s data processing addendum. Vendors that never receive student data, like the map tiles in the dashboard and this site’s analytics, are listed in the privacy policy.

• Penetration testing

  LockedIn commissions independent third-party penetration tests of its web application and API. Findings and their fixes are tracked, and schools can review them under the audit terms below.

• Vulnerability management

  Automated vulnerability scanning of application code and infrastructure dependencies, with critical vulnerabilities patched first. Every change goes through code review and dependency auditing.

• The app on the phone

  The app runs inside the standard iOS and Android sandbox. It doesn’t access messages, calls, photos, browsing history or files, and on iPhone it has no technical way to.

• Device integrity

  Every compliance report from a student phone carries a per-device attestation (Apple App Attest on iPhone; Google Play Integrity and a hardware-backed signing key on Android), and the server checks it on every request. For now that check runs in observe mode: an unverified report is logged and counted, not refused, until enough phones have completed attestation. The apps’ own integrity checks report signs of tampering to the school’s dashboard.

• Policies

  Security policies and procedures are documented and reviewed at least once a year.

• Backups

  Encrypted daily backups with point-in-time recovery, kept for seven days in the same region as the data, under the same encryption and access controls. They’re used only to recover from a disaster, so a deleted record ages out of every backup within seven days.

• Response plans

  A documented incident response plan, with a severity model, notification clocks and tabletop exercises, reviewed at least once a year and after any significant incident. A business continuity plan is documented too.

• Telling your school

  If we suspect a security incident involving unencrypted personal information, we tell the affected school without undue delay, before our investigation is finished. A confirmed incident is reported in writing within 72 hours of confirmation. Where state law requires faster notice, we meet it, and where your data privacy agreement sets its own terms, those govern.

• SOC 2 Type II

  Not yet attested. Controls are documented and implemented, and independent attestation is in progress.

• Frameworks

  Our security program is aligned with the NIST Cybersecurity Framework 2.0 and incorporates the CIS Critical Security Controls v8. “Aligned” is our own assessment against the published criteria, not a certification.

• Privacy seals

  LockedIn holds no third-party privacy certification or seal, and doesn’t claim one.

• FERPA

  We act as a school official with a legitimate educational interest: we do a job the school would otherwise do itself, under its direct control, use student data only for that job, and never redisclose it.

• COPPA and state laws

  We comply with COPPA and with state student-privacy laws, including California’s SOPIPA and Michigan’s Student Online Personal Protection Act. LockedIn runs no advertising and never sells or rents student data.

• Data privacy agreements

  We’ll sign the SDPC National Data Privacy Agreement (including Exhibit G for Michigan), the Hawaii Standard Data Sharing Agreement, or your state’s or district’s own. Where it conflicts with our policy, your agreement governs.

• Audits

  Once a year, or after an unauthorized-access incident, a school can audit our security and privacy measures on ten business days’ written notice, under a confidentiality agreement.