Passing a district security review: the eight artefacts to have ready

A district security review isn't an audit. It's a person with a spreadsheet, usually working from a state or consortium template, who has to decide whether to recommend you.

They aren't trying to catch you out. They're trying to finish. A vendor who makes finishing easy is a vendor who gets recommended.

Everything here is about making finishing easy.

What actually arrives

One of three things.

A standard template. Increasingly the norm: the Student Data Privacy Consortium's agreement and its questions, a state alliance template, or a district consortium's shared questionnaire. Predictable, which is good news.

A bespoke spreadsheet. Thirty to four hundred rows, assembled by the district over years. Some questions won't apply to you at all. Answer every row anyway, including "not applicable, because…". Blank rows read as evasion.

A pointer to a framework. "Provide your SOC 2 Type II report" or "describe alignment to the NIST Cybersecurity Framework." Common with larger districts and state systems.

The frameworks, and which matter

SOC 2 Type II is the most requested and the most misunderstood. It's an attestation by an auditor that your controls operated effectively over a period, usually twelve months. It isn't a certification and there's no pass mark. A report can contain exceptions and still be perfectly acceptable. What districts want is the report under NDA, and what they check is whether the scope covers the system they're buying and whether the exceptions are material.

If you don't have one, say so plainly and describe what you do instead. "We don't hold a SOC 2 report; here is our security plan mapped to NIST CSF, our penetration test summary from March, and our subprocessor register" is perfectly survivable from a smaller company. What doesn't survive is implying you have one.

NIST Cybersecurity Framework 2.0 is the most useful thing to organise around. New York's Education Law 2-d names it, several other states imply it, and its six functions (Govern, Identify, Protect, Detect, Respond, Recover) map cleanly onto the questions everyone else asks. Write your security plan against CSF and most questionnaires become a retrieval exercise rather than a writing exercise.

ISO 27001 is recognised and fine, just less common in US K-12 than SOC 2.

StateRAMP and TX-RAMP apply to cloud services sold to state agencies, and to some state-level education purchases. Usually not triggered by a district purchase.

K12 SIX publishes essential cybersecurity protections aimed at school systems themselves. Worth reading not because you'll be audited against it, but because it tells you what your customer's own posture looks like, and therefore what they'll worry about in yours.

The eight artefacts

Assemble these during the build. Every one is a filing job while you're building and an archaeology project afterwards.

1. Data inventory and flow map. Every data element, why you hold it, where it lives, who it flows to. The same artefact FERPA for engineers asks for, and the foundation of the other seven. You can't write a retention schedule for data you haven't enumerated.

2. Subprocessor register. Every third party touching district data, what they do, where they are, what terms bind them. Current, ready to publish, and including the model providers.

3. Retention and deletion schedule. What's kept, for how long, what triggers destruction. Published, per the 2025 COPPA amendments. Backed by a job that runs.

4. Security plan mapped to NIST CSF. Encryption in transit and at rest, key management, access control, change management, logging, vulnerability management, business continuity. Written once, referenced constantly.

5. Incident response runbook. Detection, triage, escalation, notification. With the per-jurisdiction clocks from the state patchwork and pre-drafted templates. Rehearsed annually, with a record that it was.

6. Access control policy, including your own staff. Who at your company can see district data, under what circumstances, with what approval, logged. This gets asked more often than teams expect, and "our engineers can query production" is an answer that ends reviews.

7. Penetration test summary. A recent third-party test. The summary, not the full report, is what gets shared. Annual is the expectation, and the finding that matters is whether the previous test's issues were remediated.

8. Accessibility conformance report. Not strictly security, but it arrives in the same envelope from the same process. Covered in accessibility with a deadline.

The questions that catch people

"Where is the data hosted?" Name the region. Many districts want US-only hosting and some state contracts require it. If you use a global CDN or a support tool storing data elsewhere, say so. This is exactly the kind of thing that's fine when disclosed and fatal when discovered.

"Who has access to our data?" Name roles, not people. Describe the approval and the logging. If support engineers can impersonate a user to debug, disclose it and describe the controls, because they will find out.

"Do you use student data to train AI models?" Currently the highest-stakes question in this space. The answer needs to be unambiguous and extend to your subprocessors. "No, and our agreement with our model provider prohibits training on submitted data" is answerable. Anything hedged reads as yes.

"What happens when we terminate?" Export format, deletion timeline, backup handling, certificate of destruction. A specific number of days beats "promptly".

"Has your organisation had a breach?" Answer honestly. A disclosed past incident with a clear remediation story is survivable and occasionally builds credibility. A discovered undisclosed one is not.

"Do you have cyber liability insurance?" Increasingly asked, sometimes with a minimum. Have the certificate ready.

Four habits that shorten reviews

Answer in their template. Not in a PDF of your own design that covers the same ground. The reviewer has to fill in their spreadsheet, and making them transcribe from your document is asking them to do your work.

Say no cleanly when it's no. Reviewers are used to vendors dressing up gaps. A plain "we don't do this today, it's planned for Q2, here's the compensating control" is trusted far more than a paragraph that avoids the question. Every reviewer has read a hundred of those paragraphs.

Keep a maintained answer bank. The same two hundred questions recur with different wording. Maintain canonical answers with owners and review dates, so the twentieth review costs an afternoon rather than a week. Stale answers are worse than none; an answer referencing a subprocessor you dropped is a credibility problem.

Give them a named human. A security contact who responds within a day. Much of what stalls reviews isn't a bad answer, it's silence.

If you're a young company

You won't have everything, and that isn't disqualifying. Districts buy from small vendors constantly.

The minimum viable posture: a written security plan against NIST CSF, a data inventory, a subprocessor register, a published retention schedule with a working deletion job, MFA on everything administrative, a recent penetration test, an incident runbook with the state clocks in it, and the NDPA signed where you operate.

That's about three weeks of concentrated work. It turns the review from a research project into a document exchange, and it's the difference between closing in the spring, in time for a purchase order before the fiscal year ends, and closing in the autumn into next year's budget.