What Happened
In late April and early May 2024, Instructure confirmed a cyberattack on its Canvas Learning Management System. The threat group ShinyHunters claimed responsibility, stating they exfiltrated 3.65TB of data affecting 275 million users across nearly 9,000 schools. By May 11, Instructure announced it had "reached an agreement" with the attackers and declared the platform safe to use.
Shortly after, ShinyHunters claimed additional attacks targeting higher education institutions through vulnerabilities in Oracle PeopleSoft software suites, which many schools use for student records, admissions, and financial aid management. Google noted that while some organizations patched the vulnerabilities in time, others were compromised and had their data published on leak sites.
The Canvas attack occurred during finals week, compounding operational disruption across affected institutions.
Timeline
Late April 2024: Initial compromise of Canvas Learning Management System
Early May 2024: Instructure confirms breach; ShinyHunters claims 3.65TB data theft
May 11, 2024: Instructure announces agreement with attackers, declares platform safe
Following weeks: ShinyHunters claims additional attacks via Oracle PeopleSoft vulnerabilities; compromised data appears on leak sites
Which Controls Failed or Were Missing
This incident exposes failures across multiple control domains:
Supplier security assessment: There's no evidence Instructure underwent rigorous security evaluation before deployment at scale across thousands of institutions. The concentration risk alone, nearly 9,000 schools dependent on a single platform, should have triggered enhanced due diligence.
Vulnerability management: The PeopleSoft attacks demonstrate that known vulnerabilities remained unpatched across multiple institutions. Google's observation that some organizations remediated while others were compromised indicates inconsistent patch management practices.
Incident response coordination: The phrase "reached an agreement" suggests ransom negotiation, yet there's no public evidence of coordinated response across the 9,000 affected institutions. Each school likely handled notification and remediation independently, multiplying effort and cost.
Contractual security requirements: The absence of strong procurement leverage meant educational institutions couldn't enforce meaningful security terms. Vendors face minimal contractual liability for breaches affecting their customers.
Monitoring and detection: The scale of exfiltration (3.65TB) suggests the attack went undetected long enough for threat actors to extract massive data volumes. Real-time monitoring of abnormal data flows was either absent or ineffective.
What the Relevant Standards Require
ISO/IEC 27001:2022 Annex A Controls
A.5.19 (Information security in supplier relationships): Organizations must identify and document information security risks associated with supplier access to assets. This includes defining security requirements in supplier agreements and monitoring supplier security practices.
For educational institutions, this means you can't simply accept vendor-provided security attestations. You need documented risk assessments that account for the sensitivity of student data, the vendor's role in your operations, and the concentration risk if you're sharing a platform with thousands of other institutions.
A.5.20 (Addressing information security within supplier agreements): Security requirements must be established and agreed with each supplier based on the type of supplier relationship. This includes defining incident notification procedures, security testing rights, and liability terms.
The Canvas incident demonstrates what happens when these terms are missing. Schools had no contractual mechanism to demand real-time breach notification, no right to audit Instructure's security controls, and limited recourse for the operational disruption during finals week.
A.5.23 (Information security for use of cloud services): Organizations must establish processes for managing information security risks associated with cloud service use. This includes understanding shared responsibility models and ensuring cloud providers implement appropriate controls.
Educational institutions using Canvas as a cloud-based LMS needed clear documentation of which security controls Instructure owned versus which controls remained the school's responsibility. The breach suggests this boundary was poorly defined.
A.8.8 (Management of technical vulnerabilities): Organizations must obtain timely information about technical vulnerabilities of information systems in use, evaluate exposure, and take appropriate measures.
The PeopleSoft attacks show this control failing at scale. Multiple institutions using the same software failed to patch known vulnerabilities before exploitation. This isn't just a vendor problem, it's an asset management and patch prioritization problem for each affected school.
SOC 2 Trust Services Criteria
CC9.1 (Vendor management): The entity identifies, assesses, and manages risks associated with vendors and business partners. This includes defining vendor performance standards and monitoring vendor compliance.
Schools need documented vendor risk assessments that consider the vendor's security posture, the criticality of the service, and the sensitivity of data the vendor processes. A learning management system handling 275 million user records should trigger your highest tier of vendor scrutiny.
CC7.2 (Security incident detection and response): The entity monitors system components and the environment for anomalies and indicators of compromise. For vendors processing your data, this means contractual requirements for the vendor to notify you of security incidents within defined timeframes.
The "reached an agreement" timeline suggests schools learned of the breach through public disclosure, not direct vendor notification. Your vendor contracts should specify notification within 24-72 hours of incident discovery, not weeks later.
Lessons and Action Items for Your Team
Immediate Actions
Inventory your vendor concentration risk: Document which vendors have access to sensitive data and how many users each vendor supports. If a single vendor breach would affect more than 20% of your user population, you have a concentration risk that requires enhanced controls.
Review vendor contracts for security terms: Pull your agreements with critical vendors and look for these clauses: incident notification timelines, your right to audit or review SOC 2 reports, liability caps, and security testing requirements. If these terms are missing, flag the contracts for renegotiation at renewal.
Map your vendor patching dependencies: For software like PeopleSoft that you deploy on-premises or in your cloud environment, document the patching process. Who monitors for new vulnerabilities? What's your SLA for applying critical patches? If you're relying on vendor notifications, you're already behind.
Strategic Changes
Build procurement leverage through collective action: Individual school districts can't negotiate strong security terms with major vendors. But state-level purchasing consortia or regional education cooperatives can. Work with peer institutions to define minimum security requirements for edtech vendors and present them as a unified buying group.
Require evidence, not attestations: When vendors claim they're "secure," ask for their SOC 2 Type II report, penetration test results, and vulnerability disclosure policy. Review the report's scope, does it cover the specific services you're using? Are there complementary subservice organization controls that shift responsibility back to you?
Define your vendor risk tiers: Not every vendor requires the same scrutiny. Create a three-tier system based on data sensitivity and operational criticality. Tier 1 vendors (like your LMS or student information system) require annual SOC 2 review, quarterly security discussions, and contractual liability terms. Tier 3 vendors (like your cafeteria scheduling software) need basic due diligence but not continuous monitoring.
Test your incident response for vendor breaches: Run a tabletop exercise where your primary LMS is compromised during finals week. Who makes the decision to continue using the platform? How do you communicate with students and parents? What's your legal notification obligation? The Canvas incident shows that vendor breaches create operational crises, not just technical ones.
Document your shared responsibility model: For every cloud service, create a one-page document that answers: What security controls does the vendor implement? What controls are your responsibility? What happens if the vendor's controls fail? This clarity prevents finger-pointing during an incident and helps you design compensating controls where vendor coverage is weak.
The Canvas breach didn't happen because educational institutions ignored security. It happened because the procurement relationship between schools and edtech vendors is structurally unbalanced. You can't audit your way out of that power dynamic, but you can use ISO/IEC 27001 and SOC 2 requirements to build a paper trail that demonstrates you demanded better security terms, even if the vendor refused. When the next breach happens, and it will, that documentation matters.
