What does a school district's IT security review ask for?

A district IT security review asks what student data your app collects, where it lives, who can see it and how it is deleted. Expect a signed data privacy agreement, a security questionnaire of roughly 50–150 questions, and network and login details. Reviews typically take 2 to 12 weeks, depending mostly on how complete your first submission is.

Every district runs its own process, but the requests converge. The reviewer is usually a technology director or data privacy officer handling dozens of vendor requests at once. A complete package on day one moves you up the queue; a package that triggers three rounds of follow-up questions can cost you the semester.

Many states use a shared student data privacy agreement that districts sign with vendors. If your state has one, signing the standard version is far faster than negotiating a custom contract.

The questionnaire varies in length, but most of it reduces to a dozen questions. Have a one-paragraph answer to each before you submit anything.

1. What student data do you collect, and is any of it beyond what the study needs?
2. Where is the data hosted, and is it in the United States?
3. Is data encrypted in transit (TLS) and at rest?
4. How do students and teachers log in? Do you support Google, Clever or ClassLink single sign-on?
5. Who on your team can access production data, and is that access logged?
6. Do you sell, share or use student data for advertising or product training?
7. If the app uses an AI model, is student input sent to a third-party provider, and does that provider retain it or train on it?
8. How quickly will you notify the district of a breach, and who is the contact?
9. How and when is data deleted at the end of the agreement, and can you certify it?
10. Do any users fall under 13, and how do you handle COPPA consent?
11. Which domains and ports must the district allow through its content filter?
12. How do you separate research data from data the district owns?

Question 7 is now the one that stalls AI-based studies most often. Name the model provider, the API terms you are on, whether prompts are retained, and whether you strip names and identifiers before a request leaves your system.

Prototypes built by a graduate student usually work in the lab and fail review for reasons that have nothing to do with the research. The common ones:

• No data inventory exists. The database grew field by field, nobody can list what is collected, and free-text fields quietly hold student names.
• Shared admin logins, so there is no way to say who accessed what.
• Third-party scripts (analytics, fonts, chat widgets) loading from domains the district filter blocks or the DPA does not cover.
• Student identifiers stored in the same table as study outcomes, which makes de-identified research exports hard to produce.
• No written deletion process, so the team cannot commit to a deletion date.
• The app works on a lab laptop but not on managed Chromebooks behind a district proxy.

Each of these is fixable in days if found early, and costs weeks if a reviewer finds it first. The fix also improves the study: a clean data model and per-user access logs are what make your efficacy data defensible to a program officer.

As a general market range, a district that has signed a state-wide agreement can approve a well-documented app in 2 to 4 weeks. A district negotiating a custom contract, or a submission that triggers follow-up rounds, commonly runs 8 to 12 weeks. Summer and the first month of school are the slowest periods.

A practical sequence

1. Week 1: build the data inventory from the real schema and remove any field the study does not need.
2. Week 1–2: draw the data flow diagram, list subprocessors, and confirm hosting region and encryption settings.
3. Week 2: add single sign-on and role-based access if they are missing; turn on access logging.
4. Week 2–3: write the technical disclosure package and answer the questionnaire in full, in the district’s format.
5. Week 3: submit alongside the signed DPA and IRB approval, then test the app on a district-managed device before teachers log in.

We work this way on research platforms. One research prototype went to a district-approved classroom pilot in under 30 days: 20 teachers across two districts, with more than 100 framework-compliant problems generated. The engineering and the disclosure package moved in parallel, so review did not wait on the build.

An engineering team can make the app pass review technically and write an accurate technical disclosure. It cannot sign the DPA for your institution or decide how FERPA and COPPA apply to your study; your institution’s counsel, compliance office and IRB make those calls. Plan for both tracks, because a district will not approve one without the other.

Write the disclosure once, carefully, and reuse it. The second and third districts in a pilot ask almost the same questions, and a maintained package turns their reviews into days rather than months.

How long does a school district IT security review take?
As a general range, 2 to 4 weeks when the district has a signed state-wide privacy agreement and your documentation is complete. Custom contracts or incomplete submissions often take 8 to 12 weeks. Submitting well before summer or the start of the school year helps.

What is a data privacy agreement for an edtech app?
It is a contract between the district and the vendor setting out how student data may be used, protected, disclosed and deleted, including breach notification terms. Many states have a standard agreement that districts sign with many vendors. Your institution’s counsel should review it before anyone signs.

Does a research pilot need district IT approval if we already have IRB approval?
Usually yes. IRB approval covers the protection of human subjects in the study, while the district reviews the software’s data handling and security on behalf of its students. Most districts ask for both, and some also run their own research review.

What do districts ask about AI features in classroom apps?
They ask which model provider receives student input, whether that provider retains or trains on it, and whether identifiers are removed before a request is sent. They also want the provider listed as a subprocessor. Have the provider’s API data terms ready when you submit.

Who should fill out the district security questionnaire?
The engineers who built and run the system, because the answers must match how it actually works. The PI should review and sign off, and legal or privacy questions go to the institution’s compliance office. Inaccurate answers are a bigger risk than slow ones.

We offer a free 30-minute review of your pilot plan or the technical section of your proposal. Bring the prototype’s repository or a demo, your pilot timeline, any district questionnaire you have received, and your funder’s requirements. Start a conversation.