How do you design a district-wide edtech interoperability standard for new software purchases in 2027?

What a district interoperability standard actually is and why it matters

A district-wide edtech interoperability standard is not a wish list stapled to an RFP. It is a written, versioned document that defines the technical and contractual minimums any new software purchase must clear before a purchase order is cut, plus the evidence a vendor must produce to prove each claim, plus the exception process for the cases where a genuinely valuable tool cannot clear a bar. Districts that skip any of those three parts end up with a standard that is either ignored or so rigid it drives buying underground into department credit cards.

The reason this matters more in 2027 than it did five years ago is arithmetic. A mid-sized district running 25,000 students typically carries somewhere between 700 and 1,500 distinct edtech products across all buildings once you count teacher-adopted freemium tools, and only a fraction of those ever passed through central IT. Every one of those products wants three things: a roster of who is in what class, an identity to authenticate against, and somewhere to write results. If each product solves those three problems its own way, the district ends up maintaining a bespoke integration per vendor. Ten integrations is annoying. Two hundred is a full-time team the district does not have budget for.

The interoperability standard collapses that N-by-N problem into a hub-and-spoke one. Instead of "how does Vendor X talk to our SIS," the question becomes "does Vendor X speak the four protocols we already run." That shift is the whole point. It converts integration from a per-purchase engineering project into a per-purchase checklist, and a checklist can be delegated to a procurement analyst while an engineering project cannot.

There is a second, quieter benefit that rarely makes it into the board presentation: exit cost. When every tool reads rosters from the same source and writes events in the same format, replacing a vendor becomes a configuration change rather than a migration. Districts that have standardized report that swapping a math intervention platform goes from a summer-long project to a two-week one. That leverage shows up at renewal time, because a vendor who knows you can leave in two weeks negotiates differently than one who knows you are welded in.

Adjacent to the core standard, most districts discover they also need a data-governance companion — a records-retention schedule, a defined data steward per domain, and a deletion workflow — because interoperability without governance just means student data moves faster in more directions. The two documents should be written by the same working group even if they ship separately.

The four protocol pillars, and what to demand for each

Most workable district standards rest on four pillars. Write each one as a requirement with a named specification, a named version, and a named piece of evidence.

Rostering. Pick one of two lanes and commit. The IMS Global / 1EdTech OneRoster specification (v1.1 or v1.2) is the broader-adopted commercial lane; Ed-Fi is the richer, more warehouse-oriented lane favored by districts that also want longitudinal analytics. Requiring OneRoster REST rather than CSV matters: CSV rostering means a nightly file drop, which means a student who transfers Tuesday morning does not exist in the tool until Wednesday. REST means near-real-time. Write the requirement as "OneRoster v1.1 REST API consumer, certified, with delta support," and ask for the certification listing, not a marketing claim. 1EdTech publishes a public certified-product directory; verifying takes about ninety seconds and catches a surprising number of "yes we support OneRoster" answers that mean "we can import your CSV."

Launch and identity. LTI 1.3 with the LTI Advantage services (Names and Role Provisioning, Deep Linking, Assignment and Grade Services) is the standard for anything that launches from an LMS. LTI 1.1 uses OAuth 1.0a shared secrets and should be treated as deprecated in any new purchase. Separately, require SAML 2.0 or OpenID Connect against the district identity provider — in practice that is usually Google Workspace, Microsoft Entra ID, or ClassLink/Clever acting as a broker. The specific ask that saves pain later: SSO must be included at the contracted price tier, not sold as an enterprise upcharge. Vendors who gate SSO behind a premium tier are a known pattern, and discovering it after signature is a budget conversation nobody enjoys.

Data export and events. Require that the district can retrieve its own data in a documented, machine-readable format on demand, not just at termination. Caliper Analytics or xAPI for behavioral events, plus a bulk export of gradebook and assessment results in CSV or JSON with a published schema. Add a clause specifying export within a fixed window — thirty days is common — and specifying that export is free. The failure mode this prevents is the vendor who technically allows export but quotes a five-figure professional-services fee to produce it.

Privacy and security. A signed student-data-privacy agreement is the baseline. Many districts use the Student Data Privacy Consortium's National Data Privacy Agreement, which has the enormous practical advantage of being pre-negotiated — if a vendor has already signed the NDPA with another district in your state alliance, your legal review shrinks from weeks to a countersignature. Layer on a current SOC 2 Type II report (Type I is a point-in-time snapshot and is meaningfully weaker), documented encryption in transit and at rest, breach-notification timelines, subprocessor disclosure, and explicit FERPA and COPPA handling. If your students include under-13 users, the COPPA consent mechanism needs to be spelled out, not assumed.

A fifth pillar worth adding once the first four are stable: accessibility. Require a current VPAT or Accessibility Conformance Report against WCAG 2.1 AA, and read it rather than filing it. A VPAT that says "partially supports" on every row is data, and it is the kind of data that surfaces in a complaint eighteen months later.

The step-by-step process for building and enforcing it

The sequence below is the one that survives contact with an actual district. It assumes roughly a semester of elapsed time and a working group of six to ten people meeting biweekly.

Step one: inventory what you already have. Before writing a single requirement, pull the actual list. Sources: the accounts-payable ledger filtered to software vendor codes, the SSO provider's application list, DNS or firewall logs showing what domains school devices actually reach, and a short survey to building leaders. These four sources disagree with each other, and the disagreement is the finding. Districts routinely discover 40 to 60 percent more tools in the wild than central IT knew about. Do not skip to standard-writing without this; the inventory is what makes the standard credible to the board.

Step two: charter the review board. Interoperability standards written by IT alone get overturned by curriculum. The functional minimum is IT/infrastructure, information security, curriculum and instruction, special education, assessment, legal or the business office, and at least one practicing classroom teacher. Give the group a written charter that specifies what it decides versus what it recommends, its meeting cadence, and its service-level commitment for reviewing a submitted product — two to three weeks is a realistic target and is fast enough that people do not route around it.

Step three: draft tiers, not a single bar. A one-size standard fails because a district-wide SIS replacement and a $400 classroom app cannot carry the same compliance load. Three tiers works well: Tier 1 for enterprise or district-wide systems and anything touching PII at scale, carrying the full requirement set; Tier 2 for building- or department-level tools, requiring SSO, a signed privacy agreement, and either rostering or documented manual provisioning; Tier 3 for free or low-cost classroom tools, requiring the privacy agreement and a teacher attestation but not full protocol conformance. Define the tier boundary by data sensitivity and user count, not by price alone — a free tool that ingests full rosters is a Tier 1 risk wearing a Tier 3 price tag.

Step four: convert the standard into procurement artifacts. This is the step districts most often miss, and skipping it is why standards become shelfware. The standard must be embodied in three concrete documents: a required RFP requirements block, a standard contract rider or terms addendum, and a vendor self-attestation form that becomes a contract exhibit. When the attestation is an exhibit, a false claim is a contract breach rather than a disappointment.

Step five: pilot before you buy. Require a sandbox integration test for every Tier 1 purchase and any Tier 2 purchase over a threshold — many districts set that around $10,000 to $25,000 annually. Give the vendor a test roster with deliberately messy data: a student in two schools, a co-taught section with two teachers of record, a mid-year transfer, a name with a hyphen and a name with a diacritic, an inactive enrollment. Watch what breaks. This single test catches more real problems than every questionnaire combined, because questionnaires measure what a salesperson believes and sandboxes measure what the software does.

Step six: publish, train, and enforce at the PO. The enforcement point is the purchase order. If finance can cut a PO for software without an approval reference number from the review board, the standard is advisory. Wire the check into the ERP or requisition workflow so the field is required. Then publish the standard publicly — vendor-facing, on the district website — because vendors who read it before pitching pre-filter themselves, and the sales conversations get dramatically shorter.

Step seven: version and review annually. Stamp the document with a version and a date. Set a fixed annual review where the board reconsiders whether a spec version should advance, whether a tier boundary moved, and which exceptions granted last year should now expire.

Costs, timelines, and the ranges to plan against

Budget honestly, because underfunding this is the most common way it dies quietly in month four.

Elapsed time. A district writing its first standard from scratch should plan four to six months from kickoff to published v1.0, then another full purchasing cycle — usually a school year — before compliance rates look respectable. Districts that adopt an existing framework rather than drafting original language compress the first phase substantially; borrowing the NDPA plus a peer district's tier structure can cut the drafting phase roughly in half. There is no prize for original prose in a procurement standard.

Staff effort. The working group itself is the visible cost: eight to ten people at two to four hours a month for the drafting period. The invisible and larger cost is the ongoing review load. If your district processes 150 software purchases a year and each Tier 1 review consumes six to ten hours of combined staff time while Tier 3 consumes under an hour, the annual steady-state load lands somewhere in the range of a half to a full FTE. Districts that do not staff that role find reviews slipping to six weeks, at which point principals start buying around the process — and once bypassing becomes normal, it does not un-normalize.

Integration platform. Most districts of any size end up paying for a rostering or identity broker rather than building one. That is a real line item, and pricing is typically per-student and negotiated, so treat published figures skeptically and get quotes. The relevant comparison is not broker cost versus zero; it is broker cost versus the loaded cost of the engineering time you would otherwise spend maintaining point-to-point integrations, plus the risk cost of those integrations breaking during the first week of school.

Vendor-side costs. Expect some vendors to quote an integration or SSO enablement fee. Negotiate these into the base price during the initial contract rather than accepting them as a separate line, because a fee accepted once becomes a fee at every renewal. Also expect a handful of incumbent vendors to be genuinely unable to meet the standard. Budget for either replacement or a formal, time-boxed exception; pretending they comply is the worst of the three options.

Where the payback shows up. The savings are mostly avoided costs, which makes them harder to present but no less real: eliminated duplicate subscriptions surfaced by the inventory (districts routinely find the same product purchased three times by three departments), reduced help-desk volume around login and roster problems in the first weeks of each term, avoided emergency integration work, and better renewal pricing from reduced switching cost. The inventory step alone frequently pays for the whole effort in year one, which is a useful thing to know when you are asking the board to fund it.

A realistic first-year target. Do not promise 100 percent compliance. Promise that every new Tier 1 purchase clears the standard, that the inventory is complete, and that a dated remediation plan exists for the legacy tools that do not comply. That is achievable and defensible. Universal compliance across a legacy portfolio is a three-year arc, not a one-year one.

Where districts get this wrong

Writing the standard before taking the inventory. Requirements drafted in the abstract are always either too strict for the long tail of small tools or too loose to constrain the big ones. The inventory tells you what the actual distribution looks like, and the tier boundaries should be drawn from that distribution rather than guessed.

Confusing "supports the spec" with "is certified against the spec." Interoperability specifications have conformance certification programs precisely because self-reported support is unreliable. Ask for the certification record. Where certification does not exist for a given capability, substitute a sandbox demonstration. Never accept a checkbox as evidence for anything that will cost real money to discover is false.

No exception path. A standard with no legitimate way to say yes to a non-conforming but genuinely valuable tool will be violated rather than followed. Build the exception process into v1.0: a written request, a documented compensating control such as manual provisioning or restricted data scope, an approval by a named person rather than a committee, and a hard sunset date. Track exceptions on a visible list. An exception with no expiration is just a permanent hole with paperwork attached.

Enforcing at the wrong point in the workflow. If the check happens after someone has already been sold, budgeted, and emotionally committed, the review board becomes the villain in every story. Enforce at requisition — before money moves — and make the standard visible to vendors and to staff so the constraint is known upstream of the sales cycle.

Ignoring the teacher-adopted long tail. Free tools adopted by individual teachers are where the real student-data exposure usually lives, and they never generate a purchase order, which means a PO-based control never sees them. Handle this with a separate lightweight approved-apps list, an SSO-level restriction on which third-party applications can request access to district Google or Microsoft accounts, and periodic OAuth-grant audits. This is adjacent to the purchasing standard rather than part of it, but a standard that only governs paid purchases governs maybe half the actual risk surface.

Treating rostering as the whole problem. Rostering is the loudest requirement, so it absorbs attention. But data export and offboarding are where districts get trapped. Write the exit terms with the same care as the entry terms: what data comes back, in what format, within how many days, at what cost, and what proof of deletion the vendor provides afterward.

Letting the standard go stale. Specification versions advance. LTI 1.1 was fine, then it was deprecated. A standard that names a version and is never revisited becomes a document that mandates obsolete technology. The annual review is not ceremonial.

Underestimating change management. The technical document is maybe a third of the work. The other two-thirds is explaining to principals, department heads, and instructional coaches why a purchase they could make in a week last year now takes three, and making the process fast and transparent enough that the explanation holds. Publish the queue. Publish the turnaround times. Nothing defuses resentment about a gate like visible evidence that the gate moves quickly.

A decision framework for tiering and exceptions

The framework below is what the review board actually runs in a meeting. It should fit on one page and produce the same answer regardless of which board member applies it.

Start with data sensitivity, not cost. Ask whether the tool ingests personally identifiable student information. If it does, and it touches more than a single classroom, it is Tier 1 regardless of price — a free tool with full roster access carries enterprise-level risk. If it holds no PII at all and requires no login, most of the standard is irrelevant and the review should be a formality measured in days.

Then ask about scope. District-wide or multi-school deployment raises the tier by one, because the blast radius of a failure scales with the number of buildings that depend on it. A tool that fails in one classroom is an inconvenience; a tool that fails district-wide during state testing week is a board meeting.

Then ask about criticality and substitutability. If the tool is on the critical path for instruction, assessment, or compliance reporting, the exit terms and export requirements matter far more than the launch requirements, because the real risk is not integration friction — it is being unable to leave. Conversely, a supplementary tool with three viable competitors can be held to a looser standard, since replacing it is cheap.

Finally, handle the non-conforming case explicitly. When a valuable tool misses a requirement, the question is never simply pass or fail. It is: what compensating control makes this acceptable, who owns that control, and when does the exception expire? Manual roster provisioning with a named owner and a quarterly reconciliation is a legitimate compensating control for a small tool. It is not a legitimate control for a district-wide system, because nobody sustains manual provisioning at that scale past the second month.

One last framing worth holding onto: the standard's job is not to block purchases. It is to make the cost of a purchase visible before the money moves. A district that approves a non-conforming tool with open eyes, a named owner, and an expiration date is in a fundamentally better position than one that approves the same tool believing a checkbox.

Related questions

Should a district build its own integration layer or buy a rostering broker?

Buy, in almost every case. Building means owning per-vendor connector maintenance forever with school-year-start deadlines and no slack. Build only if you have a genuinely unusual data model and dedicated engineering staff — and even then, expect the maintenance burden to exceed the initial estimate.

How do you handle vendors already under contract who cannot meet the standard?

Do not retroactively breach them. Apply the standard at renewal, notify affected vendors twelve months ahead so they have a real remediation window, and maintain a dated non-compliance register with an owner and a plan per entry. Legacy portfolios converge over two to three renewal cycles, not one.

What is the minimum viable version if we have no dedicated staff?

Three requirements: a signed student-data-privacy agreement, SSO against the district identity provider, and a documented free data export. Those three cover most of the privacy and lock-in exposure. Add rostering and event standards in v2.0 once the review habit exists.

Does this apply to AI tools and tutoring assistants?

Yes, plus additions. Require disclosure of whether student data trains models, where inference runs, what subprocessors are involved, human-review provisions for consequential outputs, and the ability to opt out of training entirely. Treat any AI tool touching student work as Tier 1 by default.

How does this interact with state or consortium purchasing?

Use it as leverage. Many states run privacy alliances or cooperative contracts with pre-negotiated terms; aligning your standard to those means vendors arrive pre-compliant and legal review shrinks to a countersignature. Check your state alliance before drafting original contract language.

FAQ

Who should own the interoperability standard — IT or curriculum?

Joint ownership with a single accountable executive, usually the CIO or chief technology officer, and formal sign-off from the chief academic officer. IT-only ownership produces a technically sound document that instructional leaders route around; curriculum-only ownership produces requirements nobody can verify. The executive sponsor's real job is adjudicating the cases where instructional value and technical conformance genuinely conflict, because those cases are where the standard earns or loses its credibility.

How long should vendor review take before it becomes a bottleneck?

Two to three weeks for Tier 1, one week for Tier 2, and a few days for Tier 3. Past four weeks, people start buying around the process, and once bypassing is normalized it is very hard to reverse. If your queue is running long, the answer is more reviewer capacity or a lighter Tier 3 path — not a stricter enforcement memo.

What if a vendor claims OneRoster support but only offers CSV files?

That is partial support and should be documented as such. CSV rostering means batch-updated data, typically nightly, so mid-year transfers and schedule changes lag by a day. Whether that is acceptable depends on the use case: a supplementary reading tool can tolerate it, a system used for attendance or state reporting cannot. Write the requirement as "REST API with delta support" if real-time matters to you, and verify against the certified-product directory.

Do we need a sandbox test for every purchase?

No, and requiring one for everything will collapse your review capacity. Reserve sandbox testing for Tier 1 systems and higher-value Tier 2 purchases. For everything else, the vendor attestation plus the certification record is proportionate. The point of tiering is to spend scrutiny where the risk actually is.

How do we get principals and teachers to actually follow the standard?

Make compliance the path of least resistance. Publish an approved-tools catalog so the easy answer is already vetted. Keep review turnaround short and visible. Enforce at the requisition step so nobody discovers the rule after they have committed. And give the exception process a real chance of saying yes — a gate that only ever denies gets bypassed, while one that says "yes, with these conditions and this expiration date" gets used.

What should the standard say about data deletion at contract end?

Specify a deadline in days, a required format for returned data, a written certificate of deletion covering backups and any subprocessors, and a prohibition on retaining student data for product improvement or model training after termination. Then actually request the certificate when a contract ends. Districts that write the clause and never exercise it have documentation, not assurance.

Sources

• https://www.1edtech.org/standards/oneroster
• https://www.1edtech.org/standards/lti
• https://www.1edtech.org/standards/caliper
• https://www.ed-fi.org/
• https://privacy.a4l.org/national-dpa/
• https://studentprivacycompass.org/
• https://studentprivacy.ed.gov/
• https://www.ftc.gov/business-guidance/privacy-security/childrens-privacy
• https://www.w3.org/WAI/standards-guidelines/wcag/
• https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2

Related on PULSE

• How do you run a vendor consolidation audit without disrupting active users?
• What belongs in a data processing addendum for a SaaS purchase?
• How do you calculate the true switching cost of a core system?
• What does a workable software request intake process look like?
• How do you build an approved-tools catalog people actually use?