Higher education has consolidated its entire academic operation into a handful of massive SaaS platforms. The LMS manages instruction, grading and communication. The SIS owns enrollment, records and financial aid. Identity and productivity live in a small number of cloud providers. These are not peripheral tools — they are the operational infrastructure of the institution. As IT stewards, we manage platforms we do not own, cannot restore ourselves and cannot directly control — which makes contingency planning not optional, but fundamental to the role.
The contracts are in place. The SLAs are signed. The compliance certifications are current. None of that matters to a student who cannot reach her instructor three days before finals. None of it matters to a faculty member who has no roster, no grade book and no way to document the work his students submitted before the platform went dark. SLAs govern vendor response timelines. Keeping academic operations running during that response window is IT’s responsibility.
The disruption hit during finals week 2026, and I was doing what every CIO in higher education was doing — monitoring. A major learning management system had been breached. The disruption spread fast. Finals were canceled. Exams were postponed. Students and staff were stranded without access to coursework, rosters or grade books. The costs — in academic disruption, extended contracts, emergency response — were substantial and widely reported. My institution was not directly impacted. But watching peer institutions in my own state go dark during the highest-stakes moment of the academic calendar was not reassuring. It was a confirmation of something I had been thinking about for a long time.
The disruption proved something IT professionals have relearned in every decade of their careers. Mark Twain observed that history does not repeat itself, but it does rhyme. This is a verse we have heard before: Dependence on a single point of failure, without a tested contingency plan, is not a strategy — it is a risk that has simply not yet been called. Whether the failure comes from a cyberattack, a vendor outage, an infrastructure collapse or a cloud provider’s bad deployment, the result is the same. The institution stops. And no SLA, contract or compliance certification prevents that moment from arriving.
Vigilance is not optional. Technologies are evolving faster than any IT team can fully anticipate. New platforms, new integrations, new dependencies emerge constantly — and with each one comes a new potential failure point. That is not an argument against adopting new technology. It is an argument for the one principle that never becomes obsolete: Reliance on any single critical system, whether it is a connectivity provider, an identity platform or a SaaS solution, is a proven strategy for failure. The question is never whether that system will fail. The question is whether the institution is prepared when it does.
Single points of failure fail — inevitably, and at the worst possible time. IT professionals have known this for thirty years. The SaaS layer is not exempt.
This is not a new lesson. Azure has gone down. AWS has failed. Google Workspace has had outages that took organizations dark globally. No campus runs a single ISP connection — we provision redundant circuits, preferably from independent providers, because we learned long ago that the connection will sometimes fail and the institution cannot afford to stop when it does. Financial services, government and multinational enterprises applied that same logic to every dependency in their stack. Their response to platform risk was not to demand better SLAs. It was to architect around the dependency. Redundancy. Failover. Independent continuity capability. The massive disruptions from Canvas demonstrate that effective contingency solutions for these critical platforms have not kept pace with our dependence on them. We cannot get fooled again.
That omission is what made the 2026 attack so damaging. Not the sophistication of the breach — the entry point was a peripheral free-tier environment that wasn’t even within the vendor’s primary certification scope. The damage was catastrophic because institutions had no fallback. Faculty had no rosters. Administrators had no enrollment data. There was no continuity layer. A single point of failure, at institutional scale, with no plan for when it fails.
And now the economics have shifted in the worst possible direction. PowerSchool paid a ransom in December 2024 after attackers stole data on 60 million students — and was re-extorted anyway, with individual school districts receiving separate demands months later using the same stolen data. Instructure’s CEO publicly confirmed the extortion payment. Anyone who has paid a ransom only to be hit a second time at double the cost can tell you — paying the attackers resolves nothing and instead invites more attacks. The sector has now proven twice, publicly, and at scale, that it will pay. That changes the threat calculus entirely. Higher education stops being a target of opportunity and becomes a target of strategy. Criminal groups share that intelligence. Banner serves over 1,400 institutions. Blackboard reaches tens of millions of users across thousands of campuses. Every major higher education SaaS platform is now on active threat actor priority lists — not because they are newly vulnerable, but because the sector has proven it will pay, that academic calendar pressure creates maximum leverage, and that IT has not yet built the operational alternative that our dependence on these platforms demands — and therefore the failure is ours to own, especially if we allow it to happen a second time.
The sector has proven it will pay. Every ransomware group operating today just received the same market signal. What follows is not unpredictable — it is documented, underway and aimed directly at the platforms carrying your institution’s academic operations.
As a CIO, my approach to this is not a spreadsheet or a stack of printed reports. IT is responsible for identifying critical failure points and countering them — that is not optional; it is the job. Accepting failure as inevitable without a mitigation strategy is not viable. Redundancy and continuity solutions are standard practice everywhere else in our infrastructure. There was no reason the SaaS layer should be different.
A leader’s first job isn’t to be right — it’s to be responsible.
The solution I implemented is a secure, read-only, centralized repository — a continuity strategy that ensures students, staff and faculty can continue to function whether the issue is a power outage, a cyberattack or a SaaS platform going dark. It is not a replacement for Canvas or Banner. It is the independent fallback that allows the institution to keep operating while the primary system is restored. I have learned the hard way that accepting failure without a plan is not a posture any CIO can defend.
Watching the frustration across the industry during and after the 2026 attack — institutions paralyzed, peer CIOs improvising, faculty working from personal spreadsheets, boards asking questions no one could answer — the logic of extending this capability to other institutions became unavoidable. The solution is not complex. The architecture is straightforward. The discipline behind it is thirty years old. The discipline is established. The responsibility to apply it is our field of expertise in IT.
To be precise about scope: An ACR does not prevent vendor breaches, replace cyber insurance or remove notification obligations. When an incident hits, legal counsel, security teams and institutional leadership still manage the response. What the ACR changes is what they have to work with — a governed, auditable record of what data was accessed, what manual actions were taken and how operations continued while the vendor worked to restore service.
Redundancy, disaster recovery, continuity of operations — the discipline is not new. The SaaS platforms carrying academic operations deserve the same standard we hold everywhere else.
The solution to this problem exists. A SaaS third-party continuity of operations strategy requires an independent data layer — one the institution controls, synchronized on a regular scheduled cycle from source systems, and accessible when those systems are not. Platform-agnostic across Canvas, Banner, Blackboard and PowerSchool. Read-only by design. Auditable by requirement. Independent by architecture. That last word is the one that matters — independent of the platforms whose availability you cannot guarantee.
Every CIO in higher education knows what a single point of failure looks like. Every one of us has built around them at every other layer. Servers, networks, data centers — we do not accept the single-point risk, and we do not wait for the failure to motivate the fix. The SaaS layer is not an exception.
The question is not whether your institution will face it. The question is whether you will have a continuity strategy in place when it arrives — or be explaining to your board why you did not.
Leaders don’t rent accountability — they own it outright.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
No Responses