Run a GTM Access Recertification Campaign

Review existing GTM system access against current responsibilities, resolve stale permissions and verify that approved changes took effect.

Run a Go-To-Market Strategy And Revenue Operations Access Recertification Campaign

Build an inventory that reflects actual access

Choose the systems and workspaces in scope, then obtain current access records through their authorized owners. Include named users, contractors, group memberships, privileged roles and relevant service accounts. Record when the inventory was taken so later decisions are tied to a known state.

Compare the inventory with current assignments. A familiar name on an old approval is not enough to establish a continuing need. Identify people whose projects ended, whose role changed or whose manager cannot explain the permission. Keep uncertain entries visible for an accountable decision.

Ask the owner a concrete review question

For each entry, show the current capability and the work it supports. Ask the responsible owner to retain, narrow or remove it, with a reason and any relevant end date. Avoid a bulk approval request that hides administrative privileges among ordinary reader roles.

NIST’s implementation examples call for periodic access reviews and reviews when people change roles or leave. Set the operating schedule through the organization’s policy and risk owners; a calendar reminder should complement those change-triggered reviews.

Example: a contractor’s campaign has ended

Illustrative case: a contractor still belongs to the workspace used for a completed launch. The campaign owner confirms that the assignment ended, while an administrator checks whether group membership also grants access to another active workspace. The review distinguishes the obsolete grant from any separately approved current work.

The authorized administrator removes the expired access and verifies the resulting state. The coordinator records the decision and completion evidence. If the owner cannot be reached, the entry follows the established exception process; silence is not recorded as a fresh approval.

Verify changes in the system

Track approved removals and reductions through implementation. An accepted ticket is not the same as a completed change. Compare the resulting account or group state with the approved decision and investigate any inherited permission that still provides the same access.

For service accounts and integrations, involve the system owner before changes so dependencies are understood. Keep human access review and integration ownership clear. Do not remove a poorly understood account merely to improve the completion count; resolve its owner, purpose and approved treatment.

Close the review with exceptions visible

Reconcile the inventory into retained, changed, removed and unresolved entries. Every unresolved entry needs an owner, next action and review date. Store the decisions and verification evidence under the organization’s access and retention rules; a broad status report should not expose sensitive account details.

Use recurring findings to improve onboarding and role-change procedures. If the same old groups survive every review, repair the process that leaves them behind. The next review should start from current system evidence, with previous decisions available as context rather than automatic authorization.

Sources

  1. CSF 2.0 Implementation Examples: PR.AA-01 and PR.AA-05, National Institute of Standards and Technology. Supports owner-authorized access requests, least privilege, separation of duties and review when access needs change.

Related GTM guides

Frequently asked questions

Can a manager approve all access in one step?

The review needs enough detail to judge each permission against current work. Broad approval without visibility into privileged or inherited access can miss obsolete grants.

What proves an access removal is complete?

Record the authorized decision and verify the resulting account or group state in the relevant system. Keep inherited permissions and unresolved exceptions visible.