Certified and Compromised: Why Compliant Organizations Keep Getting Breached

Clean audits. Current certifications. Mature policies.

Breached anyway.

At IDX, we regularly investigate incidents involving organizations with recent audits, current security certifications, and well-documented security programs. Those records matter. They show investment, discipline, and accountability.

But they do not answer the question that matters most during an incident:

Did the controls work when an attacker tested them?

That is where the gap appears.

The problem is not that organizations are failing compliance. The problem is that attackers are testing things compliance was never designed to prove.

SOC 2 reports, security certifications, and audit findings serve an important purpose. They help organizations document controls and demonstrate that security has structure. But they do not prove those controls will hold up against current attacker techniques, configuration drift, exception sprawl, or the pressure of an active incident.

Threat actors do not care whether a control exists on paper.

They care whether it fails under real conditions.

What "Certified and Compromised" Looks Like

The examples below reflect recurring patterns we see across DFIR matters. They are not failures of compliance alone. They are failures of validation, ownership, and operational follow-through.

MFA Was Enforced. The Session Was Still Stolen.

The audit confirmed multifactor authentication across user accounts.

That sounds good. It is good. But it does not answer a more important question: would the MFA implementation hold up against current phishing techniques?

In many business email compromise matters, the organization has MFA enabled. The attacker still gets in.

One common path involves an Adversary-in-the-Middle (AiTM) phishing kit. The user enters credentials and completes the MFA prompt. The attacker captures the valid session token and accesses the cloud environment through what appears to be a legitimate session.

The control existed.

It did not stop the technique.

How to reduce the risk:

Use phishing-resistant MFA for administrators, executives, finance users, legal teams, and users with broad mailbox access.

Review conditional access policies for exclusions and legacy exceptions.

Monitor for suspicious session activity, impossible travel, new device fingerprints, new inbox rules, and unusual mailbox access.

Treat push-based MFA and SMS MFA as higher risk for sensitive users.

Strengthen help desk verification procedures before MFA resets or device re-enrollment.

EDR Was Deployed. The Ransomware Still Ran.

The audit verified endpoint detection and response coverage.

But coverage does not always mean protection.

In ransomware matters, the issue is often not whether EDR was installed. The issue is whether the organization tuned and tested detections for the behaviors attackers use before encryption.

Out of the box EDR often detects known malware. The harder problem is detecting legitimate tools used in abnormal ways.

Common examples include:

• New or unusual remote management tools, such as AnyDesk, ScreenConnect, Atera, or TeamViewer
• PowerShell, PsExec, WMI, RDP, or WinRM used across many systems in a short period
• Attempts to disable security tools, access backups, or delete recovery options
• Large file staging, archive creation, or mass file changes

When these behaviors only generate alerts, and no one reviews them in real time, the attacker gains time to harvest credentials, move laterally, access backups, and encrypt critical systems.

The detection data existed.

The response process did not keep pace.

How to reduce the risk:

• Identify systems where EDR runs in alert-only, passive, disabled, or degraded modes
• Assign an owner and expiration date to each exception
• Require documented risk acceptance for systems outside blocking policy
• Tune detections around ransomware behaviors, not only known ransomware files
• Test whether those behaviors trigger blocking or urgent escalation, not passive alerts

Logs Were Retained. Detection Still Failed.

The audit confirmed centralized logging and 12-month retention.

That helped the investigation. During forensic analysis, those logs helped reconstruct the intrusion, including initial access, lateral movement, exfiltration activity, and encryption.

But the same logs also showed suspicious activity before the ransomware event.

The issue was not data availability. The issue was operational use.

Logs without detection logic, alert triage, escalation paths, and ownership create evidence after the fact. They do not create security outcomes on their own.

How to reduce the risk:

• Identify the alerts that require immediate review.
• Assign ownership for high-risk alerts.
• Reduce noisy rules that hide real activity.
• Confirm after-hours escalation procedures.
• Test whether key logs are retained, searchable, and complete.
• Review whether your security team uses logs for active detection or only post incident reconstruction.

Why the Gap Exists

Compliance frameworks do real work. They create structure around security programs.

But attackers exploit the space between documented controls and operational reality.

Point in Time Assurance Does Not Equal Continuous Assurance

A SOC 2 Type II report covers a defined review period. After that period ends, the environment keeps changing.

New assets come online. Configurations drift. Vendors receive access. Administrators create exceptions. Business teams adopt new tools. Legacy systems remain active.

The report reflects a period of time.

The attacker targets the environment as it exists today.

Control Presence Does Not Equal Control Effectiveness

These sound similar, but they answer different questions:

That gap is where many breach investigations begin.

Attackers Exploit Seams Between Controls

Audits often evaluate access management, endpoint security, vulnerability management, logging, and incident response as separate control areas.

Attackers do not operate that way.

They chain weaknesses across domains. An exposed system creates initial access. Weak segmentation enables lateral movement. Incomplete alert triage delays detection. Untested response procedures slow containment. Backup gaps increase recovery pressure.

No single control tells the full story.

The seams do.

The Board-Ready Validation Checklist

The strongest organizations treat compliance as a baseline. They treat security governance as an operating discipline.

A simple validation exercise helps: ask whether the controls documented in the audit would hold up under real attack conditions.

Identity controls

• Do sensitive users have MFA that resists phishing, session theft, and help desk abuse?

Endpoint protection

• Do critical systems have EDR in blocking mode, and would ransomware behavior trigger urgent escalation?

Logging and alert ownership

• Are the right logs retained, searchable, and reviewed quickly enough to stop an active intrusion?

Vendor and third-party access

• Which vendors, integrations, remote access tools, and third-party applications have persistent access to sensitive systems or data?

Recovery readiness

• When did the organization last restore from backups under realistic conditions?

A ransomware event compresses time. Teams default to what they have practiced.

What This Means for Counsel, Carriers, and Boards

For privacy attorneys, the post incident question is no longer only, "Was the organization compliant?"

The harder question is whether the compliance posture was defensible.

After an incident, a clean audit report helps tell the story. It rarely tells the whole story.

A stronger record shows that the organization tested controls, identified gaps, assigned ownership, and acted on findings.

For cyber insurers, underwriting and claims questions continue to move toward the same issue: did the represented controls operate effectively at the time of loss?

For boards and CISOs, the conversation needs to move beyond whether the organization passed the audit.

Better questions include:

• Who owns each critical control?
• Which exceptions have we accepted?
• When do those exceptions expire?
• When did we last test phishing resistant MFA?
• Which systems have endpoint tools in alert-only mode?
• Who reviews high-risk alerts after hours?
• Which vendors have privileged access?
• When did we last restore from backups under realistic conditions?
• Which incident response decisions have we rehearsed?

These questions move the discussion from compliance posture to operational resilience.

The DFIR View

In DFIR matters, this distinction becomes clear quickly.

We are often asked to determine how the attacker got in, what they accessed, what they took, and why no one detected the activity sooner.

Those answers rarely turn on whether a policy existed.

They turn on whether the control worked. Whether someone owned the alert. Whether exceptions were tracked. Whether logs were reviewed. Whether the response process moved fast enough to contain the intrusion.

Compliance still matters.

But after a breach, the harder question is whether the organization understood its risk, tested its controls, acted on known gaps, and maintained a defensible record of doing so.

Compliance is not the problem.

Treating compliance as completion is.

Audits help show whether controls were designed and operating during a review period.

Validation shows whether they hold when an attacker tests them.

About IDX

IDX investigates ransomware, business email compromise, and other cyber incidents for organizations across regulated industries. Our DFIR practice supports counsel and carriers throughout the incident lifecycle, from initial triage through forensic analysis, regulatory response, and lessons-learned reporting. We also help organizations test and strengthen the controls discussed in this post before an incident occurs.