Create a Vendor Access Register Before You Need One

Know which outside access still has a business reason

A vendor can be important to the business without needing access to every system or dataset connected to its service. Start with the vendor’s row in the security inventory, then create a separate access record for each materially different access relationship.

SF-02 records that the vendor exists and why the business depends on it. This guide owns access paths, affected systems or data, privilege, contacts, grant and expiry dates, recurring review, exceptions, removal state, and closure evidence. It does not recreate the SF-02 inventory schema.

The FTC’s small-business guidance advises limiting vendor access to a need-to-know basis and only for the time required to do the job. NIST SP 1305 uses the Cybersecurity Framework’s GV.SC category for broader supply-chain roles, requirements, and supplier relationships. CISA’s SMB vendor resource addresses vendor and supplier cybersecurity risk for smaller businesses.

Those sources establish useful context. They do not prescribe the lifecycle labels, 17 register fields, review workflow, evidence test, or example below. Those are PlainFort editorial choices for a small team—not a legal standard, certification, vendor rating, complete third-party-risk program, or guarantee that access is safe.

Keep secrets out of the register

The register is a decision record, not a credential store. Never record passwords, passphrases, API keys, tokens, private keys, recovery codes, MFA seeds, session cookies, secret answers, or instructions for bypassing access controls. Do not record sensitive connection strings, private endpoints, or enough detail to help someone reproduce access.

Record only a useful non-secret mechanism category, such as named external user, vendor-managed support account, or remote support channel. Store any authorized credential in the team’s approved secret-management system, outside this register. The register may point to an approved internal process or non-secret record identifier, but not to a secret value.

Use five truthful lifecycle states

These are operational labels, not a risk score and not a substitute for the SF-03 prioritization method.

Active

Access is currently authorized for a documented business purpose, and its review record is current. Active does not mean least privilege has been technically verified or that the vendor is secure.

Temporary

Access is authorized for a bounded task or period and has an explicit expiry date or observable review trigger. A vague intention to remove it later is not a time boundary.

Expired

The approved access period or review date has passed. Expired does not mean removed. Keep the row visible until someone establishes the real state and records the evidence.

Unknown

The team cannot establish whether access exists, its scope, owner, purpose, privilege, expiry, or removal state. Record Unknown — follow up; do not replace a missing fact with none or assume that silence means removal.

Removed

Removal was requested and the team inspected the stated closure evidence. Record exactly what was checked. A provider’s statement can be recorded as provider confirmation received; it is not independent technical proof that every access path, session, delegated account, or undisclosed route is gone.

Build one vertical block for each access relationship

Use separate blocks when one provider has materially different purposes, systems, privilege, owners, or expiry conditions. A vertical format is easier to review on a small screen and avoids hiding important evidence in a wide enterprise spreadsheet.

1. Vendor or contractor label and SF-02 inventory reference — a non-sensitive label plus the inventory row that records the business dependency.
2. Current lifecycle state — active, temporary, expired, unknown, or removed, with the reason the label is justified.
3. Business purpose or current need — the bounded outcome that still requires access; not a generic description of the vendor.
4. Affected system or data category — a useful category such as customer-support platform; do not expose private endpoints, record-level data, or regulated-data conclusions.
5. Non-secret access path or mechanism category — for example, named external user; never a credential, secret, recovery method, or bypass instruction.
6. Privilege or scope description — what the access is expected to allow, stated without sensitive configuration detail.
7. Internal accountable owner — exactly one internal role that can decide whether the access remains justified.
8. Responsible executor and backup or escalation-path reference — who performs the review/removal work and how continuity or escalation is handled.
9. External contact role or approved business-contact reference — a role or controlled contact reference, not unnecessary personal details copied into the register.
10. Grant or first-known date — use Unknown — follow up when the date cannot be established.
11. Expiry date or explicit no-expiry exception — write No expiry — exception required rather than leaving the field blank.
12. Last review date and reviewer role — who inspected the row and when, without implying the review proved the vendor secure.
13. Exception, reason, approver, and expiry or review trigger — keep any deviation bounded and visible.
14. Removal-request date and responsible party — separate the request from the result.
15. Closure evidence and non-secret evidence location — what was inspected and where its controlled, non-secret record can be found.
16. Unresolved unknown or residual risk — missing facts, weak evidence, provider non-response, unsafe removal, or scope that may be broader than documented.
17. Next review or trigger — a date or observable change such as contract end, task completion, owner change, privilege change, service replacement, or new evidence.

A block is complete when it exposes a truthful state, current need, internal owner, relevant dates, inspected evidence, unknowns, and next action. Completion does not prove that every access path was discovered, that removal worked beyond the inspected evidence, or that the vendor follows security requirements.

Review a row without inventing a vendor-risk score

1. Link the row to the known SF-02 vendor dependency. If the vendor is not in the inventory, correct that input rather than creating a second inventory here.
2. Record only non-secret facts. Mark missing facts Unknown — follow up.
3. Confirm the current business purpose and exactly one internal accountable owner using the SF-04 responsibility model. A vendor may execute, confirm information, or supply evidence; it does not implicitly acquire internal accountability.
4. Compare the stated scope, privilege, and duration with the current purpose. Lifecycle status is a workflow fact, not a severity rating.
5. Assign an expiry date or document No expiry — exception required with an internal approver and a review trigger.
6. Decide within actual authority whether to retain, narrow, expire, or request removal. Route competing work through SF-03; do not create points, weights, percentages, heat maps, or a parallel vendor-risk score here.
7. Record the evidence inspected and its non-secret location. Distinguish provider confirmation received from an independently observed result.
8. Keep non-response, unsafe removal, missing authority, weak evidence, and unresolved facts visible. Do not close the row to make the register look tidy.
9. Set the next review from the expiry, exception, task completion, service change, owner change, or another observable trigger. There is no universal cadence that fits every access relationship.

This workflow and its cadence are PlainFort editorial judgment. The first-30-days guide may schedule or defer this review, but SF-05 owns the access fields and lifecycle procedure; this guide does not recreate that four-week calendar.

Handle the gaps that resist a clean status

No internal accountable owner

Do not assign the vendor by default. Mark the owner Unknown — escalate, identify who has authority to resolve the gap, and avoid expanding access while accountability is unresolved. Naming a provider contact does not create an internal decision owner.

Access without an expiry

Use No expiry — exception required, record the current business reason, internal approver, and a dated or event-based review trigger. Do not call the access temporary.

The provider does not respond

Record the request, date, contact route, non-response, business dependency, and the internal escalation decision. Provider silence is neither confirmation of access nor confirmation of removal.

Removal could interrupt the business

Do not improvise. Record the dependency and recovery concern, then escalate to someone with the competence and authority to plan a safe change. This register does not supply backup, recovery, contract, or technical deprovisioning instructions.

Compromise may be involved

Do not use this routine register workflow during a suspected or active incident. Preserve the known facts without adding secrets, stop ordinary access-review work, and use the organization’s approved incident path or qualified help. This article does not provide breach response, forensics, notification, or legal advice.

Worked lifecycle example

Fictional example — do not copy as a completed vendor access register

Example Co. has an SF-02 inventory row for the invented provider ExampleSupport, which helps configure the invented ExampleCRM service. The example uses roles rather than people and contains no real access or credential data.

1. Vendor or contractor label and SF-02 inventory reference: ExampleSupport — Inventory V-04.
2. Current lifecycle state: Expired — removal not yet established.
3. Business purpose or current need: the bounded configuration task ended; no continuing need is documented.
4. Affected system or data category: ExampleCRM configuration; data detail remains Unknown — follow up.
5. Non-secret access path or mechanism category: Named external user; no username, password, token, endpoint, or recovery detail is recorded.
6. Privilege or scope description: Configuration access as described in the internal task record; actual scope verification remains incomplete.
7. Internal accountable owner: Operations lead.
8. Responsible executor and backup or escalation-path reference: Service administrator; backup is Owner; unsafe removal escalates to the approved recovery decision path.
9. External contact role or approved business-contact reference: ExampleSupport service coordinator — controlled business-contact record.
10. Grant or first-known date: Unknown — follow up.
11. Expiry date or explicit no-expiry exception: the task-end date passed; no extension was approved.
12. Last review date and reviewer role: Example review date — Operations lead; this is a fictional planning date, not evidence of a real review.
13. Exception, reason, approver, and expiry or review trigger: None recorded; missing documentation remains an unknown, not an approved exception.
14. Removal-request date and responsible party: Example request date — Service administrator.
15. Closure evidence and non-secret evidence location: Provider confirmation received — Internal access record; no independent session or delegated-access check was performed, so the row cannot yet become Removed.
16. Unresolved unknown or residual risk: grant date, full scope, and independent removal evidence remain unknown; escalate if the provider does not respond or removal may disrupt recovery.
17. Next review or trigger: recheck after an authorized administrator inspects the available non-secret access evidence, or immediately if suspicious activity is reported.

The example deliberately remains Expired, not Removed. It shows how an honest register can expose weak evidence instead of converting a removal request or provider statement into a stronger claim.

Know what the register cannot decide

This guide does not assess a vendor’s security posture, rank supplier criticality, select a provider, draft a contract, determine legal or regulatory obligations, certify compliance, inspect the vendor’s internal systems, reveal undisclosed subcontractors, or investigate a breach. NIST SP 1305 and the CISA resource describe a broader supply-chain-risk context; use qualified procurement, legal, privacy, compliance, or security help when that broader work is required.

Escalate privileged or production access, regulated or highly sensitive data, unclear contractual rights, missing internal accountability, unsafe removal, provider non-cooperation, evidence that cannot support the claimed state, or work beyond the team’s competence and authority. A current register improves visibility. It does not make valid access harmless or the business secure.