IT maintenance
and GDPR

Not in those words: the regulation doesn't mention maintenance contracts. What it requires is appropriate technical and organisational measures to protect data, and the ability to show that they are applied continuously, not just on the day a document was signed. In practice, a good share of those technical measures are IT: backups that work and are checked to restore, systems kept up to date, access that is controlled and removed when someone leaves the company, and a real ability to detect an incident and know what to do about it. None of that holds up on its own over time: a system that's well configured today degrades if nobody reviews it afterwards. That's why IT maintenance isn't a technical extra bolted onto compliance; it's the part that keeps it alive month after month instead of turning it into paperwork signed once.

Yes, and it's what we're most surprised to find unsigned in businesses whose GDPR paperwork is otherwise in order. If your IT provider gets into the computers holding data about customers, patients or employees (and to provide technical support they do, even if only occasionally), they are processing personal data on your behalf. That makes them a data processor, and the relationship has to be governed by a contract separate from the service contract: which data they can touch, for what purpose, what confidentiality they require of their staff, what security measures they apply, whether they can subcontract and on what terms, and what happens to the data when the relationship ends. A serious provider offers it without being asked. If yours seems puzzled when you ask about that contract, that already tells you something about how they handle the rest of their obligations to you.

Any incident involving the destruction, loss, alteration of or unauthorised access to personal data counts as a breach: ransomware that encrypts the server, a stolen unencrypted laptop, an email with customer data sent to the wrong person, even an employee looking at files without a reason to. There doesn't need to be intent, nor does the data need to leave the company. When the incident poses a real risk to the rights of the people affected, it must be reported to the supervisory authority without undue delay and, as a benchmark, within 72 hours of becoming aware of it. That's a short deadline to improvise in, so it's best decided in advance: who assesses the risk, who drafts the notification and who informs those affected if necessary. Documenting it is also mandatory, even if in the end it isn't reported because the risk is judged to be low: having no record is a failure in itself.

It's one part, and not the one that makes the difference when there's a complaint or an inspection. What almost no business has documented is what holds the rest together: who has access to which systems and why, what exactly happens on the day someone leaves the company, how often you check that backups really restore and not just that the job ran, and what would be done in the first few hours if a security alarm went off. Complying with GDPR isn't having antivirus and backups installed; it's being able to show that both work and that there's a rationale behind who gets into each piece of data. That documentary side is the first thing you'll be asked for if you ever have to answer to the supervisory authority, and also the first thing forgotten, because it causes no visible problem day to day, until it suddenly does.

The obligations are the same regardless of size; what changes is the proportionate way of meeting them, not whether you have to. A very small business doesn't need the same structure as one with a hundred employees, but it does need the same underlying guarantees: that data is protected, that this can be shown, and that there's a minimum of control over who accesses what. There's a nuance often forgotten: the size of a business says nothing about how sensitive its data is. A two-person practice or a small clinic handles more delicate health or financial data than many large companies that only deal with orders and invoices. If you're unsure exactly what level of rigour applies to your activity, that's a question for a data protection specialist; what does depend on IT (backups, access, encryption) applies just the same whatever your size.

Response time is how long it takes someone to deal with your call: pick up the phone, open the ticket, confirm it's being looked at. Resolution time is how long it takes for the problem to be genuinely fixed, which can be much longer if a part has to be ordered, a large backup restored or a third party coordinated. Almost every maintenance contract commits to the first in writing, with clear figures, and leaves the second as a vague «as soon as possible» that commits to nothing in particular. The difference matters because it's the one you actually suffer: being answered in fifteen minutes doesn't help much if the system is still down six hours after that call. Before signing, ask explicitly which of the two is guaranteed, with what figure, and what happens if it isn't met. If they only talk about response, they're probably selling you less than it seems at first glance.

For a very small business with little infrastructure and little risk it can make sense, especially at first. The problem shows up over time: ad hoc hours are requested when something has already failed, so they always go on putting out the fire of the moment and never on prevention, which is precisely what stops the fire starting. Checking backups, verifying updates, reviewing access or keeping GDPR documentation up to date never triggers an urgent call, so under a pay-as-you-go model it tends never to get done for want of an occasion. If you still choose to pay by the hour, it makes sense to explicitly set aside a fixed amount each year for preventive review, rather than leaving it to whatever budget is left over. As soon as the business grows or handles more sensitive data, a fee that includes that preventive work usually works out cheaper than the hours spent reacting late.

It has to be set out in writing in the contract, not improvised on the day you decide to switch. It should cover at least three things: the return or deletion of the data the outgoing provider had access to, the handover of credentials, passwords and technical documentation for the system, and confirmation of who really owns the domains, licences and cloud accounts taken out. That last point comes up more often than you'd think: it's not unusual to find domains or email licences registered in the provider's name rather than the company's, which turns a simple switch into a long standoff. It's also the moment when badly drafted contracts, or ones that simply don't exist, come to light: if nothing was ever signed, there's nothing to hold on to when demanding that handover. That's why it's worth reviewing this clause before you need to use it, not when you need it urgently.