Own your data.
Cyber is the largest exposure a district carries, and most of the data creating it sits with vendors rather than in the district. Giving a vendor your students' records should never mean losing control of them. The risk is too large to hand over on trust, and a district has had no third option between refusing the vendor and accepting the loss of control.
Guardian separates the two. The vendor keeps operating the data and running its product. The district keeps the ability to see every action taken on its own records and to stop any of it at any moment.
Hand over the data, keep the stewardship.
Guardian costs the district nothing and there is no system to run. The vendor buys it and operates it.
This is about risk, and about sleep, before it is about technology. A district technology leader currently finds out what a vendor did with student records when something has already gone wrong. With Guardian they watch their own tenant as a matter of routine, they are told when something looks wrong, and they can stop it themselves without filing a ticket with the vendor or waiting for a call back.
See access to your data as it happens
The district does not learn about an attack from a press release. It is watching its own tenant, and an attempt on its data is a decision made on its own screen while it is being made.
A district finds out from the news, months later. Frontline Education's breach was discovered in August 2026, disclosed in late September, and the incident-wide total is still undisclosed.
The sequence is the vendor discovers, scopes, consults counsel, and eventually notifies, and a district spends that whole window unable to tell its board or its families anything at all.
Guardian inverts the sequence. A credential reaching for records it was never approved to touch is denied, recorded against your tenant, and raised to you. You see the attempt, not the aftermath.
By the time an incident has a name in the trade press you have already watched it, bounded it, and pulled the switch if it needed pulling.
Why this works
The record is dual-axis, so the vendor sees its fleet and each district sees its own tenant. A targeted attempt on one district's records is a conspicuous event on that district's screen and one row among millions on the vendor's. The district is the party with the clearest view of its own exposure, which is the first time that has been true.
What it claims
Guardian decides and records every access attempt on the district's data and surfaces the patterns that correlate with extraction. It does not claim to detect every intrusion anywhere in a vendor's estate. The claim is that attempts against your records are visible to you as they are decided, rather than reported to you after someone else has finished investigating.
Lakeview UnifiedTenant recordWhat the district controls
The key
Held in the custody tier the district elects: platform managed outside the vendor, the district's own AWS account, or the district's own HSM. The ladder
The approval
The vendor declares what it needs. Nothing reaches the district's records until the district ratifies it.
The record
Every decision on the district's data, allowed and denied, attributed to a named actor and downloadable on demand.
The alerts
Raised to the district when something looks wrong on its own tenant.
The switch
A kill switch is a right the district already holds in its vendor agreement. Guardian is what makes it enforceable rather than contractual.
Contract language for your vendors
Naming a product in a procurement document creates a sole-source problem, and naming the properties does not. This clause names properties. Any vendor can meet it, and the ones running Guardian answer in a sentence.
Vendor shall route all staff, contractor and automated-agent access to District data through an access-control plane that:
- decides each request at the time of the request rather than at authentication, and denies any request not covered by an approval the District has ratified;
- holds the encryption key for District records outside Vendor's own operating environment, under a key policy that denies decryption to Vendor;
- binds any bulk export or restoration of District data to a live, named work assignment with a defined expiration, and routes any request outside such an assignment to the District for approval;
- attributes every access decision, allowed and denied, to a named human or machine actor, and makes that record available to the District on demand in a tamper-evident form;
- permits the District to revoke Vendor access to District data at any time, with effect on access already in progress, without terminating the integration.
Send it to the vendors holding your student records.
A vendor that can meet all five today will say so. A vendor that cannot will tell you which ones it misses, and that answer is itself the information you were missing.
No integration work, no license, no system to administer, no cost.
What an approval covers
Approving a vendor approves that vendor's declared reach at the scope the district ratified. It is not blanket consent, and the district can narrow it later.
Guardian governs the vendor's own data stores. Once data sits with another company entirely, that record ends, which is the argument for keeping the approved reach narrow.
More questions answered →