After an incident, teams often discover that some endpoints are logged and others are not, that records show the final result but not the steps leading to it, or that one shared account appears for many different people. These are architectural gaps, not missing dashboard widgets.
Capture events as part of the operation
Define an audit contract for identity-changing actions: account and credential changes, role assignments, access decisions, tenant configuration, API-key lifecycle events, recovery and administration. Identify the acting principal, target resource, time, outcome and relevant policy context without recording secrets.
WebFrolic’s security paper describes audit capture as part of the architecture, with user, session and device context. Validate the actual event coverage and retention in the deployment, then use a consistent schema so events can be searched together.
Preserve the relationship between steps
A single request may trigger multiple nested operations. Logging each operation without a correlation relationship makes the sequence difficult to reconstruct. Give related transactions a shared request identifier and retain ordering and outcomes, including validation failures and interrupted flows.
Immutability can protect evidentiary value, but it does not remove the need for access controls, retention policy, time synchronisation and monitoring for logging failures. Record changes to audit configuration too.
Make audit data useful to responders
Build queries for unusual role grants, repeated recovery attempts, unexpected network changes, credential enrolment and actions by dormant service identities. Keep dashboards aligned with the fields operators need to make decisions.
Do not turn audit records into a secondary credential store. Never include passwords, OTP values, private keys or full bearer tokens. Use identifiers and decision metadata that make events traceable without exposing the secret whose misuse you want to detect.
Test the trail before release
For each sensitive flow, confirm that successful, denied and failed operations are recorded. Test whether retries create misleading duplicates, nested actions share context and failures in the audit path are handled according to policy. Logging that silently fails under load is not dependable.
Ask someone unfamiliar with the implementation to reconstruct a sample incident. If they need source-code access or guesswork to connect events, improve the record shape, correlation and documentation.
What to ask your own team
Define a minimum event schema for sensitive identity operations?
Correlate nested transactions and retain order and outcome?
Exclude secrets while preserving principal, resource and policy context?
Test successful, denied, repeated and partial-failure cases?
Implementation guide
Design an event record that helps an investigator
An audit event should answer five basic questions: who or what acted, what resource was affected, which action was attempted, which policy context applied, and what happened. Complex identity journeys add two more: which larger transaction did the action belong to, and which step came before it?
Choose a stable event schema
Structured, consistent events are easier to correlate than free-form messages. The schema below is illustrative and deliberately contains no access token, password, OTP, session cookie or private key.
{
"eventId": "evt_demo_00081",
"timestamp": "2026-10-23T10:22:41Z",
"transactionId": "txn_demo_014",
"parentTransactionId": "txn_demo_009",
"actor": {"type": "employee", "id": "user_demo_204"},
"action": "tenant.member.role_changed",
"resource": {"type": "tenant_member", "id": "member_demo_016"},
"policy": {"id": "tenant-admin-policy", "version": "7"},
"result": "denied",
"reasonCode": "role_not_in_scope",
"sourceContext": {"networkRule": "tenant-admin-egress"}
}Do not copy this JSON as a WebFrolic event contract. Use it as a design prompt: decide which fields must be stable, which values are safe to retain, and how events from separate services will be correlated. Prefer opaque identifiers over unnecessary personal data.
- Capture the operation
- Correlate transaction steps
- Protect and retain records
- Test investigation use
Protect confidentiality as well as integrity
Logs can become a secret store by accident. Avoid recording raw credentials, access tokens, session identifiers, TOTP secrets or full request bodies that may contain sensitive data. Where a value is needed for correlation, use a safe opaque identifier or a controlled hash; restrict access to log data itself; and define how long records remain available.
Test logging failure paths
Security logging needs tests of its own. Verify that denied actions are recorded, malformed inputs cannot inject fake events, clock differences do not make a transaction impossible to reconstruct, and temporary logging outages create an alert or bounded recovery path. Also decide which operations must fail closed if evidence cannot be recorded, based on risk and system requirements.
Audit readiness checklist
Ask the team to demonstrate
- Can an investigator find the actor, target, timestamp, decision and outcome for a sensitive action?
- Can related enrollment, step-up, recovery and authorization transactions be reconstructed in order?
- Are secrets and unnecessary personal data excluded or masked?
- Are records protected against unauthorized reading, modification and deletion?
- Are retention, access reviews, backup and incident-response retrieval tested?
- Are logging loss, injection attempts, malformed records and time skew included in test plans?
WebFrolic's product materials describe audit capture as an architectural concern and reference user, session and device context. A deployment review should verify exact event coverage, retention settings, access permissions, delivery guarantees and export behavior; a product-level design statement is not by itself evidence of every operational configuration.
Further reading
- OWASP Logging Cheat Sheet: event selection, sensitive data, protection and testing.
- NIST SP 800-92 — Guide to Computer Security Log Management.
- WebFrolic Audit, Transactions and the security white paper.
Useful evidence is not the largest log. It is the smallest reliable record that lets the right person reconstruct an action and decide what to do next.