The District of Columbia Public Schools notified families in a letter sent Wednesday, July 29, that an unauthorized third party may have accessed student information stored in a web-based application used for its Summer Learning registration. According to DCPS, the incident involved data from 55 schools, mainly elementary schools with after-school programs run by the district, along with data from students in summer programs. The student information that may have been exposed includes name, student identification number, date of birth, school and grade level, parent or guardian name, home address, and phone number. DCPS said it does not collect Social Security numbers or parental financial information. In the letter, Yiesha Thompson, interim deputy chancellor of finance and operations, said that upon learning of the incident the district immediately engaged the D.C. Office of the Chief Technology Officer to support an investigation, removed student data from the affected application, and notified law enforcement. Interim Chancellor Kim Jackson said officials were still working to determine who was behind the breach. DCPS said it was not aware of any misuse of the potentially accessed information but urged families to remain vigilant against unsolicited calls, emails, and texts, and said it was conducting a comprehensive review of systems and evaluating additional safeguards, including whether to continue using the affected website. Reporting indicated a ransomware group had claimed responsibility for the attack, though DCPS said it was still investigating.

The families of students across 55 DCPS schools directly, and every district that relies on third-party web applications to collect student data, which is every district. The DCPS breach is a clean example of the pattern this bulletin has tracked all year: the exposed data was sitting in a vendor-operated web application, not the district's core systems, yet the district is the entity that must notify families, investigate, and answer for the exposure. The detail that it was a summer-learning registration tool is instructive, because these seasonal and peripheral applications are exactly the ones that escape the security review applied to core platforms, even though they collect the same identifying student data.

The exposed fields, name, date of birth, home address, and parent contact information, are personally identifiable information from education records, and under FERPA the district is responsible for protecting them regardless of which vendor's system holds them. A breach of this kind raises the questions federal monitors and state regulators ask after any incident: Did the district maintain an inventory that included this summer-learning application and the student data it stored? Was there a data processing agreement specifying the vendor's security obligations and breach-notification timeline? Was the application subject to the same security review as core platforms, or did it fall outside it because it was seasonal? Was the breach notification to families timely and complete under the applicable jurisdiction's breach-notification requirements? The speed of DCPS's containment response is a point in its favor; the harder question is whether the peripheral application was governed before the breach, not just after.

An EdTech Magazine analysis published July 30 examined how districts are governing the growing volume of student data they feed into AI-powered tools, and it centered on a concrete data-governance model from the Weehawken Township School District in New Jersey. Eric Crespo, the district's superintendent, described his district's data governance policy as the rulebook for who gets to see student data, how it is stored, and which vendors are allowed to interact with it, and said approved vendors are given a key to exactly one room in the house, not the whole house. In Weehawken, the policy was built with the assistance of a law firm and approved through multiple levels: a mandatory state regulation setting the floor, a technology administrator filling in district-specific details, and a public board vote making it official. It governs the full lifecycle of student records, and students and parents must complete an authorization form before first accessing the district's network. Matt Jubelirer, general manager of education marketing at Microsoft, framed the same discipline around a set of data-governance best practices: collect only the information needed for educational purposes, limit access to authorized staff, use aggregated or de-identified data wherever possible, maintain strong security controls, and be transparent with families about how data is used. Both stressed keeping a human in the loop, with Crespo describing data as a check engine light that flags a possible problem but never makes a decision on its own.

Every district that is beginning to aggregate student data across systems to feed AI-driven insights, which is a fast-growing share of them. The significance of the Weehawken model is that it treats vendor access as the central control point: rather than asking whether a vendor is trustworthy in the abstract, it scopes each vendor to exactly the data it needs and nothing more. That room-key principle is the practical answer to the exposure the DCPS breach illustrates, because a vendor confined to one room cannot leak the whole house. The model also shows the governance sequence that holds up under scrutiny: a state-regulation floor, district-specific detail, legal review, and a public board vote.

When a district aggregates attendance, grades, behavioral records, and other student data to feed AI tools, it concentrates personally identifiable information in ways that raise the stakes on access control and vendor scoping, all under FERPA. A data-governance policy that names who may see student data, scopes each vendor to the minimum it needs, and governs the full data lifecycle is the documentation that demonstrates control; its absence is the exposure. Federal and state monitors would ask: Does your district have a board-adopted data governance policy specifying who may access student data and which vendors may interact with it? Is each vendor scoped to only the data it needs, rather than given broad access? Do you collect only what is needed, de-identify where possible, and govern how long student data is retained? Is a human required to interpret any AI-surfaced insight before it drives a decision about a student?

As districts finalize AI tool contracts before the school year, an Education Week opinion analysis published July 31 set out the questions education leaders should ask before signing any AI contract, arguing that districts should not accept blind promises of educational transformation from technology companies or let classrooms become testing grounds for unvetted software. Among the questions it urges leaders to ask: what evidence the vendor has for how the tool performs across different student populations, including students with individualized education programs and English learners; whether teachers, students, and families were consulted in the product's design; whether the AI model is grounded in vetted educational content; and what safeguards exist against the tool generating inaccurate, biased, or inappropriate content. The analysis lands in the same window as a concrete state action pointing the same direction: on June 25, 2026, the California Department of Education posted a statewide Model Policy on Artificial Intelligence in Education, developed by the California AI in Education Working Group convened under Senate Bill 1288. That model policy, announced to superintendents in a July 6 letter from State Superintendent Tony Thurmond, gives districts a ready-to-adapt template addressing academic integrity and disclosure, limits on AI detection software, privacy by design, legal compliance, educator discretion, parent and guardian review rights, and AI literacy. It is exemplary rather than mandatory, but it names privacy by design as a core element that any district AI policy should build in from the start.

Every district signing or renewing AI contracts this summer, which is most of them. The convergence is the point: independent education analysis and a state education agency are arriving at the same conclusion, that the vetting has to happen before the contract is signed and the tool reaches students, not after. The Education Week questions and the California model policy's privacy-by-design principle are two expressions of the same discipline, and together they give a district both the specific questions to ask a vendor and the state-level template for building the answers into policy.

An AI contract signed without a documented vendor and data-flow review is the upstream cause of the exact incidents the other two stories in this issue describe: the breach of a vendor-held application and the enforcement action over records handling. When a district adopts an AI tool without confirming what student data it collects, where that data goes, whether it trains the vendor's models, and what safeguards govern its outputs, it takes on FERPA responsibility it has not scoped. Federal and state monitors would ask: Before signing your most recent AI contract, did you complete a documented review of what student data the tool collects and how it is used? Does the contract include the privacy-by-design protections the California model policy names? Can you produce evidence that the tool was vetted for accuracy and bias before students used it?