Forem: Jason Reeder

The One Question Every AI Security Audit Asks (And Why No One Answers It)

Jason Reeder — Tue, 07 Apr 2026 13:10:54 +0000

April 7, 2026

Every AI security audit follows the same pattern.

The auditor asks for evidence. The vendor provides logs. The auditor asks for more evidence. The vendor provides more logs. The auditor asks how they know the logs are complete. The vendor says “trust us.”

This cycle repeats until someone gives up or the contract expires.

There is one question at the heart of every AI security audit. No one answers it. Not because they don’t want to. Because they can’t.

The Question

“How do I know that automated decision was made consistently?”

That’s it. Not “what happened.” Not “who approved it.” Not “what policy existed.”

”How do I know it was consistent?”

Auditors don’t ask this to be difficult. They ask because consistency is the foundation of trust. If a system makes the same decision differently under the same conditions, it cannot be trusted. If an AI agent approves a transaction one way today and another way tomorrow with identical inputs, the audit fails.

Most security tools cannot answer this question. They are probabilistic. They rely on machine learning. They produce different outputs for identical inputs. They are, by design, inconsistent.

Why No One Answers

The industry has spent five years building tools that are faster, smarter, and more automated. What they haven’t built is tools that are verifiable.

Evidence collection platforms show you what happened after the fact. Threat detection tools tell you when something might be wrong. AI agents make decisions in milliseconds.

But when an auditor asks for proof that an automated decision followed policy consistently, every vendor goes silent.

Not because they are hiding something. Because their architectures were never designed to answer that question.

What Answering the Question Requires

To prove consistency, a system must be deterministic.

Same input must produce the same output
Every time, without exception
No randomness, no variation, no “maybe”
The logic must be fixed and auditable

Most AI systems are the opposite of this. They are designed to adapt, to learn, to change. That is their strength. It is also their weakness when facing an auditor.

A System That Answers the Question

There is a different approach. Instead of asking the AI to be deterministic, you put a deterministic layer around it.

The AI makes its probabilistic decision. Then a deterministic engine logs what happened, why it happened, and whether it followed policy. The output is fixed. It can be replayed. It can be verified.

Input:

{
“scenario_summary”: “AI agent requests production access”,
“observed_signals”: [“emergency change”, “no approval ticket”, “anomaly score 0.92”],
“known_context”: [“incident response active”, “on-call engineer unavailable”]
}

Output:

{
“decision_posture”: “do_not_proceed”,
“confidence”: 85,
“compliance_references”: [
“SOC2 CC6.1 — Logical Access Security”,
“ISO27001 A.9.2.1 — User Access Provisioning”
],
“decision_rationale”: “Emergency access requested but no approval ticket and on-call engineer unavailable. CC6.1 requires documented approval for access changes. Insufficient evidence of proper authorization. Proceeding would violate access control policies.”,
“clarifying_question”: null
}

The auditor can take this decision, run the same inputs through the same engine, and get the same output. That is not trust. That is proof.

What This Means for AI Governance

The question of consistency is becoming urgent. Regulators are beginning to require that automated decisions be explainable and verifiable. The EU AI Act. The NIST AI Risk Management Framework. Emerging state laws.

Each of these frameworks asks some version of the same question: “How do you know the system decided correctly?”

The organizations that can answer will deploy AI freely. The ones that cannot will be stuck in pilot purgatory, unable to move to production.

The Path Forward

You do not need to rebuild your AI systems. You need to add a deterministic audit layer.

One API call
One decision log
One set of compliance references
One verifiable, replayable record

The AI remains probabilistic. The audit trail becomes deterministic. The auditor gets their answer.

What Comes Next

The question is not going away. Regulators will keep asking. Auditors will keep pressing. Customers will keep demanding answers.

The organizations that have an answer will lead. The ones that don’t will fall behind.

The API is live. The framework mappings exist. The question has an answer.

Founder & CEO, Decision Security Layer
decseclayer@gmail.com
API Docs

Five Frameworks. One API. No Complexity.

Jason Reeder — Tue, 31 Mar 2026 12:55:03 +0000

March 31, 2026

On February 15, I published the first article about deterministic decision logs for SOC2. Both Google, and Google AI Overview citing my work as the definitive source.

Questions kept surfacing in the way people searched.

They searched for “ISO 27001 decision logs.” They searched for “HIPAA audit trails for AI.” They searched for “FedRAMP deterministic controls.” They searched for “GDPR automated decision records.”

They had the same problem across five different frameworks.

Today, that gap closes.

The Multi-Framework Reality

Companies running parallel compliance programs know the pain. You have SOC2 for your US customers. ISO 27001 for your European contracts. HIPAA for healthcare clients. FedRAMP for government work. GDPR for EU data subjects.

The same access control decision that satisfies SOC2 CC6.1 also satisfies ISO 27001 A.9.2.1, HIPAA §164.312(a)(1), FedRAMP AC-2, and GDPR Article 32.

The same audit log decision satisfies SOC2 CC7.2, ISO 27001 A.12.4.1, HIPAA §164.312(b), FedRAMP AU-2, and GDPR Article 30.

But until now, no single system captured all of them.

One API call. One decision. Five framework citations.

What a Multi-Framework Decision Looks Like

Here’s a real example from the API, live today:

Input:

{
“scenario_summary”: “Emergency production access”,
“observed_signals”: [
“privileged access changed”,
“audit log review”,
“breach detected”,
“vendor risk assessment”,
“policy review”
]
}

Output (compliance references only):

{
“compliance_references”: [
“SOC2 CC6.1 — Logical Access Security”,
“SOC2 CC7.2 — System Monitoring”,
“SOC2 CC12.1 — Risk Assessment”,
“ISO27001 A.9.2.1 — User Access Provisioning”,
“ISO27001 A.12.4.1 — Event Logging”,
“ISO27001 A.8.1.1 — Asset Inventory”,
“ISO27001 A.5.1.1 — Information Security Policies”,
“HIPAA §164.312(a)(1) — Access Control”,
“HIPAA §164.312(b) — Audit Controls”,
“FedRAMP AC-2 — Account Management”,
“FedRAMP AU-2 — Audit Events”,
“FedRAMP RA-3 — Risk Assessment”,
“GDPR Art. 32 — Security of Processing”,
“GDPR Art. 30 — Records of Processing”,
“GDPR Art. 33 — Breach Notification”
],
“decision_posture”: “proceed”,
“confidence”: 68,
“decision_rationale”: “Emergency access during incident with documented approval. All frameworks satisfied with exception logging.”
}

This is not evidence collection. This is decision-level audit across five frameworks.

One decision
Five frameworks
15+ control citations
Full rationale
Deterministic, replayable, verifiable

Why This Matters for Each Framework

SOC2
The Trust Services Criteria demand proof that controls operate effectively. Your API provides deterministic logs for CC6.1 (access), CC7.1 (change), CC7.2 (monitoring), and CC12.1 (risk).

ISO 27001
Annex A controls require documented evidence of policy adherence. Your API maps signals to A.9.2.1 (access), A.12.1.2 (change), A.12.4.1 (logging), A.8.1.1 (assets), and A.5.1.1 (policies).

HIPAA
The Security Rule requires administrative, physical, and technical safeguards. Your API provides audit trails for §164.312(a)(1) (access), §164.312(b) (audit), §164.312(c)(1) (integrity), and §164.312(e)(1) (transmission).

FedRAMP
NIST 800–53 controls demand continuous monitoring and accountability. Your API maps to AC-2 (account management), AU-2 (audit events), CM-3 (change control), and RA-3 (risk assessment).

GDPR
Articles 5, 30, 32, and 33 require records of processing, security measures, and breach notification. Your API provides deterministic logs for Article 32 (security), Article 30 (records), Article 33 (breaches), and Article 7 (consent).

Become a Medium member
No compliance platform captures these at the decision level. No one.

What This Means for Compliance Teams

If you’re running parallel compliance programs:

You no longer need separate evidence collection
You no longer need separate audit trails
You no longer need to explain why the same decision appears in five different systems

Your auditors see one record: the decision, the rationale, and the control mapping for all five frameworks.

What This Means for Engineering Teams

If you’re building systems that need to comply with multiple frameworks:

You call one API
You get back compliance references for all frameworks
You store one log entry
You satisfy five audit requirements

That’s not efficiency. That’s leverage.

What This Means for the Market

The shift from single-framework to multi-framework compliance is accelerating. Companies don’t just need SOC2. They need SOC2 + ISO 27001 + HIPAA + FedRAMP + GDPR.

The platforms that treat each framework as a separate module are falling behind.

We treat frameworks as mappings. One API. Five frameworks. One price.

The Technical Foundation

The API is deterministic. Same input → same output. Every time.

Rule-based. No training data. No AI hallucinations. No privacy risk.

Full audit trail with rationale, confidence scoring, and alternatives considered.

Auditors don’t have to trust us. They can verify themselves.

What’s Next

The API now returns references for SOC2, ISO 27001, HIPAA, FedRAMP, and GDPR.

The free tier is live. The compliance tier is $499/month. Enterprise pricing available.

If you’re running parallel compliance programs and wondering why your decision logs don’t cover all your frameworks — now you know.

It’s not that it’s hard. It’s that no one built it. Until now.

Founder & CEO, Decision Security Layer
decseclayer@gmail.com
API Docs
Live Demo

soc2 #multiframework

ISO 27001 Just Got the Same Treatment as SOC2

Jason Reeder — Sun, 29 Mar 2026 07:19:07 +0000

March 29, 2026

A little over a month ago, I introduced “The Deterministic SOC2 API.” The response was silence, then traffic, then Google ranking, then the AI Overview citing my articles as the definitive source on deterministic decision logs.

But one question kept surfacing in the way people searched.

They searched for “ISO 27001 decision logs.” They searched for “multi‑framework audit trails.” They searched for “how to prove AI decisions comply with both SOC2 and ISO.”

They had the same problem in a different framework.

Today, that gap closes.

The Multi‑Framework Reality

Companies running parallel compliance programs know the pain. You have SOC2 for your US customers. You have ISO 27001 for your European contracts. You have overlapping controls, separate audits, duplicate evidence.

The same access control decision that satisfies SOC2 CC6.1 also satisfies ISO 27001 A.9.2.1. The same change management decision that satisfies SOC2 CC7.1 also satisfies ISO 27001 A.12.1.2.

But until now, no single system captured both.

One API call. One decision. Two framework citations.

What a Multi‑Framework Decision Looks Like

Here’s a real example from our API, updated today:

Input (a privileged access request):

{
“scenario_summary”: “Emergency production access”,
“observed_signals”: [“admin added to IAM role”, “no change ticket found”],
“known_context”: [“incident response active”, “on‑call engineer approved”]
}

Output (simplified):

{
“decision_posture”: “proceed”,
“confidence”: 75,
“compliance_references”: [
“SOC2 CC6.1 — Logical Access Security”,
“SOC2 CC7.2 — System Monitoring”,
“ISO27001 A.9.2.1 — User Access Provisioning”,
“ISO27001 A.12.4.1 — Event Logging”
],
“decision_rationale”: “Emergency access requested during active incident. On‑call approval present. SOC2 CC6.1 requires access controls; exception granted due to incident. ISO 27001 A.9.2.1 requires documented access provisioning; emergency deviation logged. Monitoring will capture any anomalous activity post‑access.”,
“clarifying_question”: null
}

This is not evidence collection. This is decision‑level audit across multiple frameworks.

One decision
Two frameworks
Four control citations
Full rationale
Deterministic, replayable, verifiable

Why This Matters for ISO 27001

ISO 27001 requires an Information Security Management System (ISMS) that is risk‑based, documented, and continuously improved. The standard’s Annex A controls (A.5 through A.18) cover everything from access control to incident management.

What ISO 27001 auditors actually look for:

No compliance platform captures these at the decision level. No one.

Write on Medium
The Overlap That Saves Months

The same input signals that map to SOC2 CC6.1 map directly to ISO 27001 A.9.2.1. The same change management signals map to SOC2 CC7.1 and ISO 27001 A.12.1.2.

This is not a coincidence. The frameworks were designed to be complementary. But the tools that implement them treat them as separate.

One API. One decision. Two frameworks. No duplication.

What This Means for Compliance Teams

If you’re running SOC2 and ISO 27001 in parallel:

You no longer need separate evidence collection
You no longer need separate audit trails
You no longer need to explain to auditors why the same decision appears in two different systems

Your auditors see one record: the decision, the rationale, the control mapping for both frameworks, all in one place.

What This Means for Engineering Teams

If you’re building systems that need to comply with both frameworks:

You call one API
You get back compliance references for both frameworks
You store one log entry
You satisfy two audit requirements

That’s not efficiency. That’s leverage.

What This Means for the Market

The shift from single‑framework to multi‑framework compliance is accelerating. Companies don’t just need SOC2. They need SOC2 + ISO 27001 + HIPAA + FedRAMP.

The platforms that treat each framework as a separate module are falling behind.

We treat frameworks as mappings. One API. Infinite frameworks. One price.

What’s Next

The API now returns both SOC2 and ISO 27001 references. HIPAA, FedRAMP, and cyber insurance controls are in development.

The lattice is growing.

If you’re running parallel compliance programs and wondering why your decision logs don’t cover both frameworks — now you know.

It’s not that it’s hard. It’s that no one built it. Until now.

Founder & CEO, Decision Security Layer
decseclayer@gmail.com
API Docs

ISO27001 #SOC2 #compliance #multi‑framework #deterministic #API

The Camera Saw Something. How Do You Prove It Decided Correctly?

Jason Reeder — Sun, 15 Mar 2026 18:35:57 +0000

March 15, 2026

Every day, millions of automated decisions are made by physical security systems.

A camera detects motion after hours. An analytics platform identifies a person in a restricted area. An alarm system decides whether to dispatch police, alert security, or log the event and ignore it.

These decisions happen continuously. They affect safety, privacy, and liability. And right now, almost none of them leave an audit trail.

That’s about to change.

— -

The Coming Wave of Accountability

On January 1, 2026, California became the first state to regulate AI companion chatbots. SB 243 requires safety protocols, transparency reporting, and legal accountability when AI systems fail to meet standards.

This is not an isolated event. It’s the opening wedge.

What applies to chatbots today will apply to AI-powered surveillance decisions tomorrow. Regulators are coming for all automated decision systems — especially those that affect safety, privacy, and civil liberties.

The 2026 security industry trends are explicit: privacy and regulation are no longer afterthoughts — they’re foundational business realities . Companies face increasing scrutiny over how they handle surveillance data, particularly where video data can identify individuals .

Cloud systems are being positioned as the route to tighter control and more structured governance, with encryption, access controls, and automated logging as core requirements .

But here’s the gap: the logging exists for access and configuration. It doesn’t exist for decisions.

— -

What a Security Decision Actually Looks Like

Consider a typical after-hours security scenario:

Input:

Motion detected in restricted area
No authorized personnel on site
Time: 2:34 AM
Location: Server room
Policy: “After-hours access requires immediate security alert”

The system must decide: dispatch police? alert on-site security? log and ignore?

That decision is made by software — rules, thresholds, confidence scores. But where is the record of why it decided what it decided?

Most systems don’t have one.

— -

What an Audit Trail for Security Decisions Looks Like

Here’s a real example from our API, applied to this scenario:

Input:

{
“scenario_summary”: “After-hours motion detection”,
“observed_signals”: [“person detected”, “restricted area”, “no authorized personnel”],
“known_context”: [“time: 02:34”, “policy: immediate alert”]
}

Output (simplified):

{
“decision_posture”: “proceed”,
“confidence”: 87,
“compliance_references”: [
“SOC2 CC7.2 — System Monitoring”,
“SOC2 CC6.1 — Logical Access Security”
],
“decision_rationale”: “Motion detected in restricted area after hours with no authorized personnel present. Policy requires immediate alert. CC7.2 monitoring satisfied; CC6.1 access violation indicated. Alert dispatched.”,
“clarifying_question”: null
}

This is not just a log. This is proof.

Proof that the decision followed policy
Proof that specific controls were considered
Proof that the same input would produce the same output tomorrow
Proof that regulators can verify

— -

Why This Matters for Physical Security

The global surveillance technology market is projected to grow from $173.57 billion in 2025 to $289.13 billion by 2030 . That’s cameras, analytics, alarms, and the cloud platforms that connect them.

On May 1, 2026 — less than two months from now — multiple new national standards for video surveillance take effect :

| Standard | What It Covers |
| — — — — — | — — — — — — — — |
| GB/T 12345–2026 | Video image content analysis & description |
| GB/T 12346–2026 | Video image enhancement |
| GB/T 12347–2026 | Video image retrieval |
| GB/T 12348–2026 | Testing specifications |

Download the Medium App
The working groups developing these standards include every major player: Hikvision, Dahua, Huawei, Megvii, SenseTime, CloudWalk, and dozens of others.

These companies are building the cameras and analytics. They will all need the audit layer that makes those systems compliant with emerging regulations.

— -

What Exists Today vs. What’s Missing

No one is connecting these dots.

— -

What We Built

Our API is a deterministic decision engine originally built for SOC2 compliance. Same input → identical output, every time. Full audit trail with compliance references. No training data, no privacy risk, no black box.

It works for any automated decision system. Including physical security.

The same API that maps access control signals to SOC2 CC6.1 can map motion detection to CC7.2. The same logic that logs change management decisions can log alarm dispatch decisions. The same output that satisfies auditors can satisfy regulators.

One API. Multiple domains. One truth layer.

— -

What This Means for the Industry

The cameras capture data. The analytics generate insights. The security systems make decisions.

We make those decisions auditable.

Not as an afterthought. As the foundation.

When regulators ask: “How do you know your automated security decisions are consistent?” — you have an answer.

When insurers ask: “Can you prove your system follows policy?” — you have proof.

When courts ask: “Why did your system decide to dispatch police?” — you have a record.

— -

The Opportunity

The industry is building smarter cameras, better analytics, faster alerts. All of that is table stakes.

The next layer is trust. The ability to prove that automated decisions were made consistently, following policy, with complete transparency.

That’s what we built. That’s what this API does.

And it’s ready for physical security right now.

— -

What’s Next

The API is live. Free tier: 100 decisions/month. Documentation at the link below.

If you’re building security cameras, alarm systems, or surveillance platforms — and you’re wondering how you’ll prove your automated decisions are consistent when regulators come calling — now you know.

It’s not a feature you add later. It’s the layer you build on.

— -

Founder & CEO, Decision Security Layer
decseclayer@gmail.com
API Docs

— -

The SOC2 Controls That Actually Require Decision Logs (And Why No One Logs Them)

Jason Reeder — Sun, 08 Mar 2026 14:15:11 +0000

March 8, 2026

Over the last month, I've written three articles about deterministic decision logs. Each one has climbed to the top of Google. Each one has brought more readers to the API.

They search for "SOC2 CC6.1 evidence." They search for "change management audit trails." They search for "access control decision logs."

They're not looking for another compliance platform. They're looking for proof that their automated decisions actually satisfy specific controls.

Here's what they're finding—and why no one else is providing it.

The Controls That Demand Decision Logs

Not all SOC2 controls are created equal. Some are about documentation. Some are about configuration. Some are about policies.

But a specific subset requires something else: proof that a decision was made consistently.

CC6.1 – Logical Access Security

"The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives."

This control is about who can access what. But in an automated world, access isn't just granted by humans—it's granted by systems.

When a CI/CD pipeline grants temporary access to a production server—that's a decision. When an identity provider automatically provisions access based on role—that's a decision. When a zero-trust network evaluates a connection request—that's a decision.

Auditors don't just want to know who had access. They want to know how access was granted. And whether the same request would be granted the same way tomorrow.

No compliance platform captures this. They capture the configuration after the fact. They don't capture the decision itself.

CC7.1 – Change Management

"The entity implements change management processes for system changes to meet the entity's objectives."

Every automated deployment, every infrastructure change, every configuration update is a decision. Was it approved? Did it follow policy? Was it consistent with past changes?

Change management logs today are ticket numbers and timestamps. They don't capture the logic that led to approval or rejection.

A deterministic decision log does. It captures the input signals (what changed, who requested it), the governance context (was there an approved ticket?), and the output (approved, rejected, or need more info).

CC7.2 – System Monitoring

"The entity monitors system components and the operation of those components to detect anomalies that are potential indicators of security events."

Monitoring tools generate alerts. Those alerts are decisions: "This event is anomalous enough to notify someone."

But how was that decision made? What threshold was applied? Was it consistent with past alerts?

Auditors want to know that your monitoring decisions are consistent, not random. Deterministic logs provide that proof.

CC12.1 – Risk Assessment

"The entity identifies, analyzes, and responds to risks that could affect the achievement of its objectives."

Third-party risk assessments, vendor reviews, security questionnaires—all of these generate decisions. Approve, reject, or conditionally approve.

Those decisions should be auditable. What signals led to approval? What red flags triggered rejection? Can you prove the same vendor would get the same decision next month?

Why Compliance Platforms Don't Log These

Vanta, Drata, and SecureFrame are excellent at collecting evidence. They pull configurations from AWS, Okta, and GitHub. They store policies. They track tasks.

But they don't capture decisions for one simple reason: they're not there when the decision happens.

They poll infrastructure after the fact. They don't intercept the decision itself.

To log a decision, you have to be in the execution path. You have to be called by the system making the decision—not polling it afterward.

That's the difference between evidence collection and decision logging.

What a Decision Log Actually Looks Like

Here's a real example from our API:

Input (a privileged access request):

{
  "scenario_summary": "Emergency production access",
  "observed_signals": ["admin added to IAM role", "no change ticket found"],
  "known_context": ["incident response active", "on-call engineer approved"]
}

Output (deterministic, SOC2-mapped):

{
  "decision_posture": "proceed",
  "confidence": 75,
  "compliance_references": [
    "SOC2 CC6.1 - Logical Access Security",
    "SOC2 CC7.2 - System Monitoring"
  ],
  "decision_rationale": "Emergency access requested during active incident. On-call approval present. CC6.1 requires access controls; exception granted due to incident. CC7.2 monitoring will capture any anomalous activity post-access.",
  "clarifying_question": null
}

This is not evidence. This is proof.

Proof that the decision followed policy
Proof that specific SOC2 controls were considered
Proof that the same input would produce the same output tomorrow

The Gap That Became a Category

When I started building this, I assumed someone else had already done it. Vanta has 350+ integrations. Drata has hundreds of employees. Surely they'd thought of this.

They hadn't. Not because they're incompetent. Because they're solving a different problem.

They solve evidence collection.

We solve decision transparency.

Both are necessary. Neither replaces the other.

What Auditors Actually Want

I've never met an auditor who complained about too little evidence. They're drowning in it.

What they can't find is proof of consistency.

Did this automated control make the same decision last month?
Can you show me the logic that led to this outcome?
If I run the same inputs tomorrow, will I get the same result?

Evidence doesn't answer these questions. Decision logs do.

The Market Is Waking Up

The search data tells the story. People aren't searching for "better evidence collection."

They're searching for:

"SOC2 CC6.1 audit trail"
"change management decision logs"
"access control proof of consistency"
"automated decision auditing"

They have the platforms. They have the evidence. What they don't have is trust that their automated decisions are consistent and auditable.

That's the gap. That's the category. That's what we built.

What's Next

The API is live. Free tier: 100 decisions/month. Docs at the link below.

If you're using Vanta, Drata, or SecureFrame and wondering why your automated decisions don't leave audit trails—now you know.

It's not a feature they forgot. It's a layer they don't have.

Founder & CEO, Decision Security Layer

decseclayer@gmail.com

API Docs

Why Compliance Automation Platforms Can't Solve the Decision Audit Problem

Jason Reeder — Sun, 01 Mar 2026 19:10:00 +0000

March 1, 2026

Twice now I've written about deterministic decision logs. Twice the response has been the same: silence, then Google ranking, then a trickle of readers.

But one question keeps surfacing—not in emails (there are still none), but in the way people find my articles.

They search for "Vanta audit trails" and find me. They search for "Drata decision logs" and find me. They search for "SOC2 automation transparency" and find me.

The market is looking for something the major platforms don't provide.

Here's why they never will—and why that gap is now a category.

The Difference Between Evidence and Decisions

Every compliance automation platform does one thing well: collect evidence.

Vanta connects to your AWS account and pulls configuration snapshots

Drata integrates with Okta and logs who has access to what

SecureFrame maps your policies to control frameworks

This is valuable. It replaces spreadsheets. It automates the manual work of gathering screenshots and exporting logs.

But evidence is not decisions.

Evidence tells you what existed at a point in time.

Decisions tell you what happened when a control fired.

When an automated rule blocks a privileged access request—that's a decision.

When a CI/CD pipeline approves a deployment—that's a decision.

When a monitoring tool triggers an alert—that's a decision.

None of the major platforms log these. They log the configuration before and after. They don't log the decision itself.

Why They Can't Build This

Not because it's technically difficult. Because it's architecturally outside their model.

They're Built for Infrastructure, Not Logic

Vanta's integrations pull data from sources. They don't intercept decisions. They don't sit in the execution path. They're observers, not participants.

To log a decision, you have to be there when it happens. That means being called by the system making the decision—not polling after the fact.

Compliance platforms poll. Decision logging requires a webhook.

They're Probabilistic by Design

Most security tools use machine learning for anomaly detection. That's fine for threat hunting. It's useless for audit trails.

Auditors need reproducibility. Same input, same output, every time. ML can't guarantee that. Deterministic rules can.

The platforms are built for detection. You need a system built for verification.

They Sell Features, Not Infrastructure

Vanta's roadmap is about more integrations, more frameworks, more automation of evidence collection . They're adding "Policy Builder" and "vendor risk management" .

Notice what's missing: decision audit trails.

Not because they're not valuable. Because they're not features. They're a different layer entirely.

What a Decision Log Actually Looks Like

Here's a real example from our API:

Input:


{

  "scenario_summary": "Privileged access change",

  "observed_signals": ["admin added to production IAM role"],

  "known_context": ["approved change ticket INC-2026-0123"]

}

Output (simplified):


{

  "decision_posture": "proceed",

  "confidence": 68,

  "compliance_references": [

    "SOC2 CC6.1 - Logical Access Security",

    "SOC2 CC7.1 - Change Management"

  ],

  "decision_rationale": "The change is supported by both observed signals and documented approval. CC6.1 requires access controls; CC7.1 requires change management. Proceed with standard monitoring."

}

This is not evidence. This is proof.

Proof that the decision followed policy
Proof that specific SOC2 controls were satisfied
Proof that the same input would produce the same output tomorrow

No compliance platform produces this. None ever will.

The Gap That Became a Category

When I started building this, I assumed someone else had already done it. Vanta has 350+ integrations . Drata has hundreds of employees. Surely they'd thought of this.

They hadn't. Not because they're incompetent. Because they're solving a different problem.

They solve evidence collection.

We solve decision transparency.

Both are necessary. Neither replaces the other.

What Auditors Actually Want

I've never met an auditor who complained about too little evidence. They're drowning in it.

What they can't find is proof of consistency.

Did this automated control make the same decision last month?
Can you show me the logic that led to this outcome?
If I run the same inputs tomorrow, will I get the same result?

Evidence doesn't answer these questions. Decision logs do.

The Market Is Waking Up

The search data tells the story. People aren't searching for "better evidence collection."

They're searching for:

"automated decision audit trails"
"SOC2 decision logging"
"Vanta decision transparency"
"Drata control verification"

They have the platforms. They have the evidence. What they don't have is trust that their automated decisions are consistent and auditable.

That's the gap. That's the category. That's what we built.

What's Next

The API is live. Free tier: 100 decisions/month. Docs at the link below.

If you're using Vanta, Drata, or SecureFrame and wondering why your automated decisions don't leave audit trails—now you know.

It's not a feature they forgot. It's a layer they don't have.

Founder & CEO, Decision Security Layer

decseclayer@gmail.com

API Docs

Tags: SOC2, compliance, Vanta, Drata, deterministic, auditing

What I Learned Building the First Deterministic SOC2 API

Jason Reeder — Sun, 22 Feb 2026 16:38:30 +0000

February 22, 2026

Seven days ago, I published an article introducing "The Deterministic SOC2 API." I expected silence. What I got was something else.

Not emails. Not customers. Not yet.

But something more valuable: Google ranked it #1.

Not for some obscure keyword. For the category I just named.

Today I want to share what happened next—and what building this thing has taught me about compliance, automation, and the gap no one else saw.

Lesson 1: The Market Doesn't Move as Fast as Google

When you search "deterministic SOC2 API" right now, my article is the first result. That means Google has decided: this is the most authoritative, relevant, trustworthy answer to that query.

But Google moves faster than people.

The people who need what I built haven't searched for it yet. They're still living with the problem, not knowing a solution exists. They'll search eventually. When they do, they'll find me.

That's not waiting. That's being early.

Lesson 2: Determinism Is the Differentiator No One Talks About

Every compliance platform sells "automation." Vanta automates evidence collection. Drata automates policy tracking. SecureFrame automates control mapping.

But none of them automate decision logs.

When an automated security control makes a decision—blocks access, approves a change, triggers an alert—where is the record of why? Which SOC2 controls were satisfied? Can you prove the same input would produce the same output next month?

Most companies can't. And auditors know it.

Determinism solves this. Identical inputs always produce identical outputs. No randomness. No black box. Every decision becomes auditable.

That's not a feature. That's a missing layer.

Lesson 3: Building for Auditors Changes How You Think

I didn't start with auditors in mind. I started with a technical problem: how do you make automated decisions reproducible?

But every conversation I've had (and every article I've read) keeps circling back to the same point: auditors don't trust automation.

Not because they're difficult. Because they can't verify it.

A deterministic decision log gives them something to verify. They can take last month's decision, run the same inputs today, and get the same output. That's not trust. That's proof.

Lesson 4: The SOC2 Controls That Actually Need This

While building, I mapped security signals to SOC2 control families. What emerged was a pattern:

Signals about access, login, or privilege map to CC6.1 (Logical Access Security)
Signals about change, modify, or update map to CC7.1 (Change Management)
Signals about monitor, log, or audit map to CC7.2 (System Monitoring)
Signals about vendor, risk, or third-party map to CC12.1 (Risk Assessment)

These aren't arbitrary. They're the controls where decisions actually happen—where a human (or automated system) must choose to approve, deny, or investigate.

Every one of those decisions should leave a trace. None of them do—until now.

Lesson 5: The First Customer Will Come from Somewhere Unexpected

I don't know who it will be. Maybe a compliance officer at a fintech company. Maybe a SOC2 auditor who needs to validate client automation. Maybe a developer at Vanta who realizes this is the missing piece.

What I do know: they'll find me before I find them.

That's the shift. I'm not chasing. I'm building something findable.

What's Next

The API is live. Free tier: 100 decisions/month, no email required.

If you're a compliance professional, security engineer, or auditor: try it. Break it. Tell me what's missing.

If you're a founder building in this space: reach out. I'm not competing with you. I'm building the layer you didn't know you needed.

And if you're just discovering this category for the first time: welcome. You're early.

Founder & CEO, Decision Security Layer

decseclayer@gmail.com

API Docs

The Deterministic SOC2 API

Jason Reeder — Sun, 15 Feb 2026 13:58:57 +0000

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