DEV Community: Momodu Kamara-Kolleh

Your first SOC 2: the seven controls a five-person team should fix first

Momodu Kamara-Kolleh — Thu, 05 Nov 2026 12:46:25 +0000

Most small teams meet SOC 2 the same way: a bigger customer sends a security questionnaire, and somewhere in it is "Please provide your SOC 2 report." You don't have one, and the frameworks look enormous.

The good news is that a first Type I mostly comes down to a short list of things auditors look at early. If these are in place and you can show evidence for them, the rest gets much easier.

MFA everywhere that matters: your identity provider, cloud console, code host and email. Auditors will ask for a screenshot or an export showing it's enforced, not just available.
Access you can explain. Keep a list of who has access to production and why, and review it on a schedule (quarterly is common). Remove people the day they leave.
Code changes that get reviewed. Use branch protection on main, require at least one reviewer, and have CI run before merge. The pull request history becomes your evidence.
Backups you have actually restored. A backup policy is easy; a dated record of a successful test restore is what convinces an auditor.
Encryption in transit and at rest. Most managed cloud services do this by default, so the work is mostly documenting which settings you rely on.
A written incident response plan. Keep it short: who gets called, where you talk, how you decide whether to notify customers. Then run one tabletop exercise and write down what happened.
Vendor review. List the services that touch customer data, and keep their security reports or terms on file.

None of this needs a big platform. It needs someone to own it, a place to keep the evidence, and a few months of the controls actually running before the audit.

I'm building Attestlane, SOC 2 readiness software for small B2B teams, because I kept seeing founders stall at this exact point. The free assessment at attestlane.to maps your answers to the criteria and shows which of these gaps you have. It doesn't replace the auditor.

Starting your first SOC 2 in 2027? The criteria change probably doesn't apply to you yet

Momodu Kamara-Kolleh — Wed, 04 Nov 2026 12:29:06 +0000

The AICPA has published an exposure draft of the proposed 2027 SOC 2 Trust Services Criteria. If you're a small team planning a first SOC 2, here's what matters and what doesn't.

What's confirmed

The draft is real. The AICPA published it on Oct 26, 2026 and announced it on Oct 28.
Comments are open until Jan 15, 2027.
If approved, it applies to engagements beginning on or after Dec 31, 2027, with early adoption allowed.
It adds new points of focus on AI: governance, model monitoring, prompt manipulation, data poisoning, transparency of AI-generated outputs, and automated decision-making.

What's reported but not yet verified against the draft

Several firms that have read it say the common criteria drop from 33 to 20 and get renumbered. For example, access control would move to CC5 and change management to CC7, and vendor management would get its own series. Treat the exact numbers as provisional until the final version is out.

What it means if you start in 2026 or 2027

Most first Type I engagements starting before Dec 31, 2027 will still be examined against the current criteria. So don't stall your readiness work waiting for the new numbering. The underlying controls (MFA, access reviews, change management, vendor reviews, backups you've actually tested) stay the same. What changes is how they're grouped and labeled.

Two practical moves

Store your evidence by control, not by criterion number. Then remapping later is a relabel, not a rebuild.
If your product uses AI, start writing down how you govern it now: who can change prompts, how outputs are reviewed, and what data the model sees. That's the area auditors are adding.

I'm building Attestlane, SOC 2 readiness software for small B2B teams, so I've been reading this closely. If you're preparing for a first SOC 2, the free assessment at attestlane.to shows your gaps against today's criteria.

Your compliance tool saying you're "95% ready" is a liability, not a feature

Momodu Kamara-Kolleh — Wed, 07 Oct 2026 12:10:39 +0000

I've spent the last stretch building a SOC 2 readiness tool, and the most useful thing I learned has nothing to do with dashboards. It's about a quiet failure mode that kills deals — and why a lot of compliance tools are built to cause it.

The failure mode

Picture a seed-stage SaaS. They land a great enterprise lead. The lead's security team sends the inevitable email: "Share your SOC 2 report, or your current readiness status."

The founder opens their shiny compliance tool. It says: "You're 95% compliant." Great. They forward that.

Then the security team asks one specific question:

"What's your access-review cadence, and how do you evidence it?"

And the answer the founder trusts was generated, not grounded. The model paraphrased a control it half-remembered and invented a definition that's subtly wrong. The reviewer — who reads these every week — catches it in about five seconds.

Now the founder doesn't look 95% ready. They look like they don't understand their own posture. The deal stalls a quarter. Sometimes it dies.

That "95%" wasn't a feature. It was a liability dressed up as reassurance.

Why LLM compliance tools do this

LLMs are fluent and confident, and a compliance control is exactly the kind of precise, citeable text they paraphrase badly. Ask a general model "what does this control require?" and it will happily produce something that sounds right. Most of the time nobody checks.

But compliance has an adversarial reader built in: the buyer's security team. Their entire job is to catch the gap between what you claim and what you can evidence. An ungrounded, confident answer is the single easiest thing for them to flag.

The fix is boring: grounding

The fix isn't a smarter model or a prettier dashboard. It's a rule:

Every answer about a control must quote the real criterion, or say it doesn't have it. Never guess.

Concretely: every AI response is injected with the actual criterion text from the framework files on disk. The model's job is constrained — quote the source, or abstain. If the control isn't in the grounding set, the honest output is "I don't have that control's text," not a confident paraphrase.

control = frameworks.lookup(control_id)   # real text, from disk
if control is None:
    return f"I don't have the criterion for {control_id}."

# system prompt: answer ONLY from the provided criterion text;
# if the question goes beyond it, say so explicitly.
return model.respond(question, grounding=control.text)

It feels almost too simple. But "boring and correct" is exactly what you want in the one place where a confident mistake costs a customer their trust in you.

Why this matters more than features

Compliance tools love to compete on breadth — more integrations, more frameworks, more automation. Useful, but none of it is the thing a buyer's security team actually tests. What they test is whether your answers hold up under one specific question. An ungrounded tool fails the only exam that matters, no matter how many checkboxes it has.

The honest part

A readiness tool is not an audit. It doesn't make you SOC 2 certified — a licensed CPA firm still performs the examination and issues the report. Any tool (mine included) that implies otherwise is doing the same overpromising I just described.

I'm building this solo, from Freetown, Sierra Leone. It's called Attestlane and it's live if you want to poke at it (use fake company data — don't connect real systems just to test). But I wrote this because the grounding lesson holds whether you use my tool, a competitor's, or a spreadsheet:

If your compliance answers can't cite their source, don't send them to a security team.

If you've been through a first SOC 2, I'd genuinely like to hear the part that actually hurt.

I built a discovery layer for AI agents because mine kept getting lost

Momodu Kamara-Kolleh — Sat, 25 Jul 2026 23:54:41 +0000

Everyone's building AI agents right now. Almost nobody's building the boring layer underneath them: how do agents find each other?

I hit this in my own stack. I run a few MCP servers one for search, one for my database, one exposing my product's API. Their addresses lived in a JSON config I edited by hand. When I added a fourth, the file got messy. When one went down, I found out because something downstream broke and I debugged backwards. There was no single source of truth for what agents existed or whether they were alive.

MCP gave agents a common language. There's still no discovery layer. That felt like having HTTP without a service registry.

So I built agentreg. It's a self-hosted service registry for agents one Go binary:

agentctl serve &
agentctl register search-agent -c search -e http://localhost:3000
agentctl find search # discover by capability, not a hardcoded URL
agentctl list # everything, with live health

It health-checks every registered agent on a heartbeat, so a dead one shows up as unhealthy before it takes something down with it. That single feature has already saved me a debugging session.

A fair question I keep getting: "isn't this just service discovery, like Consul?" Close, but the query is different. Consul answers where is this service? a host and port. Agents need what can this thing do, is it healthy, and can I trust it? That's capability-first, and it's why the registry is agent-shaped rather
than micro service-shaped.

I'm being upfront about the stage: this is v0.1, I built it solo, and it does discovery + health and nothing more yet. No federation, no auth, no trust verification — though the code has a pluggable verifier seam for exactly that later. It's MIT, self-hosted, no cloud, no account.

Install:

brew install mkk2026/tap/agentreg
Repo: https://github.com/mkk2026/agentreg

If you run more than a couple of MCP servers, I'd genuinely like to know whether this solves a real annoyance for you or whether I'm a year early. The most useful thing you can tell me is whether you're still running it a week after you try it. That's the only feedback that counts.