Data Protection in Online Shops: How to Balance Efficiency and GDPR Compliance

Every first Tuesday of the month, over 2,500 live clusters are updated between 6:00 and 9:00 am. What sounds like a routine technical task is, in reality, a carefully planned process – monitored by a well-coordinated team that intervenes in real time whenever necessary.

For most shop owners, this day passes completely unnoticed. No downtime, no surprises, no support tickets. And that’s not down to luck, but the result of a process that is replanned every month – before the first line is updated.

This article explains how this process works, what gets updated and what doesn’t – and what you, as a shop owner, specifically need to know and do.

Companies that fail to update their systems regularly are taking an ever-greater risk. According to the BSI Situation Report 2025, the number of new vulnerabilities recorded each day rose by 24 per cent between July 2024 and June 2025. At the same time, security researchers at Outpost24, in an analysis of publicly accessible systems, classified 18 per cent of the assets examined as being at high or critical risk – often simply because patches had not been applied.

To be even more specific: according to an analysis by Netzpalaver, 76 per cent of all cyberattacks in 2024 began with an unprotected or forgotten external asset. Systems that are not kept up to date do not simply become sluggish – they become a gateway for attacks (source: netzpalaver.de)

For online shops, this is no abstract risk. In the worst-case scenario, a compromised server means data loss, a GDPR reporting obligation, reputational damage – and a shop that is offline just when customers want to make a purchase. Our e-book, ‘IT Security in E-commerce’, provides a comprehensive overview of IT security in e-commerce – from attack vectors to protective measures.

Regular updates protect against four key risks:

• Security: Critical vulnerabilities (CVEs) are patched before attackers can exploit them.
• Stability: Errors in packages, memory management and kernel modules are fixed – before they cause system failures.
• Compatibility: Dependencies are kept up to date, and software versions remain consistent.
• Compliance: Defined update processes help ensure compliance with internal IT standards and data protection requirements.

There is more to update day than just an automated script. A team of four experienced Linux administrators plans each cycle in advance: open tickets are discussed, risks are assessed, and responsibilities are allocated. Internal transparency is essential to ensure that nothing goes wrong externally.

The rollout itself follows a two-phase model.

A week before the actual live update day – that is, on the last Tuesday of the previous month – more than 700 stage clusters are updated. Why the stage systems first? Because they provide the perfect testing environment: real infrastructure, real configuration, but no live business operations depending on them.

During this week, we can calmly observe whether a package update behaves differently than expected. Incompatibilities are spotted before they reach a live shop. And you, as a customer, have time to test your application on the stage system – and take action if necessary.

Possible actions:

• Fix a bug in your application that has been revealed by the new package.
• If necessary, contact support to postpone the update of your live cluster.

On the first Tuesday of the month, between 6:00 and 9:00 am, updates are rolled out across more than 2,500 live clusters. The rollout is staggered – not all systems at once, but with a time delay to avoid overloading the infrastructure.

During this phase, a central monitoring dashboard is active. The admin team can see in real time whether services are running smoothly, if errors occur, or if intervention is required. Updates run automatically – control remains manual.

On Update Day, all Ubuntu packages on the cluster for which new versions are available will be updated. This includes the entire operating system toolchain – from basic system commands and PHP to database services and web servers.

What is not updated: any applications that you or your agency have installed and manage yourselves. These include:

• Shopware, Magento and other shop systems
• WordPress, TYPO3 and other CMS
• PM2 applications and custom services

A clear distinction: maxcluster updates the infrastructure – your application remains in your hands. We do not touch it.

To ensure that updates do not cause unexpected issues, maxcluster strictly adheres to semantic versioning. This means that we only update within the same major and minor versions – in other words, we only perform patch updates that are backwards compatible.

For example: MySQL 8.0.1 is updated to MySQL 8.0.2 – not to 8.4.1. The difference: patch updates (the third digit) are safe. Changes to the second or first digit can cause incompatibilities.

Should a major or minor version number change nonetheless, we will inform you in advance – giving you sufficient time to prepare your application.

As a rule, updates go smoothly. Ubuntu is characterised by high-quality packages and stable dependencies. Occasionally, however, exceptional cases do arise: a service fails to restart, a configuration file needs adjusting, or a service requires manual intervention. These are exceptions – and they are usually resolved on the same day.

For more serious incidents, there is a clear escalation plan:

• The monitoring team detects issues in real time via the dashboard.
• Within one to five minutes, the system can be switched over to the standby server.
• The standby server retains the data state from 6:00 am – no backup needs to be restored.
• The rollback is minimal, quick and possible without significant data loss.

The backup strategy and update process complement each other: If you have both under control, you’ll be able to act effectively even in an emergency. Our article Backups in E-commerce explains what a robust data backup system for your shop should look like.

In the event of critical security vulnerabilities – Heartbleed, Ghost, ShellShock and similar – we respond outside the regular cycle, immediately following our analysis. In such cases, services may need to be restarted unscheduled.

For most shop owners, update day passes without a hitch. Nevertheless, there are a few things you should be aware of:

Brief service restarts are possible: Packages such as php-fpm, MySQL, Apache or NGINX require a restart following an update. During this brief period, individual services will be unavailable. The downtime is usually very short – but it does occur.

Test after the update day: Even though we do not expect any incompatibilities, it is good practice to carry out a quick functional test of your shop after the update day. In the Managed Centre, under Access & Management → Package Updates, you will find a complete list of all installed packages, sorted by date.

What to do if an incompatibility does occur? In rare exceptional cases, it is possible to roll back individual packages to the previous version – as a short-term stopgap. Important to note: A downgrade excludes the package in question from further updates in the long term, thereby widening the very security gap you were trying to close. The cleaner solution is therefore always to adapt your own application to the new package version.

Critical security vulnerabilities: In the case of serious vulnerabilities such as Heartbleed, Ghost or ShellShock, we do not wait until the next update day. We respond immediately following our analysis – even outside the regular cycle. In such cases, services may be restarted at unscheduled times. We will proactively inform you in these instances.

You can find more details about the procedure and the potential risks in our knowledge base article Update-Tag.

The monthly update day is perhaps the least spectacular feature that maxcluster offers – but at the same time one of the most important. No dashboard, no new tool – just a reliable cycle that ensures your infrastructure remains up to date, secure and stable.

Two-phase rollout, software freeze, real-time monitoring, semantic versioning, rollback in minutes: these aren’t just buzzwords, but the concrete mechanisms behind the process. And they work because they are planned, tested and executed anew every month.

After update day is before update day.