How to Choose a Development Partner for a Regulated Workflow

Choose a development partner for regulated work on evidence they have delivered under the same regime, not on a general claim of compliance experience. Ask who on the team owns regulatory questions, how they handle an audit request mid-project, and what their data processing terms actually say before you shortlist.

Compliance requirements do not slow a project down when they are established early. They are expensive when discovered late, because they force rework across authentication, logging and data handling simultaneously.

Key takeaways

• Same regime, not adjacent: Health, finance and public sector obligations differ substantially; experience in one does not transfer cleanly.
• Ask who owns it: A named person accountable for regulatory questions, not a general assurance.
• Read the processing terms first: Sub-processors, breach notification, data residency and deletion belong in the contract, not in a later addendum.
• Establish constraints before scope: Requirements found after build cause the most rework.

Ask for delivery under your specific regime

"We have compliance experience" covers a wide range. Health data under GDPR, financial services obligations, public sector procurement and medical device software each impose different requirements, and competence in one does not imply competence in another.

Ask for a project delivered under the same regulation you are subject to, and for specifics: what constraints it imposed on the architecture, what they had to document, and what an auditor asked for. Partners who have genuinely done this will describe the evidence they had to produce. Partners who have not will describe their security practices, which is a different thing.

Establish the four constraints before scoping

Domain discovery is the partner's ability to understand the regulated work itself — the clinical, financial or operational process — well enough to design software that fits it rather than obstructs it.

Data boundaries are what data may be collected, where it may be stored, who may access it, how long it is retained and when it must be deleted. In the EU, health data is a special category with stricter obligations, and residency may be constrained.

Evidence is what the system must be able to prove: who did what and when, what version of a rule applied, and how a decision was reached. Audit logging designed in at the start is straightforward; retrofitted, it touches everything.

Change control is how changes are proposed, tested, approved and recorded, which in some regimes is itself regulated.

Read the data processing terms before shortlisting

The contract matters more here than in ordinary software work. Confirm each candidate's position on:

• Which sub-processors they use, and whether you must approve new ones
• Breach notification timelines and what they commit to
• Your audit rights over their processes
• Where data is stored and processed, and whether that can change
• Retention and deletion, including in backups
• What happens to your data when the engagement ends

A partner who has worked under regulation will have these documented already. One who treats the request as unusual is telling you they have not been asked before.

Name who is accountable for regulatory questions

Ask which individual on the delivery team owns compliance decisions, and what happens when a requirement is ambiguous. The workable answer is that the partner raises it, you decide with your own legal or clinical advisor, and the decision is recorded.

Be cautious of partners who volunteer confident interpretations of regulation. Your obligations are yours, and a supplier who assures you something is permitted without reference to your advisors is taking a risk on your behalf that they will not carry.

For a related planning problem where role and access design dominate, see what discovery should deliver for a multi-role platform.

Sequence compliance work first, not last

The reason regulated projects overrun is almost never the regulation itself. It is that requirements arrive after decisions have been made.

Access control, audit logging, data residency and retention should be settled before the first release is scoped, because each one shapes the architecture. Adding role-based access to a system that assumed every user could see everything is one of the most expensive retrofits available, and it usually forces rework on every screen.

Ask each candidate how they would sequence this. A partner who puts compliance discovery in the first two weeks has done it before.

Test with a bounded first phase

Where possible, start with a paid discovery covering the regulatory constraints and one workflow. It produces a document you can take to your advisors, and it shows you how the partner handles the part of the work most likely to cause trouble.

It also reveals whether they will tell you something inconvenient. In regulated work, a supplier who agrees with everything you propose is a liability rather than a convenience.

Related guides

• Alongside How to Choose a Development Partner for a Regulated Workflow, continue with Workforce Management App: Mobile, Web, and Admin Scope.
• Alongside How to Choose a Development Partner for a Regulated Workflow, continue with Workforce Visibility: Benefits, Risks, and Responsible Metrics.

If the work prompted by How to Choose a Development Partner for a Regulated Workflow leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Industry Platform.