The database traced back to a customer relationship platform used by thousands of preschools and daycare centers.
No zero-day. No ransomware crew. A misconfigured index left the door open.
Nobody at those childcare centers moved that data. A parent filled out an enrollment form, clicked "send," and the center's obligations — legal, ethical, contractual — kept traveling with the record long after it left the building. That is the outbound problem in one sentence: once a family record leaves your system, it lives inside decisions your vendor is making that your contract never described.
The Record Doesn't Stop Moving When It Reaches the Vendor
The LineLeader incident is useful because nothing about it is unusual for childcare. Enrollment CRM, parent messaging tool, meal-tracking app, bus-routing system, sibling-discount billing platform — each one accepts a family record at the front door and then hands pieces of it to something else. An email service. An analytics pipeline. A backup provider. A sub-processor you have rarely heard of.
The center that signed the contract usually pictures a straight line: parent fills out a form, data lands in the vendor's database, vendor keeps it safe. The actual path branches. A single enrollment submission can fan out to a dozen downstream services within seconds, and each hop is a decision made by the vendor's engineers about where family data is allowed to go. Your data processing agreement names none of them.
Egress Is the Word for What You're Not Watching
Security teams call outbound data movement "egress," and in most child-serving organizations it is among the least-monitored surfaces in the entire stack. Inbound access gets the attention — logins, MFA, device checks, IP allowlists. That's the front door. The back door is the traffic your systems and your vendors' systems send out: to a marketing tool that got connected two years ago, to a spreadsheet a staff member emailed home, to an API integration that a former vendor engineer wired up and never revisited.
The LineLeader database wasn't stolen. It appears to have been published, effectively, because outbound exposure wasn't being checked. Someone stood up a service, pointed data at it, and no one on either side asked the follow-up question: who can reach this from the outside, and what leaves it on the way back? For a practitioner walkthrough of how to enforce outbound controls at the identity and API layer, an episode of the CyberAttack.ai podcast on zero-Trust Egress: Locking Down Where Your Data Actually Goes covers the pattern in detail.
The Regulators Already Assume You Know Where the Data Goes
Child-serving organizations sit inside a crowded regulatory frame: FERPA if you're school-adjacent, COPPA if you collect from children under 13, HIPAA where health information touches the record, and state student-privacy statutes that have been multiplying for a decade. The through-line across all of them is the same. Sharing family data with a vendor does not transfer the obligation.
The U.S. Department of Education's guidance for schools is explicit that records maintained by a contractor acting on behalf of the organization are still treated as the organization's records for compliance purposes.
That framing changes what an audit looks like after an incident. Regulators don't ask whether the vendor was careful. They ask what you knew about where the data went, what you required in writing, and how you verified it.
What to Actually Ask Before the Next Renewal
The LineLeader story isn't about one uniquely careless vendor. The questions most child-serving organizations ask during procurement don't surface the outbound behavior that ends up in the breach notification. A better set of questions belongs in every renewal packet.
- Name every sub-processor. Ask for the current list of downstream services that will touch family records, and require notice before it changes.
- Show the egress map. Ask which external destinations the platform can send data to, how those destinations are restricted, and how misconfigurations are detected.
- Prove the deletion path. Ask what happens across every downstream system when a family withdraws or when the contract ends, and how the vendor can demonstrate it happened.
- Produce the last incident review. Ask for a redacted post-incident report from the past 24 months, or a written explanation of why none exists.
The Question the Next Board Meeting Should Open With
If a researcher pulled up an open database tomorrow with your organization's name on the parent records inside it, what would you know within the first hour? Which vendor. Which integration, which export, which staff account.
The organizations that answer those questions quickly have already mapped where family data leaves their systems and instrumented the routes. The ones that haven't will spend the first week of the incident building the map.
The LineLeader records will be a footnote in a year. The pattern behind them won't be. Family data keeps moving after you hand it over, and the only real control is knowing — with something better than a signed PDF — exactly where it goes.