Use cases
All four come from the same root: decisions are made, no record remains.
A customer complaint arrives. A record has to be found, a cause understood. Someone connects to production and looks. This is the right behaviour; that is how the work gets done.
Your activity monitoring tool sees that connection. What it sees is a connection. It does not see why the person looked, who found it acceptable, or which data reached the screen.
Six months later, when someone asks who accessed this customer's data and why, you have a connection log but no decision record.
Most organisations run a single change process. A column description and an operation touching millions of rows wait in the same queue.
The damage runs both ways. Small work is slowed for no reason, and large work does not get the attention it deserves among the small items.
The team knows this and compensates. Experienced people sense the risky one and slow down. That is a habit, not a control, and it leaves with the person.
The auditor gives a date range and asks for the changes in that period. The team assembles a table from the ticketing system, release notes, the log platform and people's memory.
The table is accurate. But it was assembled after the fact and carries the interpretation of whoever assembled it. The auditor's real question is this: did you prepare it, or did the system produce it?
Audit readiness is not a seasonal exercise. If the record forms at the moment of the event, there is no preparation stage left.
The policy says it plainly: the person who writes a request does not approve it, and the approver does not run it. The organisation believes this, and usually it does work that way.
What happened at midnight, in a team of three, during a critical incident, nobody can show. It is believed the rule held that night. The difference between believing and showing surfaces during an audit.
A rule is only a rule if the system enforces it. Otherwise it is good intent.