Districts · DPA Review
Districts are the data controller for
every tool that ingests student information.
Even the free ones.
The stakes
Tools in the average district
2,591
Instructure LearnPlatform · 2022-23
Student privacy laws enacted
100+
All 50 states and DC · since 2013
Access beyond the approved list
4x
Actual access vs. district records · L+L reviews
How we work
Who's this for?
Districts, charter networks, and colleges whose vendor stack grew faster than anyone could govern it. Tools arrive through procurement, through grants, through a teacher who found something useful on a Tuesday - and every one of them carries an agreement that somebody signed and almost nobody has read since. Under FERPA the district is the data controller for all of it, approved or not.
The largest breaches of student data don't start inside districts.
They start with the vendors districts trust.
Pressure point 01
The stack outgrew the governance
Nobody chose to run hundreds of vendors. It accumulated - signed one at a time, by different people, in different years, against different standards.
Pressure point 02
The board asks a fair question
Which tools hold our student data, and which of them are we actually covered for?
Most districts can't produce that documentation in a single sitting.
Pressure point 03
AI arrived inside tools you already approved
Vendors added generative and adaptive features to products that were approved years earlier. The agreement on file predates the capability, and district policy hasn't caught up.
What it actually is
A DPA review is a full accounting of every vendor in your stack
and whether each holds up against the law your district answers to.
and whether each holds up against the law your district answers to.
FERPA and COPPA set the federal floor. SOPPA in Illinois, and its counterparts elsewhere, set the rest.
01
For leadership and the board
A plain-language picture of where the stack stands: what's covered, what isn't, what carries real risk and why. The document you hand a board that has started asking about student data.
02
For IT and data privacy staff
A scorecard for every vendor: where the agreement falls short, which configurations need changing, which products need a separate DPA or a business associate agreement, and what has to happen before next use rather than at annual review.
The framework
Every vendor is read against the same five questions.
The PURPOSE framework. Built by Jessica Maddry, and the reason two reviews of the same stack reach the same answer.
01
Legal privacy compliance
What FERPA, COPPA and your state statute require of this vendor, and whether the agreement actually on file delivers it.
02
Technical security assurance
How the vendor holds student data, who inside the company can reach it, and what's contractually promised when something goes wrong.
03
Data flow transparency
Where student data travels once it leaves your network, which subprocessors touch it, and how much of that the vendor is willing to document.
04
AI governance and oversight
What the product decides on its own, whether a human reviews it before anything happens to a student, and whether anyone has audited it for bias. In recent reviews this has been the largest unaddressed gap.
05
Pedagogical alignment
Whether the tool is being used for the thing it was built and approved for, or has quietly become something else - a diagnostic doing the work of core instruction, for instance.
How it's scored
Three readings per vendor, so nothing rests on one judgment.
Risk tier
What the vendor exposes you to, and how fast you need to act on it. Red isn't a verdict on the product - it means something needs board-level attention before the next renewal.
Active litigation, a documented breach, or a data practice that contradicts the agreement on file. Something has to change before the next renewal.
Usable, with something unresolved - a missing clause, an AI feature nobody reviewed, a subprocessor the district has never seen named.
The agreement, the documentation, and the way the tool is actually used line up. Verified on cadence rather than re-argued every year.
Transparency tier
Some vendors publish what they do with student data. Others say very little, and from the outside a district can't tell which is which.
Privacy and security documentation is public, specific, and current.
Some of it's published, and direct questions get answered.
Little or nothing public. We file a formal documentation request rather than assume.
Overall score
A single figure out of five, carried across the five framework domains and printed on the vendor's card.
0.0 to 5.0
It's what lets a stack of a hundred vendors be triaged in one pass, instead of reread one card at a time.
The engagement
Five phases, scoped to your actual stack.
Sized on what you're really running, not on a standard package.
01
Scope
We start from two or three files showing what students and staff actually sign into. Not the procurement list - the access data.
Already done a penetration test with us? We hold this, and the phase disappears.02
Sizing
Not every tool that appears in the data is a tool in use. We separate what's genuinely active from what's merely reachable, and what the district pays for from what arrived on its own. That's what sets the length of the engagement, and you see it before the work starts.
03
Vendor evaluation
Each vendor is read against the five PURPOSE domains. We maintain a working library of these evaluations and build new ones as your stack requires, so the common vendors don't get re-litigated and the unusual ones get real attention.
04
Scoring and classification
Every vendor gets a card carrying its score, risk tier, transparency tier, review cadence, and the specific actions required. Cross-referenced against FERPA, COPPA, the U.S. Department of Education AI report, the EU AI Act, CoSN guidance, and NIST CSF.
05
Executive summary and calendar
The findings synthesized for leadership: the patterns that define your governance posture, an immediate action register, the full stack ledger, and a governance calendar that tells you what to look at and when.
What you receive
A record you can act on, and keep current.
Deliverable 01
Vendor Scorecards
One per vendor. Score, risk tier, transparency tier, review cadence, and the actions required. Where a vendor carries litigation or a documented governance failure, the card sets out the evidence and names the sources.
Deliverable 02
Executive Findings Summary
The themes that define your stack's posture, the risk distribution across it, an immediate action register, and a complete ledger of every vendor reviewed with its classification.
Deliverable 03
Governance Roadmap
The tasks and work cycles that keep the system current after we leave, so the visibility you've gained doesn't decay back to where it started.
Book a call
Start the Conversation →See where your stack actually stands.
We'll ask what you're running, who signed for it, and what nobody's looked at since. You'll leave knowing whether a review is the right next step.
See clearly.
Act strategically.
Protect what matters.
Questions we get
What districts ask before they start.
We already have DPAs with most of our vendors. What does this add?
Having an agreement and being covered by it are different things. Reviews routinely find tools whose DPA excludes the module actually deployed, products that only comply in a specific edition, and services that need a second agreement entirely. The agreement on file is the starting point of the review, not the answer to it.
What about tools teachers signed up for on their own?
Those are the ones worth finding. We scope from what's actually being accessed rather than from a procurement list, so tools that arrived outside the approval process show up alongside everything else. No district we've worked with has had a clean match between the two.
Does this cover AI?
AI governance is one of the five framework domains, and in recent reviews it has been the largest unaddressed gap. The common pattern is a vendor adding generative or adaptive features to a product approved years earlier, against an agreement that predates the capability and a district policy that hasn't caught up.
How long does it take?
It depends on how much of your stack is genuinely in use, which is what the sizing phase establishes. You get the estimate before the work starts, not after. Districts that have done a penetration test with us skip the first phase entirely, because we already hold the access data.
How is pricing structured?
Priced per engagement, scoped to your stack, quoted in writing after the scoping conversation. We used to attach a savings guarantee and no longer do - districts have consistently recovered several times the cost of the review in software they were paying for and not using, and the guarantee stopped being the reason anyone said yes.
Who does the review?
Jessica Maddry leads every DPA review. She is a Certified Ethical Emerging Technologist, and the framework the review runs on is hers. This is her lane rather than a service we staff out.
Also for districts