Compliance Is a System security Engineering Problem
In 2020, a major software vendor passed its annual security compliance audit with no significant findings. Weeks later, threat actors were discovered to have maintained undetected access to thousands of customer networks for months - including US federal agencies. Every control was documented. Evidence was clean. The audit said the system was secure. The adversary knew otherwise. That gap - between compliance artifacts and operational reality - is the problem this post is about.
Trust cannot be faked. Compliance programs that optimize for speed and badges instead of outcomes do not build trust. They erode it.
Compliance is a system security engineering (SSE) problem. It is the intentional design of systems that remain secure, resilient, and trustworthy under real operational conditions, including human behavior, imperfect execution, and failure states. NIST SP 800-160v1r1 reinforces this: building trustworthy systems requires a transdisciplinary approach, not stovepipes for software, hardware, and the human element treated in isolation. NIST SP 800-160v2r1 extends this further, making clear that a system must also be engineered to anticipate, withstand, recover from, and adapt to adversity. A compliance program that only functions under ideal conditions is not engineered. It is staged. The real failure was treating compliance as a standalone problem, or something that tools alone could solve.
What SSE Actually Requires
SSE is not synonymous with automation. SSE is about:
- Defining objectives and constraints
- Designing feedback loops
- Assigning ownership and accountability
- Modeling failure modes
- Continuously validating performance against intent
NIST SP 800-160v1r1 frames this across the full system life cycle, from requirements and architecture through operation, maintenance, and disposal. Security is not a phase. It is a property that must be engineered in from the beginning and validated at every stage. ISO/IEC 15288:2023, the international standard for systems and software engineering life cycle processes, establishes the same principle across global practice - SSE requirements do not belong to any single national framework.
NIST SP 800-160v2r1 adds a critical dimension: compliance systems must be designed not just for nominal operation, but explicitly for degraded and contested conditions. Every engineered system must address four resilience properties: anticipate adverse conditions before they occur, withstand them when they arrive, recover from their effects, and adapt to reduce future exposure. Compliance systems are almost never designed against these four properties. They are designed for the audit, not the adversary. That gap is an SSE failure, not a policy failure.
A well-engineered compliance system assumes:
- Humans exercise judgment and will occasionally get it wrong
- Controls will fail and must degrade safely
- Exceptions are normal and must be governed, not hidden
- Evidence must reflect reality, not aspirations
Human Judgment Is a Control - Engineer It Accordingly
Human judgment is a control mechanism that can be engineered with the same rigor applied to infrastructure. In high assurance systems, we intentionally design for separation of duties, independent review, escalation paths, kill switches, and ethical accountability. Engineers do this in aviation, nuclear systems, medical devices, and safety-critical software every day.
NIST SP 800-160v1r1 supports this through its principle of distributed privilege, limiting any single individual or component from having unchecked authority. This is not a workaround for human fallibility. It is a recognized design pattern for making human decision-making safer, more accountable, and more auditable.
SP 800-160v2r1 reinforces this from an operational resilience perspective: resilience measures are of limited value if critical personnel are unavailable, undertrained, or unable to respond under stress. Too many compliance programs distribute control ownership on paper without engineering the human layer for real operational continuity. When a control owner leaves, a process breaks down under pressure, or an incident demands rapid judgment, the absence of engineered human resilience becomes immediately visible.
Trust Is an Output of a System
Trust is an emergent property, but emergent properties do not arise by accident. NIST SP 800-160v1r1 distinguishes between trust and trustworthiness: trust is the belief a system will behave as expected, while trustworthiness is the demonstrated property that justifies that belief. Compliance programs that manufacture evidence without governing actual behavior produce trust without trustworthiness. That gap is where failures occur.
SP 800-160v2r1 extends this definition to include resilience and survivability under adversity. By this standard, a compliance system that produces clean audit artifacts but collapses during an incident or a control failure is not trustworthy. The artifacts were evidence of aspiration, not performance.
ISO/IEC 27001:2022 embeds the same principle structurally. Its continual improvement requirements and Plan-Do-Check-Act model require that controls be validated against operational reality, not just documented. ISO/IEC 27002:2022 reinforces this in its implementation guidance: controls are operational mechanisms, not paper artifacts. Trust is the output when:
- Intent is clearly defined
- Controls are implemented as operational mechanisms, not documents
- Feedback loops detect drift early
- Accountability is unambiguous
- Evidence is a byproduct of operations, not a parallel process
When compliance programs are built solely to satisfy auditors, they become narratives. When built to govern real behavior, they become systems. The difference is design discipline.
Resilience Is How You Prove the System Works
A system is not proven by how it performs when everything goes right. It is proven by how it performs when things go wrong.
SP 800-160v2r1 defines cyber resilience as the capability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises. These are SSE requirements that must be specified, designed for, implemented, and validated across the system life cycle. Resilience cannot be siloed. It must span hardware, software, data, processes, facilities, and people. Applying resilience in one layer while leaving others fragile does not produce a resilient system. It produces an illusion of one.
This is no longer purely a framework consideration - it is increasingly a legal one. The EU's Digital Operational Resilience Act (DORA), which took effect in January 2025, mandates that financial entities demonstrate operational resilience through tested, documented continuity capabilities. DORA does not accept artifact-based compliance. It requires demonstrated performance under adversity. ISO 31000:2018, the international risk management standard, similarly frames risk management as a continuous operational discipline, not a point-in-time assessment. The direction of travel across regulatory and standards frameworks globally is unmistakable: resilience must be engineered, not assumed.
For compliance, the resilience test is straightforward: what happens when a key control fails, a control owner is unavailable, or an auditor asks a question the system was not designed to answer? If the answer is scrambling and surprise, the compliance system was engineered for the best case. That is not SSE. That is optimism with documentation.
Resilience in a compliance context means designing explicitly for:
- Control failure and safe degradation
- Personnel continuity and cross-trained ownership
- Incident response that does not compromise evidence integrity
- Adaptive improvement after findings, not just corrective action closure
The Real Problem Is Incentives, Not Tools
The heart of the problem is economic and cultural, not technical. Markets rewarded fast and cheap. Procurement accepted artifacts over understanding. Vendors optimized for sales velocity. Founders responded rationally. Incentives removed trust, not SSE.
NIST SP 800-160v1r1 noted that the industry responded to growing complexity with more defensive tools rather than addressing underlying SSE weaknesses, producing a reactive cycle with no structural improvement in trustworthiness. Compliance programs followed the same pattern.
SP 800-160v2r1 sharpens this in the context of persistent threats. Adversaries often maintain undetected presence for extended periods before discovery. Compliance programs optimized for point-in-time audits are structurally blind to this. Continuous monitoring and adaptive response are not operational enhancements in this framework. They are SSE requirements. Treating them as optional is an incentive problem masquerading as a resource problem.
SSE done correctly makes ownership visible, exceptions explicit, drift measurable, and trust defensible under scrutiny. Automation supports this by reducing noise, improving signal, and freeing humans to focus on judgment. It is one component in a broader control system, not a replacement for governance.
Build Systems That Make Trust Real
NIST SP 800-160v1r1 concludes that security engineering must be fundamental to systems engineering, not bolted on afterward. SP 800-160v2r1 adds that resilience must be engineered with the same intentionality, spanning every layer of people, process, and technology across the full system life cycle. ISO/IEC 15288:2023, ISO/IEC 27001:2022, IEC 62443, and DORA all point in the same direction from their respective domains. Most compliance programs today do not resemble that description.
This is a call to CISOs and compliance leaders as much as it is to engineers. The frameworks exist. The standards are aligned. The gap is not knowledge - it is the organizational will to demand that compliance be built as a system rather than assembled as a narrative.
System engineers need to reclaim compliance as an engineering discipline. That means designing for adversity, not just audits. Engineering the human layer with the same rigor as the technical layer. Producing evidence as a byproduct of operations, not a parallel artifact process. And accepting that a compliance system which cannot withstand real stress was never truly built. If we do not lead, others will continue to reduce compliance to paperwork, tools, and theater. Let's build systems that make trust real.
References
US Federal Frameworks
- NIST SP 800-160v1r1 - Systems Security Engineering
- NIST SP 800-160v2r1 - Developing Cyber-Resilient Systems
- DoD Systems Engineering Guidebook - ac.cto.mil
International Standards
- ISO/IEC 27001:2022 - Information Security Management Systems
- ISO/IEC 27002:2022 - Information Security Controls
- ISO/IEC 15288:2023 - Systems and Software Engineering: System Life Cycle Processes
- ISO 31000:2018 - Risk Management: Guidelines
- IEC 62443 - Security for Industrial Automation and Control Systems
- EU DORA (Digital Operational Resilience Act) - Regulation (EU) 2022/2554
Related Reading
