05: Where Frameworks Fall Short

*This is post 5 of 6 in Avertium's "The Trust Problem in Enterprise Security" blog series

By Sarah Clarke, Consultant - QSA and AI Architect

On March 31, 2025, the last of the future-dated PCI DSS 4.0 requirements became mandatory. As of that day, every requirement in v4.0.1 is in scope for every assessment, with no grace period left. The first round of post-transition ROCs is being completed now. From the assessor side of the table, I'm seeing a consistent pattern. Organizations are passing the new requirements without addressing most of the substantive trust problems this series has covered. The framework doesn't ask about them.

This isn't a complaint about PCI DSS 4.0 specifically. The same shape shows up in HIPAA and SOC 2. Frameworks codify the controls the industry has agreed on, and that's slow by design. The trouble is that several of the trust shifts this series has covered, such as IdP-as-attack-surface, AI agents pulling themselves into scope, vendor concentration cascading across roles, have outpaced the framework’s update cycle.

This post is about what's missing, and what an assessor or anyone preparing for an assessment can do about it before the frameworks catch up.

what 4.0 got right

PCI DSS 4.0 is a meaningfully better standard than 3.2.1, and several of its changes are direct responses to the threat patterns of the last decade.

The shift toward continuous compliance instead of annual audit-time scrambles is real and overdue:

• The customized approach gives mature organizations a way to implement controls that fit their architecture, with a documented targeted risk analysis explaining why.
• MFA requirements are stronger and broader
• Payment page integrity controls (Requirements 6.4.3 and 11.6.1) directly address the Magecart class of attack
• Logging and monitoring expectations have moved closer to what a SOC actually does

These are real improvements. The customized approach in particular is the mechanism that makes the rest of this post possible. It's how a QSA can sign off on a control that isn't in the framework's compensating-control catalog, as long as the targeted risk analysis is sound.

what it still assumes that doesn't hold

The framework was written around a model of the enterprise that's increasingly aspirational. A few implicit assumptions are worth pulling out:

• Trust components are discrete and contractual. Requirement 12.8 treats third-party service providers as a list of named entities. The reality is layered: Your payment processor runs on a hyperscaler, which provides your IdP, which authenticates the AI agent that summarizes the support tickets that occasionally contain card numbers. Each layer is a TPSP, even though the 12.8 list usually names only one or two of them.
  
  
• Vendors hold one role at a time. Nothing in the standard asks how many distinct trust-bearing roles a single TPSP plays in your environment. As covered in the previous post, this is where the most consequential concentration risk lives.
  
  
• Users authenticate; systems don't. Requirement 8 is built around human authentication. Service accounts, API keys, and OAuth tokens are addressed obliquely. AI agents, which authenticate as a service principal, read at search speed, and act on behalf of users, fall into a category the standard doesn't address with clean language.
  
  
• Data is processed by humans or by deterministic systems. Most of the framework's data-protection logic assumes that data is read by a person or by an application with predictable behavior. Generative AI agents don't fit either category - they produce outputs that recombine source data in ways the data classification policy didn't anticipate.

These assumptions still hold in many environments, but they're failing in enough places to matter — and the percentage is growing.

hipaa and soc 2 share the same blind spots

HIPAA's Security Rule has been showing its age. The proposed Security Rule NPRM from December 2024 is the first serious update in more than twenty years and starts to address some of what's missing, such as mandatory encryption, MFA, vulnerability scanning, network segmentation, and tighter business-associate accountability. It still doesn't name AI agents as a distinct category. The current proposed language treats them as another form of electronic data processing, which technically applies but doesn't help an organization figure out what an agent's compromise actually means for ePHI.

SOC 2's Trust Services Criteria are more flexible by design, and that cuts both ways. The criteria can accommodate AI agents because they don't prescribe controls; they describe outcomes. The weakness is that without prescription, organizations land on the same controls they already had, with AI bolted on top. I've reviewed SOC 2 Type 2 reports recently where the only AI mentioned was a single bullet acknowledging that Copilot is available to staff.

The frameworks codify what was hard to get right in the last cycle, while the current cycle has moved faster than the standards can adapt.

what compensating controls assessors should be asking for

This is the section I find myself talking through most often in engagements. Some are already able to be proved under the customized approach; others will probably show up in the next framework cycle. I haven't seen any on a compliance checklist yet.

• Documented scope inheritance. For each in-scope system, what other systems does it depend on, and which of those dependencies pull additional systems into scope? Most organizations have a scope diagram, but very few have a dependency tree underneath it.
  
  
• AI agent inventory with access justification. Per the previous post in the series, this should be a list of every AI agent or AI-enabled feature, the identity it holds, the data sources it reaches, and the documented business case for the access. This is the artifact missing from almost every AI deployment I see.
  
  
• Identity blast-radius testing. An exercise that walks through the question, “If our IdP is compromised at noon today, which systems lose their trust basis, and how would we know?” A tabletop is enough.
  
  
• Vendor concentration metrics, not just a vendor list. Count the distinct trust-bearing roles each TPSP holds, report the top three, and have a compensating-control plan for each.
  
  
• Real failover, exercised on a defined cadence. The exercise needs to be live, with measured time-to-recover. PCI DSS already requires incident response testing; the assessor's question should extend to provider-failure scenarios.
  
  
• Output controls for AI-summarized regulated data. Standard DLP catches sensitive data in outbound channels. AI agents produce summaries, restructurings, and recombinations that may carry regulated data in forms classifiers weren't trained on. Output validation specifically for agent-generated content is closer to a code-review process than a DLP rule.

A QSA can sign off on any of these under the customized approach if the targeted risk analysis is sound and the control meets the security objective of the original requirement. The framework doesn't prescribe them, but it doesn't prevent them either.

an exercise for you: What to do this week

A framework-gap exercise. No tooling required.

Take your most recent assessment report or SOC 2 attestation.

1. For each of the six compensating controls above, find the section of the report that addresses it. For most organizations, several of those sections don't exist, and the ones that do are sparse

2. Beside each gap, write two things:

• Whether the underlying risk applies in your environment
• Whether you could pass the next assessment by writing a targeted risk analysis and implementing a customized-approach control instead of waiting for the framework cycle to catch up

Most organizations will find that they could close at least three of the gaps before their next assessment, and that doing the work produces controls more relevant to their threat model than the prescribed baseline. The frameworks aren't asking for this yet, but the threat environment already is.

 Stay tuned for our sixth and final post in the series, ”Structured Skepticism as an Operating Model,” which will publish on July 8, 2026 at 10:00 am EST.