Security and Compliance Basics for Enterprise Web Apps

Founders building enterprise software usually encounter compliance the same way: a prospective client's security team sends over a fifteen-page questionnaire, and half the terms in it are unfamiliar. This post is written for that moment. It is not a developer's implementation checklist, it is an orientation for the person who has to decide what to pursue, what to ignore, and how much to budget, before the questionnaire arrives.

Getting this right matters because compliance is one of the few areas of software development where the order of operations changes the cost by a large multiple. Building enterprise web applications with the right architecture from day one is meaningfully cheaper than retrofitting compliance onto a system that was not designed for it. We will get to why later in this post. First, the frameworks themselves.

SOC 2, GDPR, HIPAA, and PCI DSS: what each one actually covers

These four come up constantly and get conflated constantly, despite covering different things.

SOC 2 is an American auditing standard (developed by the AICPA) that evaluates whether your organization has adequate controls around security, availability, processing integrity, confidentiality, and privacy. It is not a law. Nobody requires it. But enterprise buyers, particularly in the US, increasingly require a SOC 2 report before they will sign a contract, because it gives them evidence you take security seriously without them having to audit you directly.

GDPR (General Data Protection Regulation) is European Union law. It applies if you process personal data of people in the EU, regardless of where your company is based. It governs consent, data subject rights, and how you handle and transfer personal data. If you have any EU users or customers, GDPR applies to you whether or not you are a European company.

HIPAA (Health Insurance Portability and Accountability Act) is US law that applies specifically to protected health information, and specifically to entities defined as covered entities or business associates, generally healthcare providers, insurers, and companies that process health data on their behalf. If your app never touches health information, HIPAA does not apply, no matter how sensitive your other data is.

PCI DSS (Payment Card Industry Data Security Standard) applies if you store, process, or transmit credit card data. Most companies avoid the heaviest PCI obligations entirely by using a payment processor like Stripe or Stripe Connect that keeps raw card data off their servers. This is almost always the right architectural choice for a mid-size company, since full PCI compliance for a company handling raw card numbers directly is a serious, ongoing undertaking.

The practical question for most founders is not "which of these should we pursue" but "which of these actually applies to us." A B2B SaaS company selling to US enterprise clients with no health data and no direct card handling likely needs SOC 2 and can mostly ignore HIPAA and the heavier parts of PCI DSS. A healthtech company needs HIPAA regardless of what else it does. Know your category before you spend money chasing the wrong certification.

What SOC 2 Type II actually involves

SOC 2 comes in two flavors. Type I evaluates whether your controls are designed correctly at a single point in time. Type II evaluates whether those controls actually operated effectively over a period, usually 3, 6, or 12 months. Enterprise buyers increasingly want Type II specifically, since Type I only proves you wrote good policies, not that you followed them.

The practical process looks like this:

1. Gap assessment (2 to 4 weeks). You or a consultant review your current practices against the SOC 2 trust services criteria and identify what is missing, usually things like a formal access review process, a documented incident response plan, or vendor risk management.
2. Remediation (4 to 12 weeks). You implement the missing controls: multi-factor authentication everywhere, formal change management, logging and monitoring, an actual written security policy that employees acknowledge.
3. Observation period (3 to 12 months for Type II). An auditor needs evidence that these controls operated correctly over this window, not just that they exist. This is why Type II cannot be rushed, the clock only starts once the controls are actually in place.
4. Audit (4 to 8 weeks). A licensed CPA firm reviews your evidence and issues the report.

Total realistic cost, including audit fees, a compliance automation tool (Vanta, Drata, or Secureframe are common choices), and the engineering time to close gaps, typically runs $20,000 to $60,000 for a first Type II report at a small to mid-size company, spread across 6 to 12 months. Ongoing annual costs to maintain it are lower, usually $10,000 to $25,000, once the initial controls are in place. Companies that try to shortcut this by hiring a firm that promises SOC 2 "in 30 days" are usually buying a Type I report, which satisfies fewer enterprise buyers than they expect.

GDPR essentials without the legal jargon

GDPR compliance for a typical B2B or B2C web application comes down to a handful of concrete requirements:

• Lawful basis. You need a legitimate reason to process someone's personal data, usually consent, contractual necessity, or legitimate interest. Document which basis applies to each type of data you collect.
• Data subject rights. EU users can request a copy of their data, request corrections, request deletion (the "right to be forgotten"), and object to certain processing. Your app needs a real, working process for handling these requests, not just a privacy policy that mentions them.
• Data processing agreements (DPAs). If you use third-party vendors that touch EU personal data (your hosting provider, your email service, your analytics tool), you need a DPA with each of them establishing how they handle that data.
• International transfers. Moving EU personal data outside the EU (to a US-based server, for instance) requires a valid transfer mechanism, most commonly Standard Contractual Clauses built into your vendor agreements.

Most established cloud providers (AWS, Google Cloud, Microsoft Azure) offer DPAs and standard contractual clauses as part of their standard terms, which covers a large part of this automatically once you actually sign them, something many companies skip. GDPR fines are calibrated to be painful (up to 4% of global annual revenue for serious violations), but for most mid-size companies the real risk is not a headline fine, it is losing an EU enterprise deal because you cannot answer basic questions about data handling.

Baseline technical controls every serious app needs

Regardless of which certifications apply to you, these controls are the floor for any application handling real customer data, enterprise or not.

Encryption in transit and at rest

All traffic should run over TLS 1.2 or higher, no exceptions, including internal service-to-service traffic in more mature setups. Data at rest, meaning your database, backups, and file storage, should be encrypted using standard tools your cloud provider already offers (AWS KMS, Google Cloud KMS, Azure Key Vault). This is inexpensive to implement and expensive to explain away if you skip it.

Access control and least privilege

Every person and every service should have the minimum access required to do their job, nothing more. Engineers should not have standing production database access by default. Service accounts should have scoped permissions rather than broad admin credentials. This principle, least privilege, is one of the first things auditors and security-conscious clients check.

Audit logs

Covered in more depth in our companion post on enterprise web application development, but worth repeating here: you need a record of who accessed or changed what, when. This is both a compliance requirement and, frankly, how you figure out what happened during an actual incident.

Dependency management

Modern applications, whether built on Next.js, a Node backend, or similar stacks, pull in hundreds of open source packages. Each one is a potential vulnerability. Automated dependency scanning (Dependabot, Snyk, or similar) and a process for actually patching flagged issues, not just receiving the alert, is table stakes.

Secrets handling

API keys, database credentials, and encryption keys should never live in source code or plain text config files. Use a proper secrets manager (AWS Secrets Manager, HashiCorp Vault, or your cloud provider's equivalent), rotate credentials periodically, and never share production secrets over Slack or email.

Backups with tested restores

A backup nobody has ever restored is a hope, not a plan. Automated daily backups are the baseline; the requirement most companies skip is actually running a restore drill, ideally quarterly, to confirm the backup works and the team knows the process under pressure.

Incident response

A short, specific written plan: who gets notified when something goes wrong, how you assess severity, when and how you communicate with affected customers, and what regulatory notification obligations apply (GDPR requires notification within 72 hours of certain breaches, for instance). Having this written before an incident happens is the difference between an organized response and a panicked one.

Why architecture decisions made on day one matter most

Every control above is dramatically cheaper to build in from the start than to retrofit. Encryption at rest is a checkbox when you provision the database; it is a migration project once you have millions of rows of unencrypted production data. Audit logging is a design decision when you define your data model; it is an archaeology project once you have to figure out which of forty existing code paths modify a given table without logging anything.

The pattern we see most often with clients coming from an existing, poorly architected system is that the compliance retrofit costs more than the compliance would have cost if planned from the start, sometimes by a factor of two or three. If you know your app will eventually need SOC 2, or you already have EU users, or you are building anything adjacent to healthcare or finance, say so during the architecture phase, not after the MVP ships. Related work like custom software development and SaaS development benefits from the same principle: the cheapest time to make a security decision is before the first line of code, not after the first customer complaint.

FAQ

Do we need SOC 2 if we are a small startup?

Not necessarily, and pursuing it too early can waste money you need elsewhere. The signal to start is usually the first enterprise prospect whose procurement process explicitly requires it, or a pattern of deals stalling on security review. Many companies successfully sell to smaller and mid-market buyers for years before SOC 2 becomes necessary.

Does GDPR apply to us if our company is based in the US?

Yes, if you have users or customers located in the EU, GDPR applies regardless of where your company is incorporated or hosted. Company location is not the trigger, the location of the people whose data you process is.

What is the difference between SOC 2 Type I and Type II?

Type I checks whether your controls are designed correctly at one point in time. Type II checks whether those controls actually worked over an observation period of several months. Most enterprise buyers now expect Type II because it is meaningfully harder to fake.

Can we handle credit card payments without full PCI DSS compliance?

Yes, and most mid-size companies should. Using a payment processor like Stripe that takes on card data handling (through hosted checkout pages or tokenization) keeps raw card numbers off your servers entirely, which dramatically reduces your PCI scope down to a much simpler self-assessment questionnaire rather than a full audit.

If your team is fielding security questionnaires you are not sure how to answer, or planning a build that will eventually need to, book a free 1-hour strategy call and we will help you figure out what actually applies to your situation.