PracticalMay 30, 20266 minute read
Six controls to fix first when a deal is waiting
If an enterprise security review is the only thing between you and a signature, fix these in this order.
Priya Raghunathan
Head of Compliance Research
I spent six years at a firm that issues SOC 2 reports. I have sampled several hundred startups' evidence, and the failures repeat. If you are blocked on a security review right now, this is the order I would work in. It is also the starter scope Trellis runs on the free tier, for the same reason.
1. Access to production, with a second factor
Nothing else you do matters if this one is soft. Single sign on for everyone, a second factor enforced rather than encouraged, no shared logins, and a list of exactly who has production access with the role that justifies it. What gets sampled: an export from your identity provider, and that list. What fails: multi-factor set to optional, and one service account everybody uses.
2. Access removal, provably
This is the most commonly failed control I have seen, and it fails on completeness rather than intent. A ticket says removed from Google and GitHub. It does not mention the cloud console, the data warehouse or the observability tool, because whoever wrote it forgot those existed. Write down every system a person could have access to, once, and make the offboarding checklist that list. Then your ticket is evidence instead of a story.
3. Change management
Good news: you almost certainly already do this. Pull requests, a review, tests. The gap is enforcement. If branch protection does not require the review, a sample can turn up the one change that shipped without one, and then the control fails for the whole period. Turn on the setting, screenshot it, keep the screenshot.
4. Your policy set, dated and owned
Three fields decide whether a policy survives contact with a reviewer: an owner, an effective date, and a review cadence with evidence that the last review happened. A short policy with those three fields beats a long one without them, every time. Nobody is grading your prose.
5. Incident response, exercised once
You need severities, roles, a contact path and a statement about how and when you would tell customers. Then you need to have used it once. A single tabletop exercise with a written summary is enough for a first audit and takes ninety minutes. An informal understanding in an on-call channel is not a control.
6. Vendors that touch customer data
Almost no startup has this and every enterprise reviewer asks. One list: vendor, what data it touches, how critical it is, and a security report or a signed data processing agreement on file. Fifteen vendors is an afternoon. It is also the control most likely to be raised by your customer's own security team rather than your auditor, because they need your subprocessor list for their own report.
What I would not do first
Do not start with a penetration test, do not buy a tool that watches settings you have not configured yet, and do not write a twelve page policy nobody will read. And do not let anyone tell you a badge on your website is the same thing as a report. Your customer's security team will ask for the report.
This is preparation guidance from someone who used to audit. It is not an audit, and it is not legal advice. Your auditor's request list wins over anything you read here.
Find out where you stand
The free check runs on six controls and your own material.