Vendor access
A safe way to grant temporary admin access for a vendor visit
How to scope, grant, log, verify, and close a short-term vendor administrator account without leaving a permanent opening behind.
Start with repeatable IT work that has a clear owner, clear access limits, and a review cadence. Keep risky technical decisions with the manager or provider who owns the system.
Delegation playbook
On this pageJump to section
A vendor visit often begins with a request for administrator access that lasts longer than the visit itself. The engineer needs to change a configuration, the account stays active for weeks, and nobody remembers to remove it. Temporary access works when the work, the time window, and the exit are agreed before the account is created. The goal is to let the vendor finish the job without leaving a permanent door open.
Define the work before access
Ask the vendor to describe the change in plain language, including the systems touched, the expected downtime, and the rollback plan. Convert that description into a short scope note that the internal owner can approve. If the engineer cannot explain what will change, the visit is not ready for access. A clear scope also tells you which permissions are genuinely required and which are merely convenient.
Name the internal owner who will stay accountable for the system during the visit. That person approves the scope, receives the status updates, and signs off on the result. For sensitive systems, ask the vendor to work alongside the owner rather than alone. The arrangement slows the visit slightly and gives the company a witness who understands the change.
Choose the shortest access route
Prefer a time-bound role over a shared administrator password, and prefer a named vendor account over a generic service login. Use the identity provider's temporary access feature where it exists, because it records who granted what and when. If the vendor must use their own tooling, limit the account to the specific application rather than the whole tenant. The shortest route is the one that grants only the permissions the approved change needs.
Check whether the task can be done through a support session instead of a standing account. A screen-sharing session with the owner present may be safer than a new login for a one-hour fix. If the vendor needs to work after hours, record the reason and the window in advance. The route should match the risk, not the vendor's default request template.
Set a start and end time
Write an explicit start and end time for the access grant, including the timezone. The end time should include a buffer for the vendor to finish notes and hand back the system. Calendar the removal as a task with an owner, not as a note in the ticket. Access that depends on someone remembering is access that will outlive its purpose.
Tell the vendor when the account will stop working so they can plan around it. If the work runs long, require a fresh approval with a new end time instead of extending the old grant silently. This rule keeps every extension visible to the owner. It also discourages the habit of requesting access for the whole week to cover a two-hour task.
Log the session
Record the account used, the approver, the start and end time, the systems touched, and the changes made. If the platform supports session recording or command logging, enable it for the visit. The log should let a reviewer reconstruct what happened without interviewing everyone who was online. Keep the log with the change record so the next audit can find it.
Ask the vendor for a short summary at the end of the visit, including anything left unfinished. Compare that summary with the approved scope and note any divergence. A vendor who wandered outside the scope is a signal to tighten the next grant. The log is most useful when it is written while the details are fresh.
Verify the change afterward
Test the result before the access window closes, because the vendor is still available to fix a mistake. Check the configuration, the service health, and any dependent workflow the change was meant to improve. Confirm that the rollback path still works if the change fails later. A change that looks correct but breaks a dependency is not finished.
Have the internal owner sign off in the change record with the date and the evidence. If the vendor left a temporary setting or a test account behind, remove it before closing the task. Note any follow-up work and assign it to a named person. The visit is complete when the system is verified and the cleanup is done, not when the vendor disconnects.
Close and review
Disable the vendor account at the agreed end time and confirm that sign-in fails. Check for API tokens, connected apps, or scheduled jobs created during the visit, because those can outlast the login. Remove any temporary firewall rule or share that was opened for the work. Then record the closure in the same log that tracked the grant.
Review the visit at the next vendor meeting and ask whether the same work could be done with less access next time. Repeated visits for the same task suggest a missing capability or a process the company should own. Feed that finding into the contract or the support plan. Each visit should leave the company with a smaller future access need, not a larger one.
Keep a register of vendor accounts
Maintain one list of every external account that can reach a company system, including the vendor, the system, the owner, and the current status. Update it when a grant is created and when it is closed, not at the end of the quarter. A register that is rebuilt from memory each audit will always miss something. The list should be short enough to review in a single meeting.
Review the register monthly and flag any account whose planned end date has passed. Ask the owner to confirm the closure or explain why the access is still needed. Remove accounts that no longer have a business sponsor, even if they are technically disabled. A dormant account with an owner is still a decision waiting to be made.
Sources and next step
Use the CISA Cross-Sector Cybersecurity Performance Goals and the NIST Cybersecurity Framework 2.0 as primary references for the access, asset, backup, and vendor practices discussed in this guide. The NIST contingency planning guidance supports the restore checks described here. Apply your own policies, contracts, and system documentation to the workflow. Compare this guide with the monthly backup restore spot-check and the temporary vendor access guide before changing a live process.
Keep decisions, approvals, and evidence in systems the business already controls. If the coordination is recurring and your technical owner can define the boundaries, review the IT virtual assistant service areas and contact ITVirtualAssistant to discuss a limited pilot.
Operating brief
What this guide should help you decide
Routine intake, status updates, records, screenshots, and documentation upkeep.
Approvals, risky system changes, security decisions, and final technical judgment.
How to use this guide
Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.
Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.
Workflow
Recommended operating workflow
Define the request
Write what a safe way to grant temporary admin access for a vendor visit means in your company, where requests enter, and what finished work looks like.
Limit the access
Give the assistant only the tool permissions needed for intake, records, status updates, or documentation.
Run a pilot
Use a two-week sample period so the manager can review accuracy before expanding the workflow.
Review patterns
Summarize repeat issues, blocked requests, and escalation volume so the technical owner can improve the process.
Decision rules
| Question | VA fit signal | Escalate when |
|---|---|---|
| Is the work repeatable? | The same request appears weekly and can be described in steps. | The request changes business policy or system design. |
| Can quality be reviewed? | The manager can inspect the output without redoing the work. | Only a senior technical person can judge correctness. |
| Is access contained? | The assistant can work with read-only or role-limited access. | Admin rights, customer data, or security settings are involved. |
Delegation checklist
- Write the intake source, expected output, and manager review cadence.
- Confirm the assistant has only the permissions needed for the workflow.
- List the events that require escalation before work continues.
- Track examples for two weeks before changing the workflow.
- Save examples of good and bad outputs so the assistant has concrete references.
- Review the workflow monthly and remove permissions that are no longer needed.
Example first-week agenda
Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.
What to review before delegating
Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.
What should an IT virtual assistant handle first?
Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.
Get free IT support review