Data breaches don’t usually come from one big, dramatic failure.
More often, they happen because of a series of smaller decisions that didn’t feel risky at the time. Access gets granted and never reviewed. An integration is set up quickly to solve a problem and then left in place. Old data sticks around because no one is quite sure when it’s safe to delete it.
None of these things stand out on their own, but together they create exposure. The practices in this guide have been gathered from across the education and assessment sector, reflecting what we see working well in organisations that take data security seriously.
Recent incidents across the education and assessment sector have reinforced how important it is to look beyond the core platform itself and examine the wider ecosystem around it. Integrations, access controls, operational processes, and third-party tools all introduce potential points of risk if they are not actively reviewed and managed.
For organisations working in education and assessment, the impact is higher than most. The data involved is often tied to academic progress, professional standing, and future opportunities, which raises the importance of getting security and governance right.
Where the Real Risks Sit
One of the biggest misconceptions is assuming the core platform is always the weak point. Increasingly, risk sits in the surrounding ecosystem.
That includes:
- Integrations with third-party tools
- APIs and access tokens
- Identity providers and SSO configurations
- Support access and internal permissions
- Staging or testing environments
- Legacy systems that are still connected
Modern EdTech environments are rarely a single system. Most organisations rely on a network of connected platforms exchanging data across the assessment lifecycle. LMS platforms, assessment software, proctoring services, analytics tools, accessibility tools, CRMs, payment systems, and identity providers all play a role.
As these ecosystems become more interconnected, the potential attack surface grows beyond the core platform itself. A weak integration, an overlooked access token, or a third-party service with excessive permissions can all create unintended pathways into wider systems and data.
Industry reporting increasingly reflects this. Third-party involvement is now a significant factor in many breaches, while compromised credentials and mismanaged access remain among the most common entry points. In many cases, incidents are less about “breaking in” and more about legitimate access being used in ways that were never properly anticipated or reviewed.
The Most Common Culprits
Most incidents don’t come from a single failure. They come from a combination of smaller issues.
Data over-retention
Many organisations keep more data than they need, for longer than they need it. That increases the impact if there is ever an incident. Good practice is simple here: collect what you need, keep it for a defined purpose, and remove it when it is no longer required.
Weak identity and access management
This remains one of the most common and avoidable risks. Access is often granted too broadly, rarely reviewed, and almost never reduced over time. Temporary permissions become permanent, shared logins remove accountability, and inactive accounts stay live far longer than they should.
Without enforced multi-factor authentication, a single compromised password can open the door to sensitive systems. Strong practice is straightforward: limit access to what is needed, review it regularly, and remove it when it is no longer required.
Poorly governed integrations
Every integration between systems is another access point into your environment. Over time, these connections build up and are often forgotten about.
The risk usually comes from integrations having more access than they need, credentials that are never updated, or connections that are still active despite no longer being used. If a system is connected to sensitive data, that connection should be reviewed regularly and tightly controlled.
Human factor
Many security incidents are not caused by sophisticated attacks, but by ordinary mistakes. A phishing email gets clicked, access is shared informally, or a setting is configured incorrectly. Good security assumes that despite frequent training, these things will happen and puts controls in place to reduce the impact when they do.
Lack of ongoing vendor oversight
Third-party suppliers are often introduced to solve specific operational needs, from proctoring and accessibility support to analytics, hosting, and identity management. Over time, those relationships can become deeply embedded into day-to-day assessment delivery.
The risk is not necessarily the vendor itself, but the lack of ongoing oversight once integrations and processes are in place. Permissions granted during implementation may remain active long after they are needed. Security reviews may happen during procurement but not continue throughout the lifecycle of the relationship. Subcontractors, inherited access pathways, or changes in vendor infrastructure can introduce exposure that organisations are no longer actively monitoring.
In practice, many environments evolve faster than governance processes around them. A more resilient approach includes regular supplier reviews, clear ownership of integrations and access permissions, scheduled audit cycles, and defined expectations around security testing, incident response, and data handling responsibilities.
What Good Data Practice Actually Looks Like
Good security is really about day-to-day operational discipline. Strong practices usually include:
Clear role-based access controls with audit logs
- Top tip: Map access to actual job roles, not individuals. Then review it regularly. If you can’t easily see who accessed what and when, you’re already behind.
Multi-factor authentication for privileged access
- Top tip: Enforce MFA for anyone with elevated permissions, no exceptions. This is one of the simplest ways to reduce risk from compromised credentials.
Defined data retention and deletion policies
- Top tip: Decide up front how long data needs to be retained, then automate deletion where you can. If you’re keeping data “just in case,” revisit that assumption.
Encryption in transit and at rest
- Top tip: Don’t just confirm encryption exists. Understand where it applies and where it doesn’t, especially across integrations and backups.
Separation of development, testing, and production environments
- Top tip: Never use real customer data in test environments unless it’s properly anonymised. This is a common and avoidable point of exposure.
Regular independent security testing
- Top tip: Ask for recent third-party test results. What matters is how often it’s done and how findings are handled.
Monitoring for unusual or suspicious activity
- Top tip: Focus on behaviour, not just events. Sudden spikes in access, unusual locations, or odd patterns are often the earliest warning signs.
Defined incident response processes with clear timelines
- Top tip: Ensure providers can clearly explain how and when incidents will be communicated. Early communication around impact, expected timelines, service availability, and recovery steps can make a significant difference during assessment delivery, particularly where candidate access, exam continuity, or regulatory obligations may be affected.
Transparency around subcontractors and data processors
- Top tip: Ask who else touches your data, not just the primary supplier. Risk often sits one layer deeper than people expect.
Questions to Ask Your Supplier
No organisation can realistically guarantee that incidents will never occur. What often matters more is how quickly issues are detected, contained, investigated, and communicated when they do.
Strong operational maturity usually shows up in the response process. Clear escalation paths, defined notification timelines, tested recovery procedures, and transparent customer communication all make a significant difference during high-pressure situations.
For organisations delivering assessments, delays or unclear communication can quickly become operational issues, not just technical ones. Candidates may be affected. Exam schedules may be disrupted. Regulatory obligations may come into play. In those moments, customers need clarity around what is happening, what support is available, and what steps are being taken next.
A mature supplier should be able to clearly explain:
- How incidents are classified and escalated
- What notification commitments or SLAs exist
- How recovery and continuity procedures are tested
- What customer communication looks like during an incident
- Which teams are responsible for coordination and decision-making
Good security is not only about reducing the likelihood of incidents. It is also about responding well when things do not go to plan.
Security Is an Operational Discipline
No platform, certification, or control removes risk entirely. Security maturity is usually shaped by operational decisions made over time: how access is reviewed, how integrations are governed, how incidents are handled, and how quickly systems can recover when something goes wrong. Good supplier relationships still require verification, which is why audit evidence, independent testing, security reviews, and operational transparency all matter.
For organisations delivering assessments, resilience matters alongside prevention. Clear communication, tested recovery processes, and continuity planning become critical when services are disrupted. Most serious issues rarely begin with a single dramatic failure. More often, they grow from gaps that were known, accepted, or simply left unchecked. That is why security is as much an operational discipline as a technical one.
Looking at your assessment security and operational resilience strategy? Speak to the Cirrus team about delivering reliable, secure and future-ready assessments.
