The Pattern I Keep Seeing
Over 25 years in cybersecurity and compliance, I've developed a strong opinion about why most compliance automation projects fail. Whether it's a vendor platform that gets deployed and abandoned, or an internal build that never quite gets adoption, the failure pattern is remarkably consistent.
The projects that die aren't killed by bad technology. They die because they're designed as passive repositories instead of active participants in how work actually gets done.
If you're building compliance automation right now, or evaluating vendors, understanding this distinction will save you millions and years of wasted effort.
The CMDB Trap: Why "Source of Truth" Thinking Fails
Here's the pattern: someone in compliance or security decides "we need a single source of truth for all our systems and controls." It sounds logical. You can't secure what you don't know about. You can't comply without visibility.
So teams start building:
- System inventory with metadata (owner, data classification, connections)
- Control mapping to requirements (NIST, SOC 2, FedRAMP)
- Evidence collection pipelines
- Risk scoring and dashboards
- Attestation workflows
The data model gets complex. You're pulling from 15 different sources. You build normalization layers, reconciliation logic, beautiful UIs. Leadership loves the demos.
Then reality hits.
The data goes stale because updating it requires manual effort. Engineers bypass the system because it's not in their critical path. Exceptions pile up. The compliance team starts maintaining a separate spreadsheet "just for these edge cases." Within 18 months, you're back to manual processes.
Why does this keep happening?
Because these systems aren't built into how work actually gets done. They're observation layers that rely on people checking dashboards and manually updating records. People don't check dashboards unless the dashboard gives them something they can't get elsewhere. Teams don't update records unless the records are required for something they already need to do.
The system isn't in the critical path of anything people actually care about.
What Went Wrong?
The root cause isn't the technology. It's the mental model.
These projects fail because they're designed as passive repositories instead of active participants in how work gets done. They're built on the assumption that if you collect enough information and make it visible, people will magically change their behavior.
They won't.
People don't check dashboards unless the dashboard gives them something they can't get elsewhere. Teams don't update records unless the records are required for something they already need to do. Data doesn't stay fresh unless it's refreshed as a byproduct of real work.
This is why CMDBs fail. This is why compliance automation becomes shelfware. The system isn't in the critical path of anything people actually care about.
The Two Rules That Actually Work
Through building compliance programs at Intel, VMware, Oracle Cloud, and AWS, I've identified exactly two patterns that prevent the death spiral:
Rule 1: Event-Driven Data, Not Polling
Your compliance system should update itself when things happen, not by periodically asking "what changed?"
The difference matters:
- Polling: Your system checks identity providers daily at 3am to see if policies changed
- Event-driven: The identity provider sends your system a webhook immediately when a policy changes
Event-driven systems stay current because they're reacting to the same events that drive the business. When an engineer deploys a change at 2am, when does your compliance system know about it? If the answer is "whenever the next sync runs," you're building a system that will become stale.
The test: Could engineers bypass your system entirely and nothing would break operationally? If yes, your data will rot.
Rule 2: Tied to Action, Not Just Observation
Every piece of data you collect should be required for a decision or trigger an action. If it's just "nice to know," it will go stale within months.
The difference:
- Observation: Your system shows which systems have MFA enabled
- Action: Your system blocks deployments to production for services without MFA
Observation is passive. It relies on someone checking the dashboard and deciding to do something. Action is automatic. The system enforces the control.
The test: Pick any data field in your compliance system. Imagine deleting it. Would anyone's workflow break? Would any automated process fail? If not, that data will go stale within six months.
From Principle to Practice: Risk-Based Monitoring
Let me be specific about how these principles play out in real compliance architecture.
The core insight: Not all controls need the same monitoring frequency. Your marketing documentation doesn't need the same attention as your customer payment processing system. But most compliance tools treat everything equally, creating alert fatigue and wasting resources.
The solution is risk-based continuous monitoring where assessment frequency is driven by multiple factors:
- Data sensitivity (PII, financial data, credentials)
- Known vulnerabilities in the technology stack
- Lateral attack surface and blast radius
- External exposure (internet-facing vs. internal)
- Business criticality
This isn't theoretical. I built a dynamic risk tool that calculated risk scores and automatically adjusted monitoring cadence. High-risk systems get hourly checks. Low-risk systems get quarterly reviews. The risk score directly changed SLAs, monitoring frequency, and escalation paths.
Why it worked:
- Event-driven: When a CVE was published affecting our dependencies, risk scores updated automatically
- Tied to action: The risk score wasn't just a number on a dashboard. It determined who got paged, what controls were required, and audit scope
The compliance team stopped maintaining manual risk registers. The security team trusted the risk scores because they reflected reality. Engineering teams understood why certain systems had tighter controls.
The tool didn't die because it was in the critical path of incident response, audit prep, and vulnerability management.
The Privacy Paradox
Here's an irony: compliance automation often creates its own compliance problems. To prove you're handling data correctly, tools collect and store sensitive configurations, user lists, and system states. Now you have PII retention and data minimization issues.
There's a better architectural approach that I've used: store cryptographic proof instead of the actual data.
Instead of storing complete configuration snapshots:
- Store SHA-256 hashes of the configuration state
- Store the compliance evaluation (PASS/FAIL with specific failures)
- Store references to where the source data lives
This gives you verifiable evidence without the retention burden. You can prove "MFA was properly configured on systems X, Y, Z on January 15th" without storing every user's authentication settings. If an auditor questions it, they can request the current configuration, re-compute the hash, and verify your historical claim.
This isn't theoretical. Digital forensics has used hash-based chain of custody for decades. Blockchain uses similar concepts for tamper-proof records. The pattern works when you need point-in-time compliance verification without indefinite data retention.
The Hard Truth
Compliance automation fails when it asks people to do extra work for "compliance reasons." It succeeds when it reduces work and makes their jobs easier.
You cannot mandate people into maintaining a CMDB. You cannot policy your way into data freshness. You can't build a system that requires continuous manual feeding and expect it to survive.
Build systems that update themselves when things happen. Build tools that people need to use to do their actual jobs. Tie every piece of data to a decision or action that matters.
If you're building or buying compliance automation right now, ask yourself:
- Does this system update automatically when things change, or does it require manual updates?
- Is this system in the critical path of decisions we make, or is it an observation layer we hope people check?
If you can't answer "automatic" and "critical path," you're building expensive shelfware.
About the author: Chris Davis is a Principal Product Security Engineer with 25+ years building security and compliance programs at Intel, VMware, Oracle Cloud, and AWS. He specializes in translating complex compliance requirements into engineering controls that actually survive in production. His 13 published books on information security and IT auditing are used in graduate cybersecurity programs. Connect on LinkedIn or read more at cloudauditcontrols.com.
