What Building Software for Regulated Industries Actually Requires | Digital Marmalade [Skip to main content](#main-content) The first thing most people think of when regulated industry software comes up is compliance. Tick the right boxes, meet the standard, pass the audit. That framing isn't wrong, exactly — the standards exist for good reasons and meeting them matters. But treating compliance as the goal tends to produce software that satisfies the auditor and frustrates the people who use it every day. Digital Marmalade has built software across several regulated environments. Medindex, built for Medindex Ltd and deployed into NHS Integrated Care Systems, has to meet the NHS Digital Technology Assessment Criteria — a demanding framework covering clinical safety, data handling, accessibility and usability. Spartacus, our cybersecurity assessment platform, operates in an environment where governance, evidence and audit trails are central to the product's value rather than peripheral requirements. Kneip, a financial services client, required software built around fund data and regulation, where precision and compliance with financial reporting standards aren't features — they're the entire brief. Three different sectors, three different regulatory frameworks, and a set of shared lessons underneath them. Compliance is a floor, not a ceiling ------------------------------------ A product that meets its regulatory requirements but is difficult to use creates its own kind of risk. Users find workarounds. Workarounds introduce inconsistencies. Inconsistencies undermine the integrity of the data or the process that the regulation was designed to protect in the first place. This is a pattern that shows up across regulated industries, and it usually starts with design decisions that prioritised passing a checklist over understanding how the product would actually be used. The most effective regulated software is built by asking what the regulation is trying to achieve and designing for that outcome, rather than for the literal requirements of the standard. Often the two align — accessibility standards exist because accessible products work better for more people, and building accessibly from the start produces better software than retroactively addressing a checklist. But where there's tension, understanding the intent behind a requirement is what lets you meet it in a way that improves the product rather than constraining it. The data model has to be right from the start --------------------------------------------- In regulated environments, the way data is structured, stored and accessed isn't just a technical decision — it's a compliance decision. For clinical software like Medindex, how patient-adjacent information is held and who can access which parts of it has to be designed against specific governance requirements before any interface work begins. For financial software, the auditability of data — being able to show what a figure was, when it changed and who changed it — is often a core requirement that shapes the entire architecture. Getting this wrong early is expensive. A data model that doesn't accommodate the governance requirements of the regulated environment it operates in tends to produce a series of increasingly complex patches, each one adding fragility. The right time to understand the regulatory implications of data design is before the data model is built, not after. Audit trails and transparency are product features -------------------------------------------------- In a non-regulated context, an audit trail is something you add for operational reasons — useful for debugging, helpful if something goes wrong. In a regulated environment, it's often a core feature that users and auditors rely on. Spartacus is a good example: the ability to show exactly how a cybersecurity maturity score was reached, with a clear record of the inputs, the assessor's reasoning and any changes over time, isn't an administrative nicety. It's what makes the assessment defensible — to the client's own board, to their regulators and to the consultants who need to stand behind their conclusions. Building this well means thinking about transparency as a design discipline from the start, not a reporting layer bolted on at the end. What this means when you're briefing a development partner ---------------------------------------------------------- The questions worth asking a potential development partner when your project sits in a regulated environment aren't primarily about which frameworks they use or how fast they can move. They're about when compliance and governance considerations enter the process. If the answer is "we bring in a compliance review once the build is done," that's usually a sign that the regulatory layer will be treated as an obstacle rather than an input. At Digital Marmalade, regulated requirements come into a project at the brief stage — shaping the data architecture, the content model and the design approach before any code is written. That's what keeps compliance from becoming a problem you solve after the fact. If you're starting a project in a regulated environment, [get in touch](../../contact) and we'll talk through what that looks like in practice. [ Back to news ](/news) September 2026 ### [ Why We Built Our Own CMS ](https://www.digitalmarmalade.co.uk/news/why-we-built-our-own-cms) Read more September 2026 ### [ How a Digital Brand Stays Itself Since 2001 ](https://www.digitalmarmalade.co.uk/news/how-a-digital-brand-stays-itself-since-2001) Read more September 2026 ### [ Designing Digital Products for Children: What Changes ](https://www.digitalmarmalade.co.uk/news/designing-digital-products-for-children-what-changes) Read more Allow cookies