How to document SaaS access revocation for an audit

Evidence model

Start with the record, not the PDF

A report is only as reliable as the operational events behind it. Record the access check and revocation when they happen. Do not reconstruct the timeline from memory at the end of the offboarding process.

NIST SP 800-53 Rev. 5.1, control AU-3, describes audit record content in terms of the event, time, location, source, outcome, and identities associated with the event. For SaaS offboarding, those concepts translate into a concrete record of the user, application, reviewer, action actor, timestamp, and result.

Minimum record

Capture the fields another reviewer would need

Subject

The offboarded identity the review covers.

Application

The specific SaaS account, integration, or access surface reviewed.

Observed state

The status seen before action: active, unknown, or already revoked.

Verification actor

The person or system that confirmed the observed state.

Action actor

The person, integration, or vendor administrator that performed the change.

Action and outcome

What was attempted and whether it succeeded, failed, or remains pending.

Time

A timestamp with UTC or an explicit local offset.

Evidence reference

The authoritative source, event identifier, or artifact supporting the result.

Exception

The unresolved risk, owner, and next action when closure is not verified.

NIST also cautions that audit trails can create privacy risk. Keep the record useful, but do not copy unnecessary employee attributes, message content, secrets, tokens, or raw vendor payloads into the evidence package.

Attribution

Keep verification actors and action actors distinct

The person who checks an application is not always the person or system that disables the account. A reliable record preserves both roles:

• Verification actor: observed the access state or confirmed the resulting state from an authoritative source.
• Action actor: performed the revocation. This may be an administrator, an automated connector, or the application vendor.
• Approval or policy owner: authorized an exception or accepted a remaining risk when the workflow requires that decision.

If an integration performed the action, identify the integration as the action actor and retain the accountable human or service context separately. Do not silently attribute automated work to the reviewer who happened to open the record.

Outcome

Use statuses that preserve uncertainty

Unknown is an operational state, not a cosmetic problem. Keep it visible with an owner and next action. That prevents an export from presenting incomplete work as completed revocation.

Example event sequence

This is an illustrative record with role labels, not customer or employee data.

Export boundary

State exactly what the report proves

A generated report can accurately summarize the records included in the export: statuses, actors, timestamps, notes, and evidence references. It should not imply that an external auditor, application vendor, or timestamp authority independently validated the events unless that validation actually occurred.

Cryptographic hashes can help detect whether an artifact changed after export. They do not, on their own, establish who performed the underlying action or whether the source record was correct. Immutable storage and third-party timestamping are separate evidence-hardening decisions.

Use the offboarding checklist to define the operational sequence. Review Sever’s security boundaries and the sample evidence report to evaluate how the resulting record is presented.

Primary references

Sources

• NIST SP 800-53 Rev. 5.1 — AC-2, AU-3, AU-7, AU-8, and AU-9
• NIST SP 800-92 — Guide to Computer Security Log Management

This guide maps operational recordkeeping concepts to SaaS offboarding. It does not certify compliance, prescribe a retention period, or replace requirements set by your auditors, counsel, contracts, or internal policies.