How Universities Can Manage Vendor Risk After the Canvas Breach

What the Canvas Breach Reveals About Third-Party Risk in Higher Education

When it comes to vendor risk management in higher education, the stakes are high. With platforms that are deeply integrated, “it’s part of your daily academic operations,” says Walt Powell, lead field CISO at CDW. “Students use it for assignments and messaging and course materials. When a platform like that is disrupted or compromised, it affects instruction, communications, trust and privacy.”

The Canvas data breach points to a systemic gap. “Many institutions have spent years securing their front door while leaving the loading dock wide open,” says Fadi Fadhil, field CIO and director of field strategy at Palo Alto Networks. Behind the scenes, universities rely on hundreds of Software as a Service (SaaS) platforms that are deeply integrated, and that creates new vulnerabilities.

The bottom line: “Software vulnerabilities are always a risk, and that risk is higher now due to the ability of threat actors using AI,” says Jeremy Kirk, a director on the Okta threat intelligence team. 

DISCOVER: Learn how to govern unsanctioned shadow data to remain FERPA-compliant. 

Building a Vendor Vetting Framework: What To Require Before Onboarding a Platform

A strong approach to third-party vendor risk management includes vetting potential partners thoroughly. “A good vendor assessment should be treated like a business process, not a procurement checkbox,” Fadhil says. “The goal is to understand not just the product but the ecosystem it creates.”

To that end, Powell proposes a series of key questions that cover visibility and clarity around incident remediation, such as: 

• Where does the data live? 
• What data will live there? 
• How does identity and access work: Does the platform support single sign-on, MFA and role-based access? 
• Will we have privileged access? 
• How does the platform integrate with the rest of the environment? Will we get logs? 
• Will we be able to review admin activity or application programming interface (API) activity?
• What happens when something goes wrong? 
• What’s the notification policy? 
• How fast will you notify me? 
• What information will you provide?

EXPLORE: Find a checklist for comprehensive third-party vendor readiness.

Contractual Safeguards and SLA Requirements That Protect Institutions When Vendors Fail

For robust SaaS security, colleges and universities should be looking to implement contractual safeguards.

At a high level, “contracts should assume that incidents will happen,” Fadhil says. “At a minimum, institutions should require clear breach notification timelines, defined responsibilities during incident response, logging retention requirements, forensic cooperation, security audit rights, and expectations around identity management and API security.”

Universities should be asking for clear breach notification timelines. “How quickly after discovering a situation are you going to report this stuff to us, and how thoroughly are you going to report specific information about impacts to specific institutions?” Powell says.

Service-level agreements should also be spelled out in detail. “The SLAs are important because uptime is not just a technical metric. It affects the outcomes of assignments and finals and grades — the whole 9 yards,” he says.

How To Audit Existing Vendor Dependencies and API Key Exposures

To understand the third-party risk, schools need insight into their existing vendor dependencies and API key exposures. “Keeping an up-to-date asset management registry is critical,” Kirk says.

“This has never been more true than in an AI age, where you think of AI agents almost as a super-application in your system that access resources. You are going to want to know who has access to which applications, and what their access is,” he says.

This doesn’t have to be a big lift. “You could literally just create an Excel-based exposure register,” Powell says. “I’d be looking for data, systems, credentials and owners. How are we plugging in the data, what systems are connected, what credentials are used as far as API keys and privilege access, and then, who owns what?”

Such an inventory should assess all third-party connections, Fadhil says. It should look to identify every SaaS application in use, every API integration, every service account and long-lived token, as well as “who owns them and whether they are still needed,” he says.

Communicating With Faculty and Students During a Vendor Security Incident

Even with the right protections in place, a third-party breach can still happen. Schools need to respond effectively. People can handle bad news, but “they don’t handle uncertainty very well,” Fadhil says. “Communications should be timely, transparent and focused on actions.”

There’s a balance to be struck here. University CISOs and IT teams need to keep faculty and students informed. At the same time, “nobody wants to give inaccurate information,” Kirk says, and it can take a while to understand the nature of a breach.

LEARN: See how training your higher ed cybersecurity team supports your security strategy.

To be both transparent and responsible, “it’s perfectly acceptable to say, ‘These are the things that are confirmed so far, this is the stuff we don’t quite know about yet,’” Powell says. At the same time, universities should be giving practical advice — like UW-Madison’s warning to watch out for phishing messages.

Higher education institutions such as Yale University, Rutgers University, UC Berkeley and the University of Colorado leaned into swift, proactive and transparent communications once they learned about the breach. 

IT leaders can also offer guidance around continuity, answering questions such as, “How should you do your assignments, your exams, your grades? Who can approve extensions? Where should we post updates?” Powell says. 

In addition to building trust and transparency, practical information like that can help a university community to ride out a disruption — even one with a deeply integrated third-party platform.