We Built the First Deterministic SOC2 Decision API. Here's Why No One Else Has.
February 15, 2026
Every security team using automation tools like Vanta, Drata, or SecureFrame has heard the same feedback from auditors:
"Your controls show 'green.' But how do I know the automated decisions were made consistently? How do I audit the decision itself?"
This question exposes a gap no one has filled—until now.
The Problem No One Solved
Compliance automation platforms are excellent at collecting evidence. They pull configuration snapshots from AWS, Okta, and GitHub. They store policies. They track tasks.
But they don't capture how decisions were made.
When an automated control blocks access, approves a change, or triggers an alert—where is the record of why? What specific signals led to that outcome? Which SOC2 controls were satisfied? If an auditor asks next month, can you prove the same input would produce the same output?
Today, most teams can't. And auditors know it.
The Market That Didn't Exist
We spent months researching before writing a single line of code. What we found surprised us.
Compliance automation platforms like Vanta and Drata are exceptional at gathering infrastructure evidence and storing policies. They solve the "what" of compliance—what configurations existed, what documents were approved. But they don't solve the "how"—how decisions were actually made when automated controls fired.
Security decision engines focus on real-time threat response and risk scoring. They're built for speed, not auditability. Their outputs often vary between runs, making them impossible to verify after the fact.
Rule engine projects like Newton.RS provide high-performance execution for developers who want to build their own systems. But they're infrastructure components, not turnkey solutions. They don't come with SOC2 mappings or ready-to-use APIs.
No one connected these dots. Not because it's technically difficult, but because it requires thinking like both an engineer and an auditor. The market wasn't waiting for this solution—it didn't know the solution was possible.
What We Built
Decision Security Layer is a deterministic decision API built specifically for SOC2 audit trails.
It accepts three inputs:
{
"scenario_summary": "OAuth forwarding rule updated",
"observed_signals": ["identity forwarding changed"],
"known_context": ["approved change request #12345"]
}
And returns a structured decision record:
{
"decision_posture": "proceed",
"confidence": 68,
"compliance_references": [
"SOC2 CC6.1 - Logical Access Security",
"SOC2 CC7.1 - Change Management"
],
"primary_risks": [...],
"second_order_consequences": [...],
"tradeoffs": [...],
"decision_rationale": "The change is supported by both observed signals and documented approval. CC6.1 requires access controls; CC7.1 requires change management. Both conditions are met. Proceed with standard monitoring.",
"clarifying_question": null
}
The key property: identical inputs always produce identical outputs. No randomness. No black box. Every decision can be reproduced and audited independently.
Why Determinism Matters for SOC2
Auditors don't trust automation because they can't verify consistency. Deterministic decision logs change this.
Replayability. Any past decision can be re-run with the same inputs, producing identical outputs. This gives auditors a verifiable chain of custody for every automated decision.
Control mapping. Every decision cites the specific SOC2 controls it satisfies—CC6.1 for logical access, CC7.1 for change management, CC7.2 for system monitoring, CC12.1 for risk assessment. Auditors see exactly which controls were invoked and why.
Transparency. The rationale, alternatives considered, and confidence score are all captured in a human-readable format. No black box. No "the system decided."
This transforms automated decisions from opaque outputs into auditable evidence.
The Technical Foundation
We built on a simple insight: decision rules can be expressed as pattern matches against security signals.
Signals containing words like "access," "login," or "privilege" map to SOC2 CC6.1—Logical Access Security. Signals containing "change," "modify," or "update" map to SOC2 CC7.1—Change Management. Signals containing "monitor," "log," or "audit" map to SOC2 CC7.2—System Monitoring. Signals containing "vendor," "risk," or "third-party" map to SOC2 CC12.1—Risk Assessment.
These mappings were curated through hundreds of hours of compliance research and auditor interviews. They're rule-based, so they never drift. And because the engine is deterministic, the output is always reproducible.
Why We're First
The market didn't miss this opportunity because it's hard to build. It missed it because the problem sits at an intersection no one was watching.
Compliance companies think like evidence collectors, not decision loggers. Security companies think like threat detectors, not audit trail generators. Rule engine projects provide infrastructure, not turnkey solutions.
We sat at the intersection and built what neither side would.
What Happens Next
The API is live today. Free tier: 100 decisions/month, no email required. Documentation and a live demo are available.
For compliance teams, SOC2 auditors, and security leaders: Stop guessing. Start proving.
Founder & CEO, Decision Security Layer
decseclayer@gmail.com
GitHub | API Docs
Top comments (0)