ERAData processing agreement
This agreement is between the school that registers on ERA (the School, data controller) and [legal name of business], operator of ERA (the Processor). It applies when the School ticks the agreement box at registration.
1. Purpose
The Processor handles personal data only to provide ERA to the School: emergency alerts, staff and student accountability, attendance and drill reports, plus the nurse's Clinic portal if the School switches on the clinic module. It does not use the data for any other purpose.
2. Data covered
| People | Categories of data |
|---|---|
| Staff | Name, school email, role, safety status, live chat messages, notification token |
| Students | Name, student ID, homeroom, grade, attendance, daily "at clinic" status |
During alerts, staff report status with fixed buttons, including "needs medical help". The app has no free-text notes on rooms or students. The live chat is free text; the School should tell staff not to share health details there.
2a. Clinic module (optional)
The clinic module is off by default. If the School switches it on, the school nurse can clear a student's daily "at clinic" status. Nothing else is recorded.
The app has no free-text field for clinic notes, so no symptoms, diagnoses or medications are stored, and no clinic visit history is kept. The "at clinic" status resets daily, like attendance. The School can switch the module off at any time.
3. School's responsibilities
- Have a lawful basis for putting the data into ERA
- Tell staff, students and families how their data is used
- Decide who in the school has access, and keep that list up to date
- Enter only the data ERA needs
4. Processor's responsibilities
- Act only on the School's documented instructions
- Keep the data confidential, and bind anyone with access to confidentiality
- Keep each school's data separate from every other school's
- Apply appropriate technical and security measures
- Help the School respond to requests from individuals
- Delete or return the data when the service ends
5. Developer access
The app developer has standing access to all portals for troubleshooting, setup assistance and maintenance. This access is used only for those purposes and is logged where possible.
6. Sub-processors
| Provider | Purpose | Location |
|---|---|---|
| Google Cloud (Firebase) | Hosting, database, sign-in, notifications | europe-west1, Belgium |
| Microsoft | Sign-in, if the School uses Microsoft accounts | [to confirm] |
The School will be told before any new sub-processor is added and may object.
Report emails are sent through a script that runs on the School's own Google account, not by the Processor.
7. Security incidents
If the Processor becomes aware of a breach affecting the School's data, it will tell the School without undue delay and within [48] hours, with what is known and what is being done.
8. Retention and deletion
Operational data is deleted automatically at the School's daily reset: attendance, "at clinic" status, alert statuses, alert history, sweep progress and chat messages. An admin reset after a drill deletes the same data immediately. Drill reports are emailed to the School before the reset; the Processor keeps no copy.
Setup data (school settings, room structure, student roster, staff access lists) is kept while the School uses ERA. When the agreement ends, the Processor deletes the School's data within [30] days, after an export if the School asks for one.
9. International transfers
Data is stored in the EU. Any transfer outside the EU or Turkey happens only with safeguards required by GDPR and KVKK. [to confirm with lawyer]
10. Audits
The School may ask for information showing compliance with this agreement, with reasonable notice.
11. Term and governing law
This agreement lasts as long as the School uses ERA. Governing law: [to confirm].
12. Changes
Each version is numbered and dated. The School is notified before a new version takes effect, and ERA records which version each School accepted and when.