A SOC 2 auditor does not want your security tooling. They want proof that a control operated, continuously, over a window of time — and the proof has to be dated, attributable, and impossible to have edited after the fact.
That single sentence is the whole difference between "we are secure" and "we passed SOC 2". Most small engineering teams have the first and none of the second, and they discover the gap about four weeks into a Type II observation window, when someone asks them to produce evidence for a period that has already ended.
This is what auditors ask for, what you can evidence automatically, and what still needs a person.
The practical consequence: Type II evidence cannot be manufactured at the end. If your window starts in January and you begin collecting in October, you have a nine-month hole nothing will fill. Start the collection before the window, not during it.
Every framework has its own control numbering, and every auditor has their own request list. Underneath, small engineering teams get asked for the same five things.
The request sounds like: "Show us that identified vulnerabilities are tracked to resolution within defined timeframes."
What satisfies it:
The detail that trips teams up is first detected. Auditors sample findings and check the clock started when the issue became known, not when someone got around to triaging it. If your tracker records "created" as the day an engineer manually filed a ticket, every SLA in your report is measured from a date you chose. That is the finding.
We wrote up how to define those windows in vulnerability remediation SLAs.
The request: "Show us that code changes are reviewed and approved before reaching production."
For most small teams this is the easiest one, because GitHub or GitLab already keeps it: branch protection requiring a review, the PR record itself, and the merge commit. What auditors add is evidence the rule could not be bypassed — so export the branch protection settings, not just the PRs. A screenshot of a setting on the day of the audit does not prove it was on in March.
If you can also show that security review happened inside the PR rather than in a separate quarterly sweep, this control and the vulnerability-management one start sharing evidence. See security review in pull requests.
The request: "Show us who had access to production, that access was authorised, and that it was removed on offboarding."
Evidence:
Small teams fail this one on offboarding, and on the systems nobody thinks of as production: the error tracker, the analytics tool, the CI provider, the DNS registrar. Write the list once. Keep it in version control so its history is the evidence.
The request: "Show us that you would detect a security-relevant event, and that someone responded."
Evidence: alert configuration, plus a sample of actual alerts and what happened next. An empty incident log is not automatically good news — auditors read it as "no detection" as easily as "no incidents". A handful of real alerts, triaged and closed with a note, is stronger evidence than silence.
The request: "Show us a record of security-relevant administrative actions, and that the record cannot be altered."
This one is binary. Either your system writes an append-only log or it does not. A table an admin can UPDATE is not an audit trail, and an auditor who asks the right question will find that out.
Here is the honest split. Roughly half of a small team's SOC 2 evidence can come out of tooling. The rest is writing, and no product removes that.
| Control area | Automatable | Needs a human |
|---|---|---|
| Vulnerability management | Detection dates, severity, owner, closure dates, SLA breaches | The policy that defines the deadlines |
| Change management | PR records, review approvals, branch protection export | The written change policy and exception process |
| Access management | Current access lists, grant and revoke events | Authorisation records, quarterly review sign-off |
| Monitoring | Alert config, alert history, response timestamps | The incident response plan and post-incident notes |
| Audit trail | The log itself | Retention policy, who may read it |
| Risk assessment | Nothing | All of it — the register, the ratings, the decisions |
| Vendor management | Nothing | The vendor list, reviews, and DPAs |
| HR controls | Nothing | Background checks, security training records, policy acknowledgements |
The bottom three rows are why "compliance automation" platforms cost what they cost: they are mostly a document workflow with a checklist attached. If you have a five-person team, you can write those documents yourself in a week. What you cannot do yourself, cheaply, is reconstruct nine months of detection and remediation dates you never recorded.
So the priority is obvious: start recording the dated, machine-generated evidence today. Write the policies later — you can always write a policy retroactively, and you can never backfill a timestamp honestly.
An evidence report that regenerates from live data every time you open it is a dashboard, not evidence. When an auditor asks for the vulnerability report covering March, and the report re-queries today's database, you have handed them something that will look different tomorrow.
What a defensible report looks like:
That last point matters more than it sounds. When we built compliance reporting at CheckVibe, the catalogue explicitly marks controls it cannot evidence as unsupported rather than quietly dropping them. Knowing that four of your controls have no automated evidence is the useful output. A green checkmark you did not earn is a liability you will discover in the audit.
Week 1 — stop the bleeding. Turn on whatever records dates. Get a scanner running on a schedule so findings have a first-detected timestamp. Turn on your provider's audit log. Export your current access list to a repo.
Week 2 — write the four documents that unblock everything. An information security policy, an access control policy, a vulnerability management policy with the SLA table in it, and an incident response plan. Two pages each. They will be imperfect. Imperfect and dated beats perfect and absent.
Week 3 — close the change-management loop. Branch protection on, reviews required, security checks running in the PR rather than on a quarterly cadence. Export the settings.
Week 4 — pick the window and dry-run it. Choose the Type II observation window start date. Generate every report you would hand an auditor, for the previous month, as a rehearsal. You will find the holes now, when they cost a week, rather than in month nine.
To be precise about what is and is not covered, because vague compliance claims are exactly the problem:
Team plans start at $25 per seat per month with a five-seat minimum; the compliance reporting sits on Team Advanced at $50 per seat. The pricing page has the full split.
None of that writes your risk register, your vendor reviews, or your training records. Nothing does.
Type I is realistically 6 to 10 weeks from a standing start, most of which is writing policies and closing obvious gaps. Type II adds the observation window itself — a minimum of three months, though enterprise buyers increasingly ask for six or twelve. The window is wall-clock time you cannot compress, which is why the date you start collecting evidence matters more than the date you start the project.
No, but you need somewhere the dated evidence lands. A five-person team can maintain the policy documents in a repository and pull evidence from the tools it already runs. Compliance platforms mostly sell the document workflow plus integrations that collect the same evidence; they are worth it when the coordination cost exceeds the licence cost, which usually happens somewhere north of 20 engineers.
SOC 2 is an attestation report from a US CPA firm against the AICPA Trust Services Criteria; you receive a report describing your controls and the auditor's opinion. ISO 27001 is an international certification against a standard, focused on having an information security management system. The underlying evidence overlaps heavily — access reviews, vulnerability management, change control — so teams that do one can usually reach the other without starting over.
No. A scanner produces detection evidence, which covers part of one control area. SOC 2 asks about access management, change management, incident response, risk assessment, vendor management and HR controls as well. What a scanner can do — and what nothing else does as well — is prove when something was found, which is the timestamp every remediation SLA in your report is measured from.
That the control did its job throughout the window, not that it existed. For vulnerability management, design effectiveness is having a policy that says criticals get fixed in seven days. Operating effectiveness is a sample of actual critical findings from the window, each showing detection, ownership and closure inside seven days — or a documented exception explaining why not.
No, and teams over-correct on this. A documented risk exception — this finding is accepted, here is why, here is who approved it, here is the review date — is a functioning control. An undocumented overdue finding is a failure. Auditors are looking for a process that handles reality, not for a report with no red in it.
Running a team on CheckVibe? Shared triage, SLA policies and an append-only audit log ship on both team tiers, with SOC 2 and ISO 27001 evidence reporting on Team Advanced. See what teams get, or scan your app free to see what a first evidence run would find.
Paste your URL and get a security report in 30 seconds — 100+ automated checks with AI-ready fix prompts.
Related articles
The questions enterprise buyers actually send small vendors, how to answer honestly when the answer is no, and what to prepare before the first one.
How to set remediation deadlines by severity, when the clock should start, and why measuring from triage instead of detection inflates every number.
How to put security checks inside code review without teaching your team to ignore the bot: what to block on, what to comment on, what to leave out.