How a Logistics Company Passed SOC 2 with OKF and Claude — The Koorier Case Study

“Koorier is a last-mile logistics company — forty people, a few thousand parcels a day, and, when its first enterprise shipper demanded a SOC 2 report, a compliance program scattered across a dozen SaaS tools that had never spoken to each other. This is how they turned that sprawl into a single OKF knowledge graph the whole team could query through Claude, while CATAAM’s ASM, iASM, and red-team exercises found the exposure a checklist never would.”

The forcing function was a contract. A national shipper wanted to route volume to Koorier, and the paper gate was a SOC 2 Type I report inside 90 days. No report, no contract. Koorier had no CISO, no security engineer, and an ops team that measured its day in stops-per-route, not controls.

The instinct — the one every early-stage company has — was to buy a compliance SaaS, connect a few integrations, and start screenshotting evidence into a dashboard. That works until an auditor asks a question the dashboard can’t answer. We’ll come back to why Koorier chose a different foundation and treated the tool as a Vanta alternative rather than the source of truth.

The real problem wasn’t the controls — it was that nobody could see the whole picture

SOC 2 is not, at heart, a checklist. It is a claim about a system: these are the people, this is the data, these are the processes, and here is the evidence that we run them safely. Koorier’s problem was that the system was smeared across a dozen vendors, and no single person — or tool — held the map.

The data lived in a transportation management system and a warehouse system. Driver location streamed through an ELD/telematics vendor. Identity and access ran through Google Workspace. Operational chatter — including, it turned out, a fair amount of customer data — lived in Slack. The app and its database ran in AWS. Payroll and HR onboarding sat in a people platform. Background checks came from a screening vendor. And a meaningful slice of the actual deliveries was run by subcontracted delivery partners — fourth parties Koorier was still accountable for.

Every row is a place evidence lives, an owner who may not know they own a control, and a data flow an auditor will ask about. Twelve tools, twelve exports, twelve mental models. That is not a controls problem you can screenshot your way out of — it is a knowledge problem.

Step 1 — Turn the compliance program into a knowledge graph (OKF)

Instead of another dashboard, Koorier built a map. CATAAM exported the whole program as Open Knowledge Format — an open, vendor-neutral standard that packages knowledge as a graph of linked Markdown files with YAML frontmatter. Each file is a node; the links between them are the edges. If you are new to it, start with what Open Knowledge Format is.

In Koorier’s graph, every control was a node. So was every asset, every vendor, every policy, and every person. The edges carried the meaning that had been trapped in people’s heads: this vendor processes this data; this control is satisfied by this evidence; this person owns this system; this subcontractor sits behind this DPA. For the first time the whole SOC 2 system existed in one place a human could read.

Because it is just Markdown, the graph lived in Git — every change reviewed and versioned, the way Koorier already shipped code. We wrote about why that pairing is so powerful in OKF and Git. And because it is a graph, it is not a document you read top to bottom; it is something you traverse — the difference we unpack in OKF vs MCP.

This is the part that made the SaaS a tool and not the truth. The graph is portable, vendor-neutral, and diffable — Koorier owns it. A GRC platform became one more integration feeding evidence into the graph, not a black box Koorier would have to re-key its entire program into. That is the practical case for treating CATAAM as a Vanta alternative rather than a lock-in.

Step 2 — Find the exposure a checklist never would: ASM, iASM, and a red team

A tidy control list means nothing if the front door is open. CATAAM ran an external attack-surface scan of everything Koorier exposed to the internet, then wired continuous attack-surface management in so the picture stayed current instead of going stale the day after the audit.

The scan surfaced the usual quiet sins — a forgotten staging subdomain still pointing at production, an over-permissive object-storage bucket, an undocumented driver-app API. And one that mattered more than all of them: an exposed MCP server a developer had stood up to let an internal assistant reach the dispatch system — reachable from the open internet, no auth in front of it.

This is where iASM — CATAAM’s intelligent, evidence-gated layer — earned its keep. Raw scan output is noise to an auditor. iASM took each confirmed finding and mapped it to the exact SOC 2 control it broke: the open bucket to CC6.1, the exposed MCP server to CC6.6 (protecting the system boundary), the stale subdomain to CC7.1. Crucially, only confirmed findings — with evidence — were allowed to mark a control. No speculative “maybe” ever became a compliance claim.

Then CATAAM red-teamed the program the way an attacker would, not the way a questionnaire does. The team phished the dispatch desk (a clean CC6 access lesson), walked through the exposed MCP server to reach internal tooling — the exact pattern behind the MCP zero-day that maps straight onto SOC 2 and ISO 42001 — and found engineers pasting production secrets and customer records into ChatGPT and Claude to “move faster.”

That last one is its own control failure and its own fix. Koorier put Prompt Guard in front of its LLM use to stop secrets from leaking into ChatGPT and Claude — turning a red-team finding into an enforced, monitored control instead of a memo nobody reads.

Step 3 — Employees fixed the gaps by asking Claude, over MCP, against the live graph

Here is the move that changed how Koorier actually closed the gaps. CATAAM exported the compliance program as a signed OKF bundle and pointed a Claude connector over MCP at it. Claude reads Markdown natively and, over the Model Context Protocol, fetches exactly the nodes it needs — so instead of one person chasing evidence across twelve tools, the whole team could interrogate the graph in plain English.

And they did — the non-security people most of all:

• Marta, head of operations, asked: “Which vendors touch customer PII, and which are missing a signed DPA?” Claude traversed the vendor and data nodes and returned two vendors with no DPA on file — and the owner for each. Two emails later, a real gap was closed.
• Devon, a dispatch lead who had never read the SOC 2 framework, asked: “What evidence is still missing for CC6.6?” Claude followed the control-to-evidence edges and handed back the specific gap, the system it lived in, and who was accountable.
• The founder asked, the night before the readiness review: “Are we actually ready for the CC7 section?” — and got a node-by-node answer instead of a shrug.

The reason this worked — and didn’t just hallucinate a comforting answer — is that OKF gives the model real, current, verifiable context to stand on. Every answer cited the exact node it came from, so a claim could be checked, not trusted. It is the pattern we describe in OKF for AI agents: grounded context beats a bigger prompt. Compliance stopped being one overwhelmed person’s job and became something any employee could contribute to by asking a question.

And because every fix was a commit to the graph, the audit trail wrote itself. When the assessor asked “show me how access review works,” the answer was a diff — the node, its history, who changed it and when. Re-audit is no longer a fire drill; it is a git log.

From findings to controls: SOC 2, mapped and monitored

CATAAM’s whole discipline is turning a finding into a control obligation rather than a scary headline. Each red-team result and each new CVE landed on the SOC 2 control it affected, with the evidence attached. Instead of a one-time evidence scramble, Koorier wired automated SOC 2 evidence collection and continuous control monitoring so the graph stays green between audits, not just on audit day.

Because the program lived as a portable graph, extending it later — to ISO 27001, once the next customer asks — is additive, not a restart. If you are weighing which report to pursue first, ISO 27001 vs SOC 2 walks through the trade-off.

The outcome

Koorier closed its material gaps inside the 90-day window, passed the SOC 2 Type I readiness assessment, and kept the enterprise contract that started the whole thing. But the durable win isn’t the report — it is that the program is now a living graph the team maintains by working, not a binder that rots the moment the auditor leaves. Type II is a continuation of the same system, not a second project.

The results here reflect Koorier’s engagement and the way these controls actually behave; your mileage depends on your stack and your starting point. The mechanism, though, travels.

What to steal from Koorier’s playbook

• Model the system, not the checklist. Put every control, asset, vendor, policy, and person into one linked graph — the sprawl is the problem, and a graph is the only thing that holds all of it.
• Own your compliance data. Keep the program as a portable, Git-versioned OKF graph; let the GRC tool feed it, not cage it.
• Test the front door, not just the paperwork. ASM finds the exposure, iASM maps confirmed findings to the exact control, and a real red team finds what a questionnaire can’t.
• Make every employee a contributor. Expose the graph to Claude over MCP so anyone can ask “what’s missing for CC6.6?” and get a cited, checkable answer.
• Turn findings into monitored controls. A red-team result or a fresh CVE should become a control obligation with continuous monitoring — not a memo.

If your evidence is scattered across a dozen vendors and a SOC 2 clock is running, start where Koorier did: run a free external attack-surface scan to see what is already exposed, and look at the OKF Context Engine to turn your compliance program into a graph your team — and Claude — can actually reason over.

Frequently asked questions

What is OKF and how did it help Koorier with SOC 2?

OKF (Open Knowledge Format) is an open, vendor-neutral standard that packages knowledge as a graph of linked Markdown files with YAML frontmatter — each control, asset, vendor, policy, and person is a node, and the links are edges. Koorier used it to pull a SOC 2 program that was scattered across a dozen tools into one portable, Git-versioned graph the whole team could read and, over MCP, that Claude could traverse to answer questions from real current facts.

How did Koorier employees use Claude and MCP to fix SOC 2 gaps?

CATAAM exported the program as a signed OKF bundle and pointed a Claude connector at it over the Model Context Protocol (MCP). Non-security staff — operations, dispatch, the founder — asked plain-English questions like “which vendors touch PII without a DPA?” or “what evidence is missing for CC6.6?” Claude traversed the graph and returned cited, checkable answers, so closing gaps became something any employee could do, not just one compliance owner.

What are ASM and iASM in this engagement?

ASM (attack surface management) is the continuous external scan of everything Koorier exposed to the internet — it found a stale staging subdomain, an open storage bucket, and an exposed MCP server. iASM is CATAAM’s intelligent, evidence-gated layer that maps each confirmed finding to the exact SOC 2 control it breaks (e.g., the exposed MCP server to CC6.6), so only verified issues ever become compliance claims. A red-team exercise then tested the program the way an attacker would.

Is CATAAM a Vanta alternative for logistics companies?

Yes — logistics and last-mile companies use CATAAM as a Vanta alternative, with a difference: the compliance program lives as a portable OKF knowledge graph that the company owns and versions in Git, with automated evidence collection, continuous control monitoring, and attack-surface testing built in. The GRC tooling feeds the graph rather than locking your program inside a dashboard.