Key takeaways
-
Almost no shadow IT tool passes FERPA's actual test for handling student data lawfully. The regulation requires a vendor be under the institution's "direct control," and a tool a department signed up for with a credit card, with no contract IT ever reviewed, fails that test by definition, not by accident.
-
Shadow IT is not primarily a discipline problem. Departments adopt ungoverned tools because the governed path is slower than the deadline they are working against, which means consolidation only sticks if the governed alternative is actually faster to adopt, not just more compliant.
-
Consolidation is a sequence, not an announcement. Discovery, risk ranking, and migration each take real work, and an institution that skips straight to "everyone must use the approved tool" without doing that work first will have the same shadow IT problem again within a year.
Why shadow IT isn't a discipline problem
A department adopts a scheduling tool, a survey platform, or a project tracker without going through IT, and the instinct in a lot of institutions is to treat this as a compliance failure on the department's part. That framing misses what actually happened. The department had a deadline, the approved procurement and IT review process was not fast enough to meet it, and a free or low-cost SaaS signup was. Shadow IT is what happens when the governed path loses on speed, not when staff deliberately choose to create risk. An institution that responds only with a stricter policy, without also making the governed path faster, will watch the same behavior recur under the next deadline.
The FERPA test almost no shadow tool passes: direct control
Under 34 CFR 99.31, a contractor or vendor can be treated as a school official, and therefore access education records without separate consent, only if it performs a service the institution would otherwise handle itself, is under the institution's direct control regarding the use and maintenance of the records, and is bound by FERPA's redisclosure limits. The Department of Education's own third-party service provider guidance makes clear that direct control is typically established through a signed contract, and that a vendor's terms of service changing without the institution's notice undermines its ability to demonstrate that control. A shadow tool adopted by credit card, with no reviewed contract and no institutional signature on any terms, has no direct control relationship with the institution at all. If that tool holds any student data, the institution has no FERPA-compliant basis for the disclosure that just happened, whether anyone intended a disclosure or not.
What "consolidation" actually means: discovery, risk-rank, migrate
Consolidation is not a single action. It is four distinct steps, and skipping any one of them is why so many consolidation efforts stall after an initial burst of attention.
Discovery finds the tools actually in use, not the tools IT already knows about. A peer-reviewed study of shadow IT in higher education documents that tools adopted outside the formal review process are common across departments, and no institution has a complete list of them without actively looking, since by definition these tools were adopted specifically to avoid the review process that would have made them visible.
Risk ranking sorts discovered tools by what they actually hold, not by how the department describes them. A scheduling tool with no student data is a low priority. The same scheduling tool syncing to a roster with names and grades is a different problem entirely, the kind FERPA's "school official" FAQ treats as squarely inside the direct control test, and the two should never be ranked identically just because they share a product category.
Migration moves the data and the workflow, not just the label, and where a contract is being renegotiated as part of that move, the same conflict-of-interest exclusion under 2 CFR 200.319 that governs any other procurement still applies. A department using a shadow tool for a real, ongoing process needs a governed replacement that does what the shadow tool did, or the department will find another ungoverned way around the gap the migration created.
Retirement closes the loop: the vendor relationship ends, the data is exported or deleted per the vendor's own terms, and the tool stops being a live risk rather than a legacy one nobody remembers to finish decommissioning.
Where shadow IT already looks like a procurement bypass
A shadow tool adopted without institutional review has also typically bypassed whatever procurement process the institution's own policy requires. For contracts tied to federal awards, 2 CFR 200.318 requires a documented contract administration system, which a credit-card SaaS signup obviously does not have. Vendor security posture is a separate gap: institutions that would normally require a HECVAT assessment before onboarding a vendor rarely get the chance to ask for one when a department has already been using the tool for months by the time IT finds out, the same NIST Cybersecurity Framework asset management gap that undermines everything downstream of it.
What actually determines a shadow tool's risk level
|
Risk factor
|
Low risk
|
High risk
|
|
Data handled
|
No institutional or personal data
|
Student records, financial data, or health information
|
|
Contract status
|
No contract needed, no data exposure
|
No reviewed contract despite handling regulated data
|
|
Integration depth
|
Standalone, no connection to institutional systems
|
Synced to the SIS, HR system, or financial system
|
|
User base
|
Single individual, informal use
|
Department-wide or cross-department process dependency
|
A governed consolidation workflow
Discovery runs continuously, not as a one-time audit
New shadow tools are found through expense reports, network traffic, and self-reporting incentives, not a single point-in-time inventory that goes stale within a semester.
Every discovered tool is classified against FERPA's direct control test
A tool handling any student data is checked against the three-part school official standard: institutional function, direct control, and redisclosure limits. A tool that fails any prong is flagged for immediate remediation, not a future review cycle. Where the tool would also need to satisfy GLBA's service provider oversight requirement, that gap is flagged alongside the FERPA determination rather than discovered separately later.
Risk ranking drives priority, not discovery order
The highest-risk tools, those touching regulated data with no contract in place, are addressed first regardless of when they were discovered.
A governed alternative is identified before the shadow tool is removed
Migration only works if the department's actual workflow need is met by the replacement, not just the product category.
Data export and account closure are tracked to completion
A migration is not finished when the new tool goes live. It is finished when the old vendor relationship is formally closed and the institution can confirm the data was exported or deleted.
The consolidated inventory becomes the new baseline
Once a tool is governed, it is tracked the same way any other institutional application is tracked, closing the loop so it does not quietly drift back into shadow status when its next renewal comes up.
Kissflow and the SaaS rationalization stack
Kissflow is the governed execution layer at the edges of the SaaS rationalization stack. It does not replace the discovery tools that scan network traffic or expense data to find shadow IT in the first place. It replaces what happens after discovery, when a found tool has to be risk-ranked, a decision has to be made about migration or retirement, and a governed replacement has to actually go live faster than the shadow tool did.
If your institution runs a dedicated SaaS management or discovery platform, Kissflow does not compete with it for finding shadow tools. It sits alongside it as the layer that takes a discovered tool through classification, HECVAT review, migration planning, and closure, and, just as importantly, gives departments a governed intake path fast enough that the next urgent need does not become the next shadow IT tool.
The differentiation that matters to a CIO: when a new category of shadow risk emerges, or the institution's FERPA or procurement review criteria change, the office that owns technology governance updates the intake and classification workflow directly, instead of waiting for a discovery tool vendor to add a consolidation workflow that was never central to what that platform was built for.
Frequently asked questions
-
Is shadow IT always a security problem?
Not automatically. A tool with no institutional or personal data carries limited risk regardless of how it was adopted. The risk concentrates specifically in tools that handle regulated data, integrate with institutional systems, or become department-wide process dependencies without ever having been reviewed.
-
Why does FERPA's "direct control" requirement matter so much for shadow IT specifically?
Because it is the exact test a credit-card SaaS signup almost always fails. Without a reviewed contract establishing the institution's control over how the vendor uses education records, the institution has no FERPA-compliant basis to let that vendor handle student data at all.
-
Why do consolidation efforts often fail after an initial push?
Because they skip straight to a policy announcement without making the governed path faster than the shadow path it is meant to replace. If the approved alternative is still slower to adopt, the underlying pressure that created the shadow tool in the first place has not gone away.
-
Does every shadow tool need to be replaced immediately?
No. Risk ranking should drive priority. A tool with no institutional data and no cross-department dependency can be addressed later. A tool touching student records with no contract in place should be addressed immediately.
-
What happens to the data when a shadow tool is retired?
It depends on the vendor's own terms, which is exactly why migration and retirement have to be tracked to actual completion, confirming export or deletion, rather than considered done once the department stops actively using the tool.
-
Does Kissflow replace our SaaS discovery or spend management tool?
No. Kissflow is the workflow layer that takes a discovered shadow tool through risk classification, review, and migration, and gives departments a fast, governed intake path so the next urgent need does not become the next shadow tool.
Request a 30-minute walkthrough to see how Kissflow discovers, risk-ranks, and migrates shadow IT into governed apps with a faster intake path than the tools it replaces. Book a demo today.
