How do you create a student data governance framework that maps every edtech tool to its data flow in 2027?

What it is and why it matters

A student data governance framework is the written, enforceable answer to a question most districts and institutions still cannot answer on demand: *which vendor holds which piece of a student's record, and by what authority?* It is not a policy binder. It is a maintained set of artifacts — a tool inventory, a per-tool data flow map, an owner assignment, a contract register, a classification scheme, and a review cadence — plus the routine that keeps them current as staff adopt new software.

The reason this became urgent is arithmetic. A mid-sized K-12 district typically runs a student information system, a learning management system, an assessment platform, a special education case management system, a transportation or nutrition system, a communications platform, and then somewhere between fifty and several hundred instructional apps that individual teachers adopted on their own. Research from LearnPlatform's annual edtech reports has repeatedly put the number of distinct edtech tools accessed in a district's typical school year in the several-hundred range, with a long tail of tools used by only one or two teachers. Higher education is not simpler — it is the same shape with more autonomy at the department level.

Each of those tools is a data flow. Even a free vocabulary game usually collects a name, a class roster position, a login identifier, and a performance history. Under FERPA, most of that is an education record when it is maintained by or on behalf of the institution, and the school official exception (34 CFR § 99.31(a)(1)) is what allows a vendor to hold it at all — but that exception carries conditions: the vendor must perform a function the institution would otherwise perform itself, must be under the institution's direct control regarding use and maintenance, and must not redisclose. If nobody wrote down which tools you are claiming that exception for, you cannot demonstrate compliance when a parent asks or an auditor calls.

Layer on the other statutes. COPPA governs the under-13 population and pushes verifiable parental consent onto operators — schools can consent on parents' behalf only in narrow educational-use circumstances, per the FTC's guidance. PPRA restricts surveys touching protected categories. IDEA adds confidentiality obligations for special education records. State student privacy laws — California's SOPIPA, New York's Education Law § 2-d, Colorado's Student Data Transparency and Security Act, Connecticut's contract requirements, and dozens more — impose their own duties, and several of them require a *published list of every vendor with student data* plus contract terms. New York 2-d in particular requires each contract with a third-party contractor to include a data security and privacy plan and a supplemental information page posted publicly. That statutory requirement alone forces exactly the artifact this framework produces.

The practical payoff is not compliance theater. When a vendor breach notice lands — and they land regularly, with the 2023 MOVEit incident sweeping in education service providers and the PowerSchool incident in early 2025 hitting districts across North America — the difference between a two-hour response and a six-week scramble is whether you already know which student fields that vendor held for which cohorts. A maintained flow map turns "we are investigating" into "the exposure is limited to these fields for these grade levels, and here is the notification list."

Building the inventory before you build the map

You cannot map flows for tools you have not found. The inventory step is where most frameworks quietly fail, because the official procurement list captures maybe a third of what is actually in use.

Pull from at least four independent sources and reconcile them:

Identity provider logs. If students and staff sign in through Google Workspace for Education, Microsoft Entra ID, Clever, ClassLink, or a SAML IdP, the OAuth grant and application sign-in logs are the single richest discovery surface you have. Google's Admin console exposes connected third-party apps with the scopes each was granted; Entra ID's enterprise applications and consent grants do the same. Export ninety days of sign-in events and you will find tools nobody in central IT has heard of. Pay specific attention to broad OAuth scopes — anything requesting Drive read access, Classroom roster access, or full profile access is holding more than it needs.

Network and DNS telemetry. Your content filter (Securly, GoGuardian, Lightspeed, Cisco Umbrella, or a firewall's DNS logs) records outbound destinations from managed devices. Aggregate distinct domains by request volume over a month. The top few hundred, after stripping CDNs and ad infrastructure, are your real usage picture — including tools accessed without any SSO grant.

Financial records. Query the general ledger and the P-card statements for anything coded to software, subscriptions, or instructional materials. This catches the department-funded and grant-funded purchases that skipped IT review, and it catches renewals of tools everyone forgot they bought.

Human canvass. A short structured survey to every building — five questions, not fifty: what do you use with students, how do students log in, does it hold grades or IEP information, who set it up, and did anyone sign anything. Keep the tone non-punitive; the goal is discovery, not discipline. Building-level tech coaches or media specialists usually already know most of the answers and will surface the shadow tools if you ask them rather than the principal.

Reconcile into one record per tool with a stable identifier. Deduplicate aggressively — the same vendor often appears as three product names and two domains. Expect the reconciled list to be two to five times longer than the procurement list. That gap is the finding, and it is worth reporting to leadership on its own before you do anything else.

Then triage. You do not map four hundred tools at equal depth. Sort into tiers:

• Tier 1 — systems of record. SIS, LMS, assessment, special education, and anything holding IEP, 504, health, discipline, free-and-reduced-lunch status, immigration-adjacent fields, or full identifiers. Usually five to fifteen tools. These get a full flow map, a signed DPA, a security review, and an annual re-verification.
• Tier 2 — rostered instructional tools. Anything receiving an automated roster sync via Clever, ClassLink, Google Classroom, OneRoster, or LTI. Typically thirty to eighty tools. These get a flow map at field granularity, a DPA, and a review every two years or on renewal.
• Tier 3 — low-data or anonymous-use tools. No roster sync, no persistent account, no identifiable data leaving the browser. These get a documented determination and a spot check, not a full map.
• Tier 4 — unapproved. Everything holding student data with no agreement. This is a queue to be worked down, not a category to live in.

Publish the tier definitions before you tier anything. Otherwise every conversation becomes a negotiation about whether a specific favorite tool "really" counts.

The step-by-step process

The framework assembles in a fixed sequence. Skipping ahead — writing policy before you have an inventory, for instance — is the most common way a governance program stalls in month three.

Step one: charter and sponsorship. Name a data governance lead with authority — usually a chief technology officer, chief privacy officer, or in higher education a registrar-plus-CISO pairing. Establish a standing committee that includes instruction, special education, student services, legal or general counsel, and at least one building-level teacher. Meeting monthly for the first two terms, quarterly after. Write a one-page charter stating scope, decision rights, and what happens when a tool is found non-compliant. Without stated decision rights the committee becomes advisory and nothing gets retired.

Step two: define your data element taxonomy. Before mapping anything, agree on the vocabulary. A workable starting taxonomy for student data: directory information as your institution defines it under FERPA; identifiers (name, student ID, state ID, email, device ID); demographics (DOB, grade, race/ethnicity, gender, home language); enrollment and schedule; academic performance (grades, standards mastery, assessment scores); behavioral (attendance, discipline, referrals); special populations (IEP, 504, ELL, gifted, homeless/McKinney-Vento status); health and immunization; family and household (guardian contacts, address, FRL eligibility); and system-generated telemetry (clickstream, time-on-task, keystroke or browsing monitoring). Sensitivity ratings attach to the element, not the tool — that is what makes the map composable.

Step three: map each Tier 1 and Tier 2 flow. A complete flow record for one tool answers, at minimum: what elements enter, by what mechanism, from what source system, on what cadence, to what processor, hosted in what region, subprocessed by whom, retained how long, deleted by what trigger, and returned or destroyed how at contract end. Get the mechanism specific — "Clever secure sync, nightly, sections and enrollments only" is a usable answer; "integrated with the SIS" is not. Where a tool writes back into a system of record (a gradebook passback via LTI AGS, for example), map that direction too. Bidirectional flows are where surprising data expansion happens.

Step four: match every flow to paper. For each mapped tool, locate the contract, DPA, click-through terms, or state-standard agreement (the Student Data Privacy Consortium's National Data Privacy Agreement is widely used, and many states run their own SDPC alliance with a shared registry — check whether a signed agreement for that vendor already exists in your state's alliance before negotiating a new one). Record the execution date, the term, the renewal date, the breach notification window, the subprocessor clause, the deletion obligation, and the security exhibit. A flow with no paper is a finding.

Step five: remediate the gaps. Three exits for every gap: get an agreement signed, restrict the flow so it no longer carries regulated data, or retire the tool. Set a deadline per tier. Publish the retirement list with enough lead time — a term, ideally — so teachers can transition rather than lose a tool mid-unit.

Step six: close the loop with intake. Every new tool request goes through a short form that produces a draft flow record as its output. If the intake does not feed the map, the map decays within one school year.

Costs, timelines, and typical ranges

Budget honestly, because underscoping is what makes governance programs look like failures at the six-month mark.

Time to first complete map. For a district with roughly 200 to 400 discovered tools, expect four to seven months from charter to a published Tier 1 and Tier 2 map. Rough allocation: three to five weeks for discovery and reconciliation, two weeks for taxonomy and tiering, eight to fourteen weeks for the flow mapping itself, and four to eight weeks for contract reconciliation and remediation — the last of which runs on vendor response time, which you do not control. Small districts under 2,000 students with a tight tool list can compress this to eight to twelve weeks. A large university with decentralized departmental purchasing should plan on nine to eighteen months and should expect to do it college by college.

Labor. The mapping itself is roughly 45 to 90 minutes per Tier 1 tool once you have a template and a cooperative vendor contact, and 20 to 40 minutes per Tier 2 tool. Multiply: 12 Tier 1 tools plus 60 Tier 2 tools lands somewhere near 40 to 60 hours of focused work, plus meeting overhead. Realistically that means 0.25 to 0.5 FTE for a half-year, or a dedicated person for two to three months. The variance is almost entirely vendor responsiveness — some send a completed data flow document within a week, others take three chase emails to produce a subprocessor list.

Staffing patterns. Districts under about 5,000 students usually run this as a fractional responsibility inside an existing technology director role, sometimes supported by a regional education service agency or BOCES that maintains a shared vendor registry. Districts in the 5,000 to 25,000 range increasingly fund a dedicated data privacy officer or split the role between a data manager and a compliance analyst. Above that, and in higher education, it is typically a small team under a CISO or chief privacy officer.

Tooling. You can run the first cycle in a spreadsheet plus a shared drive, and many institutions should — the discipline matters more than the software, and a premature platform purchase often becomes an unmaintained system of its own. When the tool count and change rate outgrow the spreadsheet, the realistic options are an edtech management platform (LearnPlatform, now part of Instructure, and Lightspeed Digital Insight are established in K-12), a vendor risk management module in an existing GRC platform, or the state SDPC alliance registry if your state runs one. Pricing in this space is quote-based and varies by enrollment; get two or three quotes rather than trusting any published figure.

Ongoing cost. Steady state is cheaper than the build but never zero. Plan on roughly 10 to 20 percent of the initial effort per year: a term-start re-verification sweep, intake reviews as new requests arrive (a busy district sees somewhere between two and ten a month during the school year), renewal-triggered contract reviews, and one annual audit pass. If the ongoing number is budgeted at zero, the map will be stale by the second year, which is functionally the same as not having one.

What actually costs the most. Not the mapping. The expensive line items are the remediation work when you discover a widely-loved tool with no agreement and no willingness to sign one, and the legal review hours if your counsel reviews each DPA individually rather than working from a standard template. Adopting a standard agreement — the NDPA or your state's equivalent — and treating vendor redlines as the exception rather than the norm is the single largest cost lever available.

Where teams get it wrong

Mapping the tool instead of the data. A record that says "Vendor X — student data — yes" is not a map. The unit of governance is the data element flowing to a specific processor for a specific purpose. If your record cannot tell you whether a vendor holds IEP status, you cannot scope a breach and you cannot answer a parent's access request. Force field-level granularity on Tier 1, minimum.

Treating the map as a project. A one-time inventory ages out fast. Teachers adopt tools in August. Vendors get acquired and change subprocessors mid-term. Free tiers add analytics. Without a recurring re-verification and an intake path, a beautifully complete map is roughly 60 to 70 percent accurate one year later — accurate enough to be dangerous, because people trust it.

Ignoring the click-through tier. The tools that cause incidents are rarely the SIS. They are the free-tier app a teacher signed up for with a school email, accepting consumer terms of service that permit data use for product improvement and contain no deletion obligation. These never appear in procurement. They appear in your OAuth grant log and your DNS log, which is why discovery cannot be a purchasing exercise.

Letting the roster sync be a blank check. Clever, ClassLink, Google Classroom, and OneRoster syncs are enormously convenient and quietly over-share. Many default share configurations push more fields than the receiving tool needs — full demographics where a name and a section would do. Audit the actual share configuration per application inside the rostering platform, not the vendor's claim about what they receive. Trim to minimum necessary. This is usually the highest-value hour of the whole project.

Confusing a signed DPA with a verified flow. A signed agreement is a legal control. It is not evidence of what the system does. Verify at least a sample against reality — check the actual sync payload, check where the data is hosted, check the subprocessor list on the vendor's trust page against what the contract permits. Where the contract and the behavior disagree, the behavior is what will show up in a breach.

Forgetting deletion and offboarding. Retention is the most consistently unmapped element. When a tool is retired or a student graduates, someone must trigger deletion and get confirmation. Build the offboarding step into the framework from day one — a retired tool with an unreturned copy of five years of student records is a live risk with no owner.

No named owner per flow. "IT owns it" produces orphaned records. Every flow needs a person, not a department: usually the instructional or program leader who depends on the tool, with technology as the co-signer. Owner turnover should trigger reassignment.

Building governance in a room without teachers. A framework that makes adoption impossible gets routed around, and shadow IT gets worse, not better. Publish the approved list prominently, make the intake fast — a two-week turnaround target for a low-risk tool is achievable — and give a clear path for the teacher who found something genuinely good.

Decision framework: when to choose what

Not every tool earns the same treatment. Route by the data it touches and the leverage you have.

Some concrete routing rules worth writing into the framework:

Choose a full flow map when the tool holds special-population status, health data, discipline records, biometric or monitoring data, or full identifiers for a whole population. The cost of not knowing exceeds the mapping effort by an order of magnitude.

Choose the standard agreement path when the vendor is in your state's SDPC alliance or already signs the NDPA. Do not negotiate what someone else has already negotiated — check the registry first. This alone can cut contract cycle time from weeks to days.

Choose restriction over retirement when a tool is instructionally valuable but over-collecting. Trimming the roster share to name and section, disabling optional analytics, or moving to a non-rostered classroom-code login often converts a Tier 1 problem into a Tier 3 determination without losing the tool.

Choose retirement when the vendor will not sign, will not disclose subprocessors, reserves rights to use student data for its own product development or advertising, or has no deletion commitment. These are not negotiable positions for regulated student data, and holding that line once — publicly, with a named tool — does more for the program's credibility than a year of policy documents.

Choose an exception with a hard expiry when a critical system genuinely cannot be remediated this term. Write the compensating controls, the expiry date, and the approver's name. An exception with no expiry is just a permanent gap wearing a form.

Choose to buy a platform when you exceed roughly 150 governed tools, your change rate exceeds five intake requests a month, or you have more than one campus maintaining its own list. Below that, a well-run spreadsheet with a defined schema and a version history beats an underused platform.

For higher education specifically, add a departmental delegation model: central governance sets the taxonomy, the standard agreement, and the tiering rules; departments maintain their own tool records against that schema and report into a central registry. Central mapping of every departmental tool at a large university does not scale and will produce a stale artifact.

Related questions

How is this different from a general data governance program?

Scope and law. Student data governance inherits FERPA, COPPA, PPRA, IDEA, and state student privacy statutes, and its risk surface is dominated by hundreds of small vendors rather than a few enterprise systems. The mechanics — inventory, classification, ownership, review — are shared with general programs.

Who should own the framework?

A single named lead with authority to retire tools, typically a CTO, data privacy officer, or in higher ed a CISO-and-registrar pairing, backed by a cross-functional committee including instruction and special education. Per-flow ownership sits with the program leader who uses the tool, not with IT alone.

Do we need to map free tools teachers found themselves?

Yes, if they touch identifiable student data. Free tools typically carry consumer terms with weak deletion and use restrictions, making them higher risk than paid systems. Discover them through OAuth grant logs and DNS telemetry, then route them through the same tiering decision as any other tool.

How often should the map be re-verified?

Tier 1 annually with a full re-verification, Tier 2 each term or on renewal, Tier 3 by spot check yearly. Additionally re-verify on any trigger event: vendor acquisition, subprocessor change, breach notification, or a material product change.

What is the single highest-value first step?

Export ninety days of identity provider application grants and DNS logs and reconcile them against the procurement list. The gap between the two is usually large, immediately actionable, and the most persuasive artifact you can bring to leadership when asking for the program's budget.

FAQ

What exactly goes in a data flow record?

Source system, elements transferred, transfer mechanism and cadence, receiving processor, hosting region, subprocessors, purpose, retention period, deletion trigger, contract reference, named owner, and next review date. If your template captures those thirteen fields consistently, you can answer nearly any audit, breach-scoping, or parent-access question from the record alone.

How do we handle vendors that will not disclose their subprocessors?

Treat non-disclosure as a finding, not a shrug. Most reputable education vendors publish a subprocessor list on a trust or privacy page and commit to notice before changes. If a vendor holding regulated student data refuses to name its processors, you cannot demonstrate the direct-control condition of the FERPA school official exception, and retirement or restriction becomes the reasonable path.

Does a state privacy alliance agreement replace our own mapping?

No. An alliance agreement — an SDPC state alliance registry entry, for example — solves the contract layer efficiently and saves real negotiation time. It does not tell you which of your systems actually sends which fields to that vendor in your configuration. The contract is one column of the flow record; the rest is still yours to document.

What should we do about AI features that vendors add to existing tools?

Treat a new AI feature as a material change that triggers re-review, because it usually changes purpose, retention, and subprocessing at once. The specific questions: is student input used to train models, is it shared with a model provider, what is the retention on prompts and outputs, and can the feature be disabled at the tenant level. Get answers in writing and attach them to the flow record.

How do we keep the map current without a full-time person?

Two mechanisms carry most of the load: an intake form whose output is a draft flow record, so new tools enter the map automatically rather than as a later cleanup, and a term-start sweep that re-pulls the identity provider grant list and diffs it against the map. The diff is short once the program is running — usually a handful of new entries — and that diff is the work.

What do we publish publicly?

At minimum a current list of vendors holding student data with the categories of data each holds, which several state laws require outright and which parents increasingly expect. Many institutions also publish the annual notification of FERPA rights, the directory information designation and opt-out, and a plain-language summary of the framework. Publish the list at a stable URL and date it.

Sources

• https://studentprivacy.ed.gov/ — U.S. Department of Education Student Privacy Policy Office
• https://www.ecfr.gov/current/title-34/subtitle-A/part-99 — FERPA regulations, 34 CFR Part 99
• https://www.ftc.gov/business-guidance/privacy-security/childrens-privacy — FTC COPPA guidance for businesses
• https://studentprivacy.ed.gov/resources/protecting-student-privacy-while-using-online-educational-services-requirements-and-best — ED guidance on online educational services
• https://privacy.a4l.org/ — Student Data Privacy Consortium (Access 4 Learning)
• https://www.nysed.gov/data-privacy-security — New York State Education Department, Education Law § 2-d
• https://www.cisa.gov/K12Cybersecurity — CISA K-12 cybersecurity resources
• https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf — NIST Privacy Framework
• https://www.cosn.org/ — Consortium for School Networking (CoSN) privacy resources

Related on PULSE

• How do you run a vendor risk review for an edtech purchase before signing?
• What belongs in a student data retention and deletion schedule?
• How do you scope a breach when a school vendor is compromised?
• How do you audit a Clever or ClassLink roster share configuration?
• What does a workable new-tool intake process look like for a school district?