The short answer
Regulated builds differ less in features than in what has to be provable. Assume you will need to show who did what and when, on what data, under which version of the rules. Design for that at the start, because it shapes how records are stored.
The single most expensive mistake is a system that overwrites rather than versions. Once history is gone, no amount of later work brings it back.
What regulation usually adds
- An audit trail that cannot be edited
- Access control fine enough to show who could see what
- Data retention and deletion rules that are actually enforced
- Evidence that a control operated, not just that it exists
- Change management showing what was deployed and when
- The ability to reconstruct a decision made months ago
The last one is the demanding requirement. It means storing not just the outcome but the inputs and the rules in force at the time.
Version, never overwrite
Operational databases are built to hold current state. Regulated systems need history. Where a record changes, keep the previous version with who changed it and when.
This costs storage, which is cheap, and it costs some design effort, which is not. It is the difference between answering a regulator's question in an hour and answering it with an apology.
Evidence that a control worked
| Requirement | What the system must produce |
|---|---|
| Approval before an action | Who approved, when, and on what version |
| Segregation of duties | Proof the same person did not do both |
| Checks performed | A record per check, not a policy document |
| Access restricted | Who had access on a given date |
| Data deleted on schedule | Evidence it happened, not that it was scheduled |
Auditors ask for the right column. A policy saying the control exists is not evidence that it operated.
Get the requirements from the right people
- Your compliance function owns the requirements, not the developers.
- Get them written down before the build, not interpreted from a regulation.
- Where a requirement is unclear, resolve it with your adviser rather than guessing.
- Record which requirement each design decision satisfies.
- Have compliance review the design, not just the finished system.
Engineers interpreting regulation on their own is a common and avoidable failure. They will make reasonable choices that turn out not to satisfy the actual obligation.
Be honest about what software cannot do
Software can enforce a control and produce evidence. It cannot decide what your obligations are, and it cannot substitute for the judgement your compliance function exercises.
Any supplier who tells you a system will make you compliant is overselling. What it can do is make compliance demonstrable, which is valuable and different.