Incident & Breach Notification

Scope: what a subscribing institution can expect from DevAcademia if a security incident affects student education records, and how DevAcademia coordinates the notifications that FERPA, US state breach-notification laws, and (for EU/EEA/UK institutions) the GDPR require.

Audience: school district legal counsel, data-protection officers, and security teams.

About this document. This describes DevAcademia's incident-

notification commitment and how we support institutions if a

security incident affects student data. It is reviewed

periodically, and the specific commitments are reflected in the

agreement entered into with each institution.

#Executive summary

FERPA itself has no standalone statutory breach-notification mandate, but institutions expect one, and nearly every US state has a data-breach-notification law that layers on top of FERPA. DevAcademia commits to notifying each affected institution within 72 hours of confirming any unauthorized disclosure of personally identifiable information — a commitment reflected in the Data Processing Agreement established with each institution. For EU/EEA/UK institutions, DevAcademia additionally provides the information a controller needs to meet its own GDPR Article 33 and Article 34 obligations.

#What counts as a reportable incident

DevAcademia treats an event as a FERPA-relevant incident when all three of the following are true:

1. Personal data is involved — the event touched at least one

field that identifies a specific student. Aggregated or de- identified data is not personally identifiable information.

1. The disclosure was unauthorized — the data was accessed by

someone who was not the student, the parent (for a minor), the institution, or a party the institution had authorized.

1. There was an actual disclosure, not merely a possibility —

a misconfiguration that could have exposed data but did not is handled as a security incident, and escalates to this process only once there is evidence that someone actually accessed the data.

When there is any doubt, DevAcademia treats the event as reportable. Over-notifying is preferable to leaving an institution uninformed.

#What DevAcademia does when an incident is confirmed

1. Preserve. DevAcademia freezes and preserves the relevant

audit records and logs so the scope of the incident can be established accurately and cannot be altered.

1. Assess. DevAcademia's security team determines what data

was involved, whose data it was, how it was disclosed, and for how long.

1. Contain. DevAcademia takes immediate action to stop any

ongoing disclosure (for example rotating credentials, revoking access, or taking an affected component offline).

1. Notify. Within 72 hours of confirming an unauthorized

disclosure, DevAcademia notifies each affected institution's designated point of contact.

1. Support and remediate. DevAcademia provides the institution

with the details it needs for its own notifications, fixes the root cause, and records the incident and its resolution.

#What the notification contains

Each notification to an affected institution includes, to the extent known at the time and updated as the investigation proceeds:

• A description of what happened and when it was discovered.
• The categories and approximate number of students and records

involved.

• How the disclosure occurred and whether it has been contained.
• The steps DevAcademia has taken and will take in response.
• A point of contact for follow-up questions.

DevAcademia sends an initial notification within the 72-hour window even if the investigation is ongoing, and follows up with additional detail as it becomes available.

#Who notifies students and parents

Under FERPA, the institution decides whether and how to notify affected parents and students — that is the institution's statutory duty as the controller of the records. DevAcademia's role is to give the institution accurate, timely information so the institution can meet its own obligations under FERPA and its state's breach-notification law.

#Sub-processor incidents

If one of DevAcademia's sub-processors notifies DevAcademia of a breach on their platform that may have affected DevAcademia data, DevAcademia assesses the scope and, if institution data was involved, follows the same notification process above. DevAcademia does not pass a sub-processor's raw breach notice to institutions unmodified — it first determines whether and how the institution's data was actually affected.

#EU/EEA/UK institutions — GDPR alignment

For institutions subject to the GDPR, DevAcademia acts as a processor and assists the institution (the controller) with its Article 33 (supervisory-authority notification) and Article 34 (data-subject notification) duties by providing, without undue delay, the information the controller needs to assess and report the incident. DevAcademia does not notify a supervisory authority on the institution's behalf — that is the controller's decision — but supplies the facts required to make and support that decision. Note that the GDPR's 72-hour clock runs from the controller's awareness, which DevAcademia's prompt notification is designed to support.

#Contact

To report a suspected incident, or to reach DevAcademia's security team, contact security@devacademia.com. General compliance questions go to compliance@devacademia.com.

#Change history