What Happened
Canvas, the world's most widely used Learning Management System (LMS), suffered a major cyberattack orchestrated by the hacker group ShinyHunters. The group exploited a vulnerability in Canvas's "Free-For-Teacher" account programme — a feature with relatively loose permission controls — and used it as a launchpad to move laterally into Instructure's core servers.
The scale of the breach was staggering:
- Approximately 3.65TB of data stolen
- 8,809 schools affected globally, including Harvard, MIT, Stanford, Columbia, and Princeton
- An estimated 230 to 275 million users impacted
- Data compromised included student names, email addresses, student IDs, course enrolment information, and billions of private messages
The breach forced Instructure to take Canvas offline on 7 May. Numerous universities — in the middle of their final examination period — were left scrambling. Exams were postponed. Instructors hunted for students' personal email addresses. Academic calendars were disrupted across North America, Europe, Asia, and beyond.
On 11 May, Instructure announced it had reached an agreement with ShinyHunters. The hackers returned the data and provided digital certificates of destruction. Whether a ransom was paid was not disclosed. Even so, Instructure acknowledged it could not provide a 100% guarantee that all copies of the data had been permanently deleted.
The Most Uncomfortable Truth: Canvas Had the Certifications
Here is where the story becomes particularly instructive for security and privacy professionals.
Instructure was not an organisation that had ignored information security. Quite the opposite. At the time of the breach, Instructure held:
- ISO 27001 certification (renewed annually, covering Canvas LMS)
- SOC 2 Type II attestation
- PCI DSS 4.0 compliance
- Regular internal and external audits against NIST 800-53 and OWASP Top 10
On paper, this is an impressive compliance portfolio. And yet, the breach happened — and according to ShinyHunters, it was not even the first time they had accessed Instructure's systems. The hackers stated explicitly that a previous intrusion had been discovered, patched over, and left uninvestigated.
So how do we make sense of this?
Three Lessons the Industry Cannot Afford to Ignore
A Certificate Covers What Is in Scope — Not What Is Left Out
ISO 27001 requires organisations to define the scope of their Information Security Management System (ISMS). The standard demands that all information assets within that scope are identified, risk-assessed, and protected. However, the depth of coverage — particularly for peripheral or lower-visibility features — depends heavily on how rigorously the scope is defined and how thoroughly the audit is conducted.
The Free-For-Teacher programme was a product feature with relaxed access controls. It is precisely these kinds of "edge features" that tend to receive less scrutiny during audits, yet represent exactly the kind of overlooked entry point that sophisticated attackers seek out.
A meaningful audit does not stop at the obvious. It asks: What are we not looking at? What do we assume is low risk?
Least Privilege Is a Principle, Not a Checkbox
ISO 27001 Annex A explicitly requires access controls to follow the principle of least privilege — users should have only the access necessary to perform their function, nothing more. In this case, a Free-For-Teacher account provided enough access to allow lateral movement into core production systems.
This is not a failure of the standard. It is a failure of implementation. Having a policy that states "we follow least privilege" is not the same as systematically verifying, at every level of the system, that excessive permissions do not exist.
Incident Response Requires Root Cause Analysis, Not Just Patching
Perhaps the most critical lesson from this breach is what happened — or rather, what did not happen — after the first intrusion.
ShinyHunters explicitly stated that Instructure had previously detected an unauthorised intrusion, applied a security patch, and moved on without contacting the attackers or conducting a thorough root cause investigation. Patching the immediate vulnerability is necessary. But it is only the first step. A robust incident response process requires understanding why the vulnerability existed, what else may have been accessed, and whether the threat actor is entirely out of the environment.
Skipping root cause analysis does not close an incident. It postpones it.
Educational Institutions Also Bore the Impact
It is worth noting that universities and institutions using Canvas had no direct control over the vulnerability that was exploited. The compromise happened on Instructure's infrastructure, not within the schools' own systems.
This is the reality of the modern technology landscape: organisations are only as secure as the weakest point in their supply chain.
For educational institutions — and indeed any organisation that relies on third-party SaaS platforms — this breach is a reminder to ask harder questions during vendor procurement:
- Does your vendor's certification scope cover the features and data that are most relevant to you?
- What contractual obligations exist if the vendor suffers a breach involving your users' data?
- Have you conducted a Security Risk Assessment & Audit to evaluate the actual security posture of your key vendors, beyond simply reviewing their certificates?
- Have you performed a Privacy Impact Assessment (PIA) to understand what data you are placing with each vendor and what the consequence of its exposure would be?
A vendor holding an ISO 27001 certificate is a starting point, not an endpoint. It tells you that a management system exists. It does not tell you how deeply it is embedded across every feature, every team, and every third-party integration.
Turning the Lens Inward: What Would Have Made a Difference?
Mapping the Canvas breach against established frameworks reveals exactly where gaps existed and where interventions could have changed the outcome:
| Framework | What It Should Have Caught |
|---|
| ISO 27001 (access control, Annex A) | Excessive permissions on Free‑For‑Teacher accounts |
| Penetration Testing | Lateral movement pathways from low‑privilege accounts into core systems |
| Security Incident Response | Root cause analysis after the first intrusion; full threat actor eviction |
| Security Risk Assessment & Audit (SRAA) | Schools evaluating Instructure’s system security posture and privilege segregation before deployment |
| Privacy Impact Assessment (PIA) | Schools limiting the volume and sensitivity of student data stored on the platform |
| ISO 27701 | Structured obligations around personal data exposure, notification timelines, and regulatory reporting |
None of these frameworks are theoretical. Each one, properly implemented, represents a point at which this breach could have been detected earlier, contained faster, or its impact significantly reduced.
The Real Value of Certification: Process, Not Paper
At DQS, we conduct more than 200 audits every day across 60 countries. In four decades of doing this work, one pattern appears consistently: the organisations that get the most from certification are not those that treat it as an annual compliance exercise. They are the ones that treat the audit as a genuine opportunity to find what they have not found themselves.
This is the philosophy behind how DQS audits are conducted — and it is what distinguishes a rigorous audit from one that simply confirms documentation exists.
Our auditors are not checklist-runners. They are practitioners — engineers, computer scientists, legal experts, and security professionals — matched to each client based on sector-specific experience. Before we arrive, we invest significant time identifying the right auditor for your organisation, because the depth of an audit depends entirely on the quality of the professional dialogue it generates.
Critically, our process does not stop at what is documented. The system analysis examines what is described. The on-site system audit examines what is actually implemented — across every process, every team, and every feature that touches sensitive data. A peripheral account programme with excessive permissions, like the Free-For-Teacher accounts that gave ShinyHunters their entry point, would not pass unexamined in a DQS audit. That is precisely the kind of gap our auditors are trained to surface.
After every audit, an independent technical review is conducted by DQS's certification board — a second layer of scrutiny that ensures no significant non-conformity is overlooked before a certificate is issued.
This rigour has a cost. DQS is not the lowest-priced certification option in the market. But the Canvas breach illustrates precisely what under-examined certification looks like in practice: a full compliance portfolio, a vulnerability that persisted across two separate intrusions, and a breach that ultimately exposed 275 million people's personal data.
Certificates confirm that a system exists. Rigorous, independent auditing confirms that the system works — in every corner of the organisation, not just the ones that are easy to audit.
Final Thought
The 2026 Canvas breach will be studied for years as the largest data breach in the history of the education sector. Its scale is unprecedented. But its causes are not.
A peripheral feature with loose access controls. A least-privilege principle applied inconsistently. An incident closed without root cause analysis — and exploited again eight days later.
These are not exotic failure modes. They are the everyday gaps that robust information security management — properly implemented and independently verified — exists to close.
The question every organisation should be asking right now is not *"Do we have the certificate?" but "Does our certificate reflect the reality of how we actually operate?"