Retention for VPN Logs: Tie It to the Incident, Not a Number
Retention follows the incident, the content and the policy, not a universal deadline. Find every copy, stop verbose collection, and keep a short record.
Nobody actually asks how long to keep a VPN log; they ask what the log is for, and the answer to that sets the date. Two files can come out of one incident with different lifetimes, and treating them as one policy produces both over-retention and lost evidence. A debug export captured while the cause was unknown is not the same artifact as a line in a monitoring store. Start from the purpose, then pick the date.
Answer four questions before you pick a date
Four questions decide whether a file stays: is the incident still open, what does the file contain, who needs to read it, and what does the applicable policy require. Answer them in that order and the retention date falls out. The reasoning fits in a table:
| Question | How it moves the answer |
|---|---|
| Incident state | An open investigation justifies a protected original; a closed one rarely does |
| Content | Connection identifiers, internal names and addresses raise the cost of a leak |
| Audience | Who retrieves it, and whether a redacted excerpt would serve them instead |
| Policy floor | The applicable service or organizational rule, which overrides a shorter reasoning |
While the incident is open, keep one protected original so you can compare events or answer a support question later, and give it an owner and a purpose in writing. For anyone outside the response team a short redacted excerpt is usually enough, and it is far easier to defend than the full export. The original and the excerpt are separate artifacts with separate audiences, and merging them is what creates both over-retention and lost evidence. The policy sets a floor, so if it demands longer than your reasoning, the policy wins.
Close the incident with a record, not an export
Write a four-line record into the ticket: the symptom, the client and version, the one error line that identified it, and the fix. Attach nothing else, because the export was for you and the record is for the next person.
The record is also more likely to be read: the full export mostly serves whoever captured it, and that person already knows what happened. Keep the record where the next incident will be searched for, which usually means the ticket rather than a folder named after a date. A case number can carry the reference if the record has to be traceable without exposing a connection identifier. If a question is still open, the original stays under the protected-copy rule above; once the record exists, everything else can go.
Find every copy before you delete one
Look in the export folder, then the journal for the incident window, then the ticket attachments, then the backup catalog, then the monitoring store. If the same connection identifier turns up in a fifth place, the inventory was wrong. The journal is the usual surprise, because it kept collecting while you were reading the export.
Use the supported rotation and deletion path instead of unlinking files by hand. A file that is still open keeps its storage after the directory entry disappears, so the deletion looks complete and frees nothing. That is a storage bug wearing a privacy label, and it satisfies neither goal.
Stop the collection before you verify the deletion
Stop the temporary verbose collection through the application that owns it, not by editing its output file. A forgotten debug setting keeps writing fresh records after the old ones are removed, which quietly undoes the work you just did. Check the effective logging level rather than the value you remember setting. Then confirm that what remains is protected and that only the intended people can retrieve it.
The principle is data minimization: keep what a stated purpose needs, for as long as it needs it, and nothing more, as the RFC 6973 privacy guidance frames it. A file kept without a purpose is a liability with a timestamp. The decision is finished when you can name the file, its purpose, its owner and its end date.