You Can Be Compliant and Still Be Unsafe

In December 2024, PowerSchool suffered a credential-based breach that exposed sensitive student and staff data across thousands of North American school districts. The attacker didn’t defeat a sophisticated defence. They used a stolen credential to walk through a customer support portal that had no MFA in place.

PowerSchool held industry-standard compliance certifications at the time of the breach. Those certifications didn’t fail. They performed exactly as designed. That’s the problem.

Compliance is not safety. It never was. And the organizations that treat them as interchangeable are operating on a false picture of their own exposure.

What Compliance Really Measures

A compliance audit (SOC 2, ISO 27001, PCI DSS) is a process verification exercise. An auditor reviews whether your organization has defined the right controls, documented them correctly, and produced evidence they were followed during the audit period.

That’s a meaningful exercise. It forces documentation discipline, accountability structures, and risk awareness. EliteSec holds ISO 27001:2022 certification and has worked through the audit process from both sides. The value is real.

But a passing audit answers a specific question: does a security program exist and is it documented? It does not answer whether that program stops an attacker. Those are different questions, and conflating them is where organizations get into trouble.

PowerSchool’s compliance certifications confirmed their program existed. They said nothing about whether a support portal had been left outside the MFA enforcement boundary. Auditors sample. They review policy. They don’t probe what happens when controls are stressed, combined in unexpected ways, or simply missing from a corner of the environment no one thought to check.

What Penetration Testing Adds, and Where It Stops

A penetration test is an adversarial exercise. Its purpose is to find out whether controls hold under pressure, not to confirm they exist.

A skilled tester chains together findings that each look minor in isolation: a misconfigured permission, an overly broad service account, a forgotten endpoint without MFA. Individually, none would fail a compliance audit. Together, they form a complete path from unauthenticated access to data exfiltration.

That’s the dimension compliance doesn’t cover. Adversarial testing surfaces what documentation reviews cannot.

But a pen test is also a point-in-time exercise against a system that keeps changing. New integrations, new vendors, new staff, new infrastructure. The environment you tested in January may look materially different by June. And a finding that gets logged, patched, and closed in a tracker without anyone verifying the fix actually holds has accomplished nothing except cleaner paperwork.

The pen test finds the gap. It doesn’t close it. And it doesn’t ask why the gap existed or whether the process that created it is still running.

The Two Dimensions Both Instruments Miss

Process integrity. PowerSchool’s breach wasn’t just a missing MFA toggle. It reflects a process that allowed a support portal to exist outside the standard access control review cycle. You can remediate the finding and leave the factory that produced it untouched. Neither a compliance audit nor a pen test forces the harder question: what in our operating model created this exposure, and have we actually changed it?

Human behavior. A compromised credential entering through a support portal is as much a people problem as a technical one. Phishing, credential reuse, poor password hygiene — these are the conditions that enabled PowerSchool’s breach. Compliance frameworks typically require evidence that security training happened. They don’t test whether it changed behavior. Penetration tests don’t model social engineering unless it’s explicitly scoped. The human layer is the one both instruments handle least well, and it’s consistently where breaches begin.

A More Complete Picture

Compliance, penetration testing, process integrity, and human behavior aren’t alternatives to each other. They’re each measuring a different dimension of the same question: are we actually secure, or do we just have documentation that says we are?

Organizations that stop at compliance have answered one dimension and called it done. Organizations that add penetration testing have answered two. The ones operating at a genuinely different posture are asking all four questions — and treating the answers as a system, not a checklist.

The board conversation worth having isn’t “are we certified?” It’s “what does our certification not cover, and what are we doing about it?”

PowerSchool was certified. The attacker didn’t care.

---

If you’re not sure what your compliance certification doesn’t cover, that’s the right question to be asking. Get in touch and we’ll help you find out.