← Back to PAM Best Practice main site
PAM Academy › Module 10 — Why PAM Projects Fail

Module 10: Why PAM Projects Fail

Marta, CISO of Caldwell Manufacturing, learns why two PAM projects died: ten failure modes, each the dark mirror of a module.

Story: “The Post-Mortem”
~20 minutes
Lead: Marta, CISO (Chief Information Security Officer)
Failure PatternsLessons LearnedProgramme RecoveryGovernanceCourse Recap
Included
Part of the PAM Best Practice Academy curriculum
Module 10 video coming soon ← Back to Module 9
  • 8-part story-led module (coming soon)
  • Follows Marta at Caldwell Manufacturing
  • Practical, vendor-neutral PAM guidance
  • Key facts and real-world examples
  • 10-question knowledge check
Overview
Curriculum
Instructors
10
Module Number
8
Story Parts
20
Minutes
10
Quiz Questions
Module 10 — Why PAM Projects Fail
~20 minutes
COMING SOON
The question this module answers
Why do PAM projects fail, and how does each discipline in this course prevent it?

Marta, CISO of Caldwell Manufacturing, visits Abby Steel after her company's second PAM project collapses. Her board wants to know why Abby Steel finished when Caldwell didn't. As she tells her story, the team recognises ten failure modes, each a module of this course run in reverse, and the module becomes a revision of the whole curriculum.

What you will learn
▶
Recognise the ten failure modes that stall, restart or kill PAM projects.
▶
Link each failure mode to the module whose discipline prevents it.
▶
Explain why treating a breach as an individual failure rather than a systemic one guarantees it will happen again.
▶
Apply the correct order for building a programme: strategy, operating model, processes, controls, and only then the tool.
▶
Use Layla's 'map home' to diagnose a struggling programme and cover every door: human, machine, outsider and emergency.
Module curriculum
1
Part 1: The Visitor and the Uncomfortable Numbers
Coming soon
2
Part 2: Failures One and Two: Blame and a Tool Without a Programme
Coming soon
3
Part 3: Failures Three and Four: No Discovery, No Prioritisation
Coming soon
4
Part 4: Failures Five and Six: Buying the Demo, Breaking Monday
Coming soon
5
Part 5: Failure Seven: Deploy and Walk Away
Coming soon
6
Part 6: Failures Eight and Nine: Frozen in Time, Never Measured
Coming soon
7
Part 7: Failure Ten: The Forgotten Doors
Coming soon
8
Part 8: The Map Home
Coming soon
9
Knowledge Check10 questions · pass mark 8/10
Quiz
Part 1: The Visitor and the Uncomfortable Numbers

Marta arrives with her board's question, and the industry pattern appears: deployments stuck at partial coverage, shelfware, and restarts that inherit old scars.

Part 2: Failures One and Two: Blame and a Tool Without a Programme

Caldwell fired the engineer and changed nothing, then bought a vault with no strategy, operating model or owner. The tool automated the chaos.

Part 3: Failures Three and Four: No Discovery, No Prioritisation

Project one protected only the 90 accounts Caldwell knew about. Project two tried 'everything, everywhere, at once' and lost its funding.

Part 4: Failures Five and Six: Buying the Demo, Breaking Monday

The platform was chosen by demo, discount and deadline, then launched big-bang with no pilot or rollback. It ended as shelfware.

Part 5: Failure Seven: Deploy and Walk Away

Recordings nobody opened and alerts sent to an unstaffed mailbox. An attacker sat inside for seven months with the evidence in plain sight.

Part 6: Failures Eight and Nine: Frozen in Time, Never Measured

The programme ignored clouds, pipelines, machine identities and an AI pilot, and no one ever independently measured it.

Part 7: Failure Ten: The Forgotten Doors

Both breaches came through machine identities, vendor logins and break-glass accounts. Humans were vaulted, but everything else stayed in shadow.

Part 8: The Map Home

Marta sees the difference: Abby Steel treated every step as a discipline, while Caldwell treated the whole thing as a purchase. Layla hands her the rules, and the course ends with a charge to the learner.

Key facts
  • Caldwell Manufacturing (fictional) ran two funded, staffed PAM projects in three years, and both collapsed.
  • Project one scoped only the 90 privileged accounts Caldwell knew about, while Abby Steel's discovery had found 312 accounts that were on nobody's list.
  • Project two's 'everything at once' scope left everything 15% protected and nothing finished after twelve months, so the board stopped the money.
  • Big-bang go-live: plant supervisors locked out, a four-hour help desk queue by 9 a.m., and blanket exemptions by Wednesday. The tool stayed installed but went unused.
  • In Caldwell's second breach the attacker was inside for seven months, with the evidence sitting in unopened session recordings. Against IBM's 292-day average for credential breaches, that was 'tragically normal'.
  • Both breaches came through forgotten doors: a machine identity with a five-year-old password, a vendor login from a finished project, and break-glass credentials on a laminated card.
Knowledge Check
Q1: After its first breach, Caldwell fired the engineer and issued a memo on individual accountability. Why did the breach happen again?
The new engineer was less careful
The system that created the forgotten account (no ownership, reviews or lifecycle) was never fixed
The memo was not signed by the board
The vault had not been purchased yet
Q2: According to Layla, in what order should a PAM programme be built?
Tool, controls, processes, operating model, strategy
Controls, tool, strategy, processes, operating model
Strategy, operating model, processes, controls, then the tool
Operating model, tool, strategy, controls, processes
Q3: What was the core mistake in Caldwell's first project scope of 90 accounts?
Protection was scoped to what they knew, not what discovery would find
It included too many test-lab servers
It focused only on cloud accounts
It rotated passwords too often
Q4: Project two adopted 'everything, everywhere, at once'. What did this lead to?
Full protection in six months
A vendor dispute over licences
An immediate second breach
Everything 15% protected, nothing finished, and the board stopping the money
Q5: Which advice does Sofia give Marta about selecting a platform?
Always take the quarter-end discount
Requirements first, vendors second, and never sign in the same month you first saw it
Choose the vendor with the best demo environment
Let the vendor write the requirements
Q6: What does Grace say Caldwell failed at in its big-bang go-live?
Security
Budgeting
Landing: no pilot, no phases, no communication ahead of the change and no rollback plan
Vendor selection
Q7: What does failure seven, 'collected is not monitored', describe?
Sessions were recorded and alerts fired, but nobody reviewed them, so an attacker stayed inside for seven months
No session recording was ever enabled
Logs were deleted every night
The SIEM was never purchased
Q8: In failure eight, which part of Caldwell's identity estate was the least protected?
The on-premises domain admins
The finance team's user accounts
Front-desk visitor logins
The fastest-growing part: clouds, container pipelines, machine identities and an unreviewed AI pilot
Q9: Which statement captures failure nine?
An unmeasured programme doesn't know it's failing, and that is not the same as succeeding
Measurement slows a programme down
Green status reports prove a programme works
Only external auditors can measure maturity
Q10: According to failure ten, a PAM programme must cover which four kinds of 'door'?
Servers, desktops, laptops and phones
Development, testing, staging and production
Humans, machines, outsiders and emergencies
Finance, HR, IT and operations
Requirements
Completion of Module 9 (recommended)
Basic understanding of IT administration or security concepts
Target audience: security and IT professionals, PAM practitioners and programme leads
No vendor-specific tool knowledge required — this module is vendor-neutral
Your instructors
NK
Nabeel Khaliq
IAM & Privileged Access Management SME · Founder, PAM Best Practice Ltd
Practitioner with deep hands-on experience implementing PAM across enterprise environments. Founder of PAM Best Practice Academy, a UK-registered education and community hub for PAM professionals. Arsenal and Middlesbrough fan.
AR
Adrian Russo
IAM & Privileged Access Management Architect
Senior PAM architect with extensive experience designing and deploying large-scale CyberArk and BeyondTrust implementations across enterprise environments globally. Keen cyclist.
ID
Iftikar Din
Manufacturing-focused Cyber Security Engineer
Cyber security engineer specialising in industrial and manufacturing environments. Brings real-world operational technology (OT) security perspective to PAM implementation. Middlesbrough fan who loves gardening.
Your progress
Module 10 — Why PAM Projects Fail
Not started0%
Module breakdown
Part 1: The Visitor and the Uncomfortable NumbersComing soon
Part 2: Failures One and Two: Blame and a Tool Without a ProgrammeComing soon
Part 3: Failures Three and Four: No Discovery, No PrioritisationComing soon
Part 4: Failures Five and Six: Buying the Demo, Breaking MondayComing soon
Part 5: Failure Seven: Deploy and Walk AwayComing soon
Part 6: Failures Eight and Nine: Frozen in Time, Never MeasuredComing soon
Part 7: Failure Ten: The Forgotten DoorsComing soon
Part 8: The Map HomeComing soon
Knowledge Check10 questions
What next
Course complete
The course ends with Layla's map home, ten rules from fixing the blame culture to covering every door, and a charge to learners to build the version of the story where the Tuesday never happens.
PAM Community
Join our network of PAM practitioners, mentors and industry partners across the UK.