Reality Check
I have met two founders recently. Small teams, one of them four people, each with a customer contract that has a SOC 2 clause in it. Both are starting from zero. The obvious first move is to shop for a compliance platform. That is the wrong place to start.
Why Do You Need It?
The answer decides your timeline, so get it straight before anything else. There are three cases:
- The client needs it to sign. The observation window alone is at least 3 months, and it will hurt. You can start the window before everything is 100% in place, but expect a scramble. Try to add a contingency to the contract that gives you 6 to 8 months, with the customer going live on interim terms.
- The client will need it down the line. This is the comfortable one. 6 to 8 months is feasible, and you can build the controls without a gun to your head. You still do not need to be perfect on day one: the observation window can start before every control is complete.
- You just want it to attract customers. Not recommended until proven right. Maybe your customers need something else, like a security questionnaire answered well or a pen test summary. Ask a few of them before you spend months on it.
Also, even if your customer has SOC 2 themselves, they can absolutely work with a company that does not. They will go with some bare requirements towards you. Ask for them, or offer the minimal set a SOC 2 company would meet: MFA, encrypted laptops, access reviews, a vendor list, an incident process. That often unblocks the deal while the real audit is still ahead.
Type and Criteria
Whichever case you are in, two choices remain, and both are worth settling early:
- Type I or Type II. Type I checks that your controls are designed properly on one day. Type II checks that they actually ran over a period, usually 3 to 12 months. I do not recommend Type I. Type II only, because continuity is king. Nobody buys from a vendor because they passed a check once. They want proof you stay compliant, and a separate Type I is an extra audit on the way to the Type II you need anyway. Even as a bridge for a customer who will not wait, Type I costs nearly as much as Type II, so you end up paying twice. That is not worth it for a small shop.
- Which criteria. Security is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional. Most customers only need Security. Do not volunteer for more. If the customer's wording is vague, ask them. One email now saves a month of work on controls nobody asked for.
What an Auditor Actually Does
SOC 2 is not a certification. A licensed CPA firm writes an opinion on whether your controls meet the AICPA's Trust Services Criteria. The criteria are public, the controls are yours to choose, and the evidence is yours to produce.
Here is the part that surprises people: you do not choose the sample. The auditor asks for the full population first, every production change, every hire and leaver, every incident, every vulnerability scan. The exact items only become known after the window closes, when they pick the samples themselves and ask for the exact artifact for the exact date. So the real job is making sure the population list matches reality, and that every item in it has a record behind it.
You will need many samples, but you do not have to guess which ones. The auditor mostly tells you what they will look at, so get their documentation first: the request list, the population definitions, the evidence they expect. Make that your tier 1 task list. It does not mean it is all you do, you still build the rest of the system. It means you start with what will actually be tested.
The criteria themselves are free to read: the AICPA publishes the 2017 Trust Services Criteria with revised points of focus (2022). Security comes down to nine questions: who is in charge, do people know the rules, what can go wrong, do you notice when it does, who can touch what, how do you run production, how do changes ship, and what about vendors and disasters. They are the "common criteria", CC1 to CC9, and for Security the document says no additional criteria are needed.
One more thing from reading it: the "points of focus" listed under each criterion are not a checklist. The document says some may not be relevant to you and that management may customize them. The auditor tests the controls you chose, so a small honest set beats a long fictional one.
What to Start With
1. Scope and Auditor
- What to Do: Write one page: your product, the systems it runs on, who has access, which vendors touch customer data. Then talk to an auditor before you write a single policy. Ask for their documentation, and ask whether they offer a pre-check (some call it a readiness assessment). Get the rules of engagement in writing: who your contact is, how evidence is submitted, how long they take to respond, what happens when a control is missed.
- Why It Matters: Type II needs an observation window, and the window starts once your controls are live. They do not all have to be perfect, so agree with your auditor what must be in place on day one. Every week spent polishing policies is a week the clock has not started.
- The Relationship: Believe it or not, personal interaction counts in an audit. Clear rules matter most the first time, because you do not know this auditor yet. Auditors know that if you work well together, you will come back. At the same time they sit in limbo, because they are neutral by design: they can tell you what they test, but not how to pass. A good working relationship is how you learn what matters without asking them to consult.
2. Access
- What to Do: SSO or at least MFA everywhere, a password manager, an onboarding and offboarding checklist with a ticket per person, and a quarterly access review.
- Why It Matters: Access is one of the most heavily sampled areas. A review sheet with one tab per system, a reviewer, a date, and a few "no" rows with a note on what you fixed is more believable than a sheet where everything is fine.
3. Laptops
- What to Do: Disk encryption, screen lock and automatic updates, proved with a dated record per laptop, such as a screenshot attached to a ticket, because the ticket records when you did it.
- Why It Matters: Auditors ask for evidence of practice, not only the policy text. Four machines do not need an MDM tool. They need a habit.
4. How Code Ships
- What to Do: Branch protection, a reviewer on every change, CI that runs the tests, and approval by someone other than the author.
- Why It Matters: The segregation of duties is tested. With four people, and one of them holding the admin rights to the branch protection, that is a real design question. Solve it before the window opens, not during. The criteria give you room: where segregation is not practical, management selects and develops alternative control activities. Write down what yours are.
5. Scans, Backups, Incidents
- What to Do: Run vulnerability scans from day one and keep every one. Restore a backup once. Keep an incident log, even an empty one with a dated "none".
- Why It Matters: Start late and your earlier months have no evidence. And if nothing ever happens, the auditor can only note that the control never occurred. That is fine, but have the tracker ready.
6. Risk Assessment and Vendors
- What to Do: A spreadsheet of what could go wrong, how likely, how bad, and what you do about it. A vendor list, and a dated note on each critical vendor's own SOC 2 report.
- Why It Matters: Having the vendor's report is not enough. Someone has to document a review of it inside your window. This is the one that slips, because a tool or a calendar happily puts the next review date outside the window.
7. Policies, Short and True
- What to Do: A handful of short documents is enough: information security, access, change management, vulnerability management, incident response, risk, vendors and resilience. State frequencies you actually meet.
- Why It Matters: An auditor tests your practice against your policy. "We run pentests regularly" is too vague to prove. "Annually" is a promise you now have to keep. Nothing in SOC 2 requires a pentest, so only promise what you will do.
8. Leadership Review
- What to Do: Founders meet every quarter, review risks, access, incidents and open work, and keep minutes.
- Why It Matters: It is easy, and it is routinely forgotten. You also do not need a board. SOC 2 does not require one, and the founders acting as the management team can provide the oversight.
No Tool? Three Sheets
A GRC tool is a spreadsheet with integrations and a monthly invoice. For four people, three sheets cover most of it:
- Vendors: name, data touched, report type, report period end, last review, next review, decision.
- Policies: name, version, owner, approver, last review, next review.
- Evidence calendar: control, cadence, owner, last done, where the evidence lives.
Every recurring date goes on a calendar with an owner. The honest cost of going without a tool is discipline, and one person who owns that calendar.
Let Your Agent Do the Work
Of course you can hand much of this to an AI agent, and you should. It can read the criteria, draft the three sheets, write first versions of the policies, chase the calendar and pull exports. That is the boring part, and it is good at boring.
What it cannot do is make a policy true. The auditor tests what you actually do against what the document says, so every sentence an agent writes needs a human who checks it against practice. Treat the agent like any other system with access: give it the least it needs, review changes to how it works, and let a named person sign off on each control run. Expect the auditor to ask about it.
And keep it away from the dates, which brings us to the next problem.
Backdating
Here is the moment it happens. It is month five of the window. You open the evidence calendar and the quarterly access review from month three never happened. Nobody did it wrong. Nobody did it at all. And creating a document dated month three takes minutes.
Don't.
A missed review is an exception: a line in the report with an explanation and a fix. A record created later and dated earlier is a question about every other record you handed over. Auditors sample, and they look at metadata.
The question they ask is simple: who stamped the date, you or a system?
- Records a system produced (pull request merges, login logs, scanner reports) carry the system's date already. Do nothing.
- Records you wrote yourself (access review sign-off, risk assessment, meeting minutes, policy approvals) are the exposed ones. Write them in a tool that records when you did: a ticket per review, a pull request per policy change, minutes in a shared document with revision history.
My rule: prefer evidence a system produced over evidence someone typed. Where it has to be typed, make it live in a tool that records when.
You do not need hash chains, a second git remote or any other cryptographic ceremony. And if a control was missed, say so. Do it late, record the real date, write down why it slipped, and tell your auditor before they find it. That costs you an exception. The alternative costs you trust.
Where to Get Help
If you would rather not carry this alone, you can buy a GRC tool or take an open source one. Either way, there will always be a human part: someone has to own the calendar, check that policies match practice, chase the evidence and talk to the auditor. Big companies hire a compliance officer for it. Small ones do it on nights and weekends. Or my team at Auditbahn does it.
