Security & Compliance
Technical reference for IT directors and procurement teams · Version 1.0 · February 2026
1. Executive Summary
ExamLock is a phone-locking and exam/test integrity platform designed for Australian schools. Our core privacy principle is simple: we cannot leak what we do not store.
Students using ExamLock have no accounts, no names, no emails, and no passwords on our servers. Students are identified only by a school-issued student number and a one-way hash of their device ID — both meaningless without access to the school's Student Information System (SIS).
Breach scenario: If an attacker gained full access to ExamLock's database, they would find pseudonymous records such as STU-20481 anda3f8c9...b2e1. They could not identify any student without separately compromising the school's SIS.
All data is hosted on Supabase infrastructure in AWS Sydney (ap-southeast-2), ensuring Australian data sovereignty.
2. How an Exam or Test Session Works
One-time setup (per device):
- Student enters their student number on the app
- The app generates a random device UUID and hashes it with SHA-256 locally
- Only the hash is sent to the server — ExamLock never sees the raw device ID
Per exam or test:
- Teacher creates an exam or test in the dashboard → a JWT-signed QR code is auto-generated
- Student scans the QR code → self-registers for the exam or test and checks in
- Student's phone locks automatically
- Teacher monitors status in real time
- Teacher ends the session → all phones unlock
Total student interaction: enter student number once (per device), then scan a QR code per exam or test. No app accounts, no passwords, no setup wizards.
3. Privacy Architecture — What Data Lives Where
| On ExamLock's Servers | NOT on ExamLock's Servers (Ever) | On School's Systems Only |
|---|---|---|
| device_hash (SHA-256) | Student names | student_number ↔ real identity mapping |
| student_number | Email addresses | Contact details |
| school_id | Phone numbers | Parent/guardian info |
| Timestamps (check-in, lock, unlock) | Date of birth | Medical or welfare records |
| Phone lock status | GPS / location data | |
| Platform & OS version | Photos, contacts, files | |
| Violation events (type + time) | Browsing history, biometrics |
4. Data Inventory
| Data Field | Stored? | Example Value | Sensitivity | Purpose |
|---|---|---|---|---|
| student_number | Yes | STU-20481 | Low (pseudonymous) | Link check-ins to a student identity known only to the school |
| device_hash | Yes | a3f8c9...b2e1 | Low (irreversible hash) | Bind a student number to a specific device |
| checked_in_at | Yes | 2026-02-16T09:00:00Z | Low | Record attendance time |
| phone_locked | Yes | true | Low | Track exam or test compliance |
| phone_lock_verified_at | Yes | 2026-02-16T09:01:00Z | Low | Confirm lock was verified |
| platform / os_version | Yes | Android 14 | Low | Debugging and compatibility |
| check_in_method | Yes | qr_code | Low | Audit trail of check-in method |
| violation_type | Yes | app_exit | Low | Record policy violations |
| Student name | No | — | — | Never collected |
| Student email | No | — | — | Never collected |
| GPS / Location | No | — | — | Never collected |
| Biometrics / Photos | No | — | — | Never collected |
5. Breach Scenario Analysis
Scenario: Full database compromise
An attacker gains read access to the entire ExamLock database. What do they get?
- Student numbers (e.g.
STU-20481) — meaningless without the school's SIS - Device hashes — irreversible SHA-256 hashes, cannot be linked to a physical device
- Exam and test timestamps and lock status — operational data only
- Violation records — "student X exited the app at time Y" with no real identity
Result: The attacker holds purely pseudonymous data. They cannot identify a single student without independently compromising the school's SIS. Under Australia's Notifiable Data Breaches (NDB) scheme, pseudonymous data that cannot be re-identified is unlikely to meet the "serious harm" threshold requiring notification.
For our full breach response procedure, see the Data Breach Notification Procedure.
6. How Teachers See Student Names
ExamLock stores student numbers only. Teachers need to identify students during exams and tests. Here is how name resolution works across current and planned modes:
| Mode | Status | How It Works | Names on ExamLock Servers? |
|---|---|---|---|
| ID-Only Mode | Current | Teachers see student numbers and cross-reference with their printed class roll | No |
| Live SIS Lookup | Roadmap | Dashboard queries the school's SIS API in real time to resolve names in the browser | No |
| CSV Cache | Roadmap | Teacher uploads a CSV mapping (student_number → name); cached in browser localStorage only | No |
In every mode — current and planned — student names never flow through ExamLock's servers.
7. QR Code Security Model
QR codes are the primary mechanism for exam and test check-in. Each code is a cryptographically signed JWT token.
| Control | Implementation |
|---|---|
| Token format | JWT (JSON Web Token) per RFC 7519 |
| Signing algorithm | HMAC-SHA256 |
| Signing key | EXAMLOCK_JWT_SECRET (server-side env var, never exposed to clients) |
| Token expiry | 24 hours from generation |
| Payload contents | exam_id, school_id, issued_at, expires_at — no student PII |
| Rate limiting | All anonymous check-in endpoints are rate-limited |
| Replay protection | Server validates expiry and exam/test status before accepting check-in |
8. Phone Locking — How It Works
Android
- UsageStats polling — detects when the student leaves the ExamLock app
- SYSTEM_ALERT_WINDOW overlay — displays a blocking screen preventing app switching during exams and tests
- No MDM profiles, no Device Admin, no Device Owner
- Permissions: Usage Access + Draw Over Other Apps + Camera + NFC
iOS
- Automatic Assessment Configuration (AAC) — Apple's official API for exam and test lockdown
- Uses
AEAssessmentSessionframework - No MDM profiles, no supervised mode required
- The same API used by standardised testing platforms
What ExamLock does NOT do
- No MDM profile installation or device enrolment
- No access to SMS, calls, or contacts
- No GPS or location tracking
- No background camera or microphone access
- No reading of files, photos, or browsing history
- No data collection outside of active exam or test sessions
9. Infrastructure Security
| Layer | Implementation |
|---|---|
| Database | Supabase PostgreSQL with Row-Level Security (RLS) on all tables |
| Encryption in transit | TLS 1.2+ on all connections |
| Encryption at rest | AES-256 (managed by Supabase / AWS) |
| API rate limiting | Applied to all anonymous endpoints (check-in, QR validation) |
| Service role key | Server-side only; never shipped in client bundles |
| Mobile credential storage | Android: EncryptedSharedPreferences · iOS: Keychain Services |
| Data hosting region | AWS Sydney (ap-southeast-2) — Australian data sovereignty |
| Authentication | Supabase Auth (teachers/admins only); students have no auth accounts |
10. Australian Privacy Principles (APPs) Compliance
Compliance with the 13 Australian Privacy Principles under the Privacy Act 1988 (Cth).
| APP | Principle | ExamLock Compliance |
|---|---|---|
| 1 | Open & transparent management | This document + public privacy policy at /privacy |
| 2 | Anonymity & pseudonymity | Students are pseudonymous by architecture — student numbers only, no names or personal identifiers |
| 3 | Collection of solicited information | Minimal collection: student number + device hash + exam/test timestamps. No PII collected. |
| 4 | Dealing with unsolicited information | No mechanism exists to submit unsolicited personal information |
| 5 | Notification of collection | Privacy policy available at /privacy; this document provided to schools |
| 6 | Use or disclosure | Data used solely for exam and test integrity. No third-party sharing, no marketing, no analytics. |
| 7 | Direct marketing | No student data used for marketing. No marketing communications sent to students. |
| 8 | Cross-border disclosure | All data hosted in AWS Sydney (ap-southeast-2). No cross-border transfer. |
| 9 | Adoption, use, or disclosure of govt identifiers | Student numbers are school-assigned, not government identifiers |
| 10 | Quality of personal information | Minimal data collected; schools manage student number accuracy via their SIS |
| 11 | Security of personal information | TLS 1.2+, AES-256, RLS, rate limiting, encrypted mobile storage (see Section 9) |
| 12 | Access to personal information | Schools can export/request all data associated with their school_id |
| 13 | Correction of personal information | Schools can update student records; students can request correction through school |
11. NSW-Specific Compliance
| Requirement | ExamLock Compliance |
|---|---|
| PPIP Act 1998 (Privacy and Personal Information Protection) | Student data is pseudonymous; no personal information as defined under PPIP is stored on ExamLock servers |
| NSW DoE data hosting requirements | All data hosted in AWS Sydney (ap-southeast-2) — meets Australian data sovereignty requirements |
| HRIP Act 2004 (Health Records) | No health records collected or stored |
| Children's Online Privacy Code (OAIC, due Dec 2026) | Architecture already exceeds expected requirements — no student PII stored, pseudonymous by default, minimal data collection |
12. Contact & Further Information
Document version 1.0 · February 2026 · ExamLock