Compliance for Startups (And the Devs Who Are Their Own DevOps Team)

Why You're Reading This

Hopefully you're reading this before you've already lost business due to security concerns or "lack of seriousness" — but if not, you know what they say about the 2nd best time to plant a tree.

If you're developing (or have already developed) an app that accesses any sort of personal or credit card data, or whose clientele are primarily in a regulated space (financial, medical, education, legal, etc.), you're going to get asked to prove you take security seriously. This is a map of what you'll get asked for, what actually applies to you, and what it costs to find out late.

What This Stuff Actually Is (And Isn't)

Before we get into it, one thing worth understanding: almost none of this is law. No regulator will ever knock on your door asking for your SOC 2 report, and there's no fine for not having one. It exists because procurement teams and security reviewers started asking for it, and enough vendors got one that it became the price of admission. Depending on the space and the individual customer, there may be a preference or even requirement to go with certified vendors only.

That changes the question you should be asking. It's not "am I required to have this?" It's "will not having this cost me a deal I want?"

The other thing to understand is that you usually don't inherit these obligations from your own industry; you inherit them from your customers. Build a scheduling app and you're regulated by nothing in particular. Sell that same app to a hospital system and you're a business associate under HIPAA, because their obligations flow down to you through the contract you signed. Your buyer's regulator becomes your regulator.

Setting aside laws that only apply in narrow circumstances, like Sarbanes-Oxley in the U.S., privacy law is the biggest exception to all of this; ignoring it is actually illegal rather than just commercially painful. Card handling is its own category: PCI DSS isn't law either, but your payment processor can fine you or cut you off entirely, which in practice hurts about the same. We'll get to both at the end.

Another thing to keep in mind: which framework you go for depends on who your buyers are, not where your company is incorporated. SOC 2 carries more weight in the U.S., while ISO 27001 is usually preferred abroad. That said, a European fintech selling into American banks still needs a SOC 2 — so follow your buyers before your postcode.

SOC 2

This is the one you'll get asked for most, especially if you do business in the US, so it's worth understanding properly.

SOC 2 comes from the AICPA, so it has accounting roots, and it can only be performed by a licensed CPA firm. Its sibling, SOC 1, covers financial reporting; SOC 2 was purpose-built for service organizations that handle customer data. In practice it's become the default security assurance report for SaaS in the United States, and more and more businesses are asking for it regardless of industry.

It's important to know that what you get at the end isn't a certificate, it's a report: an auditor's opinion on whether the controls you claimed to have actually exist and actually work. That being said, don't assume just because you're paying an auditor that they won't give you exceptions on your report, or even potentially outright stop the engagement without giving you a report if your prep is bad enough. Depending on the client, exceptions can kill a deal just as easily as not having a report. Proper preparation is key.

Who asks for it

Fintech and banking tech, healthcare tech, HR and payroll platforms, insurance tech, ed tech, legal tech, and increasingly any B2B SaaS selling to mid-market and above. Note that none of those industries are regulated by SOC 2. Banks answer to the FFIEC and OCC, hospitals to HIPAA, schools to FERPA. None of those name SOC 2 anywhere. It just became the common currency for proving you're safe to buy from.

Types

There are two types of SOC 2:

• Type 1 is a point in time; the auditor confirms your controls are designed properly and were in place on a given date.
• Type 2 covers a period, usually three to twelve months, and tests whether those controls actually operated the whole time.

Type 2 is what buyers really want, but if you're new or only recently became compliance conscious then Type 1 is what you should realistically get first, and it's enough to unblock most deals while you build the observation window for Type 2. Generally speaking, if you can pass the Type 1 then the Type 2 is just a matter of time… but you'll want to make sure you're following best practices in the meantime: make sure you're following your policies, which should include stuff like ensuring every change has a documented ticket, every new employee is sufficiently vetted, terminations/decommissions (if any) are handled swiftly, etc. Not sure what to put in your policies? We'll cover that in a later blog.

Trust Services Criteria (TSCs)

The SOC 2 is split into 5 categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Each TSC has different controls focused on different areas. Your audit size (and cost) may increase depending on which TSC you select, so choose wisely.

In my experience most organizations probably want Security (which is mandatory), Availability, and Confidentiality by default. If your app has a lot of PII, then you'll probably also want Privacy. Processing Integrity doesn't come up often, but that doesn't mean it isn't necessary for your specific app. Hopefully you know your own application well enough to determine exactly which criteria your customers expect.

How much does it cost?

This can be a tough question. The price of the audit itself fluctuates pretty wildly so I recommend shopping around; I've seen some sub $10k with the right deals (and if you hit up the auditor at the right time in the quarter), some $20k+. Depending on your model, that could be the cost of multiple lost deals.

Keep in mind you may have to turn on additional services that you weren't using before, which may scale to the size of your business, but should be considered the cost of doing business. Also keep in mind that gap assessment and remediation is more costly the less groundwork you've done. You can hire some companies or consultants to not only do the entire thing for you, but also even build (or rebuild) your entire cloud to be compliant — but that could cost you anywhere from $10–30k+. Generally speaking, the longer the environment goes without compliance, the more it costs.

How long does it take?

If you're starting cold with no experience, no documentation, and no formal controls, expect three to six months of preparation before you're ready for a Type 1. Then the Type 2 observation window is another three to twelve on top. So from a standing start to a Type 2 report in hand is realistically about a year.

That number is why the "start before you need it" argument matters. Who knows how many deals you could lose before then.

ISO 27001

If SOC 2 is the American answer, ISO 27001 is the international one. It's the default across Europe, and increasingly across Asia and the Middle East as well.

The structural difference matters. SOC 2 attests that specific controls operated correctly; ISO 27001 certifies that you have an information security management system, meaning a documented process for identifying risk and doing something about it. One is about the controls, the other is about the machine that produces the controls.

Practical differences worth knowing:

• You get an actual certificate with ISO, which people like having.
• The audit is done by an accredited certification body rather than a CPA firm; think BSI, Schellman, or A-LIGN, accredited by a national body like UKAS or ANAB.
• The cadence is different: ISO runs on a three year cycle with lighter surveillance audits in years one and two, where SOC 2 is a fresh report every single year.

The good news if you're weighing both: the control overlap is substantial. Doing both is nowhere near double the work, and most compliance platforms will map your evidence across the two. If your buyers are split between US and European, it's worth planning for both from the start rather than bolting the second one on later.

FedRAMP, StateRAMP, and CMMC

Short version: if you're a small team, these probably aren't for you, and I want to save you some time.

FedRAMP is what you need to sell cloud services to US federal agencies. It's built on NIST 800-53, and it's a multi-year effort with costs that start in the six figures and go up from there. You also can't just decide to do it; you need a sponsoring agency willing to back your authorization, which is a chicken-and-egg problem when you have no federal customers yet. If your solution is going to be used by the DoD, then the DoD Cloud Computing SRG layers additional requirements on top of FedRAMP for defense workloads, so it's harder still.

StateRAMP is the state and local government equivalent; it's meaningfully lighter than FedRAMP and there are small businesses that have gotten through it, so it's not out of reach the way FedRAMP is. But it also doesn't apply to all state governments, so you should have some state-level interest before you even bother looking into it.

CMMC applies if you're in the defense industrial base, meaning you're touching controlled unclassified information as part of a DoD contract or subcontract. It has tiers, and the lower ones are self-assessed, so it's more accessible than the name suggests.

If you genuinely want federal work as a small team, the realistic path is subcontracting under a prime who already holds the authorization, and inheriting their environment rather than building your own. That's not a compromise — it's how most small vendors get into the space.

PCI DSS and HIPAA: The Ones With No Certificate

These two get grouped together here for one reason: in most cases neither gives you a document you can hand a prospect. What you have instead is your own word, backed by whatever evidence you can produce if someone asks.

PCI DSS

PCI DSS applies if you touch cardholder data, and it comes from the card brands rather than from any government. Nobody will arrest you for non-compliance; your payment processor will just fine you or stop processing your payments, which in practice is worse.

The thing most people get right by accident is scope reduction. If you use Stripe, Paddle, or similar and card data never touches your systems, you're likely eligible for SAQ A, which is a short self-assessment questionnaire you fill out yourself. That's the good outcome, and it's why "just use Stripe" is genuinely good advice. If you actually handle cardholder data, things get more and more complicated and expensive as the number of records you have goes up.

The trap is thinking that using a processor gets you out entirely. It doesn't. Build a custom checkout form that handles card numbers before passing them along, and you're back into heavier scope with far more requirements. Same if you store card data for recurring billing yourself rather than using tokens. The rule is simple: if card data touches your infrastructure, even briefly, you own that scope.

Large merchants above roughly six million transactions a year do get formally audited by a Qualified Security Assessor. If that's you, you're not reading this article.

HIPAA

HIPAA applies if you're a covered entity, or, much more likely, a business associate: someone handling protected health information on behalf of one. Build anything for a clinic, hospital, or insurer that touches patient data and that's you.

Two things people commonly get wrong:

1. There's no HIPAA certification. No auditor gives you a certificate. Anyone selling you one is selling you their own opinion. What you have is a signed Business Associate Agreement and direct legal liability under it.
2. HIPAA is narrower than the word "medical" suggests. If you sell medical equipment through an ordinary online storefront, you're not creating protected health information and HIPAA doesn't apply to you. The line is whether you handle health information tied to a specific individual's care or payment for care, not whether your product is health-related.

Because there's nothing to hand over, buyers ask for proof other ways: your policies, your risk assessment, your training records, and increasingly your SOC 2. That last one is why healthcare vendors often end up with a SOC 2 anyway; it's the closest thing to a certificate that exists in this space. There's still a lot to go through, so if any of your clientele touch these spaces it still might be worth getting a consultant to ensure you're following. Last I checked their rates were around $10k or so, but it's been a while since.

Optional Frameworks and Questionnaires

These ones cost nothing, but do show that you're serious about security and compliance — so they're worth at least a look.

Open Web Application Security Project (OWASP): Not technically mandatory, but if your web app doesn't handle the OWASP Top 10, then you might not be in business for very long. There are separate lists for web apps, APIs, and LLMs, so make sure you're reading the one that matches what you've built. If you weren't aware of it until now, spend time getting aware before going public.

National Institute of Standards and Technology (NIST): If you're really serious about security and compliance, you can follow the latest version of NIST 800-53. Fair warning: that's the catalog FedRAMP is built on and it runs to hundreds of controls, so if you just want a starting point, the Cybersecurity Framework or 800-171 is the more sensible entry. Some may be overkill for simpler apps, but you can't go wrong at least following as a guideline until all you have left to do is out of budget. Some customers may appreciate "FedRAMP-level security and compliance" if you manage to get that far.

Center for Internet Security (CIS): CIS has benchmarks that are product agnostic and used to harden all sorts of devices — computers, phones, cloud instances, and many more. They come in two levels: Level 1 is the baseline most people start with, since it hardens without breaking functionality, and Level 2 goes further for defense-in-depth at the cost of possibly breaking things.

Cloud Security Alliance Consensus Assessments Initiative Questionnaire (CSA CAIQ): This is a standard questionnaire that allows you to more-or-less market your security posture in a public space. There are a couple hundred questions, and it might answer some customer requests outright if you fill one out, but I think I've only come across one customer who insisted upon it.

Vendor specific: Amazon, Microsoft, and Google all have their own version of best practices, called the Well-Architected Framework for AWS and Azure, and the Google Cloud Architecture Framework for Google. They're necessary because these vendors will let you build whatever you want without compliance by default, so not following said guidelines and just standing up resources as-needed is likely to dig you into a hole of technical debt that you don't even know you're getting into. Worth knowing that none of these count as compliance evidence; no auditor will accept a Well-Architected Review as proof of a control. They overlap heavily with what you'll be asked for, but they're architectural guidance, not an audit artifact. If only someone would do something about that…

Privacy Law

Everything above is optional in the sense that nobody fines you for skipping it. This section is different. These are actual laws with actual penalties, and they apply whether or not any customer ever asks.

The main ones you should know exist:

• GDPR (EU/EEA) is the big one, and it applies based on whose data you hold rather than where you're located; if you have EU users, you're in scope regardless of where your company sits.
• UK GDPR is Britain's near-identical post-Brexit version, so complying with one gets you most of the way to the other.
• CCPA/CPRA (California) gives California residents rights over their personal information, and it applies to businesses over certain revenue or data-volume thresholds.
• The other US state laws now number about twenty, including Virginia, Colorado, Connecticut, Texas, and Oregon, and they're broadly similar to California's with irritating variations in the details.
• PIPEDA (Canada) is Canada's federal privacy law, currently in the middle of a long-running effort to modernize it.
• LGPD (Brazil) is closely modeled on GDPR, so the same compliance work largely carries over.
• Australia's Privacy Act applies to most businesses over a revenue threshold, with mandatory breach notification.
• COPPA (US) applies if your service is directed at children under 13, and the penalties are steep enough that you want to know early if you're in scope.
• FERPA (US) covers student education records, so it matters if you're selling into schools or universities.

The practical takeaway: the requirements across these overlap heavily. Know what personal data you collect, why, where it lives, and how to delete it on request. That inventory answers most of the questions in most of these laws — and if you don't have it, none of them are satisfiable.

Where This Leaves You

The good news is that there's a great deal of overlap in the questions you'll face from all of these frameworks, just in different formats: do you know what you built, do you know who can access it, do you know what changed and when, and can you prove any of it to someone who wasn't there.

Compliance is engineering, not paperwork. The documentation matters, but the documentation is a description of something. If the thing it describes doesn't exist, you're going to be in for a world of hurt — which is why the earlier you start, the cheaper it gets.

So the practical order of operations is roughly as such:

1. Figure out who your buyers are and what they'll ask for. That decides which frameworks you should pursue.
2. Get your policies written, because they're the cheapest gap to close and every auditor asks for them in week one.
3. Do a gap assessment to make sure your infrastructure and practices meet your policies before you engage anyone, so you find out what's broken on your own schedule instead of theirs.
4. Remediate.
5. Talk to auditors — understand it may be a few weeks to get on their schedule, so try to plan accordingly.

The mistake almost everyone makes is doing that in reverse: signing with an auditor first, getting portal access, and discovering what the controls are while the clock is running. I recommend only doing that once you've got some experience. Every gap you find at that point is a gap you're fixing under time pressure, in an environment that was never built to accommodate it.

All of this gets cheaper the earlier you do it. A compute instance without proper hardening and patching can be fixed in a few minutes in month one. In month eighteen, suddenly that random compute instance is load-bearing, running an OS past EOL, has a bunch of vulnerabilities that are somehow several years old, and nobody remembers what it was even running in the first place or why its security group is set to be completely open to the internet. None of that was a compliance problem in month one. It is now.

How We Handle This

Full disclosure: this is the part where I talk about what we built.

Everything above describes a retrofit. You build a cloud environment, you run it for a while, and then someone asks for a SOC 2 and you go back to find out how far it's drifted from what you'd need. That gap is the expensive part, and it's the part we designed around.

Tudovu is a compliance-native infrastructure platform. Everything gets built as Infrastructure as Code, every change is checked against compliance controls before it merges, and your cloud updates from your repo rather than from someone clicking around in a console. That means your change history is your audit evidence, and configuration drift stops being a thing that happens to you.

A few specifics:

• Our Architect agent builds infrastructure the way any frontier model would, except it opens a pull request against your IaC repo instead of spraying unreviewed resources into your account. You review, you merge, and your environment updates itself.
• Our Remediator agent works like the compliance scanners you've used before, with one difference: it ships fixes as IaC rather than just listing findings and giving you solutions. It watches your security services such as AWS Inspector, GuardDuty, Trusted Advisor, and Security Hub, and when something needs fixing it can generate the change and open the PR — custom fix included if the situation calls for it.
• Our Documentarian agent handles the policy set through an interview process, using existing documents as context. We used it on ourselves; our entire documentation set took about an hour.

And these are just the core features. It's part of a full suite of compliance tools including data rooms, a trust center that can answer security questionnaires from context and previous answers, risk registries, and more.

The result, for us, was this: we got auditor portal access on June 30th, 2026 at 5:33 PM, and submitted our last control July 1st at 8:35 PM. About 90% of the SOC 2 done in a day. That's the part that usually eats weeks. From there it was simply a matter of answering clarification questions as they came up.

That's what we mean by compliance by default.