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

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
- 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.