Third-Party Vendor Risk: What the PowerSchool Breach Reveals About the SaaS Exposure Inside Your Business

The 2025 PowerSchool breach exposed tens of millions of student and staff records – names, Social Security numbers, medical information – through a single compromised credential at a widely trusted software vendor. Most of the affected organizations had done nothing wrong internally. Their networks were intact. Their own passwords were fine. The breach happened inside a system they paid for and trusted but never formally audited. That is the definition of third-party vendor risk. And it is not a school district problem. The odds are high that your business is carrying the same exposure right now.

1. What Happened with PowerSchool
2. Why This Is a Small Business Problem, Not Just an Education Problem
3. The SaaS Blind Spot: Trust Without Verification
4. What Third-Party Vendor Exposure Actually Looks Like
5. What a Well-Run IT Environment Has in Place
6. Steps You Can Take to Reduce Third-Party Vendor Risk Now
7. The One Question Every Business Owner Should Ask Today

What Happened with PowerSchool

PowerSchool is a cloud-based student information system used by thousands of school districts across North America. In early 2025, attackers gained access to its customer support portal using a single set of stolen credentials. From there, they pulled records on students and teachers across dozens of districts – data those districts had no reason to believe was at risk, because the breach did not originate inside their own walls.

The attacker did not exploit a firewall vulnerability. They did not phish a teacher or administrator. They walked in through the vendor’s door using a key that should have been far better protected. Early disclosures indicate that basic controls – including multi-factor authentication – were either absent or inconsistently enforced on the compromised portal.

The result: a cascading exposure event affecting millions of people, caused by decisions made – or not made – by a vendor, not by the organizations that trusted them. This is precisely why third-party vendor risk deserves formal attention in every organization’s security program.

Why This Is a Small Business Problem, Not Just an Education Problem

It is tempting to read a story about school districts and conclude it does not apply to your business. That would be a mistake. The structural problem here – trusting a vendor with sensitive data without ever auditing their security – is one of the most common blind spots in small and mid-sized businesses today.

Think about the software your business runs on every day. A cloud accounting platform. A payroll processor. A CRM holding years of client contact data. An HR system with employee records. A project management tool where confidential client deliverables live. Each of those vendors holds data that matters to your business, your clients, and potentially your regulatory standing.

Have you ever asked any of them for a security questionnaire? Reviewed their certifications? Confirmed whether they enforce multi-factor authentication on administrative access? Most small businesses have not – not because they are careless, but because no one told them this was their responsibility.

The Cybersecurity and Infrastructure Security Agency (CISA) has been sounding alarms about software supply chain and third-party vendor risk for years. The PowerSchool breach is the most visible recent proof point.

The SaaS Blind Spot: How Third-Party Vendor Risk Hides in Plain Sight

There is a quiet assumption baked into most software purchasing decisions: if a vendor is big enough, well-known enough, or expensive enough, their security must be adequate. PowerSchool served millions of users across some of the largest school districts in the country. That scale, that adoption, that apparent legitimacy – none of it protected their customers when internal controls failed.

This is the SaaS blind spot. Decisions to adopt new platforms run through procurement, finance, and maybe legal. Security review – when it happens at all – is usually a checkbox on a vendor signup form asking the vendor to self-attest to their own practices. Self-attestation is not a security control. It is a formality.

For small businesses, the risk compounds with the sheer volume of tools in the stack. A 20-person firm might run 15 to 25 distinct cloud services. Each one is a trust relationship. Each one is a potential entry point. And very few were formally vetted before the first invoice was paid.

What makes this particularly tricky is that third-party vendor risk is not just about whether the vendor gets breached. It is also about what they can access on your behalf, what data they retain after you stop using them, how they handle their own subcontractors – sometimes called fourth-party risk – and whether their incident response plan would notify you quickly enough to matter.

What Third-Party Vendor Exposure Actually Looks Like

Here are the categories of exposure that typically go unexamined in small businesses:

• Credential sharing and access sprawl: Many platforms issue admin credentials that are shared across a team, rotated rarely, and never tied to multi-factor authentication. One compromised credential – at the vendor level or through a phishing attack on your side – gives an attacker full access.
• Data retention you did not agree to: Vendors often retain client data long after a contract ends, in backup systems or data stores that may have weaker controls than the primary platform. You may not know your data still exists there.
• Subprocessors you never heard of: Most platforms use their own third parties – cloud infrastructure, support tools, analytics services. Your vendor’s privacy policy may technically disclose these, but almost no one reads far enough to find them.
• No breach notification timeline in the contract: If a vendor is breached and your data is involved, how quickly are they required to tell you? Many vendor contracts have no meaningful deadline – and some have clauses that significantly delay disclosure.
• Compliance obligations that travel with your data: If you are subject to HIPAA, or if clients impose security requirements on you, a vendor-originated breach may not reduce your liability. You agreed to protect that data. Where it lives does not change the obligation.

What a Well-Run IT Environment Has in Place

A well-run IT environment does not just secure what sits inside your network. It extends accountability to every vendor your business depends on. Here is what that looks like in practice.

A vendor inventory that is actually maintained. You cannot manage risk you cannot see. A current list of every platform, service, and tool your business uses – with the data each one touches – is the foundation. Most businesses are surprised by how long that list turns out to be.

Security questionnaires for high-risk platforms. Not every tool requires the same level of scrutiny. But any platform that holds sensitive client data, employee records, financial information, or access to your core systems should be able to answer basic questions about their certifications, access controls, and incident response procedures. Asking is not adversarial – it is standard practice for any serious business relationship.

Contract language that protects you. Breach notification timelines, data deletion requirements, subprocessor disclosure, and liability terms are all negotiable – especially at renewal. Many businesses sign vendor agreements without anyone reviewing the data security clauses. A well-run environment means someone is reading those terms.

Multi-factor authentication enforced everywhere. The PowerSchool breach came in through a compromised credential. Multi-factor authentication would not have guaranteed prevention, but it would have raised the cost of that attack significantly. Every platform your team accesses should have it enabled and enforced – not left optional.

Regular review, not a one-time check. Vendor relationships change. A vendor with a strong security program when you signed two years ago may have since gone through an acquisition, a leadership change, or a cost-cutting round that reduced their security investment. Periodic review – even annually – catches drift before it becomes a breach.

This is the kind of work that a well-structured managed IT program builds into the operating model, rather than leaving it as an ad hoc task that never reaches the top of the list.

At Xact IT, this has been part of how we operate across every client relationship since 2004. Zero client breaches in 22 years is not accidental – it is the result of treating the extended vendor environment as part of the security perimeter, not separate from it.

Steps You Can Take to Reduce Third-Party Vendor Risk Now

Knowing the problem exists is the first step. Acting on it is what separates businesses that get ahead of third-party vendor risk from those that discover it after a breach. Here is a practical sequence any organization can start this week.

Step 1 – Build your vendor inventory. List every cloud tool, platform, and external service your business uses. Note what data each one touches: client records, employee data, financial information, intellectual property. This list becomes the map for everything that follows.

Step 2 – Tier your vendors by risk. Not every tool carries the same exposure. A vendor with access to payroll data or client health records is a Tier 1 risk. A tool your team uses for internal polls is not. Focus scrutiny on the high-stakes relationships first.

Step 3 – Send security questionnaires to Tier 1 vendors. Ask about their certifications (SOC 2, ISO 27001), breach notification timelines, multi-factor authentication enforcement, and subprocessor practices. Reputable vendors expect these questions. Vendors who resist or deflect them are telling you something important.

Step 4 – Review your contracts. Pull the data security, breach notification, and data deletion clauses from your top vendor agreements. If you cannot find them, that is your answer. Flag these for revision at the next renewal.

Step 5 – Enforce multi-factor authentication across every platform. Audit each platform your team accesses and confirm that multi-factor authentication is not just available but required. This single control would have significantly complicated the PowerSchool attack.

Step 6 – Schedule an annual vendor review. Put it on the calendar now. Vendor risk does not stay static – it accumulates quietly. An annual review keeps it visible. For a broader cybersecurity framework, the NIST Cybersecurity Framework provides a vendor-neutral structure that scales to organizations of any size.

If your team does not have the bandwidth to own this process internally, our cybersecurity services are built to make vendor risk management an embedded, ongoing function – not a project that stalls before completion.

The One Question Every Business Owner Should Ask Today

Here is the most useful thing you can take from the PowerSchool story: if one of the software vendors your business uses right now suffered a breach tonight, would you know by morning? If the answer is no – or “only if they decide to tell me” – that is the gap worth closing.

The breach did not reach PowerSchool’s customers because those organizations were negligent. It reached them because the structure of modern software-as-a-service creates inherited third-party vendor risk that most organizations never formally acknowledge. School districts, physician practices, professional services firms, financial advisors, non-profits – the industry does not matter. If you use cloud software, you carry third-party vendor risk. The only real question is whether it is managed or invisible.

Most of the businesses we work with came to us after a near-miss or a moment of recognition – not after a catastrophic event. The ones who avoid the catastrophic event are the ones who asked the right questions before something forced the answer.

If you want a direct conversation about where your vendor exposure stands, Book a Free Cybersecurity Strategy Call. Twenty minutes. No pressure. Just clarity.