Auditing temporary vendor access grants after the work is finished

Question and scope

This study asks whether every temporary vendor grant issued during a review period is closed, documented, and matched to an approved change. The unit is the grant, not the vendor, because one vendor can hold several short-lived accounts across different systems. The population is every external account or role created for a vendor visit during the quarter. The result is a closure rate and an exception list, not a judgment about the vendor relationship.

Set the review period and the systems in scope before collecting data. Include identity-provider accounts, application roles, VPN profiles, and any shared session tool used for remote support. Exclude vendor accounts that are permanent parts of a managed service, but list them separately so the boundary is visible. The scope note is what keeps the audit from drifting into a general access review.

Define an expiring grant

A temporary grant is an access right that was created for a defined task and was expected to end on a stated date. It may be a named account, a role assignment, a time-bound token, or a support session with a recorded start and end. The definition should name the expected end condition, such as account disabled or token revoked. Without that condition, the audit cannot decide whether the grant is open or closed.

Record the approval, the start time, the planned end time, and the system owner for each grant. If the approval was verbal, note who gave it and when the record was created. A grant with no approval is an exception even if it has already expired, because the process failed at the control point. The audit should surface that pattern rather than only counting open accounts.

Collect the grant record

Pull the account list from the identity provider, the application admin consoles, and the remote support tool. Compare the sources because a vendor can appear in one system and be missing from another. Export the creation date, last sign-in, assigned role, and current status for each external account. Save the raw exports with the audit date so the findings can be reproduced.

Ask the internal owners to confirm which grants they authorized during the period. Their list is often shorter than the system export, and the difference is the interesting part. A vendor account that nobody recognizes may be a leftover from an earlier project or a reseller arrangement. Treat unknown accounts as high-priority exceptions until they are explained.

Verify the revocation

For each grant that should have ended, check that the account is disabled, the role is removed, and any token or key is revoked. Test the sign-in path where the system allows it, rather than trusting a status field alone. A disabled account can still have an active API token or a connected app that bypasses the login. Record which check proved the closure and who performed it.

Check the session and audit logs for sign-ins after the planned end time. A post-expiry sign-in is evidence that the revocation failed or that a credential was not included in the closure. Report the date, the source address, and the action performed if the log provides them. The finding is stronger when it shows exactly what remained possible.

Sample high-risk grants

Read the full record for every grant that touched a high-risk system, such as finance, customer data, identity administration, or network configuration. For lower-risk grants, sample a portion and verify the closure the same way. Weight the sample toward grants with broad roles or long planned durations. The goal is coverage of the risk, not an equal number from every system.

Ask a second reviewer to recheck a handful of the sampled closures independently. Their result should match the first review; a disagreement reveals an ambiguous status field or a check that depends on interpretation. Record the disagreement rate and revise the procedure if it is high. An audit that cannot be repeated by another person is not yet a control.

Report exceptions with age

List every open or unverified grant with its system, owner, approval date, planned end date, and current age. Sort the list by age and by system sensitivity so the reader sees the most serious items first. Add the reason the grant remains open, if it is known. An exception list without an owner and a date is only a complaint.

Summarize the closure rate for the quarter and compare it with the prior period if the data exists. Show the number of grants that required a second reminder before closure, because that measures the process rather than the outcome. Report unknown accounts separately from known grants that expired late. The two problems need different fixes.

Compare access with the change record

Match each grant to the change or ticket that justified it, and confirm that the systems touched fall inside the approved scope. A grant that allowed access to a system the vendor did not need is a scope failure, even if the account closed on time. Note the permissions that exceeded the task. This comparison is where the audit produces the most useful preventive finding.

Check whether the change record includes the rollback and verification steps that the access was meant to support. If the vendor had broad access but no documented change, the approval process is weaker than the account list suggests. Feed that finding back to the owner who approves vendor work. Access control and change control should tell the same story.

Turn findings into a renewal rule

Set a rule for the maximum life of a temporary grant and the conditions that require a fresh approval. Require the account to expire automatically where the platform supports it, with a manual check as the fallback. Add the removal task to the visit checklist with a named owner and a calendar reminder. The rule should be short enough that a busy manager can follow it.

Review the rule after one quarter and compare the exception count with the baseline. If late closures persist, find out whether the problem is the tool, the reminder, or the owner's workload. Adjust one factor at a time so the effect can be seen. A rule that is never reviewed becomes another document nobody uses.

Limits and next use

The audit can only see accounts and tokens that the systems expose. A vendor using a personal remote-access tool outside the approved stack may never appear in the exports. Logs may also be incomplete or retained for too short a period. State those limits so the closure rate is read as evidence about the visible estate, not a guarantee.

Repeat the audit each quarter and track the exception count, the age of the oldest grant, and the number of scope failures. The next study could add a short interview with the system owners about how they approve and remove access. That context explains why a control works in one team and fails in another. The combination is more useful than either source alone.

Set a review cadence that survives turnover

A vendor access audit is easy to run once and hard to sustain. Assign the audit to a role rather than a person, and record the steps in the operations manual so a new administrator can repeat them. Keep the exports and the exception list in a shared folder with the review date. The next reviewer should not have to reconstruct the method from an email thread.

Review the exception list at the monthly operations meeting and close the oldest high-risk item first. If the same vendor appears repeatedly, address the relationship rather than only the individual grant. A vendor that cannot follow the time-bound process may need a different support arrangement. The audit should change the contract, not just the account list.

Report the closure rate and the oldest open grant to the manager each quarter. A simple trend is enough to show whether the process is improving. Celebrate the closures that happened on time, because the people removing access need to see that the work matters. A control that is only noticed when it fails will not last.