The Engineering Problem Hidden Inside "Who Changed This?"
A record stating that a user changed a value at 14:03 appears useful until an investigation asks the questions that matter: was that person actually authenticated, did they hold the required authority, was the account shared, could the record itself have been altered, and can the change be connected to the exact system state that followed?
In controlled, regulated and high-consequence environments, "who changed this?" is not a simple database query. It is an engineering question about accountable action. A system can be technically functional while still being unable to provide a defensible answer.
Attribution begins before the audit event
An audit trail can only be as reliable as the identity bound to the action. If several people use one account, the system records an account identifier, not a person. If an account is provisioned without an adequate identity-verification process, it may not even represent the intended individual. If credentials are compromised, the audit trail may faithfully record the actions of an unauthorised actor.
This does not make audit records useless. It defines their evidential boundary. A username is evidence that a credential or authenticated session performed an operation. The strength of the claim that a particular person performed it depends on the surrounding identity and authentication controls.
A defensible design therefore starts with unique identities, controlled account lifecycle management and appropriate authentication assurance. Accounts should be created, changed, suspended and removed through defined processes. Privileges must be reviewed when responsibilities change, not only when an annual access review happens to identify an obsolete role.
The authentication mechanism should reflect the consequence of misuse. Password-only access may be unsuitable for administrative or approval actions where credential theft, password reuse or unattended sessions create material risk. Multi-factor authentication can improve assurance, but it is not a universal remedy. Its implementation must account for recovery flows, enrolment controls, factor replacement and the risk that a weak service-desk process becomes the practical route around a stronger login control.
Authority is separate from identity
Knowing who acted does not establish that they were entitled to act. Authentication answers whether a system accepted an identity claim. Authorisation determines what that identity may do in the current context.
This distinction is often blurred in systems built around broad roles such as administrator, supervisor or engineer. Such roles can be operationally convenient but difficult to defend. A role that grants unrestricted access to configuration, data correction, approval and user administration concentrates incompatible powers in one account.
Separation of duties should be designed into the workflow where the risk warrants it. For example, a person proposing a calibration interval change may require independent review before it takes effect. An operator entering a result may be prevented from approving that same result. A system administrator may maintain the platform without being able to modify controlled measurement records.
Authorisation also needs to be evaluated at the point of action, not merely at login. Permissions can change during a session, a user may move between organisational roles, and an approval may be valid only for a particular asset, procedure or site. Recording the effective authority used for a consequential action can be as important as recording the identity.
Session integrity determines whether the event can be trusted
Many significant failures occur after a valid login. A user walks away from an unlocked terminal. A browser session remains active on a shared workstation. A session token is copied from an insecure device. A long-running session retains privileges after the account should have been disabled.
Session controls establish the continuity between authentication and action. Relevant measures include inactivity timeouts appropriate to the operating environment, re-authentication for high-risk operations, session revocation after access changes, protection of session tokens, and controls against concurrent or anomalous sessions where justified by the threat model.
For critical actions, the system may need explicit confirmation of intent. This is not simply another click. A meaningful confirmation binds a defined action, its relevant content and the authenticated user at a known time. If a controlled record is approved, the evidence should identify the approved version, not merely show that an approval occurred somewhere in the workflow.
Time requires similar care. Events from application servers, identity services, databases and connected equipment are difficult to reconstruct if clocks diverge. Time synchronisation, recorded time source where material, timestamp precision and a defined handling of time zones all affect event ordering. In distributed systems, ordering cannot always be inferred from timestamps alone; correlation identifiers and causation links may be needed to reconstruct a sequence.
An audit history must resist convenient revision
An audit table that application administrators can edit or delete is a log, not necessarily a trustworthy history. Even where direct editing is prohibited in the user interface, database access, backup restoration, bulk import utilities and maintenance scripts may provide alternate paths that bypass ordinary controls.
A useful audit record captures sufficient context to explain an event: the object affected, the previous and new values where appropriate, action type, authenticated identity, effective authority, timestamp, originating service or device, and a transaction or correlation identifier. It should also record failed security-relevant attempts where these assist investigation, such as repeated authentication failures or denied privilege escalation.
Immutability is an architectural property, not a field called audit_log. Controls may include append-only storage, restricted write paths, cryptographic integrity checks, independently retained log streams, monitored privileged access and retention policies aligned to the intended use and applicable requirements. Each mechanism has limits. A hash chain detects alteration only if its verification material and validation process are protected. Write-once storage does not establish that the original event was complete or correctly captured.
The objective is not to make change impossible. Controlled systems must be maintained, corrected and evolved. The objective is to ensure that a later reviewer can distinguish authorised correction from concealed alteration, and can establish the state of the record at each relevant point.
Evidence must survive operation, change and investigation
Accountability fails when it is treated as a reporting feature added near release. It must be specified through intended use, risk assessment, security architecture, data model, operating procedures and validation.
Testing should examine adverse conditions, not only the expected audit entry after a successful update. Can an expired session submit a request? What is recorded when a transaction partially fails? Does a bulk import generate attributable history for every changed item? Can an administrator alter records through a maintenance interface without equivalent controls? Are audit records preserved and searchable after migration, restoration or software upgrade?
For regulated use, the applicable legal and regulatory requirements, guidance and organisational procedures must be identified for the specific system and jurisdiction. No generic audit function establishes compliance by itself. Evidence must show that controls are appropriate to the intended use, implemented as specified and maintained under controlled change.
The practical test is straightforward: following an event, can a competent independent reviewer reconstruct what changed, who was authenticated, what authority applied, how the action entered the system, what state resulted and whether the history remains trustworthy? If the answer depends on assumptions outside the evidence, the system has not fully solved the question it appears to answer.