Seven Years of Logs and Three Jurisdictions

The framing 'how long must we keep logs' hides the real question, which is 'what evidence does each purpose require, and for how long'. Retention is governed by necessity and purpose limitation, not by choosing the longest period anyone has asked for. Keeping raw authentication logs containing email addresses, IP addresses and health-indicating URLs for seven years is unlikely to be justifiable; keeping proof that a control operated for seven years usually is.

Separate the artefacts. The auditor's underlying requirement is evidence of control operation for a financial test - that the authentication control was configured and functioned in each audit period. That can be satisfied by monthly signed extracts of authentication events, control configuration snapshots with hashes, or aggregated access statistics retained for the required period, while raw logs age out at 12 months. Offer these alternatives explicitly and get the auditor's written agreement; auditors frequently accept derived evidence once the control objective is discussed rather than the data format.

Check the actual statutory basis. Financial record-retention rules typically cover transaction and accounting records, not authentication logs, and the auditor may be applying a general rule loosely. Where a longer period is genuinely mandated in a jurisdiction, retain only the minimum fields needed and pseudonymise identifiers.

Tier the schedule and document it:

• Raw logs: 12 months, the period needed for detection, investigation and the typical breach-investigation window.
• Security-event metadata and control evidence: the audit-required period, minimised and access-restricted.
• Legal hold: overrides deletion entirely for a defined scope, applied automatically on incident or inquiry, with a named owner and a tested mechanism to suspend deletion.

The legal hold is the critical control here, because the regulator inquiry may well touch authentication records. Confirm that automated deletion will not remove in-scope data before the response is due.

Start with roles. Vantis is the controller of employee data; the MSSP is a processor; the US-hosted SIEM vendor may be a further processor or sub-processor. Each leg needs a lawful transfer mechanism, a data processing agreement with sub-processor flow-down, confidentiality and training obligations, and a transfer impact assessment covering government access in the destination. The DPO's observation that URLs reveal health-related absences is the most important fact here: that can elevate the data to a special category, which changes the analysis and the safeguards required.

Controls to require:

• Minimisation at collection. Filter or truncate full URLs, strip query strings likely to carry health terms, and avoid ingesting content fields that are not needed for detection. Most SIEM use cases need domain and path, not parameters.
• Pseudonymisation of user identifiers in the raw log stream, with a lookup held in the EU and access controlled.
• Role-based access inside the MSSP, limited to named analysts on named shifts, with logs of analyst queries and periodic attestation of who has access.
• Contractual controls: prohibition on using the data for any other purpose, no onward transfer without approval, breach notification timelines, deletion and return on exit, and audit rights.
• A regional architecture option for the localisation requirement: a log collection node in-country that retains the regulated category locally, forwarding only filtered or aggregated events out. Whether this satisfies the localisation law depends on its exact wording - obtain local counsel's written view rather than assuming a technical workaround is sufficient, and check whether the requirement also covers remote access from abroad.

The realistic plan is to have the filtering and pseudonymisation in place quickly, since they reduce risk regardless of the localisation question, and to run the architectural decision in parallel with legal analysis. Employee monitoring and works council consultation may also apply in the EU and should be handled by the DPO, not by security.

Treat these as two matters that may or may not be connected, and do not let the inquiry deadline distort the investigation.

Day one to three: issue a preservation notice covering the misdirected email, related mailboxes, the acquired subsidiary's marketing systems and the contact lists. Instruct that nothing be deleted, including the lists, notwithstanding their unlawful basis - destruction during an inquiry is far worse than the underlying defect. Engage external counsel so that the inquiry response and the internal investigation attract privilege where available.

Scope the misdirected email: which data subjects, what categories of information, whether the recipients included external parties, whether recall succeeded, and whether any onward forwarding occurred. If the exposure is likely to result in high risk to the individuals, notification to affected patients is likely required and should not wait for the regulator's view; prepare it in parallel with the response.

On the consent lists, establish the facts before forming a position: what was purchased, from whom, under what representations, whether any permission can be traced, and whether the acquisition due diligence covered data assets. Remediation options are re-permissioning, which is usually impractical for purchased lists, or deletion with recorded evidence. Deleting is often the right answer, but only under a documented decision that preserves the audit trail. Report the acquisition as a governance finding: data and security diligence is required pre-close, with a mandatory 100-day integration control review.

For the 14-day response, be accurate rather than comprehensive. Confirm what is known, state what is still being established with dates, describe containment and remediation already completed, and name accountable owners. A short, truthful, dated response with a plan reads far better than a defensive submission that later proves incomplete. Brief the board before it goes, and align the insurance notification and any other regulator contact so the organisation speaks with one voice.