Data Retention: How Long to Keep Monitoring Records

Storage limitation: the principle missing from retention policies

The GDPR sets out six processing principles, and storage limitation is the one that makes the least noise in day-to-day engineering. Article 5(1)(e) requires personal data to be kept in a form that permits identification of the data subject only for as long as the processing purposes require (GDPR). Recital 39 is more explicit: the controller should set time limits for erasure or a periodic review (GDPR). So it is not enough to get rid of data eventually - the schedule has to exist beforehand. On top of that comes the accountability duty in Article 5(2): the controller must be able to demonstrate compliance with the principles (GDPR). A retention policy is therefore less an exercise in diligence than the evidence that your own data holdings follow any order at all.

That order gets tested in several places. Article 13(2)(a) requires the storage period to be disclosed at collection time, or failing that the criteria used to determine it (GDPR). Article 15(1)(d) gives data subjects the right to be told the envisaged storage period (GDPR), and Article 30(1)(f) requires the record of processing activities to state, where possible, the envisaged time limits for erasure of the different categories of data (GDPR). Anyone who cannot answer those three questions consistently does not have a data protection problem in one place, but in three. And because breaches of the principles sit in the upper fine range under Article 83(5), the topic is not a minor line item commercially either.

For website monitoring, personal reference is the decisive fork. The European Court of Justice held in the Breyer case that dynamic IP addresses can be personal data for a website operator if that operator has legal means to have the person identified (European Court of Justice). Access logs and check logs containing visitor addresses therefore fall under storage limitation. Screenshots can show names, order numbers or messages from a customer account. Session recordings capture movements and input. Form events contain field contents depending on the setup. Plain response times, status codes and certificate lifetimes, by contrast, often carry no personal reference at all - a different case that tolerates a different deadline.

Which data website monitoring actually produces

Before a deadline can be set, the data landscape has to be named. A monitoring account collects more categories than the interface suggests, and they differ considerably in personal reference, value and shelf life. The overview below summarises what typically accumulates and how the respective deadline can be derived. The column "typical period" lists corridors observed in practice, not statutory values - with the exception of the last row.

Two patterns stand out. First, the short periods typically apply to categories with direct personal reference - logs holding an IP address, session recordings, form events. Second, the long periods typically apply to data whose personal reference is not needed for the later analysis at all. That gap is where the room to manoeuvre sits, because an availability figure covering twelve months does not need a single check row from March. Anyone keeping image states as evidence should also review which parts of a page need to be captured in the first place; the screenshot and changelog feature rests on the same consideration.

Where a retention period comes from

A retention period is not chosen, it is derived. Four sources come into play, and the actual period usually follows from the longest of them - but only for the data category that source genuinely covers. A common mistake is to mentally extend the eight-year period for accounting vouchers across the whole data estate and then keep everything for eight years.

These four sources produce a period with a rationale for each data category. That rationale is the real value of the retention policy: it turns a number in a settings dialogue into a decision that can be followed. And it often shows that a shorter period is sufficient than first assumed. How technical metrics can be aggregated for the long view without losing meaning is described in the article on response times using p95 and p99 instead of the average.

Logs with IP reference: seven, thirty or ninety days

No category is argued over as much as access and check logs holding IP addresses. There is no statutory period for them. In practice a seven-day mark has become established, derived from case law on storing dynamic IP addresses to fend off disruptions to operations (Federal Court of Justice). A longer retention period is not ruled out, but it requires a documented balancing test that makes the security purpose and the necessity of the additional days verifiable (GDPR). For operators of critical infrastructure the BSI Act names no minimum period for log data; the frequently cited guide value of 90 days comes from the BSI minimum standard on logging and detection of cyberattacks and applies there to the federal administration (BSI).

The spread is wide, and that is not a contradiction but the system: the period follows the balancing test under Article 6(1)(f), and Recital 49 names network and information security explicitly as a legitimate interest (GDPR). What matters is not the number but whether the balancing test exists in writing. A second lever lowers the risk regardless of the period: if the IP address is truncated or replaced by a check value after a short core period, analysis remains possible while the personal reference disappears. How measurement can be set up without recognising individual visitors in the first place is described in the article on cookieless tracking without consent banners.

With alert and incident history the pendulum swings the other way. The NIS2 Directive requires affected entities to submit an early warning within 24 hours, a notification within 72 hours and a final report within one month (NIS2 Directive). The Cyber Resilience Act likewise requires an early warning within 24 hours for actively exploited vulnerabilities (Cyber Resilience Act). Anyone wanting to evidence such notifications later needs an incident file that clearly outlasts the reporting window - one to three years is common. That file usually holds only timestamps, status values, measures and operator accounts, however, not the full raw logs. Which alerts are worth keeping is already decided when monitoring alerts are configured.

The exception: commercial and tax law

Against the erasure duty stands a retention duty, and it has moved recently. The Fourth Bureaucracy Relief Act shortened the period for accounting vouchers from ten to eight years; the change applies to vouchers whose period had not yet expired on 31 December 2024 (German Fiscal Code). The period for invoices under VAT law was adjusted in parallel (German VAT Act). What was not shortened is the ten years for annual accounts, commercial books and inventories (German Commercial Code). Credit institutions, investment firms and undertakings under insurance supervision are excluded from the shortening: for them Section 147 (3) sentence 1 of the German Fiscal Code continues to apply in the version in force on 31 December 2024, that is ten years (Introductory Act to the German Fiscal Code).

In practice that means anyone who wrote their retention policy before 2025 is carrying an outdated number in at least one place. And because the erasure duty revives once the retention period expires, keeping data too long is itself a breach of storage limitation. For electronic filing there is the additional point that the principles for the proper keeping and retention of books require immutability, machine evaluability and traceability across the entire period (Federal Ministry of Finance). The period starts at the end of the calendar year in which the last entry was made (German Fiscal Code) - so an invoice from January effectively sits for almost nine years.

For a monitoring account the conclusion is pleasantly clear: the long period covers the billing records of the contractual relationship, not the measurement data. Check logs, screenshots and session recordings are not accounting vouchers. Throwing them into the same retention bucket extends their lifetime without a legal basis and, in the event of a breach, enlarges exactly the estate an attacker walks away with. Separating billing data from measurement data therefore belongs at the start of the retention policy, not at the end.

Aggregation instead of deletion: the defensible middle path

Between "keep" and "gone" lies a third option missing from many policies: aggregation. Roughly 43,200 individual checks in a month at a one-minute interval become one row per day carrying availability, response time percentiles and error rate. The value for trend analysis is preserved, the personal reference disappears, and storage demand drops by several orders of magnitude. Recital 26 of the GDPR makes clear that the data protection principles do not apply to anonymous information (GDPR) - a cleanly aggregated daily value with no route back to the individual session therefore falls out of the erasure duty.

Two conditions decide whether aggregation holds. First, the aggregation must cut off the route back: if an identifier survives alongside the daily value that allows the individual session to be reconstructed, the result is pseudonymous rather than anonymous - and therefore still personal data. Second, further processing for statistical purposes has to be safeguarded; Article 89(1) requires appropriate safeguards such as data minimisation and pseudonymisation (GDPR). Article 11 adds that a controller is not obliged to keep additional identifying information solely to comply with the regulation (GDPR) - so data need not be made more identifiable than the purpose requires.

In practice this can be built in tiers: raw data for the short period during which incidents are investigated, and daily aggregates for the long period in which trends and evidence matter. A status page with a 90-day band then needs 90 daily aggregates rather than 90 days of raw logs - a separation already built into reports and status pages. The same principle applies to image states in a different form: instead of keeping every image indefinitely, the detected difference between two states is enough, as described in the article on detecting website changes by image comparison.

Documenting periods in the record of processing activities

A retention policy that exists only in an application's settings is worth little in an audit. Article 30(1)(f) requires the record of processing activities to state, where possible, the envisaged time limits for erasure of the different categories of data (GDPR). The relief for organisations with fewer than 250 employees under Article 30(5) rarely helps here, because it falls away as soon as the processing is not occasional (GDPR) - and continuous monitoring is the definition of "not occasional". Where a service provider is used, the period also belongs in the processing agreement under Article 28, along with a rule on what happens to the data when the contract ends (GDPR).

1. Record data categories individually: check logs, response times, screenshots, session recordings, form events, alert history, team access logs and billing records belong in separate entries. Catch-all items such as "technical data" block every later justification.
2. Assess personal reference per category: note whether and through what a reference arises - IP address, customer identifier visible in an image, field content from a form. Without that assessment neither a period nor an aggregation can be justified.
3. Derive the period, do not set it: note purpose, legal basis and the longest applicable source for each category. The derivation is the part a supervisory authority actually reads.
4. Define the aggregation tier: determine which category moves into an aggregate once the raw data period expires and which disappears entirely. Note what cuts off the route back to the individual session.
5. Automate the prune run: a policy without technical execution is a statement of intent. The run should start on a schedule, log its results and include files, copies and backups - not just the primary table.
6. Plan for data subject requests: define how an individual is removed from the estate before the period expires and who performs it. The one-month deadline in Article 12(3) leaves little room for improvisation (GDPR).
7. Review annually: periods go out of date. The shortening for accounting vouchers since 2025 is the most recent example (German Fiscal Code). A fixed review date with a name attached belongs in the policy.

The retention policy touches several neighbouring topics along the way. Defining who on the team may see and export which data feeds directly into it; the underlying system is described in the article on access rights and audit trail in the monitoring team. Anyone wanting to know whether data leaves the country at all will find the measurement approach in the article on data flow and third-country transfer of a website. And where processing carries a high risk - session recordings are the classic case - the route runs through a data protection impact assessment for web tracking, which asks for the storage period anyway.

Setting up retention periods in XICTRAQ

In XICTRAQ retention is not a free text field but a plan-based setting enforced by a daily prune run. The same set of values feeds both the disclosure in the interface and the prune job, so the two cannot drift apart - two hand-maintained tables reliably diverge as soon as only one of them is touched. The run removes check logs, certificate checks, security scans, raw analytics records, changelog entries and the associated image files from disk: files first, then the database rows.

For the submission to the data protection officer what counts most is that these values can be retrieved and justified: the plan determines the period, the period is stated in the application, the run enforces it, and the outcome can be verified. This is complemented by processing and hosting in Germany: no transfer to a third country arises that would need additional safeguards under Article 44 and following (GDPR). The cookieless analytics also works without recognising individual visitors and without accessing terminal equipment storage under Section 25 (TDDDG). That removes some of the most sensitive categories at collection time instead of having to delete them laboriously later.

A defensible retention policy is ultimately not a document but a process with four parts: named categories, derived periods, automatic enforcement and a fixed review date. Check in the free trial which periods apply to your data holdings, or have a personal demo show how retention, aggregation and the prune run work together. How the topic fits into the remaining obligations is covered in the overview of GDPR compliance for websites.