Vendor Risk
Vendor access follows least privilege, MFA where feasible, approved connection methods, logging, and prompt revocation when no longer needed.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Third parties receive only the systems and privileges needed for an approved purpose, use controlled authentication and connection methods, leave useful activity records, and lose access promptly when the need ends.
First SOC 2 program
Require a named company sponsor and ticket for every vendor account or connection. Use individual accounts, least privilege, multifactor authentication where feasible, a defined expiration date, and a simple quarterly review of all third-party access.
As the company scales
Centralize vendor identities through the identity provider or privileged-access platform, automate time-bound provisioning and revocation from approved requests and contract status, monitor privileged sessions, and run risk-based access certification with system owners.
Identify vendor user accounts, privileged sessions, support connections, virtual private network access, API keys, service accounts, integrations, and physical access where applicable.
You should end up with: A vendor-access inventory linked to the vendor, sponsor, system, privilege, and connection method.
Document the business purpose, requested systems and privileges, named users, data exposure, duration, sponsor, and system-owner approval before provisioning.
You should end up with: An approved access request that supports every active vendor access path.
Use individual identities where possible, apply least privilege, enable strong authentication, restrict connection routes, set expiration, and avoid persistent administrative access unless justified.
You should end up with: Configuration evidence showing identity, privilege, authentication, restrictions, and activation date.
Retain authentication and relevant administrative activity, alert on unusual or unauthorized behavior, and define who investigates vendor-access events.
You should end up with: Access and activity logs, alert configuration, and linked investigations where applicable.
Have the company sponsor and system owner periodically confirm the vendor relationship, named users, business need, privilege, and access method.
You should end up with: A dated access review population with decisions and completed removals or changes.
Remove vendor identities, privileges, keys, integrations, sessions, and network paths when work ends, a user leaves, a contract terminates, or risk becomes unacceptable.
You should end up with: Revocation records tied to the triggering event and verified across all known access paths.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Each vendor identity or connection has a current business purpose, company sponsor, named user or workload, scoped privilege, duration, and system-owner approval before provisioning.
Include this context
request and vendor identifier
Include this context
named user or workload
Include this context
business purpose and sponsor
Include this context
system and requested privilege
Include this context
start and expiration dates
Include this context
approvers and timestamps
Weak evidence to avoid
A ticket asking to give vendor support access with no named vendor user, target system, privilege, sponsor, duration, data exposure, or owner approval.
Confirm what the record proves
Business sponsors and system owners periodically assessed both continued need and least-privilege scope for every vendor access path and completed removals.
Include this context
review identifier and period
Include this context
reviewed access population
Include this context
sponsor and system owner
Include this context
retain, modify, or remove decision
Include this context
decision date
Include this context
completion evidence
Weak evidence to avoid
A manager certifies VendorCo still used without seeing individual accounts, roles, API keys, integrations, or evidence that removal decisions were completed.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Applicable vendor human identities use multifactor authentication, and any infeasible use has an approved, time-bounded alternative safeguard.
Include this context
vendor identity
Include this context
target system
Include this context
authentication method
Include this context
MFA enrollment or enforcement state
Include this context
effective date
Include this context
exception reference if applicable
Weak evidence to avoid
A global identity-provider settings screenshot that does not identify the vendor accounts, enforcement scope, enrollment state, date, or excluded connection method.
Confirm what the record proves
The complete current population of vendor human and nonhuman access can be connected to a vendor, sponsor, system, privilege, creation date, and status.
Include this context
identity, key, or integration identifier
Include this context
vendor and sponsor
Include this context
system and privilege
Include this context
identity type
Include this context
created and last-used dates
Include this context
status and expiration
Weak evidence to avoid
An application user list with external email addresses but no vendor association, sponsor, role detail, service-account coverage, creation date, or expiration.
Confirm what the record proves
Access removal was triggered and completed across accounts, sessions, credentials, integrations, and connection paths when the approved need ended.
Include this context
ticket and trigger identifier
Include this context
vendor identity or connection
Include this context
systems and access paths
Include this context
requested and completed times
Include this context
implementer
Include this context
verification result
Weak evidence to avoid
A closed disable vendor ticket that names no accounts, keys, integrations, target systems, completion timestamps, or verification from authoritative access listings.
Type 1
Current third-party access standards, configured request and authentication controls, and a point-in-time vendor-access listing reconciled across authoritative systems as of the examination date. Inspect an applicable current access, review, or revocation record when that population exists; for any population with no occurrence, retain its complete zero-result query and walkthrough a representative request through provisioning, review, and verified revocation.
Type 2
Every vendor human account, service account, key, integration, remote connection, and privileged session active at any time during the period, plus every vendor access request, modification, review decision, and revocation event in the period.
Reconcile vendor identities, keys, integrations, privileged accounts, and remote connections from authoritative systems to approved requests and the vendor inventory, then trace every remove decision and termination trigger to verified revocation.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Third parties receive only the systems and privileges needed for an approved purpose, use controlled authentication and connection methods, leave useful activity records, and lose access promptly when the need ends.
Compare the documented owner with the intended role (Vendor Risk Owner / CISO / Legal), then compare dated records with the stated cadence: Prior to onboarding; periodic based on risk; at least annually for critical/high.
Reconcile vendor identities, keys, integrations, privileged accounts, and remote connections from authoritative systems to approved requests and the vendor inventory, then trace every remove decision and termination trigger to verified revocation.
Current third-party access standards, configured request and authentication controls, and a point-in-time vendor-access listing reconciled across authoritative systems as of the examination date. Inspect an applicable current access, review, or revocation record when that population exists; for any population with no occurrence, retain its complete zero-result query and walkthrough a representative request through provisioning, review, and verified revocation.
Every vendor human account, service account, key, integration, remote connection, and privileged session active at any time during the period, plus every vendor access request, modification, review decision, and revocation event in the period.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Each vendor identity or connection has a current business purpose, company sponsor, named user or workload, scoped privilege, duration, and system-owner approval before provisioning.
For each selected record, confirm it demonstrates Business sponsors and system owners periodically assessed both continued need and least-privilege scope for every vendor access path and completed removals.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Applicable vendor human identities use multifactor authentication, and any infeasible use has an approved, time-bounded alternative safeguard.
For each selected record, confirm it demonstrates The complete current population of vendor human and nonhuman access can be connected to a vendor, sponsor, system, privilege, creation date, and status.
For each selected record, confirm it demonstrates Access removal was triggered and completed across accounts, sessions, credentials, integrations, and connection paths when the approved need ended.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.