Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Aliaska Varieva
What GDPR asks of the people who run the systems: controller vs processor, the eight Article 28 contract terms, the principles in plain words, Article 32 security controls, records of processing, the 72-hour breach clock, data subject requests, DPIAs, DPOs, transfers, fines and a checklist table.
Updated: October 2026
A client asks for your data processing agreement, and the question lands on whoever runs the backups, the admin accounts and the firewall. GDPR is a privacy law, yet a large part of it runs on IT: access control, encryption, logging, backups and breach reporting. This guide turns GDPR compliance into the contracts, controls, records and clocks that IT teams and MSPs own, with a checklist table to work through.
This is a practical guide, not legal advice: check your own obligations with a data protection lawyer.
The General Data Protection Regulation has applied since 25 May 2018. It covers personal data, which Article 4 defines as any information relating to an identified or identifiable person. A name counts. So does an email address, an IP address, a device ID or location data.
The reach is wider than the map suggests. Under Article 3, GDPR applies to organisations established in the EU. It also applies to organisations elsewhere that offer goods or services to people in the EU or monitor their behaviour there. A US retailer selling to German customers is in scope, and its MSP inherits GDPR duties through the contract, wherever the MSP is based.
The part IT feels most is accountability. Article 5(2) makes the controller responsible for compliance and requires it to "be able to demonstrate" that compliance. In practice, that means evidence: a signed contract, a records file, an MFA coverage report, a restore test log. A control nobody can show is hard to defend in front of a regulator.
UK readers: the same rules apply as the UK GDPR, enforced by the Information Commissioner's Office (ICO) and amended by the Data (Use and Access) Act 2025.
Article 4 splits the roles in two. A controller decides why and how personal data is processed. A processor handles personal data on the controller's behalf.
For client data, an MSP is usually the processor. The ICO's guidance on controllers and processors uses an example close to home. A bank hires an IT services firm to store archived data. The IT firm makes plenty of technical calls. It still stays a processor, because the bank decides why the data is kept and for how long.
The same MSP is a controller for its own data. Staff records, the client contacts in your PSA used for billing and your marketing list belong to you, so the full controller duties apply there. The ICO calls this split normal. A processor serving other organisations is "very likely" to be a controller for some data and a processor for other data.
This exact argument played out on r/msp, where a London client's MSP refused the processor label:
The line moves when you start making the client's decisions. Article 28(10) says a processor that determines the purposes and means of processing is treated as a controller for that processing. Reusing client mailbox data for your own analytics or marketing would cross it.
Professor Messer's short lesson on data roles covers data owners, controllers and processors in under three minutes:
The quick test: ask who decides why the data exists and how long it's kept. If the answer is the client, you're the processor.
Article 28 says processing by a processor must be governed by a contract in writing, electronic form included. The market calls it a data processing agreement, or DPA. It describes the subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of people involved.
Then come eight terms. Under Article 28(3), the processor must:
If a client sends its own DPA, check it against these eight terms before signing. If it doesn't, send yours.
Term seven is where IT gets tested. When a client leaves, "delete or return" covers backups, the PSA, the documentation platform and that export someone parked on a file share. Write the offboarding runbook before the first client leaves, and keep a deletion record for each one.
Sub-processors need the most care. Your RMM, PSA, backup service, cloud host and email security vendor may all touch client personal data. Article 28(2) says a processor can't engage another processor without the controller's prior specific or general written authorisation. Under a general authorisation, you tell the client about any added or replaced sub-processor and give them the chance to object.
How MSPs announce tool changes to clients came up on r/msp, and one answer links a public sub-processor list from the contract:
Article 28(4) adds the flow-down. The same data protection obligations go into your contract with each sub-processor, and if a sub-processor fails, you "remain fully liable" to the client. Keep a current sub-processor list and review those vendors once a year. Our guide to vendor risk management covers how to run that review.
Article 5 sets six principles for handling personal data, plus a seventh, accountability, which makes the controller prove the other six. They read like ethics. For IT, each one maps to a setting, a policy or a report.
| Principle | In plain words | What IT does |
|---|---|---|
| Lawfulness, fairness and transparency | Have a legal reason and tell people | Know which system holds what, and why |
| Purpose limitation | Use data only for the reason you collected it | Keep support data out of marketing tools |
| Data minimisation | Collect only what you need | Trim form fields and ticket templates |
| Accuracy | Keep it correct | Sync HR leavers to the directory and fix stale records |
| Storage limitation | Don't keep it longer than needed | Set retention on mailboxes, logs and backups |
| Integrity and confidentiality | Keep it secure | Run the Article 32 controls below |
| Accountability | Prove all of the above | Keep the evidence where you can find it |
Storage limitation is the principle IT controls most directly. Mailboxes, file shares and backup sets grow by default. A retention policy agreed with the client and applied in the tools turns the principle into a scheduled deletion job.
Article 32 doesn't list products. It asks controllers and processors for "appropriate technical and organisational measures" that match the risk, weighed against the state of the art and the cost. It names four examples. They are pseudonymisation and encryption; ongoing confidentiality, integrity, availability and resilience; timely restores after an incident; and regular testing of all of it.
Access control comes first. Every account that can reach personal data needs MFA, admin accounts stay separate from daily ones, and leavers lose access the day they leave. Least privilege applies to your own technicians too: a tech who supports one client shouldn't hold standing admin rights to every client.
Encryption covers data at rest and in transit. That means full-disk encryption such as BitLocker or FileVault on every laptop, encrypted backups, and TLS for anything crossing a network. It also pays off after a breach. Under Article 34(3)(a), the controller doesn't have to notify affected people if the data was unintelligible to anyone without access, as encrypted data is.
Logging is how you answer "what happened?" Centralise sign-in, admin and file access logs, protect them from tampering and keep them long enough to investigate. Our guide to log management covers what to collect and for how long.
Backups prove themselves at restore time. Article 32(1)(c) asks for the ability to restore personal data "in a timely manner". Only a restore test can show that. Schedule the tests and record the result and the time each restore took.
The organisational half carries equal weight: written procedures, staff training and confidentiality commitments for everyone with access. Article 32(4) adds that anyone working under your authority processes personal data only on the controller's instructions.
Patching and vulnerability scanning close the doors attackers walk through. Article 32(1)(d) then asks for a process to test, assess and evaluate the measures regularly. Vulnerability scans, phishing simulations, access reviews and an occasional penetration test all count, as long as the results lead to fixes.
The UK's Advanced case shows what a regulator means. In March 2025, the ICO fined Advanced Computer Software Group £3.07 million under UK GDPR after a 2022 ransomware attack. Advanced processes personal data on behalf of NHS and other healthcare organisations. Attackers got in through a customer account without MFA, and the personal data of 79,404 people was taken.
The findings, per the ICO's announcement, were gaps in MFA coverage, a lack of comprehensive vulnerability scanning and inadequate patch management. That's a processor fined in its own right, over three lines of a standard MSP security baseline.
Article 30 asks each controller to keep a written record of processing activities. It covers the purposes, the categories of people and data, and the recipients. It also lists transfers outside the EU, planned erasure time limits and a general description of security measures.
Processors keep their own, shorter record under Article 30(2). It names each controller you act for and the categories of processing you carry out for each. It also lists any transfers and a general description of your security measures. For an MSP, that's an entry per client, and the regulator can ask to see it.
There's an exemption for organisations with fewer than 250 employees, but it's narrow. It falls away if the processing is likely to result in a risk, isn't occasional, or includes special categories of data such as health records. Continuous managed services are hard to call occasional, so plan on keeping the record.
IT already holds the raw material. Asset inventories, application lists, SaaS admin consoles and your documentation platform show where personal data lives. Turn them into a data map with one row per system: data categories, purpose, location, retention and who has access. In OpenFrame, the device inventory and Mingo's osquery reads of endpoint state show what runs on each machine, a starting point for that map.
Professor Messer's lesson on privacy covers legal implications, data responsibilities, and data inventory and retention in about five minutes:
A personal data breach is wider than a hack. Article 4 defines it as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. A lost unencrypted laptop counts. So does ransomware that leaves records unavailable.
Article 33 gives the controller 72 hours after becoming aware of a breach to notify its supervisory authority. The exception is a breach unlikely to result in a risk to people's rights and freedoms. A late notice must explain the delay, and details can follow in phases. Every breach gets documented, including the ones that aren't reported.
"Aware" has a specific meaning. The EDPB's breach notification guidelines say a controller becomes aware when it has "a reasonable degree of certainty" that a security incident has compromised personal data. A short investigation to reach that point is allowed. The clock doesn't wait for the forensic report.
Processors run a different clock. Article 33(2) says the processor notifies the controller "without undue delay" after becoming aware. The EDPB adds that the processor doesn't need to assess the risk first. In principle, the controller is aware once the processor has told it. Your call starts the client's 72 hours, and any delay before that call is your own breach of Article 33(2).
When the risk to people is high, Article 34 adds a second notice. The controller tells the affected people without undue delay, in clear and plain language. Encryption can remove that duty, which is one more reason to encrypt laptops and backups.
Regulators see these notices every day. DLA Piper's January 2026 survey counted an average of 443 breach notifications a day across the EEA and the UK.
The bar may move. The European Commission's Digital Omnibus proposal from November 2025 would limit regulator notices to breaches likely to cause a high risk. As of October 2026, it's still awaiting a committee decision in the European Parliament, so today's 72-hour rule and risk test apply.
For GDPR, the incident runbook needs a few things in writing:
Our guide to incident response covers the rest of the plan, from roles to the first hour.
People can ask what you hold about them and ask for it to be deleted. Article 15 gives them access, including a copy of their data. Article 17 gives them erasure on several grounds, such as data no longer needed, consent withdrawn or unlawful processing.
Article 12(3) sets the deadline: respond without undue delay and within one month of receiving the request. That can stretch by two further months for complex or numerous requests, as long as the person hears about the extension within the first month.
The request goes to the controller, but the search runs through IT. Mailboxes, file shares, the CRM, the PSA, HR systems, chat history and backups can all hold one person's data. For a processor, Article 28(3)(e) means helping the client answer, not answering the person directly. Route any request that reaches you to the client the same day.
Backups are the hard part of erasure. The ICO's right to erasure guidance accepts that data may stay in backups until it's overwritten. The condition: you put it "beyond use" and tell the person what will happen. In practice, add a runbook step that removes the data again if that backup is ever restored.
Three more obligations belong to the controller on paper. In practice, each one lands on an IT project plan.
Article 35 requires a data protection impact assessment, or DPIA, before processing that's likely to result in a high risk to people. It names three cases: systematic and extensive profiling with significant effects, large-scale processing of special category or criminal offence data, and large-scale monitoring of public areas. National regulators publish lists of other processing that needs one.
For IT, the trigger is usually a project. Think employee monitoring software, a new patient records platform, a CCTV rollout or an AI tool fed with customer data. The assessment describes the processing, tests necessity and proportionality, weighs the risks and lists the safeguards. The safeguards section reads like your Article 32 baseline, so IT writes a large share of it.
Article 37 makes a data protection officer, or DPO, mandatory in three cases. The first is public bodies. The second is organisations whose core activities involve regular and systematic monitoring of people on a large scale. The third is large-scale processing of special category or criminal data. A DPO can be on staff or on a service contract, and the contact details go to the regulator.
National law can go further. Germany's Federal Data Protection Act requires a DPO once at least 20 people regularly work on the automated processing of personal data. MSPs based in Germany, or serving German clients, should check that threshold first.
Personal data leaving the EEA needs a legal route under Chapter V. For an MSP, that question covers every tool in the stack. Where does the RMM vendor host data, where does the PSA store tickets, and which region holds the backups?
The cleanest route is an adequacy decision. The European Commission adopted one for the EU-US Data Privacy Framework on 10 July 2023, covering US companies that take part in the framework. The EU General Court upheld it in September 2025, and the challenger has appealed to the Court of Justice. The two US frameworks before it were struck down, so keep a fallback ready.
That fallback is usually the Commission's standard contractual clauses, modernised in June 2021, plus an assessment of the destination country's laws. Transfers carry weight with regulators: the largest GDPR fine to date, against Meta in 2023, was about transfers to the US.
Article 83 sets two tiers. The lower tier, up to EUR 10 million or 2% of total worldwide annual turnover, covers the controller and processor obligations in Articles 25 to 39. Security, records, breach notification, DPIAs, DPOs and processor contracts all sit there. The higher tier, up to EUR 20 million or 4%, covers the principles, data subject rights and international transfers. In both tiers, the higher of the two figures applies.
European regulators issued about EUR 1.2 billion in GDPR fines in 2025, according to DLA Piper's January 2026 survey. Big tech took the largest penalties. The Advanced case shows the other end: an IT and software supplier fined as a processor in its own right.
Fines aren't the only exposure. Article 82 lets people claim compensation for material or non-material damage. A processor is liable only where it broke the obligations aimed at processors or acted outside the controller's lawful instructions. That's one more reason to follow the DPA to the letter.
Work through this table with each client and keep the evidence column current. It's the file you'll want when a client, an auditor or a regulator asks.
| Control | GDPR article | What IT does | Evidence to keep |
|---|---|---|---|
| Roles and contract | Art. 28 | Confirm who is controller and who is processor; sign a DPA with all eight terms | Signed DPA per client |
| Sub-processors | Art. 28(2), 28(4) | List every vendor that touches client data; notify clients before changes | Sub-processor list, change notices |
| Records of processing | Art. 30 | Map systems, data categories, purposes, locations and retention | Article 30 record per client |
| MFA and access control | Art. 32 | MFA on every account with access to personal data; least privilege; same-day leaver removal | MFA coverage report, access reviews |
| Encryption | Art. 32(1)(a) | Full-disk encryption on endpoints, encrypted backups, TLS in transit | Encryption status report |
| Logging | Art. 32 | Centralise sign-in, admin and file access logs; protect them from tampering | Retention settings, sample searches |
| Backups and restores | Art. 32(1)(c) | Back up, then test restores on a schedule | Restore test log with dates and times |
| Patching and scanning | Art. 32 | Patch on a schedule; run vulnerability scans | Patch compliance report, scan results |
| Regular testing | Art. 32(1)(d) | Phishing simulations, access reviews, penetration tests | Test reports and fixes |
| Breach response | Art. 33, 34 | Runbook with awareness logging and client notice steps | Runbook, breach register |
| Data subject requests | Art. 12, 15, 17 | Search and export across systems; erasure steps that cover backups | Request log with dates |
| Retention and offboarding | Art. 5(1)(e), 28(3)(g) | Retention policies in the tools; delete or return data when a client leaves | Retention settings, deletion records |
| DPIA support | Art. 35 | Supply the security section for high-risk projects | Completed DPIAs |
| International transfers | Art. 44 to 49 | Know where each vendor stores data; check DPF status or sign SCCs | Transfer map, signed SCCs |
GDPR compliance for IT comes down to four moves: know your role, sign the right contract, run the controls and keep the proof. Processors answer to their clients first, so a fast breach call and a clean offboarding count as much as MFA coverage. Start with the checklist, fill in the evidence column and review it with each client once a year.
Next, see how GDPR sits next to SOC 2, HIPAA and other frameworks in our guide to IT compliance.
Head of Platform
Hi! I’m Aliaska, and I’ve been working as a software engineer (mostly Java + a bit Kotlin) for over 8 years now. I mostly spend my time building backend services, integrating systems, fixing bugs (the fun part 🙃), and making sure things don’t fall apart behind the scenes.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.