Rather than sampling system state periodically, Soteria listens for state change events: configuration changes, policy updates, access control modifications, vulnerability scan results, patch deployments. Each event that affects a control state generates an evidence record automatically.
01. The Ritual and the Reality
"Compliance is not security." Say it at any gathering of security professionals and watch the heads nod. The statement is correct. It is also, at this point, nearly devoid of operational meaning, because the people who need to internalize it most deeply, the people who build compliance processes, purchase compliance tools, and make resource allocation decisions based on compliance status, have heard it so many times that it no longer registers as information.
The ritual acknowledgment of the distinction has become a substitute for actually acting on it. Organizations say compliance is not security, then spend most of their security budget achieving compliance, then express surprise when compliant systems are compromised. The surprise, at this point, is the surprising part.
What we are interested in at Helios Prime is not the statement of the problem. The statement is settled. We are interested in what building systems that actually reflect the distinction looks like, what the architecture is, what the data structures are, what the engineering tradeoffs are when you treat security and compliance as related but distinct problems requiring related but distinct tooling.
Soteria is our attempt to build that tooling. This note is an account of what we have learned so far.
// SOTERIA LOG - CYCLE 16
"Initial premise: if compliance evidence is generated continuously rather than periodically, assurance state becomes a sensor rather than a certificate. This seems obvious. It turns out to be architecturally non-trivial. We have been in the non-trivial part for four months."
02. How the Conflation Happened
The conflation of compliance and security did not happen because people were careless or uninformed. It happened because, at one point in the history of enterprise security, the conflation was approximately reasonable.
In the era when compliance frameworks like NIST, ISO 27001, and PCI-DSS were being developed and adopted, the security landscape was different. The threat surface was smaller. The attack techniques were less sophisticated. The defenders had more time. In that context, a framework that specified a set of controls and required periodic evidence of their implementation was a reasonable approximation of actual security practice. If you had implemented the controls, you were probably more secure than if you had not. The compliance certificate was a noisy but not entirely misleading signal.
What changed: the threat surface expanded dramatically, attack techniques matured rapidly, the time between vulnerability and exploitation compressed from months to hours to minutes in some cases, and the compliance frameworks, which operate on annual or semi-annual cycles, did not compress with them. The gap between compliance cadence and threat cadence became the gap between compliance and security.
"Compliance frameworks were designed for a threat environment that no longer exists at the cadence at which those frameworks were designed. The frameworks have not become wrong, their update cycles have become incompatible with the problem they are trying to address."
The frameworks are still useful. They are not wrong. The controls they specify are, broadly, the right controls. The problem is the temporal mismatch: a control that was compliant six months ago may not be compliant today, and a system that is compliant today may not be secure tomorrow. The periodic audit captures a snapshot of a moving target and presents the snapshot as a current state.
03. What Compliance Actually Measures
It is worth being precise about what compliance frameworks actually measure, because the precision clarifies where the gap is.
// THE TEMPORAL STRUCTURE OF THE PROBLEM
- Audit conducted: T=0 → assurance state known
- Vulnerability introduced: T=0+n (unknown)
- Assurance state: still "compliant" until T=0+12 months
- Attack occurs: somewhere in (T=0+n, T=0+12)
- Audit finds the gap: T=0+12 → remediation begins
"The assurance system was never wrong in its own terms. It accurately reflected the state at T=0. That state was no longer operationally relevant from T=0+n forward."
This is not a criticism of the frameworks. It is a description of their design. They were not designed to provide continuous assurance. They were designed to provide point-in-time evidence of control implementation. The gap is in how the point-in-time evidence has been used, as a proxy for continuous security posture, rather than what it is: a historical record of a specific assessment.
04. The Evidence Gap
The specific problem we are solving with Soteria is what we call the evidence gap: the period between evidence generation events during which the organization's true security posture and its documented assurance state may diverge, with no systematic mechanism for detecting or surfacing that divergence.
The evidence gap is not constant across organizations. It depends on how frequently evidence is collected, how quickly changes to the security posture are documented, and how actively the relationship between control state and threat environment is monitored. For most organizations using standard compliance frameworks, the evidence gap is measured in months.
During the evidence gap, several things can happen: new vulnerabilities can be introduced, existing controls can degrade or be misconfigured, new threat techniques can emerge that the implemented controls do not address, and configuration drift can move the system's actual state away from its documented state. None of these changes are captured in the assurance record until the next audit cycle.
"The evidence gap is the space in which compliance and security come apart. Everything that makes an organization more vulnerable without making them less compliant happens in the evidence gap. It is often large. It is always invisible in the compliance record."
The evidence gap is not eliminated by conducting more frequent audits. The evidence collection process itself is manual, expensive, and disruptive. What eliminates the evidence gap is changing the architecture of evidence generation: from periodic manual collection to continuous automated generation. This is Soteria's central premise.
05. Soteria's Central Premise
Soteria starts from a single architectural inversion: what if compliance evidence was generated continuously rather than collected periodically?
In a traditional compliance process, evidence flows like this: control state exists in the system → periodically, an assessor collects evidence of that state → the evidence is documented → the documentation is reviewed → a compliance determination is made. Evidence generation is a human process applied to a system state. It is periodic, manual, and expensive.
The Soteria premise: control state can be monitored continuously and evidence can be generated automatically as control state changes. Instead of sampling the system state periodically, the system's state is observed continuously, and the compliance evidence record updates whenever the state changes. The evidence is always current because it is generated in real time.
// THE ARCHITECTURAL INVERSION
Traditional: System state → (periodic human sampling) → Evidence → Assurance determination
Soteria: System state changes → (automated event generation) → Continuous evidence stream → Real-time assurance state
"The compliance record is not a snapshot. It is a sensor. The assurance state is not a certificate issued periodically. It is a reading available at any time."
This is not a new idea in principle. Continuous monitoring has been discussed in security literature for over a decade and is referenced in several compliance frameworks as an advanced capability. The novelty in Soteria is the attempt to make it work as a complete system, not just for a subset of controls or a specific framework, but as a general architecture for evidence generation that can be mapped to multiple framework requirements simultaneously.
06. Continuous Assurance as Architecture
What does continuous assurance actually look like in architectural terms? This is where the engineering gets interesting and occasionally difficult.
A continuous assurance system needs to do several things simultaneously: monitor the state of controls across the system in real time, detect changes in control state (both intentional and unintentional), generate structured evidence records that meet framework documentation requirements, maintain a current assurance state that reflects the live control configuration, and surface divergences between intended control state and actual control state immediately rather than at audit time.
01 Event-driven evidence generation
02 Control mapping layer
The evidence record needs to be interpretable in framework terms. Soteria maintains a mapping from system-level state changes to control identifiers across multiple frameworks simultaneously. A firewall rule change generates evidence relevant to multiple controls in multiple frameworks, the mapping layer handles the translation.
03 Assurance state engine
The assurance state is not a static record. It is a computed view of the current evidence state across all monitored controls. The engine continuously computes compliance status based on current evidence, identifying controls that are currently met, controls that are met by evidence that is aging, and controls that are currently unmet.
04 Drift detection and alerting
When actual control state diverges from intended control state (e.g., through configuration drift, unauthorized change, or system evolution) Soteria surfaces the divergence immediately rather than accumulating it for audit discovery.
05 Audit evidence packaging
When a formal audit requires evidence, Soteria generates a point-in-time evidence package from its continuous record. The package meets framework documentation requirements. The difference from traditional audit preparation: the evidence was being generated continuously and the package is assembled, not collected.
07. What Changes When Evidence Is Live
We have been running Soteria in development and early operational use for several months. The behavioral changes it produces are interesting and not all of them were anticipated.
The anticipated change: compliance state is always current. An organization running Soteria knows, at any moment, whether they are compliant with the frameworks they have mapped. This was the primary design goal and it is working as designed.
The unanticipated change: the relationship between compliance work and security work shifts when evidence is continuous. In a traditional compliance regime, security teams spend significant time in evidence collection sprints to document control state before an audit deadline. This work is real but it is orthogonal to security: collecting evidence of controls that already exist does not make the organization more secure, and the sprint cadence pulls security resources toward documentation and away from threat response at predictable intervals.
"When evidence is continuous, compliance work stops being a separate activity. It becomes a property of the security work rather than a parallel track. The controls are implemented; the evidence is generated automatically. The audit sprint does not exist. The time it consumed is available for other things."
The second unanticipated change: when divergence from intended control state is surfaced immediately rather than discovered at audit, the organizational response to drift changes. In a periodic audit environment, drift that persists for months before discovery often has organizational inertia behind it. The drift has become the de facto state, and correcting it requires acknowledging a prolonged period of non-compliance. In a continuous environment, drift is surfaced within hours and correction is routine rather than remediation.
A third observation, which we are still trying to understand fully: continuous evidence changes the relationship between compliance state and security posture in ways that are not yet fully characterized. Our hypothesis, which Soteria is designed to test, is that continuous assurance reduces the evidence gap and therefore reduces the divergence between compliance state and security posture. We have preliminary data supporting this. We do not yet have data sufficient to characterize the relationship precisely.
08. Open Questions
1. "Is continuous compliance evidence generation sufficient to close the evidence gap, or does the gap persist in the mapping between control state and security posture?"
// Status: The evidence gap closes. A related gap, between compliant control state and effective security posture, remains. These are different gaps requiring different instrumentation.
2. "How does continuous assurance interact with regulatory frameworks that require periodic formal attestation? Can a continuous record substitute for a point-in-time audit?"
// Status: Framework-dependent. Some frameworks are beginning to accommodate continuous monitoring evidence. Many are not yet there. Regulatory acceptance is a constraint on adoption independent of technical feasibility.
3. "At what scale does event-driven evidence generation create noise problems, a high rate of state changes generating evidence faster than it can be meaningfully consumed?"
// Status: Real concern at high scale. We are developing evidence aggregation and materiality thresholds to address it.
4. "Is the distinction between compliance and security ultimately bridgeable by tooling, or is it a governance and incentive problem that tooling cannot solve?"
// Status: Both. Tooling can close the evidence gap. The incentive structures that led organizations to treat compliance as a proxy for security are not solved by tooling. We build the tools. The governance problem is someone else's jurisdiction. Reluctantly.
5. "Can the continuous assurance model be extended to cover threat model coverage, not just control implementation, but whether the controls cover current threats, or does that require a fundamentally different architecture?"
// Status: This is the next hard problem. Soteria is solving the evidence generation problem. Threat model coverage requires continuous threat intelligence integration that we have not yet designed.
09. Notes & References
This note draws on work across several fields. References below are not exhaustive, they represent the specific sources that shaped our thinking on this problem.
[01] NIST SP 800-137, "Information Security Continuous Monitoring for Federal Information Systems and Organizations," 2011. The framework reference for continuous monitoring. Good diagnosis, implementation left as an exercise.
[02] Ross, "Managing Risk from Information Systems: An Organizational Perspective," NIST 2008. The original framing of risk-based security that compliance frameworks are supposed to implement.
[03] Soteria Experiment Log, Cycles 12–19. Internal.
[04] Verizon DBIR, various years. The consistent finding that many breaches involve vulnerabilities that were known and unpatched (i.e., non-compliant states that persisted in the evidence gap) is directly relevant to the evidence gap problem.
[05] Anderson, "Security Engineering," 3rd ed. The compliance-security gap is discussed throughout in the context of security economics. Chapter 26 is particularly relevant.
[06] Schneier, "Beyond Fear," 2003. The security theater critique applies directly to compliance-as-security. We are trying to build something that is not theater.
[07] Helios Prime, "Automated Reasoning and the Confidence Problem," Lab Notes, Jun 2026. The calibration problem in automated reasoning and the evidence gap in compliance have a structural similarity: both involve a system reporting a state that is not current.
* A note on scope: this document describes our thinking as of the time of this writing. The field moves. Our opinions may move with it. We will update this note when they do.