A customer wants SOC 2 or ISO 27001. Here is what to do.
When a customer, insurer, or acquirer asks for SOC 2 or ISO 27001, treat it as a commercial blocker you clear to keep the deal. Both audit how your software handles data. The paperwork is policies an auditor signs. The rest is engineering: someone has to build and own the system that meets the controls, and that engineering is the part most vendors skip.
01 / Why the ask showed up
A SOC 2 or ISO 27001 request is almost always commercial: a deal you want to close, a customer you want to keep, or a buyer running diligence.
The trigger that pays is a person, not a deadline. A larger customer will not sign until you can show it. Their procurement or security team put a control questionnaire in front of you. An insurer wants it before they renew your cyber policy. Or an acquirer is running tech due diligence and wants proof your systems are handled to a standard. In every case the fix has a clear payoff attached, which is why it is worth doing right rather than fast.
So do not let anyone sell you urgency about a coming AI or data law. The honest picture is the opposite. The EU deferred its high-risk AI duties to December 2027 and August 2028, and Colorado repealed its AI Act before it ever took effect. The thing that moves your revenue is the customer, insurer, or acquirer in front of you asking. Answer that, and set the fear-selling aside.
Not sure where your system stands? A short software audit reads it and tells you plainly.
02 / What SOC 2 and ISO 27001 are
SOC 2 is a US audit report on how your system protects data. ISO 27001 is an international certificate for the management system around it. Customers ask for one or the other depending on where and to whom you sell.
SOC 2 is a report, produced by a licensed auditor, on how well your system meets five trust criteria: security, availability, processing integrity, confidentiality, and privacy. A Type I report checks the design at a point in time. A Type II report checks that the controls operated over a window, usually three to twelve months, which is what most serious buyers want. See the SOC 2 readiness entry for the plain-language version.
ISO 27001 is an international standard you get certified against. It is less about one system and more about the management system around information security: risk assessments, defined controls, and evidence that you run them and review them. It carries more weight with European and enterprise buyers. The ISO 27001 entry covers the difference in detail.
The two-layer truth nobody explains
Both standards have two layers, and this is where founders get misled. The first layer is the policy paperwork: written policies, an inventory of assets, an access-review process. A consultant or a compliance-automation tool can help you assemble this, and an auditor signs off on it. The second layer is the engineering: encryption, access controls, logging, backups, change management, and monitoring that have to be built into the software and kept running. A policy that says "we encrypt data at rest" fails the audit if nobody built the thing that does it. The paperwork is cheap. The engineering is the work, and it is the part we own.
A practice-management platform we built carries HIPAA and SOC 2 controls in one system. See how that plays out for healthcare software, where the engineering and the paperwork have to line up.
03 / What the ask means for your system
Behind each line in a security questionnaire is a question about your software. Here is what the auditor is really asking, and what someone has to build to answer it.
A control questionnaire reads like a checklist, but every item maps to something concrete in your codebase and infrastructure. This is the translation most non-technical founders never get.
| What the customer or auditor asks | What it means for your system | What we do |
|---|---|---|
| "Is data encrypted at rest and in transit?" | Storage and connections must use current encryption, with keys managed properly | Configure encryption across the system and document how keys are stored and rotated |
| "Who can access production and customer data?" | Access must be role-based, least-privilege, and logged | Build access controls and access logging, and set up the review process the auditor checks |
| "Show your change-management process." | Code changes need review, testing, and a traceable trail before they reach production | Put pull-request review, tests, and deploy history in place so every change is evidenced |
| "How do you monitor and respond to incidents?" | You need logging, alerting, and a written response plan that is really wired up | Stand up monitoring and alerting and hand you a response runbook tied to the real system |
| "Are backups tested and recoverable?" | Backups must exist, run on a schedule, and be proven restorable | Configure automated backups and test a restore so the recovery evidence is real |
| "Is your code free of known vulnerabilities?" | Dependencies and code need scanning, especially anything AI-generated | Run dependency and code scanning in the pipeline and remediate what it finds |
That last row matters more than it used to. Roughly 45% of AI-generated code ships with at least one OWASP Top-10 vulnerability (Veracode, 2025), so a vibe-coded system rarely passes without remediation. Read is AI-generated code safe to ship.
04 / The two paths
You can hire a compliance-automation tool to organize the paperwork, and you still need someone to fix the engineering underneath. Most founders need both, and the second is the one that gets skipped.
Compliance-automation platforms are useful. They collect evidence, track policies, and connect to the auditor. What they do not do is write the code or fix the infrastructure. If your system does not meet a control, the tool will show you a red mark, and you still need someone to close the gap.
| Policy paperwork | The engineering underneath | |
|---|---|---|
| What it is | Written policies, evidence collection, auditor coordination | Encryption, access controls, logging, backups, monitoring in the software |
| Who handles it | A compliance tool or consultant, then an auditor signs it | Someone who can build and change the system, and owns the fix |
| What happens if it is wrong | A policy that describes a control you do not have fails at audit | The control passes because the system genuinely does it |
| Where founders get stuck | Tool shows the gap, no one on the team can close it | We close the gap and hand you the evidence |
| Who owns it after | You, if it is written down | You, in your own repo and accounts, from day one |
We do the remediation and own it end to end. Scope it as a fixed-price build, or keep an embedded engineering team on it while controls stay live.
05 / How we clear it
We start by reading your system, name the exact gaps between where it is and what the standard requires, then build and own the fixes so the controls pass and keep passing.
You do not need to understand encryption or access-control design to get through this. You need a partner who does, who works to a standard rather than to a marketing word, and who hands you everything at the end. Here is the shape of it.
- 01Week 0
Read the system and the ask
We audit what you have against the specific controls in front of you and confirm what you own today. You get a clear gap list with a fixed price, credited to the build.
- 02Build
Build the engineering that has to pass
Encryption, access controls, logging, backups, monitoring, and dependency scanning, built into the software and documented as evidence the auditor can read.
- 03Build
Line up the paperwork
We map each control to the policy it supports and work alongside your compliance tool or consultant so the written layer and the built layer say the same thing.
- 04Handover
Hand it over, audit-ready
You own the repo, infrastructure, docs, and evidence in your own accounts. The auditor runs their process, and the controls are real when they check.
The build is backed in writing. See what we stand behind on the guarantees page, then start a conversation.
06 / Common questions
A customer wants SOC 2 to sign. Do I legally need it?
No. SOC 2 is not a law and no regulator requires it. It is a commercial ask: your customer's security or procurement team will not sign until you can show your system handles their data to a standard. That is a good problem, because it means a deal is on the table. Treat it as a blocker you clear to win the deal, and set aside anyone selling you legal urgency around it.
What is the difference between SOC 2 and ISO 27001?
SOC 2 is a US audit report on how one system meets trust criteria like security and confidentiality, usually asked for by US buyers. ISO 27001 is an international certificate for the management system around information security, and it carries more weight with European and enterprise customers. Both check policy paperwork and the engineering underneath. Which one you pursue depends on who is asking. Our SOC 2 readiness and ISO 27001 entries cover each in plain language.
Can a compliance tool like Vanta or Drata do this for me?
A compliance-automation tool organizes the paperwork, collects evidence, and connects you to an auditor. What it does not do is write code or fix infrastructure. When it flags that your system fails a control, you still need someone who can build the missing encryption, access control, or logging. We do that engineering and own it, then line the built layer up with whatever tool you use so the audit passes on the strength of a real system.
How long does it take to get audit-ready?
It depends on how far your current system sits from the standard, which is exactly what a short audit tells you. Closing the engineering gaps is a scoped, fixed-price build. The formal audit window is separate: a SOC 2 Type II report observes your controls operating over three to twelve months. We get the system genuinely meeting the controls first, so that observation window is time passing rather than a scramble to fix things while the clock runs.
Is my AI-generated software a problem for the audit?
It can be. Roughly 45% of AI-generated code ships with at least one OWASP Top-10 vulnerability (Veracode, 2025), and auditors increasingly ask how you scan and remediate code. AI tools also tend to skip the unglamorous controls: access logging, key management, tested backups. None of this is fatal. It means the system needs a review and remediation pass before it will pass. Read is AI-generated code safe to ship for the fuller picture.
Do I own everything you build for compliance?
Yes, from day one. The repository, source code, infrastructure, documentation, and the audit evidence live in your own accounts, not ours. When the auditor checks, they check your system, and when the engagement ends, nothing is held hostage and nothing has to be rebuilt to leave. Owning the controls is also what lets you keep passing future audits without depending on us. See the guarantees page for how the build is backed in writing.
Last updated June 2026 · Talk with Felipe
Your build
Taking on new builds
Have something in mind?
Tell us what you're making. We reply within a day with a fixed price and a date.