Choosing a tech stack for compliance-heavy SaaS

When a SaaS product sells to banks, hospitals or large enterprises, compliance stops being a document and starts shaping the system. Customers send security questionnaires, ask for a SOC 2 report or ISO 27001 certificate, and write data processing terms into their contracts. Depending on the market, the product may also need to meet GDPR, PCI DSS or HIPAA.

None of these frameworks tells you which database or language to use. They describe outcomes: data is protected, access is controlled, changes are reviewed, incidents are noticed. The stack you choose decides how hard it is to show those outcomes, year after year, to people whose job is to doubt you.

What compliance actually constrains

Strip away the paperwork and most requirements fall into a handful of technical areas.

• Data residency. Some customers or regulations require data to stay in a region. GDPR restricts transfers of personal data out of the European Economic Area unless specific safeguards are in place, and many buyers simply ask for EU hosting to avoid the question. This decides your cloud regions, and also where your backups, logs, email provider and support tools keep their copies.
• Audit trails. You need to show who did what, when, and from where: in the product, in the infrastructure and in the code. These records must be hard to alter and kept for a defined period.
• Access control. Staff should reach only what their role needs, with strong authentication and a record of each grant. Access to production data should be rare, justified and logged.
• Encryption. Data encrypted in transit and at rest is the baseline. The harder questions are who controls the keys, how they rotate, and whether some customers need their own.
• Retention and deletion. You must keep some records for years and delete others on request. GDPR's right to erasure reaches into backups, analytics copies and logs, which is where most systems struggle.

Map each requirement you face onto these areas before choosing anything. The mapping becomes the checklist every later decision is tested against.

Managed services or running them yourself

A managed database, queue or key service from a major cloud provider comes with the provider's own certifications and a shared responsibility model. The provider proves the physical security, patching of the platform and durability. You prove how you configured it and who can reach it.

That split usually favours managed services for a compliance-heavy product. Every component you run yourself adds evidence you must produce: patch records, backup tests, vulnerability scans, access reviews. A small team can spend a surprising share of its time proving that a self-run database is looked after.

There are reasons to run things yourself. A customer may require on-premises or single-tenant deployment. A managed service may not be available in the region you need. For HIPAA, a provider must sign a business associate agreement, and not every service in its catalogue is covered by it, so check the list before choosing. For card data, the usual advice is to keep it out of your systems entirely by using a payment provider's hosted fields or tokenisation, which shrinks the scope of PCI DSS to a fraction of the stack.

Choose managed by default, and self-run only where a requirement forces it.

Choose boring, well-supported tools

Auditors and enterprise security teams are more comfortable with technology they recognise, and so are the engineers who will maintain the system in five years. For a compliance-heavy product, boring is a feature.

Useful tests for each component:

• Is it widely used, actively maintained, and does it publish security advisories?
• Does it support the controls you need natively: encryption, fine-grained permissions, audit logging, single sign-on?
• Can you hire people who know it?
• Does the vendor, if there is one, publish its own compliance reports?

A mainstream relational database, a mainstream language and framework with a long security track record, and a major cloud provider will pass most of these tests. A new database with an exciting data model may be the right choice for a product, but in this context it needs a stronger reason than interest.

Keep the number of components small. Every extra service is another data flow to document, another vendor to assess and another place personal data might leak into.

Build logging and evidence in from day one

Much of an audit is a request for evidence: show us the access review from last quarter, the approval for this change, the alert from that incident. Teams that collect evidence as a side effect of normal work pass audits calmly. Teams that assemble it by hand, the week before, do not.

Design for evidence from the start:

• Infrastructure as code. Every change to the environment goes through a reviewed pull request, so the history is the change log.
• Protected branches and required reviews. The repository shows that no code reached production without a second person approving it.
• Central, append-only logs. Application, infrastructure and access logs flow to one place with restricted write access and a defined retention period.
• Product audit events. Record security-relevant actions in the product itself (sign-ins, permission changes, exports, deletions) in a structured form customers can be shown.
• Single sign-on for staff. One identity for every internal tool makes onboarding, offboarding and access reviews a query rather than a hunt.

Keep personal data out of logs where you can. A log full of email addresses and tokens becomes a second copy of your database, with weaker protection and its own retention problem.

Keep the stack changeable

Regulation changes, customers bring new requirements, and a large deal may arrive with a region you do not yet serve. The stack should be able to follow without a rewrite.

A few habits help:

• Treat region and tenant as configuration, not assumptions baked into code, so a new deployment is a new set of values.
• Put a thin layer of your own code between the application and the services most likely to change, such as email, storage and identity. Swapping a vendor then touches one module.
• Classify data early. Knowing which fields are personal, sensitive or regulated lets you apply encryption, retention and residency rules field by field instead of across everything.
• Write down each significant decision and the requirement behind it. When a framework changes, you can see which decisions it affects.

Avoid building abstractions for changes nobody has asked for. The aim is to make likely changes cheap, not to make every change possible.

Where to start

List the frameworks your customers will ask for in the next year or two, and map their requirements onto residency, audit, access, encryption and retention. Default to managed services from a major provider in the regions you need, keep payment data out of your systems, and choose mainstream tools with native security controls. Set up infrastructure as code, reviewed changes, central logs and staff single sign-on before the first release rather than after.

Getting this right early does not make a product compliant by itself; policies, training and processes still matter. It does mean that when the first enterprise questionnaire arrives, the answers already exist in the system.