Offboard Vendor Portal Credentials

Inventory the portals and the people

List every supplier portal the AP team uses, the company entity it serves, the business owner, and the people with access. Include invoice submission portals, supplier networks, bank portals used for remittance inquiries, and any tool that stores supplier documents.

For each portal, record the account type: named user, shared team account, service account, or API credential. The type determines what offboarding means. A named user can be disabled; a shared account may need a credential rotation and a new custodian.

Record the portal's owner in the business, not only in IT. The business owner can say whether the access is still needed, while IT can say whether the account exists.

Tie access to a named role

Access should map to a role with a business reason, not to a person who happened to need it once. Record the role, the tasks it supports, the approval, and the review date. A portal login with no documented role is difficult to defend and easy to forget.

Separate read access from submission or bank-detail access. The person who downloads statements may not be the person who can change remittance instructions. The portal's own permission model should reflect that distinction, and the internal record should match it.

Store the role mapping in the access inventory, not only in the portal. A portal view shows who has access; the internal record explains why the access was granted and when it should end.

Trigger offboarding from the HR or contract event

Use the departure, role change, or contract end as the trigger. The AP owner should receive the event, not wait to notice that a login is no longer used. Record the trigger date, the effective date, and the person responsible for removal.

For a contractor or outsourced role, tie the trigger to the engagement end and to any early termination. A vendor portal account can outlive the contract if nobody owns the removal. Put the portal in the offboarding checklist beside email and ERP access.

Remove sessions, keys, and recovery paths

Disabling a login is not enough if an active session, a saved browser credential, an API key, or a password reset path remains. Revoke sessions, rotate keys, remove the user from approval groups, and change the recovery email or phone if the departing person controlled it.

Check the portal's audit log for recent activity before and after removal. Record the last login, the removal timestamp, and the administrator who performed it. If the portal does not expose that detail, record the limitation and use the vendor's confirmation instead.

Check saved credentials on shared devices and browser profiles used by the team. A departing user's saved login can remain active on a computer that is reassigned to someone else.

Keep shared credentials out of scope

Shared logins weaken attribution because the portal cannot show which person submitted or changed a document. Where a shared account is unavoidable, name a custodian, store the credential in the approved vault, and rotate it when the custodian changes.

Do not place a shared credential in a document, chat, or spreadsheet that survives the person. If the team needs a functional mailbox, use a controlled account with named delegates rather than one password distributed to several people. The offboarding record should show which model is in use.

Verify from the vendor side

After removal, ask the supplier or portal administrator to confirm that the user is disabled and that no active sessions remain. Record the confirmation reference, date, and contact. Internal deactivation alone does not prove the external account is closed.

Test a login attempt only through an approved method and only if the test will not lock or disrupt a live account. A screenshot of a disabled user from the portal administration page is stronger evidence than a claim that the removal was requested.

If the supplier cannot provide written confirmation, capture the portal administration screen with the user status and the date. Redact unrelated users before storing the screenshot.

Record the evidence and the exception

The offboarding record should include the person, role, portal, trigger, removal actions, verification, and any residual access. If a removal is delayed, record the reason, the interim control, and the owner. Do not mark the task complete because a request was sent.

If the portal cannot remove a user without deleting history, record the alternative control the vendor offers and who accepted it. Exceptions should have an end date. A permanent exception is usually an unmanaged risk with a polite name.

Give the exception an end date and a compensating control, such as a vaulted shared account with a named custodian and a shorter rotation interval.

Review access quarterly

Compare the portal user list to the active AP roster and to the vendor contracts. Remove users who no longer have a role, and investigate accounts that do not map to a person. Sample a few removals and confirm the evidence is present.

Review administrator accounts separately. The person who can add or remove users has more power than an ordinary submitter. Limit that role, log the actions, and require a second approval for a new administrator where the portal allows it.

Record who performed the review and which portals were in scope. A review that covers only the portals someone remembered is not a complete access review.

Close with a removal certificate

Close the offboarding when every portal entry for the person is disabled or transferred, sessions and keys are revoked, the verification is attached, and the access review reflects the change. The record should name the person who performed and the person who verified.

Keep the certificate with the access review for the period the company requires. If the person returns in a new role, create a new access request rather than reactivating the old account, so the new scope is approved on its own terms.

If a portal has no user list export, document the manual check and the limitation so the next reviewer knows the evidence is weaker than a system report. State who performed the check and when.