How to keep an audit log of actions in custom software
An audit log for custom software records who signed in, who exported, who approved, and who changed a setting, and it states how long those lines are kept, whether an old line may be altered, and who may read them. The operations runbook says where this shift looks for logs. Scope change says who may accept a change to the spec. Knowledge-base access says who may search, open, or export in the library. This note is the record of those four actions inside the business application.
On this page
- Keep the operations log apart from the runbook, scope change, and the library
- Select sign-in, export, approval, and a change of settings
- A line that has been written is protected from change and from deletion
- Name who may read, and give them read-only access
- The company writes how long the lines are kept
- Tell a named person when an unauthorized change is detected
- A correction is a new line that points back at the original
- The log is in use when the four actions, the readers, and the retention period are written
Keep the operations log apart from the runbook, scope change, and the library
The runbook answers where the logs and the boards sit once production is in use, and which step this shift checks first. Scope change answers whether the spec changes and who may accept that change. Knowledge-base access answers who may search, open, or export a set of documents, and which audit fields those actions carry. The operations audit log answers a different question: in this business application, who signed in, exported, approved, or changed a setting, and whether the original line can still be read afterwards. The four can point at the same operation number. See How to write an operations runbook for custom software, How to control scope changes in custom software, and How to set access levels on a knowledge base.
Delivery still sits under Custom software, websites, and applications. If an incident timeline cites the log, see How to write an incident postmortem for custom software. The cover states the log's version, where it is kept, and which application version it matches. The library's actions are not copied into the business application, and these four actions are not used as the library's permission table.
Select sign-in, export, approval, and a change of settings
The electronic catalog NIST SP 800-53 Rev. 5.2.0, read on 2 November 2026, is titled Electronic (OSCAL) Version of NIST SP 800-53 Rev 5.2.0 Controls. Its metadata last-modified is 2026-10-22, and the version is 5.2.0. AU-2 in that catalog says to identify the event types the system is capable of logging, to select which of them are logged, and to say why those types are adequate for an investigation afterwards. The knowledge-base note already uses it for search, open, and export. This note selects four actions in the business application: sign-in, export, approval, and a change of settings.
Each action has a rationale: sign-in shows who came in, export shows whether data left, approval shows who agreed, and a change of settings shows who altered a parameter. An action with a blank rationale is not yet a selected event, and the application does not write it into this log. The catalog does not require a fifth action, and it does not set a number of seconds in which a line must be written. If the company adds another action, the same row names it, gives the rationale, and dates the choice.
A line that has been written is protected from change and from deletion
AU-9 says to protect audit information and audit logging tools from unauthorized access, modification, and deletion, and to alert organization-defined personnel or roles when unauthorized access, modification, or deletion is detected. The discussion says audit information includes audit records, audit log settings, audit reports, and personally identifiable information in them. Protection is technical, and it limits who may access and run the logging tools to people who are authorized. Physical protection is not this note.
Enhancement AU-9(1) says to write audit trails to hardware-enforced, write-once media. The discussion says that applies to the first writing of the trail and to the backup. It is an enhancement. It is not a medium every custom application has to buy. If the company selects it, the record names the medium and the day it was turned on. If it does not, old lines are still not edited and not deleted. A correction is a new line. Saying that the previous line should be fixed does not replace that new line.
Name who may read, and give them read-only access
AU-9(6) says to authorize read-only access to audit information for an organization-defined subset of privileged users or roles. The discussion says restricting those authorizations to read-only limits the damage such users could do, for example deleting records to cover up activity. The catalog does not list job titles, and it does not say that the person who approves a transaction may read the log.
The company writes the people or roles who may read, and dates the list. People on the list may read. They may not change a line and they may not delete one. A person who approved a transaction, or who changed a setting, does not open the log unless that person is on the list. If the list is blank, the log is not open for anyone to browse. If a read is itself recorded, that is a new line saying who read which span and when. The body of the log is not pasted into the new line.
The company writes how long the lines are kept
AU-11 says to retain audit records for an organization-defined time period, so they can support an investigation afterwards and meet regulatory and organizational retention requirements. The discussion says organizations keep the records until they are no longer needed for administrative, legal, audit, or other operational purposes. Its examples include Freedom of Information Act requests, subpoenas, and law-enforcement actions, and it says the National Archives and Records Administration General Records Schedules are federal policy on retention. Those examples belong to the discussion. They are not this company's schedule.
The company writes a retention period for the four actions, who set it, the day it was set, and which kind of later investigation the period is meant to support. A blank period is not filled with an estimated day on which lines are deleted. When a period ends and lines are removed, someone who is allowed to delete, and who is not merely on the read-only list, signs. People on the read-only list cannot delete. The deletion is a new line. During the retention period the old line stays as it was.
Tell a named person when an unauthorized change is detected
AU-9 says to alert the named personnel when unauthorized access, modification, or deletion is detected. The company writes that person's name on the cover. The name may differ from the read-only list. If the name is blank, a detected event has no recipient, and the protection of this log is not yet written.
The alert states the time, whether it was access, modification, or deletion, and which span of the log it concerns. The alert does not replace a new audit line. If the event is carried into an incident postmortem, the timeline stays in that note. The cause is not rewritten inside the alert. If the named person is away, the deputy already written on the cover receives it. If no deputy is written, the person on duty does not receive it in their place.
A correction is a new line that points back at the original
A failed sign-in, a refused export, a rejected approval, and a setting change that did not pass are still written, with the outcome marked refused. A line with no outcome is not complete. Each of the four actions has to be able to fill the audit content the knowledge-base note already lists: type, time, place, source, outcome, and identity. Those fields are not redefined here. See How to set access levels on a knowledge base.
If a line is found to be wrong, that line is not opened and edited. A new line records the correction, points at the original time and identifier, states the corrected content, and is signed by the person who wrote it. The original line stays readable. When both lines could be taken as what was true at the time, the earlier line is the record of that time. The correction only explains the later change.
The log is in use when the four actions, the readers, and the retention period are written
If one of the four actions has no rationale, if the read-only list is blank, if the retention period is blank, or if nobody is named to receive an alert, this log is not treated as being kept. The application may write events to a temporary store first. That store is not this log, and it is not what an investigation cites.
Three checks show the log is being kept: sign-in, export, approval, and a change of settings each have a rationale and can record an outcome; an old line cannot be changed or deleted, and a correction is a new line; the read-only list and the retention period both have a date. A blank item means an investigation does not cite this batch of records.