The short answer
Review the access a supplier actually has, not only the supplier’s name on a contract list. Identify each account, connection, permission, internal sponsor, and business purpose. Decide whether to retain, narrow, suspend, or remove access, then verify the approved change. Coordinate changes that could affect physical operations with the responsible operations owner.
Illustrated guide
Read the diagram as text
- Identify: Account, permission, purpose, sponsor.
- Decide: Retain, narrow, suspend, or remove.
- Verify: Check the approved change took effect.
Build a list of access paths
A purchasing list will identify suppliers, but it may miss how they connect. Ask IT and application owners for guest accounts, remote support tools, administrative roles, shared folders, service accounts, and application integrations associated with vendors. Include providers that maintain equipment or support a specialist application. Keep the inventory limited to the systems in scope so the first review remains manageable.
For each path, record the supplier, named user or account, destination, permission level, authentication method, and internal sponsor. Identify whether access is always available or enabled for a particular task. Record unknowns as questions. An unfamiliar account could support a necessary integration, while a recognizable supplier name could conceal permissions that are broader than the present business need.
Ask the sponsor to justify continued access
The sponsor should confirm what work the supplier performs now, which information or systems it needs, and when the next access review should occur. A renewed contract does not automatically justify every existing permission. Ask whether support can use a narrower role, a named account, or access enabled only during an approved support window. The technical owner should evaluate whether the proposed restriction is practical.
CISA and NSA guidance on managed service providers in cloud environments discusses shared responsibilities and reviewing provider activity. Apply that idea to the local relationship: identify who approves access, who administers it, and who notices unexpected use. Ask where activity records are kept and who can retrieve them. Do not assume the supplier and customer are both watching the same events.
Make decisions that someone can implement
Use clear outcomes such as retain with a stated purpose, reduce to a named role, disable pending confirmation, or remove after transition. Give each decision an owner and a date. If a supplier needs broad permissions temporarily, document the task, the approval, and the expected end point. Set a reminder that reaches a person who can verify whether the access remains necessary.
Illustrative example: a nonprofit’s event contractor needs a shared planning folder but also retains an old finance group membership. The event owner confirms the current need, finance confirms the old access can end, and IT removes the finance membership. The reviewer then checks effective access. This example illustrates a review workflow and does not describe an actual organization or engagement.
Coordinate changes that affect operations
A water district may have supplier access supporting a maintenance process or operational system. Establish the responsible operations contact before changing that access. Understand what the connection supports, what service window is suitable, and how staff can obtain help if the change prevents necessary work. Keep technical testing and configuration changes within separately approved boundaries.
Ask about dependencies before disabling a shared or service account. Another integration may rely on the same identity. When the account must be replaced, plan the transition and verify the new access before retiring the old path. Avoid sending passwords through ordinary email as a workaround. If ownership cannot be established, escalate the uncertainty to an accountable manager rather than silently accepting it.
Verify removal and improve the next review
A completed request is a starting point for verification. Check the relevant group membership, application assignment, remote access configuration, or integration permission after the approved change. Record the date and the person who checked. Where access exists in multiple systems, verify each relevant path. Removing a cloud guest account does not by itself prove that a separate vendor portal account was removed.
Keep a compact review record containing the access population, sponsor decisions, changes, exceptions, and unresolved items. Use it to improve supplier onboarding and offboarding so future reviews require less reconstruction. If the organization cannot establish its access baseline, the security assessment service at Security Assessment can provide a structured starting point. Review frequency should reflect the access and operational context, with additional reviews when relationships change.
Sources and further reading
This field note is general educational guidance. Your organization’s requirements, scope, and service arrangements determine the work that applies.