Evinact Associate Baden Hughes explains why the Instructure/Canvas data breach has exposed a gap in vendor cybersecurity due diligence that most procurement frameworks don’t address.
When you last went through a vendor procurement process, did you check whether the vendor would pay a ransom if they were hacked? Would it have changed your view if you thought they would pay up under pressure?
On 29 April, learning management system vendor Instructure “detected unauthorized activity in Canvas”. Instructure said it “immediately revoked the unauthorized party’s access, started an investigation, and engaged outside forensic experts.”
Then again on 7 May, the same threat actor gained additional access through a second Canvas vulnerability.
This incident was widely reported. Instructure holds around 40% market share in North America, and is a significant provider to Australian and New Zealand education institutions too. Analysis suggests this is the largest educational security breach on record, exposing data from approximately 275 million users across 8,800 institutions worldwide.
On 11 May, Instructure confirmed it had made an arrangement with ShinyHunters, the group that breached Canvas twice in ten days. In return, the company received what it called “digital confirmation of data destruction” – shred logs – and a written assurance that “no Instructure customers will be extorted as a result of this incident.”
Institutions, teachers and students were on the wrong end of that transaction. Apparently none of them were consulted about this course of action
In Australia, RMIT, UTS, Western Sydney University and TasTAFE are among the education institutions now working through what data of theirs was caught up in the breach. For most, that work follows a familiar pattern: assess exposure, meet notification obligations under the Privacy Act, brief executive, brief students, engage legal and insurance providers, and hope the regulator agrees the response was reasonable.
That pattern is necessary, but it isn’t sufficient. The Instructure/Canvas incident has surfaced a question that almost no procurement or vendor management function in education is actually asking: what is the propensity of this vendor to pay a ransom, and if they do, what does it tell us about our data and our confidence in their security?
What do “shred logs” actually prove?
Nothing in the way that matters.
A deletion confirmation from a criminal organisation isn’t evidence of data destruction. It’s a representation by a counterparty whose business model is built on gaining and holding leverage. ShinyHunters has been linked to breaches at Penn, Princeton and Harvard in the last twelve months alone; the idea that they have now permanently deleted ~275 million records deserves the cynicism it has been greeted with.
The operational reality is simple. Once data leaves an organisation’s perimeter, they can’t get it back. You can only get a promise that it won’t be used. Instructure has bought a promise. That promise has been wrapped in the language of technical control – “shred logs” – and presented as resolution. It isn’t.
The due diligence signal you were given for free
Set aside the ethics of paying a ransom for a moment. The decision to come to an agreement tells you things about the vendor you didn’t have to ask for.
A vendor that pays up after a breach has, at minimum, signalled the following:
- that its recovery position was insufficient to absorb the operational and reputational cost of refusal;
- that someone in the organisation has the authority to authorise a payment of that scale, on that timeline, presumably with an insurer underwriting it and lawyers assuring it;
- that its decision-making under duress prioritises commercial continuity over the risk transfer that ransom payments create for the rest of the ecosystem.
None of these are inherently disqualifying. But all are material to your assessment of the vendor’s posture, and almost none of them appear in standard education sector or wider commercial and public sector procurement questionnaires from our experience. Even vendors who bring information security certifications to the table don’t provide an answer to these questions.
The Instructure/Canvas incident handling tells you something, too. The first ransom demand was reportedly ignored. Canvas was “patched” and brought back online. The hackers then breached the system a second time, suggesting either that remediation was incomplete or that the original exposure was never fully understood.
That’s a useful data point for any education institution still relying on the vendor’s first-incident communications and remediation effectiveness as the basis for its own risk assessment.
A regulatory exposure that now travels with the vendor
There’s also a piece of the Australian regulatory landscape that hasn’t been fully absorbed into vendor due diligence yet.
Since 30 May 2025, Part 3 of the Cyber Security Act 2024 requires entities carrying on business in Australia with an annual turnover above $3 million – and all critical infrastructure responsible entities – to report ransomware or cyber extortion payments to the Australian Signals Directorate within 72 hours, including any payments made on their behalf.
Every Australian university comfortably clears the $3 million threshold; some are specifically critical infrastructure entities under the SOCI Act by virtue of their research infrastructure and programs.
The reporting obligation isn’t the issue on its own. The issue is a now-explicit national policy expectation that ransom payment is a regulated event, not a private commercial choice. A vendor’s payment posture is no longer just a question of values. It’s part of the regulatory environment your institution is being asked to operate in.
What to actually ask in vendor due diligence
Existing procurement frameworks cybersecurity sections are built around the probability of an incident and the distribution of obligations that flow from one. They’re not built around the question of what your vendor will do when it’s been compromised and is under time or commercial pressure.
A more defensible assessment, for any provider holding student or staff personal information at scale, should at minimum address:
- Vendor’s written ransom payment policy: Does one exist? Has it been signed off at board level? Who has authority to invoke it, and within what dollar thresholds?
- Customer consultation obligations: Will the vendor consult affected customers before agreeing to pay, or simply notify them after the fact? Instructure/Canvas customers learned about the decision when the deal was already done.
- Sanctions and reporting exposure: Has the vendor mapped the jurisdictions in which it would or would not pay, and how it manages OFAC and equivalent screening before a payment? Australian ransomware reporting timelines compress the negotiation and screening window further.
- Vendor’s solution recovery position: What is the documented RTO and RPO for the systems holding your data, and what evidence supports it? A credible recovery position and data defenses narrows the rational case for payment. The absence widens it.
- Insurance language: Does the vendor’s cybersecurity insurance policy cover ransom payment, and on what conditions? Insurance underwriters have increasingly hard-coded payment behaviour into policy wording. That language is now part of your supply chain risk, whether you’ve read it or not. Does your own cybersecurity insurance policy consider ransom payment by your institution or your suppliers? Does your cybersecurity insurance provider?
None of this prevents a breach. But it does change what you know about the vendor before one occurs, and what optionality you preserve when one does happen.
The decision was made for you
The most uncomfortable feature of the Instructure/Canvas incident isn’t that data was exfiltrated. It’s that a vendor with around 40 per cent market share in North American higher education made an apparently unilateral decision that transfers risk to every institution that uses its solutions.
Customers did not consent. Customers cannot verify. Customers will, however, carry the trust consequences when the next ShinyHunters letter arrives, whether at Instructure or one of its peers.
Procurement and vendor management functions exist, in part, to protect institutions from precisely this kind of inherited decision. At Evinact, we work with organisations to make that protection real, through better procurement policies, independent assurance, and contract frameworks that ask the hard questions before a press release forces the issue.
If you’d rather have those answers before your next vendor cybersecurity incident, get in touch.
