Audit Tenant Access Changes

When a member gains or loses access, the product needs an audit record that can answer who changed what and when. A generic “settings updated” event cannot reconstruct a permission change. A full request body may expose tokens or personal data. Design the event to carry the decision, not the secret. The OWASP Logging Cheat Sheet covers security-event content and sensitive-data exclusions.

Access event schema

Use stable identifiers only as needed. Keep invite tokens, session cookies, full API keys, and private record bodies out of the event. Apply access control to the audit viewer, because the event stream itself reveals staff and customer activity.

Verify the record

Create a synthetic tenant. Invite a member, change a role, revoke it, and test an invalid change. Check that successful transitions emit one accurate event and denied transitions emit a safe denial event without a grant. Compare event order with the stored membership state. A queued event can arrive late; it should retain the original action time and a correlation ID.

The OWASP Authorization Cheat Sheet explains why role changes need explicit decisions. This event schema is evidence for those decisions, not proof that the policy was correct. The reviewer should be able to compare the event with the rule and result. If the system cannot distinguish an admin grant from a support override, add that distinction before relying on the log for incident review.

Illustrative failure case: commit an A member-role change, then interrupt audit delivery before acknowledgement. Retry the same action ID. Require one final membership state and one grant event with that action ID. If membership and event cannot share a transaction, retain a durable pending event and reconcile it; do not report the change as fully audited while its event is missing.