Shop Server Logs: How Long IP Addresses May Be Stored

The GDPR governs storage periods through a principle, not through days. Under Art. 5(1)(e) GDPR, personal data may only be kept in a form that permits identification for as long as necessary for the purposes (GDPR). Recital 39 is more specific: to ensure data is not kept longer than necessary, the controller should establish time limits for erasure or for a periodic review (GDPR). Setting a period is therefore the controller's task. Its length is set by the shop operator, who must be able to justify it.

The legal basis for server logs in a shop is usually Art. 6(1)(f) GDPR, legitimate interest. The German Data Protection Conference describes the assessment in three stages (Datenschutzkonferenz): a legitimate interest, the necessity of the processing to pursue it, and the balancing against the interests of the data subjects in the individual case. For security purposes Recital 49 sets the direction: it names processing to ensure network and information security, for example by operators of communication networks and providers of security services, as a legitimate interest to the extent strictly necessary and proportionate (GDPR). For your own shop that shows the direction but does not replace your own balancing test. In the same case the CJEU accepted that an operator, there federal institutions, may have a legitimate interest in ensuring that its websites keep functioning beyond their specific use (CJEU).

This sentence is often quoted as a retention period for all logs. It does not support that. The BfDI assesses processing by federal public bodies, bases it on Art. 6(1)(e) GDPR together with the Federal Data Protection Act, and refers to the purpose of "optimising the website" (BfDI). For that purpose the full IP address is usually not necessary, according to the BfDI (BfDI). The page does not name a period in days for attack detection. For a shop the figure is therefore a guide value for analysis, not a rule for the raw log, and the legal basis remains legitimate interest with a balancing test of its own.

Truncating means discarding the rear part of the address. An IPv4 address is 32 bits (RFC 791) long, and removing the last byte is common. The IpUtils::anonymize helper of the Symfony framework, which Shopware is also built on, removes 1 byte for IPv4 and 8 bytes for IPv6 by default (Symfony). For IPv4 that is a common compromise: the network stays recognisable for analysis, the individual connection no longer does without further effort.

For IPv6 the same rule is not enough. An IPv6 address is 128 bits (RFC 4291) long, and for common addresses the last 64 bits (RFC 4291) form the interface identifier. Removing exactly that part keeps the network prefix, which often belongs to a single connection. The address assignment recommendation provides home sites with significantly more than a single /64 network (RFC 6177). The example configuration below therefore keeps only the first three groups for IPv6. Whether that creates enough distance depends on the assignment practice of access providers; if you need it tighter, keep only two groups and document the decision.

Replacing instead of truncating is the second option. The BfDI names changing the IP address, possibly with a hash function, as a measure that can reduce the risk adequately without impairing the purpose (BfDI). A plain hash of an IPv4 address hardly achieves this, though: with 32 bits the entire address space can be computed and every hash mapped back to its address. Replacement only becomes effective with a secret key that is rotated regularly and destroyed afterwards. Art. 32 GDPR explicitly lists pseudonymisation as a technical measure (GDPR). In nginx, truncation works without an extra module:

These lines belong in the http context. If a server block has access_log directives of its own, the outer setting no longer applies there, and the line for the analysis log is added to that block as well. The raw log keeps running unchanged alongside and keeps its short period. Create the directory for the analysis log before reloading. A separate directory is needed because the package rotation rule covers all files matching /var/log/nginx/*.log, and logrotate rejects a file that appears in two rules with an error.

The cleanest log rotation ends at the edge of the server. A backup that includes /var/log keeps every log line for as long as the backup itself, so with retention over months, for months. The same applies to staging systems created as a full copy of production and to log excerpts that end up in tickets, chats or emails to service providers. What counts for the retention period is not when the original rotates but when the last copy disappears.

For backups there are two clean options: exclude log directories from the backup if the logs play no role in a restore, or align the backup retention with the shortest period it contains. How deletion duties and backups fit together in general is covered in the article on GDPR-compliant backup retention. For staging systems, logs are skipped or emptied when copying, and the test system gets its own short rotation. How test environments get by without unnecessary real data is shown in the article on staging environments.

Comparing against the oldest existing log is the simplest measurement of whether the period actually applies. The following script reports the oldest access file per directory and its age by modification time; it measures the raw log and the analysis log separately so that the longer period of one does not hide the shorter period of the other. That is the time of the last entry, because logrotate keeps it when compressing; the oldest entry in the file can be up to one rotation interval earlier:

The last step is the one most easily dropped in practice, because the setting is correct once and rarely gets checked again. A package update, a server move or a new protection layer in front of the shop brings its own logs and its own defaults. Alongside disk usage and error logs, which monitoring watches, the age of the oldest log therefore belongs among the values that should be checked regularly. How logs fill a partition under their default settings is described in the article on disk space monitoring.

In a maintenance contract these points come together. The GDPR updates cover maintaining the privacy policy with its storage periods and the record of processing activities. Web server configuration and backups are part of the technical support described under services. Response times and packages are set out in the SLA maintenance contract. That way period, configuration and documentation sit in one place and do not drift apart.