Most Regulatory Frameworks are Built on Top of Graves

Author: Nishad Sankaranarayanan

Role: Cybersecurity Executive | “Identity-First” Security Leader

What IAM practitioners need to understand about the human cost hiding inside your compliance checklist…

The Pattern Nobody Talks About Out Loud

Every major regulatory framework you work against was written in response to something that already went wrong. Not hypothetically wrong. Catastrophically, publicly, irreversibly wrong. We don’t build policy proactively in this industry; we build it reactively, after the damage has been done and the headlines have forced someone’s hand.

Think about what’s sitting underneath the frameworks you navigate daily.

• HIPAA didn’t emerge from healthcare executives deciding patient data deserved protection. It emerged from a landscape of rampant insurance fraud, discriminatory data practices, and medical record abuses that left real people with real consequences – lost jobs, denied coverage, destroyed privacy. The law was the cleanup crew, not the prevention.
• SOX didn’t come from auditors deciding financial controls needed tightening. It came after Enron and WorldCom vaporized billions in investor value and shredded retirement accounts for thousands of ordinary people who trusted the numbers they were shown. The Act is a forensic document masquerading as a compliance framework.
• GDPR wasn’t a vision for a privacy-respecting digital future. It was a regulatory response to years of data harvesting, unconsented profiling, and cross-border data abuses that regulators finally couldn’t ignore after Facebook’s Cambridge Analytica exposure became impossible to contain politically.
• The Amber Alert system is named after Amber Hagerman, a nine-year-old murdered in Arlington, Texas in 1996. The system that now protects children didn’t exist until a child was killed and her community demanded something change.
• PCI-DSS exists because card fraud became so pervasive and so costly to the financial ecosystem that the major card networks had no choice but to mandate baseline controls across every merchant touching card data. The standard didn’t anticipate the breach, it was written after thousands of them.

This is the pattern. Harm occurs. Harm scales. Harm becomes undeniable. Regulation follows. And then we all inherit the compliance framework and treat it like it arrived from nowhere, like it was always just the way things were.

It didn’t arrive from nowhere. It arrived from graves.

IAM Is No Different – Here Are the Breaches That Wrote Your Policies

The identity space follows the same pattern exactly. The controls we build and enforce today weren’t invented in a vacuum by forward-thinking architects. They were demanded by specific, named failures that exposed how badly we were underinvesting in identity fundamentals.

• Target (2013): The breach wasn’t a sophisticated nation-state attack. An HVAC vendor with network access and no meaningful segmentation became the entry point for 40 million stolen card records. The core failure was third-party identity governance, an external account with far more privilege than its function required, and no monitoring to detect its abuse. Every time I review a vendor access policy, this breach is in the room.
• SolarWinds (2020): Supply chain compromise at massive scale, enabled in part by service accounts operating with excessive privilege across thousands of customer environments. The attackers didn’t force their way in, they walked through doors that were left open by over-permissioned build pipeline identities and inadequate separation between production and development access.
• Colonial Pipeline (2021): A single compromised VPN account with no MFA enforced. One identity. No second factor. Fuel supply disruption across the eastern United States. Every MFA mandate that landed in your organization after 2021 has this incident’s fingerprints on it.
• Uber (2022): A contractor’s credentials obtained through MFA fatigue, repeated push notifications until the user accepted to stop the noise. The attacker then moved laterally through internal systems because access controls weren’t scoped tightly enough to limit blast radius. The failure wasn’t technical sophistication. It was operational immaturity in how MFA was implemented and how privilege was bounded.
• Microsoft (2023): A stolen MSA signing key used to forge authentication tokens across cloud tenants. The identity trust model itself became the attack surface. When cryptographic key management fails, every downstream access decision built on top of it is compromised.
• MGM Resorts (2023): Attackers identified a senior employee via LinkedIn, called the IT help desk impersonating them, and convinced the agent to reset credentials and MFA with no callback protocol, no strong out-of-band verification. Caesars Entertainment was hit the same month by the same pattern. The failure wasn’t in the authentication stack. It was in the help desk itself. The layer where humans prove humans and deepfake voice and video now make that layer trivial to defeat at scale.

Each of these is an IAM failure. Excessive privilege. Missing MFA. Orphaned accounts. Poor federation hygiene. Inadequate key lifecycle management. Help desk identity verification. The controls that now appear in your compliance frameworks have these incident names written invisibly inside them.

What Compliance Actually Tells You (And What It Doesn’t)

Here’s the uncomfortable truth about compliance frameworks: they are lag indicators by design. They codify the minimum bar required to prevent the breach that already happened. They say nothing reliable about the breach that’s being planned right now.

The gap between a compliance checkbox and mature IAM posture is where the next incident is living. I see this gap constantly, and it’s worth naming directly.

• MFA enabled versus phishing-resistant MFA enforced at the authentication policy layer hardware-bound, not just a push notification toggle sitting in a dashboard that nobody monitors for fatigue patterns.
• Privileged access documented versus PAM operationally enforced with just-in-time provisioning, session recording with active review, and standing access treated as a policy exception rather than the default.
• Access reviews completed versus access reviews that actually reduce privilege, where the outcome of the review cycle is measurably fewer entitlements per identity, not just a signed-off spreadsheet that nobody acted on.
• Service accounts inventoried versus non-human identities continuously monitored with behavioral baselines, anomaly alerting, and rotation schedules enforced by automation rather than calendar reminders.
• Zero Trust policy adopted versus a network architecture where identity is actually the control plane, not a slide in a board presentation, and where access decisions factor not just who the user is, but where they are, what device they’re on, and whether their current behavior looks like their baseline.

Identity used to answer “are you allowed?” It now has to answer “does this access attempt even look like you?” Impossible travel, high-risk geographies, session risk, device posture — these belong inside the authentication decision, not inside a dashboard someone reviews on Mondays.

• IAM capabilities deployed versus IAM KPIs tracked and trended over time because what doesn’t get measured doesn’t improve, and the maturity of an identity program shows up in the shape of its metric curves, not in the inventory of tools on the license schedule. If you can’t tell me whether entitlements-per-identity is declining, whether standing privilege has shrunk quarter over quarter, or how long a new joiner waits for correct access – you don’t have a program posture, you have a tool stack.

Compliance tells you what the floor looks like. It does not tell you where the ceiling is. And in my experience, most organizations have stopped somewhere between the two and called it done.

The Dangerous Comfort Zone: When Your Team Mistakes Compliance for Security

The organizational behavior this creates is one of the most persistent problems I work against. When audit cycles become the primary driver of the IAM roadmap, the team’s incentive structure warps in a specific and dangerous direction.

You stop optimizing for threat reduction. You start optimizing for evidence collection.

I’ve seen this show up in recognizable patterns across organizations of every size.

• Quarterly access reviews conducted as rubber stamps, certifiers clicking approve on hundreds of entitlements in minutes because the process was designed to generate a record, not to generate a decision. The question being answered isn’t “does this person need this access?” It’s “how quickly can we close the certification campaign?”
• Role proliferation allowed to compound year over year because the current roles passed the last audit, so nobody wants to touch them. The organization is carrying thousands of roles, most of which are poorly defined, overlapping, and impossible to audit meaningfully but the audit passed, so the conversation doesn’t happen.
• PAM tools deployed, licensed, and documented and operationally ignored. The vault exists. The accounts are technically onboarded. But privileged sessions aren’t being reviewed, standing access is still the default, and the tool that was supposed to transform privileged access management is functioning as an expensive credential repository.
• IGA platforms configured to enforce policy at provisioning and then left unmonitored for drift. Accounts created with the right access on day one, accumulating entitlements through ad-hoc requests for three years, and nobody has looked at the aggregate picture because the provisioning workflow is compliant.

If any of this feels familiar, I’m not judging the team rather I’m naming the system. When compliance is the primary success metric, this is the rational response to the incentive structure. The problem is that rational compliance behavior and effective security behavior are not the same thing, and the gap between them is where attackers operate.

IAM practioners shoould put it plainly to leadership: Audit Ready is not the same as Breach Proof. A team optimizing for closing the certification campaign rather than reducing the risk the entitlement actually carries will produce a clean audit and a vulnerable organization at the same time. The moment those two phrases get conflated above the CISO’s head, the program inherits a mandate that looks like security but isn’t.

How to Get Ahead of the Grave – A Practitioner’s Operating Model

Diagnosis without direction isn’t useful. So here is the operating model I apply when I want to move an identity program from reactive compliance posture to proactive threat-informed design. This isn’t theoretical, it’s what actually works in practice.

The list is structured deliberately: the first six harden your posture against breach patterns already on public record; the seventh forces your program to keep pace with threats no auditor has yet catalogued.

1. Threat-model your identity fabric before you scope your controls. Start with adversary behavior, not framework requirements. Map the specific identity attack paths relevant to your environment — credential theft, privilege escalation, lateral movement via federated trust, non-human identity abuse. Then ask which of your current controls actually interrupt those paths and which ones only satisfy an auditor.

• A frame worth internalizing here, from John Lambert: defenders think in lists, attackers think in graphs, and as long as that’s true, attackers win. Your access review spreadsheet is a list. The web of trust between your identities, groups, federations, service accounts, and privileged resources is a graph, and that graph is the terrain your adversary is actually traversing.

2. Define your identity tiers and map blast radius per tier explicitly. Not all identities carry equal risk. A tier-one privileged identity with access to production infrastructure and administrative federation capabilities has an entirely different blast radius than a standard user account. Your controls, monitoring intensity, and response playbooks should reflect that difference. If they don’t, you’re applying uniform protection to non-uniform risk.
3. Run tabletop exercises scoped specifically to identity failure modes. Most tabletops I’ve participated in simulate perimeter or endpoint compromises. Run the scenario where your IdP is compromised. Run the scenario where a service account with excessive privilege is abused by an insider. Run the scenario where MFA is defeated at scale through fatigue or SIM swapping. The gaps that surface in those conversations are the gaps that matter.
4. Red team your identity layer – don’t wait for a real incident to find the gaps. Tabletops surface the failures you can imagine; adversarial testing surfaces the ones you can’t. Commission identity-focused red team engagements on a recurring cadence — credential theft, session hijack, federation abuse, privilege escalation, help desk social engineering and feed what they find back into architecture rather than filing it as a report. Gaps that never appear in access reviews or audits almost always appear under someone actually trying to break in.
5. Instrument your IGA for behavioral anomaly, not just policy violation. Policy enforcement catches known-bad. Behavioral analytics surface unknown-bad. If your identity governance platform is only alerting when a provisioning rule is violated, you’re blind to the user whose access pattern changed three months ago in ways that no individual action violated policy but the aggregate behavior is deeply suspicious.
6. Build your access review process around privilege reduction as the measurable outcome. Track entitlements per identity over time. Make the success metric a declining curve, not a closed certification campaign. If your access reviews aren’t resulting in access removal, they aren’t reviews, they’re rituals.
7. Treat non-human identity with the same rigor as privileged human identity. Service accounts, API keys, OAuth tokens, pipeline credentials – these are the identities attackers are targeting at scale right now because they’re often under-governed and over-privileged. If you don’t have a comprehensive non-human identity inventory with ownership, purpose, and lifecycle enforcement, this is the highest-priority gap in most environments I’ve seen.
8. Plan for the attacks your compliance framework hasn’t named yet. The controls in your baseline were written against breaches that have already happened. Deepfake-assisted help desk impersonation, AI-generated vishing, synthetic identity fraud, ML-enhanced MFA fatigue — these are landing in production right now and appear in no auditor’s checklist. Build a forward-looking layer into your program that tracks emerging identity threats quarterly, runs tabletop exercises against them, and lands the control before the framework tells you to.
9. Rehearse the recovery, not just the detection. Assume the breach has already landed. Do the right people know their roles, and are they reachable at 3 a.m. on a holiday? How fast can you rotate privileged credentials at scale, sever federated trust, and re-establish a known-good authentication plane? Most programs have never actually measured how long identity recovery would take under real conditions. Find out before an attacker makes you find out.
10. Plan for the attacks your compliance framework hasn’t named yet. The controls in your baseline were written against breaches that have already happened. Deepfake-assisted help desk impersonation, AI-generated vishing, synthetic identity fraud, ML-enhanced MFA fatigue – these are landing in production right now and appear in no auditor’s checklist. Build a forward-looking layer into your program that tracks emerging identity threats quarterly, runs tabletop exercises against them, and lands the control before the framework tells you to.

The Obligation We Carry as IAM Practitioners

I want to end with something direct, because I think it matters.

The people building identity infrastructure today are either providing the incident report that writes the next regulation, meeting the one that already exists, or for the few doing this exceptionally well, quietly setting the bar that tomorrow’s framework will codify as the new minimum, not because something went wrong but because it got done right first.

There is no neutral position. The access controls you enforce or fail to enforce, the privilege you scope or over-grant, the MFA you deploy meaningfully or deploy performatively, all of it is making a real-world determination about whether the next catastrophic breach happens on your watch and in your environment.

That’s not meant to be dramatic. It’s meant to be accurate.

Reframing what good IAM work actually means is worth doing explicitly.

• Good IAM work is not completing a certification campaign on time. It is ensuring that the humans approving entitlements are actually examining them and removing the ones that shouldn’t exist.
• Good IAM work is not deploying a PAM tool. It is operationalizing privileged access controls to the point where standing access is genuinely exceptional and every privileged session is visible and accountable.
• Good IAM work is not enforcing MFA across the enterprise. It is enforcing phishing-resistant MFA in the places where a compromised credential would have catastrophic blast radius, and knowing specifically which those places are.
• Good IAM work is not a team drowning in manual toil. It is using the automation and AI capabilities now available to us to surface dangerous privileges, inform access review decisions, and detect the identity patterns no human reviewer will ever catch at scale, freeing human judgment for the decisions that actually require it.
• Good IAM work is not passing an audit. It is building an identity posture that would survive an attacker who has never read your audit report and does not care about your certification timeline.

The frameworks we operate inside exist because somewhere, at some point, someone’s identity infrastructure failed publicly enough to force a regulatory response. The question I carry into every architecture decision, every policy review, and every control deployment is a simple one: am I building something that prevents that, or am I building something that looks like I prevented it?

The difference between those two things is where real harm lives and where the next regulation is quietly being drafted.

Build identity infrastructure that makes the next compliance framework unnecessary.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

References

– [1] U.S. Department of Health and Human Services, “Health Insurance Portability and Accountability Act of 1996 (HIPAA),” Public Law 104-191. https://www.hhs.gov/hipaa/index.html

– [2] U.S. Securities and Exchange Commission, “Sarbanes-Oxley Act of 2002,” Public Law 107-204. https://www.sec.gov/about/laws/soa2002.pdf

– [3] European Union, “Regulation (EU) 2016/679 (General Data Protection Regulation),” Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2016/679/oj

– [4] PCI Security Standards Council, “Payment Card Industry Data Security Standard (PCI DSS).” https://www.pcisecuritystandards.org/standards/pci-dss/

– [5] U.S. Department of Justice, AMBER Alert Program, “About AMBER Alert.” https://amberalert.ojp.gov/about

– [6] Krebs, Brian, “Target Hackers Broke in Via HVAC Company,” KrebsOnSecurity, February 5, 2014. https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/

– [7] Cybersecurity and Infrastructure Security Agency (CISA), “Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations (SolarWinds),” Alert AA20-352A, December 2020. https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a

– [8] Cybersecurity and Infrastructure Security Agency (CISA) and FBI, “DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks (Colonial Pipeline),” Alert AA21-131A, May 2021. https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-131a

– [9] Uber Technologies, “Security update,” Uber Newsroom, September 19, 2022. https://www.uber.com/newsroom/security-update/

– [10] Microsoft Security Response Center, “Analysis of Storm-0558 techniques for unauthorized email access,” Microsoft Threat Intelligence, July 14, 2023. https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/

– [11] U.S. Securities and Exchange Commission, MGM Resorts International Form 8-K, September 12, 2023. https://www.sec.gov/Archives/edgar/data/789570/000119312523237814/d551104d8k.htm

– [12] Lambert, John, “Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win.,” GitHub, 2015. https://github.com/JohnLaTwC/Shared

About the Author

Nishad Sankaranarayanan is a cybersecurity executive with 20+ years of experience building and leading enterprise security programs in complex, regulated environments. He serves as Global Director of Cybersecurity at Genuine Parts Company — a Fortune 200, $20B+ global enterprise — where he leads a program spanning workforce and customer identity, cloud security, AI governance, and cyber defense across 17 countries. Previously, he was part of the post-breach security transformation at Equifax, contributing to FedRAMP authorization and NIST 800-53 compliance across a large-scale financial data environment. Nishad holds a CISO Executive Certificate from Carnegie Mellon University, serves on advisory boards for several cybersecurity startups, and founded the Atlanta IAM User Group. He is a recognized speaker at Gartner IAM Summit and Identiverse, a 2025 Constellation Research SuperNova Award recipient for Cybersecurity Leadership, and a three-time Ping Identity Excellence Award winner.