What Building for Regulated Industries Actually Requires

Building software or infrastructure for regulated industries — cannabis, healthcare, legal, financial services — changes the technical requirements in ways that aren't always obvious until the first compliance audit or regulatory inquiry arrives. The differences aren't cosmetic. They're architectural.

The businesses that navigate regulated environments without incident are almost always the ones that designed compliance into the system from the start. The ones that get into trouble retroactively bolted it on after the fact, and discovered that the data governance, audit trails, and access controls required by regulators don't fit cleanly onto systems that weren't designed with them in mind.

Audit trails are not optional

In regulated industries, the question isn't whether something happened — it's whether you can prove what happened, when, by whom, and with what authorization. Audit trails need to be:

Immutable. Records that can be modified after the fact aren't audit trails — they're notes. Proper audit logging writes to append-only storage with cryptographic integrity verification. A log entry that was modified after creation should be detectable and flagged.

Comprehensive. Every write operation to regulated data, every access by privileged users, every configuration change to systems that touch regulated data. Selective audit logging — where you log the things that seem important and skip the things that seem routine — creates gaps that become problems during investigations.

Retained appropriately. Retention periods are often specified by regulation: HIPAA has different requirements than state cannabis regulations, which differ from SEC requirements. Build the retention policy into the system architecture rather than treating it as a post-deployment cleanup task.

This connects directly to data governance — the audit trail is part of the governance framework, not separate from it.

Access control at a granular level

Role-based access control (RBAC) is standard. What regulated industries often require is attribute-based access control (ABAC) — where access decisions are made based on multiple factors: who the user is, what they're trying to access, under what conditions, and whether they have explicit authorization for that specific action.

The cannabis seed-to-sale tracking requirement is a clear example: a dispensary employee can record a sale, but cannot modify an existing inventory record without supervisory authorization, and the system must record who authorized the modification, when, and what changed. That's not RBAC — it's workflow-enforced access control with an audit trail.

Privileged access management deserves its own consideration: the people with administrative access to the systems are the highest-risk accounts from a compliance perspective. MFA, session recording, and time-limited access grants for privileged operations are the minimum in environments where a rogue admin action could constitute a regulatory violation.

Data classification and handling

Not all data in a regulated environment has the same handling requirements. PHI (Protected Health Information) under HIPAA has specific handling, storage, and transmission rules. Cannabis transactional data may need to be retained and reportable to state regulatory systems in specific formats. Financial transaction records have their own retention and tamper-evidence requirements.

The system architecture needs to reflect data classification: where different classes of data live, how they flow between components, who can access them, how they're encrypted, and how they leave the system (if they leave the system). Data that shouldn't cross certain boundaries — system components, jurisdictional lines, vendor integrations — needs architectural enforcement, not just policy documentation.

Vendor due diligence goes both ways

Every third-party component in a regulated system is part of the compliance surface. The SaaS tool you use for internal communication that accidentally gets mentioned in a HIPAA audit because someone sent PHI through it is a compliance problem. The analytics platform that captures user behavior on a cannabis platform and sends data to servers outside the state is a regulatory risk.

Building for regulated industries requires knowing what every component in the stack does with the data it touches, and making deliberate decisions about what's acceptable. This is the architectural implication of security-first architecture — the compliance analysis isn't a layer on top of the system, it's part of how the system is designed.

For software dependencies specifically, scanning lockfiles before deployment is a concrete, automatable control. Vekt covers 22 lockfile formats — including Cargo.lock, package-lock.json, and requirements.txt — checking against OSV.dev and malicious package advisories in real time. For regulated environments, this scan belongs in the CI pipeline, not as an afterthought.

Documentation as a system component

Regulated industries treat documentation differently than most software environments do. The policies, procedures, system design documents, and operational runbooks aren't support artifacts — they're part of what regulators audit. A system that works correctly but lacks documentation of how it works and how it's operated is a compliance gap.

This means technical documentation that usually gets deferred ("we'll document it when we have time") needs to be treated as a deliverable, not a follow-up. System design documents, data flow diagrams, access control policies, change management procedures — these need to exist and be maintained alongside the systems they describe.

---

Related reading

• The Technology Fragmentation Problem Most Businesses Don't See
• The Case for Self-Hosted Infrastructure in 2026
• Website Accessibility Isn't Just Ethics. It's an SEO Signal.
• The Problem with Generic Tech Recommendations
• If the Recommendation Came Before the Questions, It's Not Advisory

Frequently asked questions about building for regulated industries

Do regulations specify the technology that must be used?

Rarely at the specific technology level. Regulations typically specify outcomes — data must be encrypted, access must be controlled, records must be retained — and leave the technical implementation to the business. This gives flexibility in how you meet requirements but requires that your technical choices can be demonstrated to achieve the specified outcomes.

How do you handle regulatory requirements that vary by jurisdiction?

Multi-jurisdiction compliance usually requires a layered approach: design to the strictest applicable standard where it's practical to do so, then configure jurisdiction-specific variations on top of that base. For cannabis specifically, where state regulatory requirements vary significantly, the architecture needs to support jurisdiction-specific data residency and reporting formats without requiring separate system deployments for each state.

Is open-source software suitable for regulated environments?

Yes, with appropriate due diligence. Many regulated environments rely heavily on open-source infrastructure. The requirements are the same as for any component: the software needs to be maintained, vulnerabilities need to be patched on a defined schedule, and the licensing terms need to be compatible with how you're using it. Open-source is not inherently less secure or less compliant than proprietary alternatives.

What's the most common architectural mistake in regulated industry projects?

Treating compliance as a project phase rather than a design constraint. The teams that end up with expensive remediation work — adding audit trails to systems not designed for them, retrofitting access controls onto data models that don't support them, trying to establish data classification on systems that mixed data classes from the start — almost always deferred those decisions to "later." Later is expensive.