Privileged Access Management (PAM) Implementation Checklist Template

Start about fourteen weeks before the go-live date. The first task records the rollout, the go-live date that every due date counts from, the five people and the kind of tool, which adds the build tasks for just-in-time roles, a password vault or both.

• Set up the PAM rollout — the organisation, the tool, the go-live date of the first production wave (which every due date counts from), whether the tool gives just-in-time roles, a password vault or both, and the five people; later tasks are assigned from these fields
• Agree the goal and how success is measured — why the rollout is happening (an audit finding, a customer’s security questionnaire, an incident, a policy), what it will measure at the end, such as the number of standing admin assignments, and what is out of scope
• Set the platforms in scope — the directory and identity platform, cloud subscriptions, servers, databases, network devices and SaaS admin roles this rollout covers, and the owner of each
• Check licences, prerequisites and who manages the tool — the licences the tool needs for everyone who will be eligible for a role or approve requests, the prerequisites, and the few people who will administer the tool itself
• Write the project plan and the communications plan — the phases and dates in this checklist, the change windows, who needs to hear what and when, and how admins get help during the rollout

You cannot protect accounts you have not found. List every account that can change systems, manage other accounts or switch security controls off, on every platform in scope, and remove what nobody needs before anything moves into the tool.

• Inventory the people with admin rights on each platform — every person who holds an admin role, an admin group membership or root-level access, on which platform, through which account, and whether it is their everyday account or a separate admin account
• Find service and machine accounts with elevated rights — accounts that run applications, scheduled tasks, scripts and integrations, with an owner for each, what depends on it and where its password or key is kept
• Find local, shared and built-in admin accounts — local administrator accounts on servers and workstations, shared team logins, root and built-in accounts, and default accounts on network devices and appliances
• Find supplier and contractor admin access — accounts that suppliers, managed service providers and contractors use to administer your systems, and the contract or ticket that allows each one
• Remove admin access nobody needs before onboarding — accounts of people who have left or changed role, dormant admin accounts and duplicate assignments, removed with the platform owner’s agreement
• Record the baseline count of standing admin access — the number of standing (always-on) admin assignments on each platform after the clean-up, so the end of the project can show the change

Not all admin access carries the same risk. Group it into tiers, decide which roles become just-in-time and which accounts stay standing, and set the approval, MFA and time limits for each tier. Write the rollback plan before anything changes.

• Group admin access into tiers — the root of trust first (directory and identity administrators, the cloud tenant’s top roles and the PAM tool itself), then critical systems, then single applications and limited support functions, and fill in the tier column of the Phase 2 inventory
• Decide which roles become just-in-time and which stay standing — for each role, eligible (requested when needed) or standing, with a reason and an owner for every standing exception
• Give each admin job the least privileged role that does it — list what each admin actually does and give them the narrowest role for it, so fewer people hold the top roles
• Set the approval, MFA and time limits for each tier — who approves an elevation or a password check-out, whether MFA is required each time, the longest an elevation or check-out lasts, and whether a reason or ticket number is required
• Decide where admins may work from — the trusted devices or privileged access workstations admins use for tier 0 and tier 1 work, and whether admin sign-in is blocked from other devices
• Decide what is logged, alerted and recorded — the events that raise an alert (an elevation, an approval, a password check-out, a break-glass sign-in, a new admin, a role granted outside the tool), where the logs go, and whether admin sessions will be recorded
• Check session recording with your data protection lead — recordings capture what admins see, including personal data on screen; agree the purpose, who may watch them, how long they are kept and whether a data protection impact assessment is needed
• Plan the onboarding waves — which roles and accounts move in each wave and when; this template puts tier 0 in wave 1, tier 1 in wave 2 and the rest in wave 3
• Write the rollback plan — how to give standing access back if the tool fails or blocks urgent work, who decides, and how long it may last

Build what the design says, after a gap of about two weeks that leaves room for holidays or a change freeze. The first task’s answer decides which tasks appear: role settings and approvers for just-in-time roles, or safes, rotation and connections for a vault. The PAM tool becomes part of tier 0, so protect it like the directory.

• Configure each just-in-time role and its approvers — activation duration, MFA at activation, a required reason or ticket number, approval and notifications by tier, two or more approvers where approval is required, and eligible (not active) assignments for the pilot admins
• Set up the vault’s safes and who can see each one — group accounts into safes or folders by tier and team, and give each team access only to its own
• Set password rotation and check-out rules — how often each kind of password changes, whether it changes after every check-out, how long a check-out lasts and who must approve it
• Connect the vault to the target systems — the connections the vault uses to change passwords and open sessions on servers, databases and devices, tested on one target of each type
• Turn on session recording and set who can watch recordings — which sessions are recorded, where recordings are kept and for how long, and the few people who may watch them, as agreed with the data protection lead
• Protect the PAM tool and plan for it being unavailable — limit who can administer it, keep it patched, require strong sign-in, send its own logs to monitoring, use high availability where the tool offers it, and use the break-glass process in Phase 5 as the way in when it is down
• Send the tool’s logs to security monitoring and set the alerts — the alerts agreed in Phase 3, sent to the people who will act on them, each tested once; the break-glass sign-in alert is added in Phase 5, once the accounts exist

If the PAM tool, the identity provider or MFA fails, someone still needs a way in. Set up at least two emergency access accounts, keep them out of everyday use and test them before the go-live decision. A failed test adds a task to fix them.

• Create or confirm the emergency access accounts — at least two, not tied to any person, used only when normal admin access cannot be
• Give them strong sign-in and store the credentials safely — a phishing-resistant method such as a FIDO2 security key, different from the method everyday admin accounts use, with the credentials kept in separate secure places known only to the people authorised to use them
• Keep them out of lock-out policies and alert on every sign-in — exclude them from sign-in policies that block or restrict access, record the exception and who approved it, and add each account to an alert on every sign-in, sent to security operations
• Write the break-glass procedure — who may use the accounts, when, how they reach the credentials, who they tell, and the review after every use
• Test each emergency access account — sign in with each account, do one admin task, confirm the alert reached security operations, and record the result
• Fix the emergency access and test it again — fix what failed and test again, then change the result on the test task to Passed (un-complete that task first if it is completed)

Test with test accounts and a small pilot group before real admins depend on the tool. Brief the help desk first, then the pilot admins, then everyone who will move in the waves.

• Tell admins their sessions will be recorded — what is recorded, why, who may watch the recordings and how long they are kept, before the pilot starts
• Brief the help desk and train the pilot admins — how to request a role or check out a password, how approvers approve, what the reason or ticket field is for, the common problems and the break-glass process
• Run the pilot with test accounts and the pilot group — test accounts first, then a small group of real admins, checking each setting against the test plan: MFA, approval, expiry, alerts and notifications
• Fix what the pilot found — change settings, test again, and list any issue that stays open for the go-live decision
• Tell and train the admins in each wave — the date of their wave, what they will do differently, a short training session or recorded walk-through, where to get help, and a record of who has been trained

The sponsor decides whether the first production wave goes ahead. Nothing after the decision can be completed until it is recorded. No-go adds a rework task; Go with conditions adds a task to meet them first.

• Prepare the go-live pack — the pilot results, open issues, the break-glass test result, the rollback plan, the alerts tested, training completed and the wave plan
• Approve the go-live — the sponsor records Go, Go with conditions or No-go and the reasons; nothing after this task can be completed until it is done
• Fix the blockers and return for a go-live decision — fix what the sponsor raised, move the go-live date on the first task if needed (every due date moves with it), then ask the sponsor to change the decision and complete the approval again
• Meet the go-live conditions before wave 1 — do what the sponsor asked and record it before the first production wave starts

Move accounts into the tool one wave at a time, check each wave before starting the next, and keep the rollback plan to hand. Service account and supplier tasks appear from the answers in Phase 2.

• Run wave 1: tier 0 roles and accounts — move the tier 0 admins to eligible or vaulted access, confirm each person can elevate or check out, and confirm the alerts fire
• Run wave 2: tier 1 roles and accounts — the same steps for servers, databases, cloud subscriptions and the other critical systems, once wave 1 is stable
• Run wave 3: the remaining roles and accounts — tier 2 and tier 3 roles, SaaS admin roles and anything left from the inventory
• Onboard service account credentials and rotate them — one application at a time with its owner, in a change window: store the credential in the tool, change it, and update where the application reads it
• Check each application still runs after rotation — scheduled tasks, integrations and services run with the new credential, and nothing still uses the old one
• Move supplier and contractor admin access into the tool — a named account for each supplier engineer, time-bound access approved for each job, and the old routes in closed

The rollout is not finished until the standing access it replaced is gone and someone owns the controls. Compare the result with the baseline, then hand over to the periodic privileged access review.

• Remove the standing admin assignments that were replaced — every permanent admin assignment that now has an eligible or vaulted replacement, keeping only the break-glass accounts and the documented exceptions
• Compare standing admin access with the baseline — count the standing admin assignments again and record the change against the Phase 2 baseline
• Check for admin rights granted outside the tool — role assignments, group memberships or local admin rights added directly since go-live rather than through the tool, and whether an alert caught each one
• Set the routine for reading the tool’s audit log — who reads elevations, approvals and check-outs, how often, and where exports are kept
• Update the admin access policy and procedures — how admin access is requested, approved and removed, the tier rules, the break-glass procedure, and joiners, movers and leavers for admin roles
• Record lessons learned and close the project — what worked, what slowed the waves down, open items and their owners, and the measures from Phase 1 against the result
• Hand over to the periodic privileged access review — the inventory, tiers, standing exceptions, break-glass test record and the date of the first review, which then runs on a schedule