Introduction
"For the sake of auditing, keeping every log forever is the right answer" — that's what I thought at first. But a point audit log contains customer IDs and operation histories. In other words, the log itself is a mass of personal data.
The more you keep, the easier tracing becomes — but at the same time, "the damage if it leaks" and "the cost of guarding it" both swell. In this article, I'll explain how to balance privacy against securing the range needed for auditing: the design of retention periods and deletion. This is my thinking.
The Log Is "Convenient" and a "Risk" at Once
An Audit Log Is Personal Data Itself
A single row of a point audit log records "who moved how many points, and when." It's highly sensitive information, tying a customer ID to purchasing behavior.
The more you keep, the more you're responsible for
The log is a friend to your operations, but a leak becomes a serious incident — "each customer's entire purchase and point history spilled out." It's important to hold the sense that data carries responsibility simply by being held.
That's exactly why, rather than "just keep everything," you need to decide "for what purpose, and until when it's needed" by working backward from the goal. Not holding too much is itself a fine piece of security design.
Required Periods Differ by Purpose
There isn't just one purpose for a log. And the required retention period changes by purpose. Thinking about these separately makes the design far cleaner.
You don't need to align everything to the longest period. Deciding a period per purpose and letting go of what has served its role keeps risk down.
How to Design Retention Periods
Set a Period and Delete Automatically
The thing to avoid most is a state where "there's no mechanism to delete, and before you know it, years of data have piled up." So I built in a mechanism that automatically processes logs past their retention period.
Leave one event row each time an operation occurs
Retain it in a state usable for reconciliation and investigation
Periodically comb out events past the retention period
Erase or sever the information tied to an individual
By not relying on manual work and letting expired items be processed mechanically, you structurally eliminate the most common risk of all: forgetting to delete.
Not a Full Wipe — "Anonymization" as an Option
Deleting an expired log entirely also makes statistics and trend analysis impossible. That's where anonymization — severing only the parts that can identify an individual — becomes useful.
Risk drops to zero, but aggregation and trend analysis become impossible too
Sever the customer ID and keep only statistical use, lowering risk
Remove the customer ID, and you can still keep the trend in numbers — "when, what kind of operation, and how much of it happened." With this one bit of ingenuity — keeping it only in a form where individuals can't be identified — you reconcile utility with privacy.
Establishing Operations and Rules
Narrow Down Who Can Access It
Logs during their retention period are sensitive, so they're not left in a state anyone can view. You limit who can view them, and record "who viewed the log, and when" itself. It's a double structure — auditing even the act of viewing the audit log.
The principle of least privilege
It's enough for the people who need it to see the range they need, only when they need it. A state where everyone has full access adds risk beyond its convenience. The tighter you scope permissions, the safer it gets.
Precisely because this is a history of points equivalent to money, you keep a record of "who touched that record" as well. This also serves as a deterrent to fraud.
Build Deletion Requests into the Design
These days, a request can come directly from the customer to "delete my data." At that point, you need to have decided in advance how to handle the relevant data within the audit log.
While there's still an accounting obligation to retain data for a period you can't delete it, but once that obligation lapses, the data becomes a candidate for deletion or anonymization. If you design so you can separate "what can be deleted" from "what can't be deleted yet," you can respond to such requests without panic. Weaving this in from the start is far easier than bolting rules on afterward.
Conclusion
Keep too much and an audit log is a risk; keep too little and it's untraceable. Designing that just-right landing spot is the role of the retention period.
- Decide the required period per purpose — don't align everything to the longest
- Delete or anonymize automatically at expiry — structurally eliminate forgotten deletions
- Narrow access, and record viewing too — handle sensitive data sensitively
The contents of the log that underpin retention are explained in "Designing Event Records for Grants, Spends, and Conversions," and the overall design philosophy of the audit log in the hub article "Point Audit Logs."