RPA audit logs should record which bot did what, to which record, when, under which workflow version and for which owner. They should never contain passwords, tokens or unnecessary personal data. If a log cannot answer who changed this record, and why, it will not help in an incident.
Why bot logging is different
When a person makes a change, the application usually logs their name. When a bot makes a change, the log often shows only a service account. If that account is shared or generic, the trail goes cold. The OWASP Citizen Development Top 10 includes security logging and monitoring failures as a risk, and it applies to bots as much as to apps.
Fields to record for every run
| Field | Why it matters |
|---|---|
| Bot name and account | Ties the action to one identity |
| Workflow name and version | Shows which logic ran, so you can tell if a change caused a problem |
| Owner | Tells responders who to call |
| Start and end time | Lets you spot runs outside the schedule |
| Trigger | Schedule, event or a named person who started it |
| Systems touched | Shows scope in an incident |
| Records read and changed, by reference | Allows rollback without copying the data itself |
| Result and error codes | Distinguishes success, partial work and failure |
| Approver, if a step needed one | Evidences the human check |
Record references such as a record number, not the contents of the record.
What must never be in the log
- Passwords, tokens, API keys or session cookies. The OWASP Secrets Management Cheat Sheet says to make sure pipeline output does not leak secrets, and the same logic applies to bot output.
- Full card numbers, national identifiers or health details unless there is a clear need and protection.
- Screen captures of sensitive fields without masking.
- Full request and response bodies from the target system, which may carry all of the above.
Protect the logs themselves
The Secrets Management Cheat Sheet says auditing must be implemented so it is resilient against attempts to tamper with or delete audit logs. For bot logs, that means the bot account should not be able to edit or delete its own logs, and logs should be copied to a place that only a small group can alter.
Make logs usable
- Use one consistent format across bots so you can search them together.
- Set a retention period that matches your rules and your customers' expectations.
- Alert on patterns that matter: runs outside schedule, large record counts, repeated failures, a bot account signing in interactively.
- Review a sample of logs at your regular access review to confirm they still answer the key questions.
Tie logs to your compliance work
If you work towards a framework, bot logs are part of the evidence that access is monitored. Keep your claim modest: say what you log and review, rather than implying an outcome.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you organise records like these against the controls you track.
Try it yourself
Open the demo, pick a control that mentions monitoring or logging and look at how evidence is linked to it. Think about which of your bot log fields could serve as that evidence.
Click through it at your own pace, or open it full screen.
Quick check
Is it enough to log that a bot ran?
No. You also need what it touched, which version ran and who owns it, otherwise the log cannot support an investigation.
Can the bot write its own logs?
It can write them, but it should not be able to edit or delete them afterwards.
Sources
Last reviewed: 19 October 2026.
