The PAM Academy · Module 7
Most privileged access management programmes do not fail on technology. The vault gets installed, the connectors work, the policies are written, and two years later half the estate is still outside the platform, approvals are rubber-stamped in seconds, and nobody can name the person answerable for the domain administrator accounts on the finance servers. The controls exist. The accountability does not.
This is the part of PAM that no product ships with. A platform can enforce a rule, but it cannot decide who is allowed to approve an exception, who signs off a quarterly access review, who is woken at two in the morning when a privileged session breaks its baseline, or what happens to the engineer who found a workaround because the sanctioned route was too slow. Those are role questions, decision-rights questions and culture questions, and they are answered by people or they are answered by accident.
This module covers how to map the stakeholders across the privileged access lifecycle, how to write a RACI that survives contact with a real organisation, how to apply segregation of duties without grinding operations to a halt, what training privileged users genuinely need, and how to move a programme from compliance by instruction to ownership by choice.
Module 7: Kenji, Principal Technologist
Part of the PAM Academy. Every module follows one person through a real privileged access problem, so the lesson lands in the context of the job you actually do.
Who this module is for
CISO or Executive Sponsor
A governance model that puts accountability for privileged access with named executives rather than leaving it stranded in a security team with responsibility but no authority.
PAM Programme Lead
A stakeholder map, a decision-rights matrix and an engagement plan that keeps system owners committed after the deployment project closes.
IAM or PAM Engineer
Clear boundaries on who administers the platform, who audits it and who approves changes, so segregation of duties is enforced in configuration rather than good intentions.
GRC and Compliance Manager
Evidence that roles, approvals, recertifications and training are documented, assigned and reviewed, which is what auditors ask for after they have seen the technical controls.
IT Operations or Service Desk Lead
Practical ways to give administrators a fast, sanctioned access route so adoption improves and workarounds stop being the path of least resistance.
The problems this module solves
Nobody owns the account, so nobody removes it
Orphaned privileged accounts are accounts with real power and no living owner. They persist because ownership was never recorded at creation, and when the original administrator leaves the account simply carries on. Attackers inherit exactly these accounts because no one notices when they are used.
Responsibility sits with a team that has no authority
Security is usually told to reduce privileged access risk but cannot force an application owner to give up standing administrator rights on a system that funds the business. Without an accountable executive above both parties, every disagreement resolves in favour of the status quo and the risk register grows.
Approvals become a formality
When approvers are not told what they are approving or what a good decision looks like, requests are waved through in seconds. The audit trail then shows a control operating perfectly while providing no real scrutiny, which is worse than no control because it creates false assurance.
Controls are imposed on administrators, not explained to them
Privileged users are the most technically capable people in the organisation and the most able to route around a control they consider pointless. A programme that treats them as a risk to be contained rather than a stakeholder to be engaged will find shared credentials, local accounts and undocumented scripts quietly reappearing.
What you will learn
- PAM roles and responsibilitiesIdentify every stakeholder across the privileged access lifecycle, from executive sponsor to system owner, approver, service desk and auditor, and define what each is responsible for.
- Ownership and accountabilityEstablish a named owner for every privileged account, system and control, and put reporting structures in place so ownership is visible and reviewed rather than assumed.
- Awareness and trainingBuild role-based training and awareness that changes behaviour among privileged users, and keep the training records that both regulators and incident reviews will ask for.
- Segregation of duties and governanceApply segregation of duties to privileged operations and to the PAM platform itself, and run a governance forum with the authority to decide exceptions.
- Culture and continuous engagementCreate a culture where privileged users report problems early, incident reviews find lessons rather than blame, and engagement continues long after go-live.
Who owns privileged access management?
Ownership of privileged access is usually assumed rather than assigned, which is why it collapses under pressure. The question needs to be split into four different kinds of ownership, because conflating them is the root of most governance arguments.
Accountable executive
One senior individual is answerable for privileged access risk across the organisation, typically the CISO or an equivalent security leader reporting into the board. This person does not operate the platform. They own the risk position, the policy, the exception decisions that cannot be resolved lower down, and the reporting line to the board. Accountability cannot be shared. If two people are accountable, no one is.
Programme and platform ownership
Someone owns the PAM capability as a service: the platform, its roadmap, its availability, its integrations and its onboarding pipeline. This is a product ownership role, not a project role, and it must survive the end of the deployment programme. Many organisations discover this gap eighteen months in, when the implementation team has dispersed and no one is accountable for coverage decay.
System and application ownership
Every server, database, application and cloud subscription has a business owner who decides who legitimately needs privileged access to it. Security defines the standard; the system owner applies it to their estate and signs the access reviews. Without this layer, security teams end up guessing at business justification for thousands of entitlements.
Account ownership
Every privileged account, including service accounts and break-glass accounts, needs a named human owner recorded at the point of creation and revalidated on a schedule. Owner is a mandatory field, not an optional one. When the number of accounts with no identifiable owner starts rising again, discovery and joiner-mover-leaver processes are decaying, and that figure is worth tracking as a metric in its own right.
Which roles and responsibilities does a PAM programme need?
A PAM programme touches more of the organisation than almost any other security control. The stakeholder map below covers the roles most programmes need. Titles vary; the responsibilities do not.
- Executive sponsor: secures funding, removes organisational blockers, and makes the call when a business unit refuses to onboard. Without visible sponsorship, the programme negotiates from weakness in every conversation.
- PAM programme lead: owns delivery, the roadmap, the stakeholder plan and the reporting. Sits between the security function and the operational teams whose daily work the programme changes.
- PAM platform engineers: build and run the vault, connectors, session management and integrations. They configure policy but should not be the people who approve their own privileged access.
- Identity and access governance: owns joiner, mover and leaver processes and recertification campaigns. Privileged access decays fastest at the mover and leaver stages.
- System, application and data owners: define who needs access to their systems, approve requests and complete access reviews with genuine scrutiny.
- Privileged users and administrators: work within the sanctioned access route, use individual named identities rather than shared credentials, and report friction rather than engineering around it.
- Service desk: handles access requests, first-line support and lockouts. If the service desk cannot explain the new access route, adoption stalls on day one.
- Security operations: monitors privileged sessions, triages alerts and runs containment when an account is implicated.
- Internal audit and compliance: tests whether the controls operate as described, independently of the teams that run them.
- HR and procurement: trigger the identity events that drive access changes for employees, contractors and vendors. Every third-party privileged account needs a named internal sponsor.
- DevOps and platform teams: own pipeline credentials, secrets and infrastructure-as-code, which is where privileged access multiplies fastest.
Write these up as a one-page responsibility statement per role. Ambiguity that is tolerable during a project becomes an outage or an audit finding in business as usual.
How do you build a RACI for privileged access management?
A RACI matrix assigns four things to each activity: who is Responsible for doing the work, who is Accountable for the outcome, who is Consulted before the decision and who is Informed afterwards. It is a decision-rights tool, and its value comes from arguing about the cells, not from producing the grid.
Build it around lifecycle activities rather than around teams. A useful starting set:
- Discovery of privileged accounts: PAM engineering responsible, security leadership accountable, system owners consulted.
- Onboarding an account into the vault: PAM engineering responsible, system owner accountable, service desk informed.
- Approving a privileged access request: line manager or system owner responsible, system owner accountable, security consulted for high-risk assets.
- Granting emergency or break-glass access: service desk or on-call engineer responsible, security operations accountable, system owner and audit informed within a defined window.
- Reviewing recorded sessions and audit logs: security operations responsible, security leadership accountable. Collection without review is theatre, so name the reviewer and the frequency.
- Quarterly recertification of privileged entitlements: identity governance responsible, system owner accountable, compliance informed.
- Approving a policy exception: risk owner responsible, accountable executive signs, with an expiry date attached to every exception.
- Decommissioning access on a leaver or role change: HR triggers, identity governance responsible, system owner accountable, measured in hours rather than days.
- Responding to a privileged access incident: incident manager responsible, security leadership accountable, legal and communications consulted.
Three rules keep a RACI honest. Exactly one A per row, because shared accountability is no accountability. Keep the R column small, since a row with six responsible parties describes a meeting rather than a process. And test each row against a real event: if a privileged credential is phished tonight, does this matrix tell the on-call engineer who can disable the account without waiting for a morning meeting? If not, the matrix is documentation rather than a capability.
How do you apply segregation of duties to privileged access?
Segregation of duties in IT security means no single individual can execute and conceal a harmful action end to end. In a privileged access context, it applies to the systems being protected and, just as importantly, to the protection itself.
Separate the operator from the reviewer
The person who administers the PAM platform should not be the only person who reviews its logs. Apply role-based access control to the audit tooling so only authorised hands can change audit settings, and store audit data encrypted, access-controlled and tamper-resistant. Audit log integrity violations, meaning logs deleted, altered or truncated, deserve their own alert, because erasing footprints is an attacker’s first task after gaining privilege. Independent internal audit closes the loop by asking who audited the auditors.
Separate request, approval and execution
Requesters should not approve their own access. Approvers should not be able to grant themselves the entitlement they just approved. For the highest-risk operations, such as changes to production financial systems or to the PAM configuration itself, require dual authorisation so two named people are on record.
Separate environments and duties by role
Developers should not hold standing administrative rights in production. Backup and restore duties should sit apart from the ability to delete data. Firewall and network changes should be separated from the ability to approve them, given how often a single misconfigured rule becomes the whole breach.
Make identity individual
Segregation of duties is unenforceable on shared credentials. Every privileged user needs a unique identity, so every action is attributable to a specific person. That attribution is itself a control: people behave differently when their name is attached to the session, which deters both malicious and careless activity.
Where the organisation is too small to separate every duty, compensate with detective controls: session recording, mandatory peer review of high-risk changes, and documented management review. Record the conflict as an accepted risk with an owner and a review date instead of pretending it does not exist.
What security awareness and training do privileged users need?
Generic annual awareness training does very little for administrators. They are targeted with far better material than the general workforce receives, so training for privileged users has to be role-based, specific and tied to what actually goes wrong.
Train by role, not by headcount
- Administrators and engineers: how to use the sanctioned access route, why standing privilege was removed, how to request just-in-time elevation, and what session recording does and does not capture.
- Approvers: what a good approval decision looks like, what questions to ask, and the consequences of rubber-stamping. Approvers are rarely trained at all, which is why approval quality is usually the weakest link in an otherwise sound control.
- Service desk: identity verification before any privileged reset, and the social engineering scripts attackers use on first-line support.
- System owners: how to conduct an access review that removes something, rather than clicking approve on every line.
- Executives and sponsors: what the reporting means and which decisions belong to them.
Target the credential attack path
Credential phishing aimed at privileged users is the scenario that most often turns into a serious incident, and the pattern is patient: credentials taken one week are used the next, from an unfamiliar address, at an hour when nobody is watching. Run phishing simulations against administrator populations, cover multi-factor fatigue and push-bombing, and teach people to report a suspected compromise quickly and without embarrassment.
Use operational data to target the training
Monitoring shows where users consistently struggle, and a struggling privileged user is a risk you can fix with education instead of alerts. Repeated failed multi-factor attempts, repeated policy violations of the same type, or heavy use of emergency access point at a training gap rather than a malicious one. Track training needs identified from audits as a metric: it measures whether audits improve people or merely generate paperwork. Keep the records too, because they are evidence that privileged users were trained on data protection and compliance obligations.
How do you drive PAM adoption and overcome user resistance?
Resistance to PAM is rarely irrational. Administrators are being asked to give up direct access they have used for years, in exchange for a route that is slower on the first day and unfamiliar for a month. If the programme cannot answer why, the answer they invent is that security does not trust them.
Make the sanctioned route the fastest route
Adoption is a design problem before it is a communications problem. Measure the time from request to working access and treat it as a service level. Automate approvals for routine, low-risk elevations so reviewer attention is reserved for what matters. When the managed route is quicker than the workaround, compliance stops requiring persuasion.
Recruit champions from the sceptics
Run the pilot with a group that is friendly but not tame, because success in easy conditions convinces nobody. An engineer from the infrastructure team telling their peers that the new route is faster than their old workaround carries more weight than any security presentation. Give champions early access, listen to their complaints, and visibly change something because of them.
Separate lessons learned from blame assigned
After every incident, run a review that asks what went well and what did not, then update the procedures accordingly. Where knowledge is non-sensitive, share it internally so other teams benefit. A culture that punishes the person who reports a mistake buys silence, and silence during an incident costs far more than the mistake did. Bringing in external expertise for a complex incident is a sign of maturity, not failure.
Keep engaging after go-live
Rehearse. A response plan that has never been exercised is a document rather than a capability, so run simulated privileged access incidents on a regular cycle, quarterly in mature programmes, and let the drill expose role confusion before a real incident does. Report a small set of measures back to the people who generate them, and revisit the RACI whenever the organisation reorganises, because roles drift faster than technology does.
Kenji’s story
Kenji arrives at Abby Steel as Principal Technologist after the monitoring capability has gone live, hired for the specific job of being professionally paranoid about what comes next. The technical position looks strong. One Thursday at two in the morning a phished credential opens an off-hours database session and the account is contained in eleven minutes, against an industry average of two hundred and ninety-two days to identify and contain a breach involving stolen credentials. Kenji’s interest is in why that worked, and the answer is not the platform. A named analyst was on watch, a named engineer had authority to disable the account without waiting for a morning meeting, and the database team knew who to tell. Where he finds weakness is in ownership: service accounts with no living owner, approvers who cannot say what they approved, and a response plan whose roles have never been rehearsed by the people named in it. His closing line at the quarterly review is a warning rather than a victory lap. The programme that stands still is the programme that falls behind.
Common mistakes to avoid
Treating the RACI as a document instead of a decision
A matrix produced in a workshop and filed away changes nothing, because the value was in resolving the disagreements it surfaced. Test each row against a real scenario and publish the result where the on-call team can find it at three in the morning.
Assigning accountability to a team rather than a person
Naming the security function or the infrastructure team as accountable spreads it thinly enough to disappear. Put an individual’s name against every accountable role and every privileged account, and review the list when people change jobs.
Collecting audit evidence that nobody reviews
Recording sessions and logging every action creates assurance only if someone reads them. Assign a named reviewer and a frequency, and track the percentage of audit data actually reviewed, because an alarm that fires with nobody listening has already failed.
Training everyone the same way
Annual awareness modules aimed at the general workforce teach administrators nothing they do not already know, while approvers and service desk staff are often not trained at all. Build role-specific training for the people who make privileged access decisions.
Launching controls without explaining the reason
Privileged users who do not understand why standing access was removed will rebuild it with local accounts and scripts. Explain the threat model, show the new route, and fix the friction they report before it becomes a habit.
Key takeaways
- Accountability cannot be shared: one named individual per accountable role, one named owner per privileged account.
- A RACI earns its keep in the argument, not the grid, so test every row against a real incident at three in the morning.
- Segregation of duties applies to the PAM platform itself, so the operator of the vault must not be the only reviewer of its logs.
- Train approvers and the service desk, not just administrators, because approval quality is usually the weakest control in the chain.
- Adoption follows convenience: when the sanctioned route is faster than the workaround, the culture argument mostly wins itself.
Frequently asked questions
Who should own privileged access management in an organisation?
Split ownership into four layers. One accountable executive, usually the CISO, owns privileged access risk and reports the position to the board. A programme or product owner owns the PAM capability as an ongoing service, not just the deployment project. System and application owners decide who legitimately needs privileged access to their estate and sign the access reviews. Every individual privileged account, including service and break-glass accounts, has a named human owner recorded when it is created. Security defines the standard and operates the platform, but it cannot own business justification for access to systems it does not run.
What is a RACI matrix for privileged access management?
It is a table that assigns four roles to each activity in the privileged access lifecycle: Responsible for doing the work, Accountable for the outcome, Consulted before the decision, and Informed afterwards. Typical rows include account discovery, vault onboarding, access approval, break-glass usage, session and log review, recertification, exception approval, leaver revocation and incident response. Keep exactly one accountable name per row and keep the responsible column short. The point of the exercise is to force the organisation to resolve who decides, before an incident or an audit forces the question in less comfortable circumstances.
What is segregation of duties in IT security?
Segregation of duties means no single person can carry out and conceal a harmful action alone. In privileged access, that means requesters do not approve their own access, developers do not hold standing administrative rights in production, backup duties sit apart from deletion rights, and the administrator of the PAM platform is not the only person reviewing its audit logs. It depends on individual named identities, because nothing can be attributed on a shared credential. In small teams where full separation is impractical, compensate with session recording, peer review and documented management oversight, and record the conflict as an accepted risk with an owner and a review date.
What security awareness training do system administrators need?
Role-based training rather than the annual general module. Administrators need the sanctioned access route, the reason standing privilege was removed, how to request just-in-time elevation, and what session recording captures. They also need credential-attack training aimed at them specifically: targeted phishing, multi-factor fatigue and push-bombing, and how to report a suspected compromise quickly without fear of blame. Approvers need to know what a good approval decision looks like, and the service desk needs identity verification procedures for privileged resets. Use operational signals such as repeated failed multi-factor attempts or repeated policy violations to target training where it is genuinely needed, and keep the records as compliance evidence.
How do you overcome resistance to PAM from IT teams?
Start by accepting that the resistance is usually rational. Administrators are giving up direct access for a route that is slower at first, so make the sanctioned route genuinely fast: measure time from request to working access, automate low-risk approvals and fix reported friction quickly. Pilot with a sceptical but engaged team and let their verdict travel by word of mouth. Explain the threat model rather than issuing instructions, run incident reviews that find lessons instead of assigning blame, and rehearse the response plan so the named roles are practised. Adoption improves when the controlled path is the easiest path.
Start Module 7 in the PAM Portal
Work through Kenji’s module in full, with the walkthroughs, templates and assessment that turn this into something you can apply on Monday morning.
Open Module 7 in the PAM Portal
Vendor-neutral. Built by practitioners. Designed around the roles that do the work.