Compliance by Design: Building Requirements Into the System Itself
A procedure can instruct a user to obtain approval before releasing a record, preserve the original result, or use only calibrated equipment. It cannot guarantee that this happened. In regulated and high-consequence work, the distinction matters: a process that depends entirely on careful behaviour may be technically usable, yet still be unable to provide reliable evidence that the required control operated on every occasion.
Compliance by design means identifying the controls necessary for an intended use and making them part of the system's behaviour. This does not eliminate procedures, training or management oversight. It changes their role. The system takes responsibility for controls it can enforce consistently, while procedures address judgement, physical activities and exceptional circumstances that software cannot safely determine for itself.
The limits of procedural control
Procedures remain necessary. A calibration technician must select and connect the correct standard. A reviewer must assess whether an unexpected result is scientifically credible. An administrator must investigate a suspected account compromise. None of these decisions can be reduced safely to a simple workflow rule in every context.
However, controls such as mandatory review, segregation of duties, controlled record states and retention of historical data are often well suited to technical enforcement. If a system allows a user to mark a result as approved without the required authority, the procedure instructing them not to do so is a weak compensating control. If a released record can be silently overwritten, an audit procedure cannot restore the original information after the fact.
This is not merely a question of preventing deliberate misuse. Well-intentioned users work under time pressure, interpret instructions differently, select the wrong option, or encounter interfaces that encourage workarounds. A compliant operating process should anticipate ordinary human error rather than assume perfect execution.
Translate obligations into system behaviour
The starting point is not a list of fashionable features such as audit trails or electronic signatures. It is a clear account of intended use, applicable obligations and the risks arising if records, decisions or measurements are wrong, incomplete, unauthorised or unavailable.
Requirements should then be expressed as testable system behaviours. For example:
- A result cannot enter a released state until required review activities have been completed by an authorised role.
- The person who creates a controlled record cannot be its sole approver where segregation is required.
- A correction preserves the previous value, the reason for change, the identity of the actor and the relevant time information.
- A calibration-dependent measurement cannot be represented as valid when the associated instrument status is expired, rejected or unknown.
- Configuration changes are versioned, reviewed where necessary, and linked to the records produced under each configuration.
Each statement needs careful qualification. Whether a particular requirement applies, and how it must be implemented, depends on the governing regulation, standard, organisational procedures and intended use. Authoritative sources should be consulted for the applicable jurisdiction and domain. The engineering task is to turn confirmed obligations into unambiguous requirements, including normal operation, error handling, recovery and administrative activity.
Architecture determines whether controls are credible
Workflow controls must be supported by the underlying data model and security architecture. A user interface that hides an edit button is not an adequate control if an application interface, bulk import route or privileged database account can alter the same record without equivalent checks.
Controlled state transitions should therefore be enforced at the service or domain layer, not only in the presentation layer. Authorisation should be evaluated against a defined identity and role model. Where separation of duties is needed, the system must retain enough context to determine whether the proposed actor is prohibited from approving their own work. Interfaces, integrations and background jobs need the same policy enforcement as interactive users.
Immutable history also requires more than a log table. The design must define which events are captured, how event order is established, how timestamps are generated and protected, who can access the history, and whether retention processes preserve it for the required period. Clock synchronisation, time-zone handling and storage recovery affect the ability to reconstruct events. A timestamp with no defined source or synchronisation approach may look precise while providing weak evidence.
For measurement systems, data integrity extends to provenance. A defensible result may need links to the instrument, calibration status, method, environmental conditions, operator, source data, calculation version and review decision. Storing only the final numeric value makes later assessment difficult, particularly when an investigation must determine whether a change in result arose from the device, processing logic or human action.
Validation must challenge the control, not just the feature
A feature is not validated merely because a test confirms that it works in the expected path. Testing should show that the control resists foreseeable attempts to bypass it and behaves safely when dependencies fail.
For a release workflow, this includes attempts to release through an integration endpoint, approval after a role is removed, concurrent edits during review, network interruption during signature capture and restoration from backup. For traceability controls, it includes migration of historical records, export and import processes, retention events and verification that displayed history corresponds to underlying data.
Requirements traceability is important here. A controlled requirement should link to design decisions, implementation evidence, risk controls and verification results. This supports impact assessment when software, infrastructure or operating procedures change. Without it, change control can become an assessment of visible screens rather than the actual control structure.
Operational evidence matters as much as pre-release testing. Access reviews, backup restoration exercises, monitoring of failed integration events and periodic assessment of configuration changes all provide evidence that controls remain effective in use. Validation establishes a justified basis for use; it does not remove the need to operate and maintain the system in a controlled state.
Procedures still matter, but in the right place
Some organisations respond to uncertainty by writing increasingly detailed procedures around software limitations. This can create a fragile system in which compliance depends on users remembering exceptions, reviewers manually comparing records and administrators applying controls outside the application.
A stronger design assigns each control to the most dependable location. Software enforces deterministic rules. Procedures govern activities requiring professional judgement or interaction with the physical world. Training ensures users understand both. Oversight examines evidence, exceptions and trends rather than attempting to compensate continuously for avoidable design weaknesses.
This approach does not make compliance automatic. Suitability depends on intended use, validated operation, governance, personnel and the broader technical environment. It does make important controls more repeatable, more difficult to circumvent accidentally and easier to demonstrate during review. In regulated systems, those properties are not administrative refinements. They are part of the engineering required to establish that records and decisions can be trusted.