Writing Software for Regulated Industries

The first time an auditor walked into our office, I watched our engineering team freeze. People stopped committing code. Conversations got quiet. There was a genuine fear that anything they said or did would end up in a finding.

That reaction told me everything about how we had been approaching compliance: as a threat to be survived rather than a constraint to be engineered around. It took us two years to completely reverse that mindset, and the transformation changed how we build software in ways I did not expect.

We build telehealth software. That means HIPAA compliance is not optional — it is existential. A single breach can mean millions in fines, loss of customer trust, and potentially the end of the company. We are also SOC 2 Type II certified, which means we undergo continuous auditing of our security controls. And we operate under state-level telehealth regulations that vary across every jurisdiction where our customers practice.

Here is what I have learned about building fast in a regulated environment.

Compliance as Code, Not Compliance as Process

The biggest shift we made was moving compliance from a human process to an automated system. In the early days, compliance was a checklist that someone reviewed before each release. It was slow, error-prone, and completely dependent on the person doing the review remembering all the rules.

Today, compliance is encoded in our infrastructure and deployment pipeline. It is not something engineers need to think about — it is something the system enforces.

Access controls are defined in code. Every service's access control policy is declared in a configuration file that lives in the same repository as the service code. Changes to access control go through the same review and deployment process as any other code change, which means they are versioned, auditable, and testable. When an auditor asks "who has access to PHI in this service?" the answer is not a spreadsheet someone updated three months ago — it is a configuration file with a complete git history.

Encryption is enforced at the infrastructure level. Our platform layer ensures that all data at rest is encrypted and all data in transit uses TLS. Individual engineers do not need to remember to enable encryption — it is not possible to deploy a service without it. The platform rejects unencrypted storage configurations at deploy time.

Audit logging is automatic. Every access to protected health information generates an audit log entry. This is not implemented in application code — it is implemented in our data access layer, which means engineers cannot accidentally skip it. The audit logs are immutable, stored in a separate system with independent access controls, and retained for seven years per our retention policy.

PHI detection runs in CI. We built a custom static analysis tool that scans code for patterns that suggest PHI might be logged, stored in an unapproved location, or transmitted without encryption. It is not perfect — no static analysis is — but it catches the most common mistakes before code reaches production.

The cumulative effect of these investments is that compliance is largely invisible to product engineers. They write application code, and the platform handles the regulatory requirements. This is by design. The more you ask individual engineers to think about compliance, the more likely someone will forget.

Architecture Decisions That Regulation Forces

Working in a regulated industry forces certain architectural decisions that turn out to be good engineering practice regardless of regulation.

Data Isolation

HIPAA requires that protected health information be carefully controlled. This led us to build strict data isolation boundaries early on — PHI lives in dedicated, encrypted data stores with separate access controls, and non-PHI data lives elsewhere. No commingling.

This constraint initially felt burdensome, but it turned out to be architecturally beneficial. Having clear data classification and isolation boundaries makes our system easier to reason about, easier to test, and easier to evolve. When a new feature needs patient data, the engineer knows exactly where to find it and exactly what access patterns are approved.

Many companies without regulatory requirements end up with PHI or PII scattered across dozens of databases, log files, and caches. When they eventually need to comply with GDPR or respond to a data subject access request, it is an archaeological expedition. Our data architecture made those concerns trivial from day one.

Immutable Infrastructure

SOC 2 requires that production systems be consistent with their documented configurations. The easiest way to guarantee this is to make infrastructure immutable — production servers are never modified in place. Every change goes through the pipeline, produces a new artifact, and gets deployed as a replacement.

This eliminated an entire category of configuration drift problems and made our deployments more reliable. It also made incident response faster, because rolling back to a known-good state is a single operation.

Comprehensive Observability

Regulatory requirements for audit logging and incident documentation drove us to build observability into every layer of the system far earlier and more thoroughly than we otherwise would have.

Every service emits structured logs, metrics, and distributed traces. Every database query is instrumented. Every external API call is logged with timing, status, and correlation IDs. This was initially motivated by compliance — we need to be able to reconstruct exactly what happened during any incident involving PHI.

But the engineering benefit has been enormous. When something goes wrong in production, we can trace the exact path of a request through every service it touched, see every database query it executed, and identify the root cause in minutes rather than hours.

Moving Fast Within Constraints

The concern I hear most from engineers joining the team is "does compliance slow you down?" The honest answer is: it did, before we invested in automation. Now it does not, and in some ways it makes us faster.

Here is how we maintain velocity.

Pre-Approved Patterns

We maintain a library of pre-approved architectural patterns for common scenarios. Need to store PHI? Here is the approved pattern with encryption, access control, and audit logging built in. Need to integrate with a third-party service? Here is the approved pattern for data transfer agreements and security reviews.

Engineers do not need to figure out compliance requirements for each new feature. They select the appropriate pattern and implement it. The patterns have already been reviewed by our compliance team and approved by our legal counsel. This turns a multi-week compliance review into a five-minute pattern selection.

Risk-Based Review Tiers

Not every change carries the same regulatory risk. A change to the login page has different compliance implications than a change to the payment processing system.

We categorize changes into three tiers. Tier 1 changes — those that affect PHI, authentication, or financial transactions — require a security-focused review and a compliance check. Tier 2 changes — those that affect customer-facing functionality but not regulated data — require standard review. Tier 3 changes — internal tooling, documentation, non-functional improvements — go through automated checks only.

This tiering prevents compliance from becoming a bottleneck on low-risk work while ensuring high-risk changes get appropriate scrutiny.

Continuous Compliance Monitoring

Rather than preparing for audits as a periodic event, we maintain continuous compliance. Our systems are always audit-ready because compliance monitoring runs constantly. Dashboards show the current state of every compliance control. Alerts fire immediately when a control drifts out of compliance.

When the auditor comes, we open a dashboard and walk them through it. The entire SOC 2 audit process, which used to take six weeks of preparation, now takes two weeks with minimal disruption to engineering.

Regulation as Competitive Advantage

Here is the counterintuitive insight that took me two years to fully appreciate: in a regulated industry, compliance is a moat.

Every new competitor in our space has to solve the same compliance problems we solved. But because we invested early in compliance automation and architecture, we solved them once and amortized the cost across every feature we have built since. A new entrant has to make that investment from scratch, and until they do, they cannot sell to the same customers we sell to.

Our SOC 2 certification, our HIPAA compliance posture, and our regulatory track record are not just checkboxes — they are sales assets. Enterprise customers in healthcare will not even start an evaluation without them. Every month that a competitor spends building compliance infrastructure is a month we are shipping product features.

Lessons for Any Regulated Industry

Whether you are in health tech, fintech, government, or any other regulated space, the core lessons are the same.

Automate compliance from day one. Every manual compliance process is a scaling bottleneck and a point of failure. Encode your regulatory requirements in code, enforce them in your pipeline, and monitor them continuously.

Invest in data architecture. Know where your sensitive data lives, how it flows, and who can access it. Build isolation boundaries early. You will thank yourself when the first audit comes, and again when the first incident comes.

Make compliance invisible to product engineers. The platform should handle regulatory requirements so that engineers can focus on building product. If compliance is a tax on every feature, your velocity will suffer and your engineers will resent it.

Treat auditors as partners, not adversaries. The best auditors will help you identify gaps in your controls before they become breaches. Build a relationship based on transparency and continuous improvement.

Building software in a regulated industry is harder than building in an unregulated one. That is undeniable. But the constraints, properly embraced, produce better-engineered systems, more disciplined teams, and a durable competitive advantage that is hard to replicate. The companies that figure this out early are the ones that win.