A prospect asks if you are SOC 2 compliant, or a hospital asks for a business associate agreement before the pilot can start. You have a product in progress and a quote from a development team that does not mention either. The question to answer now, before more code is written, is how much of the plan changes.
The honest answer is that the effort splits into two very different parts. One part is organizational: policies, access reviews, vendor management, evidence collection. That is work for your company, not your developers. The other part is architectural: how tenants are separated, what gets logged, where sensitive data may and may not appear. That part is cheap to do in the first month of a build and expensive to retrofit.
This post separates them, so you can budget for each and decide what to do now versus later. It is general information for planning, not legal or compliance advice, and the auditor or counsel you work with has the final word.
First, what the two frameworks actually are
They are different kinds of thing, and mixing them up is the most common planning mistake.
- SOC 2 is an audit report. An independent auditor examines whether your controls match criteria you choose, covering security and optionally availability, confidentiality, processing integrity and privacy. A Type I report looks at the design of controls at a point in time. A Type II report looks at whether they operated over an observation period of months. There is no pass mark in the way an exam has one; you receive a report that your customers read.
- HIPAA is a US law that applies to covered entities and their business associates handling protected health information. There is no official HIPAA certification, so be skeptical of anyone who sells one. What exists is a set of rules on safeguards, breach notification, and contractual agreements between you and every vendor that touches the data.
SOC 2 is usually driven by enterprise buyers asking for evidence. HIPAA is driven by who your customers are. If you sell to healthcare providers or insurers and your software stores or transmits patient data, HIPAA applies to you whether or not anyone asks. We went through what changes inside the database in what changes once PHI enters your software.
The architecture that is cheap now and costly later
These are decisions that show up in both frameworks, and they are far easier to make before the first migration than after the hundredth.
- Tenant isolation you can explain. Every query scoped to a tenant, enforced in one place rather than remembered in each handler. Which model you choose matters less than being able to show how it is enforced; see shared schema or database per tenant.
- An audit log from the start. Who did what, to which record, when, from where. Write it as an append-only record that is separate from application tables. Auditors ask for it in a very specific way, which we covered in audit logs that answer an auditor.
- Sensitive data kept out of places it should not be. Application logs, error trackers, analytics events and support tools are the usual leaks. Decide on day one which fields are sensitive and filter them at the logging layer.
- Real authentication and access control. Single sign-on, role-based permissions, short-lived sessions, and a way to remove a user everywhere on the day they leave. B2B buyers will ask about each of these, as in the auth and SSO questions every buyer will ask.
- Encryption in transit and at rest, plus tested backups. Mostly configuration with managed infrastructure, but the restore test is a process you need to practice, per backups nobody has tested.
- A vendor list. Every third party that touches customer data, with its agreement status. For HIPAA this means a business associate agreement with each one, and it constrains which tools you can use, including some analytics, email and AI services.
Where the time and money go
We will not quote a number here, because it depends on your scope, your customers and the auditor, and any fixed figure from a blog post would be a guess. What we can say is where the cost comes from, so you can ask the right questions of any estimate.
- Engineering time for the architecture above. For a new build, this is a modest addition to the first months. For an existing product without tenant scoping or logging, it is a retrofit that can touch most of the codebase.
- Compliance tooling and an auditor. Many companies use a compliance automation platform to collect evidence, plus a separate audit firm. These are real recurring costs, and a Type II report is typically repeated each year.
- Penetration testing and remediation. A third-party test finds things, and fixing them takes developer time that should be in the plan.
- Your own time. Writing policies, running access reviews, onboarding and offboarding checklists. This lands on a founder or an operations person, and it is the part teams underestimate most.
The timeline logic is similar. A Type II report needs an observation period during which your controls actually operate, so even a perfectly prepared company cannot get one on the day it decides to. That is the main reason to start the architecture early even if you defer the audit.
A decision rule: require it in writing, build for it early, certify when asked
Do not start a SOC 2 audit because it sounds responsible. Start it when a real buyer asks for the report and the deal justifies the cost. Meanwhile build as if you will be audited, because the controls are good engineering anyway, and answer early security questionnaires from what you actually do.
For HIPAA the rule is stricter. If you will handle protected health information, decide that before design starts, sign agreements with your vendors before real data flows, and keep test environments free of real patient data. Ask any studio you are considering to say specifically how they handle both, and whether the contract covers it. Our guide to what to require in a development contract lists the clauses that matter.
When this advice does not apply
If your product never touches health data, a HIPAA program is not required, and building one wastes money. If your first customers are small businesses who accept a short security questionnaire, a SOC 2 report can wait until the first enterprise deal. Some products, such as an internal tool for one company, may need neither.
Be careful with the opposite error as well. Skipping the architectural habits because you are not audited yet is how a product ends up with no audit trail and unscoped queries, and then a six-month retrofit when the first big customer arrives. We build to those habits by default, and describe how we scope them on the approach page. To talk through your situation, the contact page is the fastest route.
Frequently asked
Does SOC 2 certify my software?
No. SOC 2 is an attestation report written by an independent auditor about your controls, not a certificate for the product. Type I covers the design of controls at one point in time, and Type II covers how they operated over a period. Customers read the report to judge your security practices.
Is there an official HIPAA certification?
No. HIPAA is a law with rules on safeguards, breach notification and agreements with vendors, and there is no government certification for software. Be cautious of vendors who sell a HIPAA certification. What matters is that you meet the rules and hold signed agreements with every vendor touching the data.
Should a startup get SOC 2 before launching?
Usually not. Build the underlying habits from day one, such as audit logs, tenant scoping and access control, then start the audit when a real buyer requires the report. A Type II report needs an observation period, so plan ahead for the timing, but avoid paying for it before a deal depends on it.
How much does compliance add to a build?
It depends on scope, customers and the auditor, so any single figure would be a guess. Expect costs in engineering time, compliance tooling, the audit itself, penetration testing and your own staff time. Retrofitting an existing product costs far more than building the controls in from the start.