An AppSec tool should log who signed in, who changed roles, policies, tokens and integrations, who approved exceptions, and who exported data, with timestamps and identities, and let you export those logs to your own systems. Without that, you cannot prove who changed a gate or dismissed a finding.
Why the tool's own logs matter
The scanner decides what ships. Anyone who can edit a policy, mute a finding or create a token can change that outcome. Auditors and incident responders will ask who did it. The answer has to come from a log you can trust and keep.
OWASP's logging guidance lists events worth recording: authentication successes and failures, authorization failures, user administration including adding or assigning tokens, all actions by administrators, use of break glass accounts and configuration changes. That list translates directly into an AppSec checklist.
Events to require
| Area | Example events |
|---|---|
| Identity | Sign in, failed sign in, SSO assertion errors, session end |
| Access | Role granted or removed, user added or removed, group mapping changes |
| Tokens | API token created, scoped, used, revoked |
| Policy | Gate edited, severity override, exception approved or expired |
| Data | Report or findings export, bulk download, retention change |
| Integration | Repository connected or disconnected, webhook changed |
Fields every entry needs
- Time of the event, in a consistent time zone
- Actor identity, including service accounts
- Source address or device where available
- Action and target object
- Result, success or failure
- Before and after values for policy changes
Logs should not contain source code or secret values. The same OWASP guidance says not to log access tokens, passwords or source code.
Retention and access
CISA's Secure by Demand guide tells buyers to ask whether security logs are included in the base product, and notes an expectation that cloud providers retain logs for at least six months at no extra charge. Use that as an opening position, then match your own policy and any audit period you must cover. Ask whether logs can be streamed to your storage through an API or a webhook, since a vendor console is a poor long term archive.
How to test in a pilot
- Change a gate setting, then find the entry.
- Create and revoke a token, then find both entries.
- Approve an exception as a second user.
- Export findings and confirm the export is logged.
- Try to edit or delete a log entry as an admin. It should not be possible.
Time how long a log entry takes to appear. Delays make incident work harder.
Tie it to evidence
For SOC 2 style audits, these logs are the evidence behind change management and access control claims. Keep a sample export in your evidence folder. See access review evidence.
Safeguard offers compliance and evidence automation, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Is a vendor's SOC 2 report a substitute for these logs?
No. A report describes the vendor's own controls. You still need logs of what your users and admins did inside your tenant.
How long should we keep AppSec tool audit logs?
At least as long as your audit and incident review windows. CISA's guide cites six months as a baseline buyers can ask for.
Sources
Last reviewed: 19 October 2026.
