Security
Design audit logs around the questions you will be asked
Audit logging works best designed backward from the few questions auditors ask, with retention set by policy rather than by tool defaults.
Audit logging fails in one of two directions. Either the system records almost nothing, so a question about who viewed a resident's file last spring has no answer, or it records everything and the answer sits inside a year of unsearchable text that is expensive to keep. Both failures look the same from the auditor's chair.
A more productive approach is to design the log backward. Start from the questions the system will be asked, then work back to the events that answer them.
Start with the questions
Write the questions down before touching any configuration. For most agency systems the list is short:
- Who accessed this record, and when?
- Who changed this field, what was the value before, and what is it now?
- Who granted this person access, who approved it, and did the access end on time?
- Who ran this report or exported this data?
- Who changed the configuration of the system itself?
Auditors, records officers, and attorneys handling a records request or a litigation hold ask variations of these. A design that answers them precisely beats one that captures more volume and cannot answer any of them without a forensic exercise.
A small set of fields answers most of them
Once the questions are fixed, the shape of the event follows. A structured record with a stable set of fields carries most of the weight:
- A timestamp in UTC from a synchronized clock
- The actor, as an immutable user identifier, not only a display name that can be edited or reused
- The action, drawn from a controlled vocabulary rather than free text
- The target, as a record type and identifier
- The outcome, including denials, which are often the interesting ones
- The source address, and a correlation identifier tying related events across services
Free text messages are for humans debugging. Audit events are for queries. A field that is not queryable will not answer anything under time pressure.
Audit logs are not debug logs
Mixing the two is a common design mistake. Debug logs are verbose, written by developers for developers, and safe to discard in days or weeks. Audit events are narrow, stable, written for a reader who is not an engineer, and kept as long as the retention schedule requires.
Separate them. The audit stream goes to storage with restricted access and append-only behavior; the debug stream stays cheap and short-lived. Separation also keeps the audit log free of content that verbose logging drags in:
- Credentials, tokens, session identifiers, and query strings carrying sensitive values
- Full record payloads, when an identifier and the changed field names would do
- Protected content copied into a store with weaker controls than the source system
If before and after values are required, protect the log at the same level as the record it describes.
Retention is a policy question
The right retention period comes from the records retention schedule covering the system, from sector rules for the data, and from any litigation hold in effect, not from the logging tool's default. Three places to look:
- Federal agencies work from NARA general records schedules, which include one for information systems security records. State and local agencies work from schedules issued by their state archives or records administrator.
- For criminal justice information, the FBI CJIS Security Policy sets audit and accountability requirements, including retention of audit records. It is revised periodically, so confirm the current period with your state's CJIS Systems Agency.
- For health data, the HIPAA Security Rule requires audit controls but sets no retention period for audit logs. The six-year figure usually cited comes from its documentation retention requirement, a separate obligation.
For the controls themselves, the Audit and Accountability family in NIST SP 800-53 is a workable checklist.
Audit logs can themselves be records, reachable through public records requests and through discovery depending on jurisdiction and content, so keeping them past the schedule creates obligation rather than safety. Retention is also rarely one number: keep recent events searchable and move older events to archival storage.
Make the log defensible
An audit log is only as good as the argument that it is complete and unaltered. Write to a destination the application cannot rewrite, in an account separate from the system being logged. Restrict who can read it, and log those reads. Keep clocks synchronized. Watch for gaps in the stream, because a silent logging failure looks the same as a quiet week. Make deletion an administrative action that is itself recorded.
Rehearse the answer
Treat this as a drill. Pick a record, pick a date range, and answer the question end to end: who touched this, when, and from where. Time it. If it takes an afternoon and a developer with database access, the design has failed. In our own reference builds, the drill is what exposes the missing field, the unwritten report, or the uninstrumented export path.
What to ask for
Ask your vendors and your own teams one concrete question: show me the query that answers who viewed this record in the last year, where that log lives, and when it gets deleted. Put the answer in the requirements for the next system you buy. Auditors do not grade volume; they ask a handful of narrow questions and expect precise answers.