Collect your SOC 2 evidence by asking for it

The controls are the easy part of SOC 2. You already have access reviews, change management, and a vulnerability process, or you can stand them up in a few weeks. The slog is proving they work, on the auditor’s schedule, with timestamps and screenshots and exports that all have to line up.

Evidence collection is the boring 80% of an audit, and it’s where engineering weeks quietly disappear. Someone opens fifteen consoles, takes a screenshot of each, labels them, drops them in a shared folder, and discovers that half of them are already stale by the time the auditor opens the folder. Then they do it again next quarter. This post is about asking for that evidence in plain language instead, and getting back something an auditor can actually use.

For a startup going through SOC 2 for the first time, the surprise is rarely the controls themselves. It’s the labor accounting. The framework reads like a checklist, and the controls feel achievable, until you realize each line item resolves into “now go prove this is true, with dated artifacts, for every system in scope, and be ready to re-prove it on the auditor’s timeline.” A single criterion about access review can mean exporting user lists from five separate systems, reconciling them by hand, and explaining the gaps. Multiply that by the dozens of criteria a Type II report covers and the “easy” audit has eaten a quarter of someone’s calendar. The boring part is the expensive part.

Where this post fits: an honest boundary

Kikimora is not a SOC 2 platform. If you’re shopping for a tool that manages your control framework, tracks your policies, runs your vendor risk reviews, and holds your auditor’s hand through the whole engagement, that’s Vanta, Drata, Secureframe, and the like. Those tools own the program.

What Kikimora does is different and complementary: it gathers and correlates the technical evidence those frameworks ask for, live, from across your actual stack. A compliance platform can tell you “you need to show that admin access is reviewed.” It generally can’t go pull the current list of admins from AWS and Azure and GitHub in one breath and hand it to you. That gathering, across tools, conversationally, is the part Kikimora is built for. Knowing the boundary up front saves everyone a frustrating evaluation.

The evidence requests, as prompts

SOC 2 organizes controls under Common Criteria. You don’t need to memorize them, but mapping a few of the heaviest evidence categories to actual prompts shows how this works in practice. Each of these is a question you can ask and get a dated, exportable answer back.

Access control (CC6)

The criterion auditors lean on hardest, because over-permissioned and stale access is where most real incidents start. The evidence is a current, accurate picture of who can do what:

List all IAM users and roles with admin or wildcard privileges, and show when each access key was last rotated.

Kikimora reads this straight from your cloud through read-only APIs, so the answer reflects production right now, not a screenshot from three weeks ago. For the deeper version of this, a full least-privilege sweep across both clouds, the same approach scales into a proper access review.

What makes this category painful by hand is that “who has admin” is never a single list. It’s IAM users plus IAM roles plus federated identities plus the service accounts everyone forgets, spread across however many AWS accounts and Azure subscriptions you run. Assembling that picture manually means logging into each one, exporting, and stitching the exports together while hoping nobody changed anything mid-export. Asking one question that spans all of them removes the stitching, which is usually where the errors and the lost hours hide. And because key rotation age comes back in the same answer, you get the access list and the hygiene finding together: who has too much power, and whose credentials are old enough to be a liability.

Change management (CC8)

Auditors want proof that production changes go through review rather than landing straight on main. The evidence lives in your version control. Kikimora connects to GitHub to show which production changes went through PR review:

Show me which production changes in the last 90 days were merged without a pull request review, if any.

Phrasing it as “which ones skipped review” is the useful version. A clean empty result is the evidence; a non-empty result is the exception list you fix before the auditor finds it. This is a small but important shift in how you ask. Requesting “all changes that went through review” gives you a giant log nobody wants to read and the auditor still has to trust. Requesting “changes that bypassed review” gives you the short list that actually matters, and an empty list is a far stronger claim than a long one. You’re proving the absence of a problem, which is exactly what a control attestation is.

Vulnerability management (CC7)

The criterion here is that you detect issues and actually do something about them. A list of open vulnerabilities alone isn’t evidence of a working control. The remediation status is:

Summarize open critical and high vulnerabilities, grouped by asset, with their current remediation status and age.

That ties scanner output to action, which is the thing CC7 is really asking about. Detection without a closed loop is just a list.

CC7 also leans on knowing your actual exposure, not just your scanner’s raw output. A critical vulnerability on an internal-only box and a critical on something the whole internet can reach are scored the same by most scanners and weighted very differently by anyone who has to defend the environment. The evidence improves when it reflects that. The same correlation that powers attack surface work applies here: if you’ve already mapped which assets are internet-facing, you can show the auditor not just that you track vulnerabilities but that you prioritize the reachable ones first, which is what a mature vulnerability-management control actually looks like.

Logging and monitoring

You have to show that you’d actually see an incident if one happened, which means proving your logging is on everywhere it should be. The trap is the one region where someone forgot to enable it. Kikimora reads CloudTrail across your AWS accounts:

Confirm CloudTrail is enabled in every region across all accounts, and flag any gaps.

The gap-flagging is the point. “It’s on” is a claim; “it’s on in all 17 regions except eu-north-1, which you should fix” is evidence plus a finding, which is far more useful the week before an audit.

Point-in-time versus continuous

The reason audit prep hurts is that most teams treat evidence as a point-in-time scramble. Week 11 arrives, the screenshot marathon begins, and everyone loses a sprint. The better model is to make the evidence re-runnable.

Because every prompt above is just a question, you can re-ask it any time. Run the access-control sweep monthly. Run the CloudTrail check after every new account gets provisioned. Save them as a set and re-run the set before each audit cycle:

Re-run our SOC 2 evidence pack and show only what changed since last month.

The shift is from “panic in week 11” to “audit-ready year round.” You’re not generating evidence under deadline pressure; you’re confirming that the evidence you already gather monthly still holds.

This is also the difference between a Type I and a Type II report in practice. Type I asks whether your controls are designed correctly at a single moment; a screenshot can answer that. Type II asks whether they operated correctly over a period, often six months or a year, which a single screenshot cannot answer at all. The honest way to be ready for a Type II is to have evidence that accumulates over the period rather than evidence you reconstruct at the end from memory and luck. Re-runnable prompts give you exactly that cadence: the same questions, asked on a regular interval, producing a trail that shows the control working month after month rather than working once, the week the auditor happened to look.

One caveat worth stating plainly: a prompt answers honestly about what it can see, which means evidence is only as complete as the integrations you’ve connected and the scopes you’ve granted. If a system isn’t connected, its controls won’t appear, and absence of a finding is not the same as proof of compliance. Connect the systems your auditor cares about, and treat the output as evidence to review, not a certificate. The auditor still audits; this just gets you to the conversation with your homework done.

The EU angle

One detail that matters for some buyers: Kikimora is built by an EU company, and the AI models it uses, from Google and Anthropic, are served exclusively from Vertex AI endpoints in EU regions. Your security data isn’t used to train anything. If your evidence includes configs, access lists, and exposure maps, which it does, then where that data is processed is itself a compliance question. For GDPR-conscious teams that’s not a footnote, and it’s worth a closer look when you’re choosing where your security work lives.

It’s a point that’s easy to skip past and shouldn’t be. The evidence you gather for SOC 2 is, almost by definition, a detailed map of your environment’s weak points: who has privileged access, which systems are exposed, where the gaps are. Handing that map to a tool that routes it through a non-EU SaaS pipeline by default is a transfer decision you’d want to make deliberately, not by accident. Knowing the data stays in-region, and never trains a model, is one less thing to explain to your own auditor, and your customers’, when they ask the question they always eventually ask.

Ask for your homework

SOC 2 evidence collection doesn’t have to be a screenshot marathon. The controls you already run produce evidence continuously; the work is just retrieving it in a form an auditor accepts, without context-switching across fifteen tools to do it.

You can start gathering evidence on a free account: the free tier includes 30 assets, unlimited integrations, and 5 million AI credits with no card required. Connect your stack through read-only integrations, then ask for your access review, your change log, your vulnerability status, and see how much of audit prep is really just a question you hadn’t thought to ask out loud.