When a school software provider is compromised, districts often face an unsettling reality. Their networks remain untouched, yet their students and employees receive notification letters about a breach.
This was the case with the Frontline Education incident, where unauthorized access through a third-party software vulnerability potentially exposed information of over 1.3 million people. The breach was discovered on August 14, and the unauthorized activity continued until August 15. The data at risk included Social Security numbers, birth dates, government identification numbers, Medicaid IDs, and student identification numbers.
These myths persist because processor relationships can feel like outsourced risk. They aren't. Here's what the law, and the facts of this case, actually say.
Myth 1: "If our network wasn't breached, we don't have a personal data breach"
Reality: Under GDPR, a personal data breach is defined in Article 4(12) by what happens to the data, not whose infrastructure was compromised. A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data qualifies, wherever the data resides.
The Frontline case illustrates this. Killeen Independent School District and Greenwood School District 50 issued their own notices without any intrusion into their networks. Yet, they still faced questions from affected students and employees. Under GDPR, the controller has the Article 33 duty to notify the supervisory authority, and a processor's breach triggers its obligation under Article 33(2) to notify the controller without undue delay. The controller's 72-hour clock starts when it becomes aware of the breach. Your own perimeter being intact is not a defense.
Myth 2: "The processor will tell us everything we need, when we need it"
Reality: Your response depends on information you don't control. Establishing who was affected and what was exposed relies on the findings and records the provider supplies. For a controller, that's a serious dependency.
Article 28(3)(f) requires the processor to assist the controller with its Articles 32 to 36 obligations, including breach notification. In practice, that contract clause is only as useful as its specifics. Does your agreement set a deadline for the processor to notify you? Does it require an individual-level account of affected records, not just a summary count? Does it specify the format and timing?
Notice the discrepancy in this incident. Greenwood identified approximately 16,678 current and former students, while South Carolina's breach notification registry lists 493,535 affected residents. Those figures describe different populations, and a district relying only on its own picture would struggle to reconcile them. Without a record-level inventory from the processor, you can't confidently decide whom to notify.
Myth 3: "A processor assessment at onboarding covers us"
Reality: A point-in-time questionnaire can't catch a vulnerability in software that sits beneath your processor's own stack. Frontline's incident came through a third-party software flaw, meaning the weak link was further down the chain than most onboarding reviews reach. The company hasn't publicly identified the vulnerable software, highlighting the visibility problem. You may never learn which component failed.
Article 28(1) requires controllers to use only processors providing sufficient guarantees to implement appropriate technical and organizational measures. Article 28(2) and (4) bring sub-processors into scope, requiring authorization and flow-down of obligations. "Sufficient guarantees" is an ongoing standard, not a one-time gate. Reassess on a schedule tied to data sensitivity, and ask at each review who the processor's own sub-processors are and how it tracks vulnerabilities in them.
Myth 4: "Once students graduate or staff leave, their data is no longer our problem"
Reality: Data that has dropped out of your active systems often hasn't dropped out of your processor's. Former students and employees may no longer appear in active databases while their details remain with a processor. They are still data subjects, and you are still the controller.
Article 5(1)(e) requires that personal data be kept no longer than necessary for the purposes for which it's processed. Article 28(3)(g) requires the processor, at your choice, to delete or return all personal data at the end of the service, and to delete existing copies unless law requires storage. Each year of retention beyond need enlarges the pool of people affected when a processor is compromised.
Ask three questions of every processor holding sensitive records:
- What is the retention period for each category of data?
- How is deletion triggered when a person leaves your organization?
- Can the processor evidence deletion on request?
Your existing data loss prevention tools likely offer limited visibility into records held in external systems. Retention schedules and deletion arrangements in the contract are your main controls.
Myth 5: "Post-breach fixes from the processor close the matter"
Reality: Frontline reports that it remediated the vulnerability, completed an investigation with an independent cybersecurity firm, and implemented additional monitoring and appropriate technical and organisational measures. It also reported no known misuse of the information. Those are the right steps for a processor to take. They don't discharge your obligations.
As controller, you still decide whether the breach is likely to result in a risk to individuals' rights and freedoms (Article 33) and whether the risk is high enough to require communicating with data subjects directly (Article 34). Government identification numbers, Social Security numbers, and Medicaid IDs are the sort of data that makes identity fraud possible, so a processor's statement about no known misuse shouldn't settle your assessment. Credit monitoring offered by the processor, two years for eligible adults in this case, is a helpful mitigation, but your risk assessment and your documentation under Article 33(5) remain your own.
What to do instead
Treat the processor relationship as part of your incident response plan, not an appendix to it.
- Test the plan with a processor scenario. Run a tabletop where your largest processor reports a breach and your network is clean. Can you get an individual-level list of affected records within your notification window?
- Write specifics into Article 28 agreements. Set notification deadlines, require record-level breach reporting, and define the format.
- Map sub-processors and review them. Know who sits beneath your processor, and reassess on a schedule matched to data sensitivity.
- Enforce retention. Set retention periods per data category, trigger deletion when people leave, and ask for evidence it happened.
- Hold your own risk assessment. Make your Article 33 and 34 decisions independently and record the reasoning.
A processor's remediation is welcome news. Your accountability under Article 5(2) is the part nobody else can carry for you.
