GDPR for IT teams and MSPs: what you need to know and do

GDPR enforcement is no longer a theoretical risk. European data protection authorities issued more than €1.2 billion in fines in 2025 alone, and the most common category of violation was insufficient technical and organizational security measures, precisely what Article 32 of the regulation requires IT teams and MSPs to implement. The cumulative fine total since 2018 has now exceeded €7.1 billion, according to analysis of the GDPR Enforcement Tracker published in early 2026.

For IT professionals and MSPs serving EU or UK clients, GDPR is an operational requirement that sits squarely within IT management, not purely a legal or compliance function. Kaseya’s platform is used by more than 50,000 MSPs and IT teams worldwide, many of them navigating exactly these obligations for multiple clients simultaneously, and this guide draws on that operational depth to cover what actually matters in practice.

This guide focuses on the technical and organizational security requirements, the breach notification obligations, and the data processing roles that make GDPR a genuine IT management concern.

What GDPR is, and who it applies to

The General Data Protection Regulation (EU 2016/679) governs how personal data about individuals in the EU and European Economic Area (EEA) is collected, processed, stored, and transferred. The UK GDPR, retained and adapted following Brexit, applies a near-equivalent set of requirements for UK-based processing, with the ICO as the supervisory authority.

Personal data under GDPR is broader than most IT teams initially assume. IP addresses, device identifiers, email addresses, and technical logs can all constitute personal data if they can be linked to an individual. The regulation applies to any operation performed on that data, including collection, storage, retrieval, use, transmission, and deletion.

GDPR applies to organizations established in the EU/EEA regardless of where data subjects are located, and to organizations outside the EU/EEA that offer goods or services to individuals in the EU/EEA or monitor their behavior. There is no minimum size threshold. A one-person business that processes personal data about EU individuals has the same obligations as a multinational.

For B2B technology companies, SaaS providers, and MSPs with EU or UK clients, GDPR almost certainly applies.

Article 32: the IT security requirement at the heart of GDPR

Article 32 is where GDPR becomes an IT management requirement. It mandates that controllers and processors implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. The regulation specifies four categories of capability:

Pseudonymization and encryption. Personal data should be protected at rest and in transit. Encryption at the endpoint and at the backup level, combined with access controls that restrict who can see unencrypted data, is the practical implementation.

Confidentiality, integrity, availability, and resilience. Processing systems must be able to maintain these properties on an ongoing basis. This maps directly to endpoint detection and response (EDR) for confidentiality and integrity, and to backup and disaster recovery for availability and resilience. These are not separate security products bolted onto a GDPR compliance program. They are the GDPR compliance program.

Timely restoration of availability. After a physical or technical incident, organizations must be able to restore access to personal data in a timely manner. Recovery time objective (RTO) is a GDPR requirement, not just an operational preference. An MSP managing client data that cannot demonstrate fast, tested recovery from backup is not Article 32 compliant.

Regular testing and evaluation. The effectiveness of security measures must be regularly tested, assessed, and evaluated. Compliance is not a one-time state. It requires ongoing assessment, documented evidence, and a process for identifying and closing gaps.

The 2025 fine against Advanced Computer Software Group, an IT provider fined £3.07 million by the UK ICO for security failures that disrupted NHS services, was the ICO’s first fine issued directly against a processor rather than a controller. The ICO found the company had failed to implement appropriate technical measures under Article 32, citing specific gaps in MFA deployment, vulnerability scanning, and patch management. This is not an abstract risk for MSPs. It establishes a clear precedent that IT service providers can be held directly liable for security failures in the systems they manage.

A practical way to think about Article 32 obligations: if you could not demonstrate to an auditor today, with documented evidence, that encryption is active on all endpoints processing personal data, that backup verification tests have been run and passed, and that incident response procedures have been tested, you have an Article 32 gap.

Data breach notification: the 72-hour rule

Article 33 requires controllers to notify their supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in risk to individuals. The UK supervisory authority is the ICO. In EU member states, it is the relevant national data protection authority.

The 72-hour clock starts when the organization has a reasonable degree of certainty that a security incident has compromised personal data. This is not when the investigation is complete. It is when awareness exists that personal data may have been affected. GDPR explicitly permits phased notification: an initial notification with what is known, followed by updates as the investigation produces more detail.

Article 34 adds a separate obligation to notify affected individuals directly when a breach is likely to result in high risk to their rights and freedoms. Health data, financial data, identity documents, and data about children are categories where this threshold is frequently met.

The operational implication for IT teams and MSPs is clear: breach detection capability fast enough to identify and confirm an incident within hours of occurrence is a GDPR requirement. Alert fatigue, slow escalation paths, and unclear incident response procedures translate into 72-hour violations. A well-run security incident response process treats the clock as starting on detection, not on conclusion of investigation.

Processors have a parallel obligation. MSPs acting as data processors must notify the controller without undue delay after becoming aware of a breach. The controller then notifies the supervisory authority within the 72-hour window. If an MSP discovers a breach affecting client data on a Friday evening and does not notify the client until Monday morning, that delay may cause the controller to miss the statutory deadline.

Data protection by design and by default

Article 25 requires that privacy controls be built into systems from the start, not retrofitted after deployment.

Data protection by design means that when systems are procured, configured, or developed, privacy requirements are part of the technical specification. Access controls, encryption, and data minimization are architecture decisions, not additions. For IT teams evaluating new tools, a privacy impact assessment is part of the process, not a follow-up.

Data protection by default means that default settings must be the most privacy-protective option available. If a system can collect less data, share less data, or provide less access, the default must favor privacy. Users should have to actively enable broader data collection, not opt out of it.

Data Protection Impact Assessments (DPIAs) are required before processing that is likely to result in high risk, including automated decision-making, systematic monitoring at scale, large-scale processing of sensitive categories of data, and behavioral analytics. For IT teams, the triggers include AI-based monitoring tools, user behavior analytics platforms, and biometric access systems. A DPIA is not optional for these categories. It is a legal prerequisite.

GDPR for MSPs: controller vs. processor

Understanding GDPR roles is one of the most practically important aspects for MSPs.

A controller determines the purposes and means of processing personal data. The MSP’s client is typically the controller of their customers’ data, their employees’ data, and any personal data their business processes.

A processor processes personal data on behalf of the controller. An MSP that manages IT systems containing personal data, provides email services, hosts data, or delivers backup and recovery services for client environments is, in most cases, acting as a data processor for that client’s data.

Processor obligations under GDPR include:

• Processing only on documented instructions from the controller
• Implementing appropriate technical and organizational security measures (Article 32)
• Notifying the controller without undue delay after becoming aware of a data breach
• Deleting or returning all personal data at the end of the service contract
• Allowing for and contributing to audits by the controller

A single MSP can be a controller for some data (its own employee data, its own customer relationship data) and a processor for other data (client personal data it manages as part of service delivery). Both sets of obligations apply simultaneously.

Sub-processors are a further layer. When an MSP uses cloud providers, backup vendors, or other services in delivering IT services to clients, those third parties may become sub-processors of the client’s personal data. Sub-processor arrangements must be disclosed to and authorized by the controller. Sub-processors must meet equivalent security standards to those required of the primary processor.

Data Processing Agreements: what MSPs must have in place

A Data Processing Agreement (DPA) is a legally required contract between controller and processor. Every MSP handling personal data for EU or UK clients must have a DPA in place with each of those clients. This is not optional and not a commercial nicety. It is a GDPR requirement under Article 28.

A DPA must cover, at a minimum:

• The subject matter, duration, nature, and purpose of the processing
• The type of personal data and categories of data subjects
• The controller’s documented instructions to the processor
• The security measures the processor will implement (Article 32 obligations)
• The process for breach notification from processor to controller
• Sub-processor arrangements and the requirement for equivalent protection
• The processor’s obligations at the end of the contract: deletion or return of data
• Audit rights for the controller

For an MSP managing multiple clients, having standard DPA terms reviewed and ready for deployment is a commercial prerequisite, not an administrative burden. MSPs without DPAs in place are not compliant as processors, regardless of how good their security posture is technically. The DPA is also where clients assess the MSP’s security practices before they become a client. For mid-market and enterprise clients with their own GDPR programs, a clear and well-drafted DPA is increasingly a condition of contract.

Compliance Manager GRC supports GDPR compliance assessment and evidence documentation across Article 32 controls, giving MSPs a structured way to demonstrate and maintain the security measures their DPAs commit to. Explore how it supports compliance programs.

Enforcement and what it means for IT providers

GDPR’s penalty structure is well known. Up to €20 million or 4% of global annual turnover for the most serious violations. Up to €10 million or 2% for procedural failures including inadequate security measures and missed breach notifications.

The enforcement reality in 2025 and 2026 is that Article 32 security failures are the most common cause of fines by count, not just by the headlines generated by large tech company penalties. The French CNIL fined Free Mobile €27 million in January 2026 for inadequate security measures following a data breach. The ICO fined Advanced Computer Software Group £3.07 million in March 2025 for the same Article 32 failures, including gaps in MFA, vulnerability scanning, and patch management. Spain and Italy have been consistently active in fining healthcare providers, financial services firms, and regional service companies.

Regulators have also confirmed that enforcement is not limited to large organizations. Analysis of enforcement tracker data shows a significant share of all fines issued to regional service providers, small SaaS companies, and local agencies. The penalties are proportionally smaller, but they are penalties.

For MSPs, the enforcement picture translates to three specific risks: direct liability as a processor for security failures under Article 32, liability to clients for breach notification delays that cause the controller to miss the 72-hour window, and commercial exposure from not having DPAs in place at all.

GDPR compliance is also a commercial requirement, not just a regulatory one. Mid-market and enterprise clients with EU/UK operations routinely require GDPR compliance evidence as part of vendor assessment and contract renewal. An MSP that cannot produce documented security controls, tested incident response procedures, and a signed DPA is not competitive in that market segment.

For a deeper look at how data governance requirements connect to GDPR, HIPAA, and the other frameworks MSPs navigate for clients, see our guide on data governance for IT teams and MSPs.