How to Build a PAM Programme: Strategy, Operating Model and Roadmap

The PAM Academy · Module 2

Who this module is for

The problems this module solves

What you will learn

1. People: define roles, responsibilities and a culture of securityName a single accountable sponsor and split the chain of custody so that the business approves access, security reviews it and IT provisions it. Build the communication and training plan that turns a control into a habit.
2. Processes: establish clear workflows for the access lifecycle and reviewsRun a five-step access request process, a same-day leaver timeline and quarterly recertification, all wrapped in a joiner, mover, leaver lifecycle that covers every identity from first day to last.
3. Controls: apply least privilege, RBAC, segregation of duties, JIT and service account controlsDeploy the five enforcement controls and extend them to the accounts most programmes miss: machine identities, third-party access and break-glass credentials.
4. Technology: use the right PAM technologies to enforce and monitorMap vaulting, credential rotation, just-in-time elevation, session recording, multi-factor authentication and HR-triggered lifecycle automation to the specific business risk each one reduces.
5. Maturity: evolve, measure and continuously improve your PAM capabilityPlace your organisation on the five-stage maturity model, agree the metrics that prove progress, and sequence a twelve-month roadmap that moves from visibility to control to automation to governance.

How do you turn a security incident into a PAM programme?

A privileged access incident is expensive, but it is also the only moment when an organisation will fund work it has deferred for years. The task in the first fortnight is to convert the incident into evidence, and the evidence into a mandate.

Start by reconstructing what happened and then deliberately widening the question. If one forgotten service account provided the way in, the next question is not who forgot it but how many more are there. That widening is what turns an incident report into an inventory. In the case study behind this module, a week of investigation surfaced forty-seven orphaned accounts with no living owner and eighty-nine users holding far more privilege than their jobs required, with a note attached warning that a week of searching had barely started.

Then name the root cause honestly. Blaming an individual produces a disciplinary outcome and no structural change. The finding that actually funds a programme is that no process caught the account, no review flagged the excess access, and no owner existed to ask. Fix the person and you fix one case. Fix the system and you fix it for everyone.

Finally, frame the ask correctly. A tool gets installed and forgotten. A project ends and its owners move on. A programme has strategy, ownership, processes, controls and a maturity path that keeps running after the incident stops being news. Put that distinction in the first sentence of the board paper, because it is the sentence that stops the conversation becoming a two-week product demonstration.

• Reconstruct the incident, then widen the search to the whole account population.
• Report the control failure, not the individual.
• Ask for a programme with a sponsor and a budget line, not a purchase.
• Capture the numbers you found now, because they become your baseline metrics later.

What is a PAM strategy, and what belongs in it?

A PAM strategy answers four questions, and the order matters more than the content. What are we protecting and why? That is strategy. Who does what? That is the operating model. How does work flow? Those are the processes. Only then: what technology enforces it all? Most organisations run this backwards and pay for it twice.

A workable strategy fits on a single page and rests on five pillars.

• Visibility. Know every privileged account, every owner and every entitlement. You cannot protect what you cannot see.
• Control. Least privilege, role-based access and multi-factor authentication enforced everywhere privilege lives.
• Governance. Clear ownership, regular reviews and policies people will actually follow.
• Automation. Lifecycle events handled by workflow rather than by memory, because memory is what forgets service accounts.
• Audit. Every privileged action recorded and every control provable to any regulator who asks.

A strategy that only speaks security will not survive its first budget round, so anchor it to two things the business already cares about. The first is business risk: protect most where the organisation bleeds most, which usually means production systems where downtime costs money by the minute, finance systems where a compromised account means fraud, and HR systems where a breach exposes personal data at scale. The second is compliance: GDPR, where weak access controls can turn into fines of up to four percent of global turnover; SOX, which demands segregation of duties in anything touching financial reporting; PCI DSS for payment data; and HIPAA wherever health information lives.

Before approval, walk the draft round the functions that could kill it in month six. One retailer let IT choose a privileged access solution unilaterally; after launch, finance could not reach the systems it needed for reporting and store operations seized up behind approval bottlenecks. The technology worked and the programme had to be rebuilt at twice the cost.

How do you build a PAM operating model and decide who owns access?

Strategy says what and why. The operating model says who and how, and it is the part that breaks more programmes than any technology ever has. The question it must answer in one line is: who owns access?

Think in three overlapping circles. IT is the hands: it provisions, configures and operates. Security is the eyes: it sets policy, reviews access and monitors for abuse. The business is the judgement: it decides who needs access to its own systems and answers for those decisions. Where the circles overlap is where privileged access management actually happens. As Kevin Stine of NIST has put it, technology offers the tools, but it is the people who execute and the processes they follow that solidify the foundation of any security framework.

Translate that into a chain of custody built deliberately on segregation of duties, so that no single person controls the whole chain:

1. The business owner approves. They know the job, so they judge the need.
2. Security reviews. Every grant is checked against policy and least privilege.
3. IT provisions. It implements what was approved, and nothing it was not asked to.

The reason for splitting the chain is not bureaucracy. In 2008 a trader at Société Générale who had moved from the back office to the trading floor retained both perspectives and used them to conceal unauthorised trades, contributing to losses of around 4.9 billion euros. One person, both sides of the process, no segregation.

Above the chain, name a single accountable sponsor who owns the strategy, the budget and the outcomes, and who reports to the board. Below it, be explicit that security owns policy and oversight, IT owns implementation and operations, and business owners own the access decisions for their own systems. Access is owned by the business, managed by IT and overseen by security. Three hands on every key.

Which processes does a PAM programme need?

An operating model that is not expressed as workflow is just a diagram. Four processes carry almost all of the risk.

Access request. Five steps, every time: request with a written business justification, approve by the business owner, review by security against policy, provision by IT, and record so that every step is documented and trackable. Skipping this discipline is how a misconfigured provisioning process at the US Department of Veterans Affairs allowed an unauthorised user to create a new account with system administrator privileges and reach veterans’ personal records.

Recertification. Access decays, so the process cannot end at provisioning. Every quarter, business owners review the access their people hold. Still needed, it stays. Not needed, it goes. A single review cycle is usually what would have removed a forgotten service account years before an attacker ever found it.

Leaver and deprovisioning. Four beats with no gaps: the HR system fires the trigger automatically on the day someone leaves, the manager confirms the full list of systems, IT removes every credential including service accounts and shared logins that hide outside the obvious list, and security verifies independently, because the team that removes access should not be the team that marks its own homework. Buffer was breached through a former employee’s account that was never deactivated after they left.

Joiner, mover, leaver. The leaver process is only a third of the lifecycle. The step organisations forget is the mover: when someone changes role, the old access has to die with the old job. Skipping it is exactly how a long-serving engineer accumulates twelve years of privilege. Get the lifecycle wrong at scale and you get Uber in 2016, where credentials that should no longer have worked exposed the personal data of fifty-seven million customers and drivers.

Automate this in stages: manual but controlled, then documented, then partially automated, then fully automated with humans handling only exceptions and approvals. Automating a broken process does not fix it, it just makes it fail faster and at scale.

What are the five PAM controls, and which accounts do programmes miss?

A control is not a guideline or a best effort. It is a rule the system itself enforces whether or not anyone remembers it exists. Five controls do the enforcement work.

• Least privilege. Every user and process gets the minimum access the job requires. If one account is compromised, the attacker gets one room rather than the building.
• Role-based access control. Permissions attach to roles and people attach to roles, which makes access consistent, scalable and auditable in minutes. Watch for role explosion, where hundreds of hyper-specific roles recreate the chaos you were escaping, and role creep, where permissions are quietly added until the role holds far more than intended.
• Segregation of duties. No single person can approve and execute a critical action, and the most dangerous operations require two authorised people at the same moment.
• Just-in-time access. Nobody holds administrative rights permanently. Elevation is requested for a task, granted for a window and expires automatically. A stolen credential that carries no standing privilege is a key to a lock that no longer exists.
• Multi-factor authentication. Something you know, something you have, something you are, with no exceptions for privileged access. Attackers entered Colonial Pipeline in May 2021 through a dormant VPN account protected by a password alone, shutting down five and a half thousand miles of fuel pipeline.

Three categories of account sit outside most programmes and deserve explicit scope. Machine identities, meaning service accounts, scripts and bots, now outnumber human identities many times over, with industry studies putting the ratio above forty to one. They do not answer MFA prompts and their passwords often have not changed in years, so vault them, rotate them, give each one a named human owner and include them in every review. Third-party access extends your perimeter to every supplier you have given a login; attackers reached Target in 2013 through credentials stolen from its air-conditioning contractor, ending in around forty million payment cards. Break-glass accounts cannot be deleted, because a crisis with no way in is a longer crisis, but they should be sealed, checked out under two-person control, alarmed on use and rotated on return.

One design rule sits above all five: a control that is too cumbersome gets bypassed, and a bypassed control is worse than none because it creates false confidence. Good controls are strong and smooth.

Which PAM technologies do you need, and how do you measure maturity?

Technology comes last in the sequence and first in most budgets. Choose it by the outcome it delivers rather than by feature count.

Mapping technology to business outcomes

• Credential vaulting and rotation. Removes shared passwords from spreadsheets and gives every service account an owner, a rotation schedule and an audit trail.
• Just-in-time elevation. Eliminates standing privilege so a stolen credential carries no rights by default.
• Session recording and monitoring. Makes privileged activity reviewable after the fact and evidences the audit pillar to regulators.
• Multi-factor authentication on privileged paths. Stops the most common intrusion route, the valid login.
• Lifecycle integration with HR and IAM. Fires joiner, mover and leaver workflows automatically so revocation never waits for a manager to remember on a busy Friday.
• Discovery and reporting. Finds accounts nobody declared and produces the recertification and coverage reports the board will ask for.

Measuring maturity and sequencing the roadmap

Maturity has five stages: chaos, where accounts are unknown and privilege unmanaged; visibility, where you can see the problem even if you cannot yet stop it; control, where least privilege, RBAC, MFA and defined processes are actively enforced; automation, where the lifecycle runs itself; and governance, where continuous review and measurable risk reduction make the programme improve itself.

Most organisations sit in stage one or two. Industry figures cited in this module put the scale of it plainly: 73 percent lack visibility into privileged access, 68 percent have over-permissioned users, 82 percent do not review access regularly and 91 percent lack formal PAM governance.

A twelve-month roadmap in four phases moves an organisation from chaos to control and beyond: months one to three complete discovery of every privileged account; months four to six extend the five controls to every system in scope; months seven to nine wire the lifecycle to the HR system; months ten to twelve establish continuous reviews and board-level reporting. Track progress against hard measures: full discovery and ownership of privileged accounts, recertification running monthly rather than annually, incidents contained in under an hour, and unauthorised privilege use at zero. On why containment speed matters, IBM’s 2024 study found breaches involving stolen credentials took an average of 292 days to identify and contain.

Common mistakes to avoid