%203fs.png){kind=logo}
I am a CTO, so I will start with a claim that can be unpopular in my own profession: in regulated software, the hard part is almost never the code. The hard part is everything the code has to be able to prove about itself, eighteen months later, to somebody who was not in the room when it was written.
When a client in healthcare or financial services asks how we approach compliance, they are often expecting an answer about certificates. They want to know which standards we hold. That is a reasonable question, but it is the wrong one to lead with. A certificate tells you that a system passed an audit on a particular day. It does not tell you whether the team building your software treats compliance as part of engineering or as a document produced at the end to satisfy a procurement checklist. Those are different disciplines, and only one of them survives contact with a regulator.
There is a common delivery model in which software is built first and made compliant afterwards. A team ships the features, and then a separate effort begins: writing the documentation, retrofitting the access controls, reconstructing the audit trail, and explaining architectural decisions that were made months earlier for reasons nobody recorded at the time.
This model fails quietly and expensively. The reason is that many compliance requirements are not features you can add late. They are constraints on how the system is built in the first place. Data minimisation under GDPR is not a setting you switch on before an audit; it is a decision about what the database is allowed to store, made before the schema exists. An audit trail that will satisfy a financial regulator is not a log file you generate retrospectively, but an architectural commitment to capturing specific events, immutably, from the first line of code. By the time the feature is built, the cheapest moment to get these decisions right has already passed. What follows is rework, and rework in a regulated system is not just slower. It reopens questions the client believed were closed.
The discipline that distinguishes regulated software engineering is unglamorous, and it is mostly about what the team does before and during the build rather than after it.
It means threat modelling a feature before it is written, so that the security properties are designed in rather than discovered in a penetration test. It means treating documentation as a deliverable with the same status as the code, because in a regulated industry, an undocumented system is, for practical purposes, a non-compliant one. It means designing data flows so that personal or clinical data can be located, restricted, and explained, because at some point, someone will have a legal right to ask where their data is and what was done with it. And it means writing systems on the assumption that an auditor will eventually trace a single transaction end to end, and that the architecture should make that easy, rather than archaeological.
None of this is exotic engineering. It is ordinary engineering, performed with the constant awareness that the system will have to account for itself to someone outside the team. That awareness is the actual deliverable. It is also the thing that does not show up in a rate card.
The reason this matters at the point of selecting a partner is that the discipline I have described is not a skill you can demonstrate on a trial task, and it is not one a team can adopt in the first month of a regulated project because the client has asked for it.
It is closer to a habit than a capability. A team develops it by spending years building systems where an access control decision was always also a compliance decision, where documentation was never optional, and where someone external could and did come back later and ask the system to justify itself. Teams that have worked this way stop treating compliance as a separate workstream, because in their experience, it never was one. Teams that have not will tell you, sincerely, that they can do regulated work, and they are not lying. They simply have not yet had the experience of a feature they were proud of being the reason an audit failed. That experience is what changes how engineers think, and it cannot be transferred onto a project by contract.
In the regulated end of the Polish software sector, this way of working has become close to the default rather than a specialism. I am stating that as a practitioner observation rather than a statistic: it is what I see in the teams we build and in the engineers who join us from elsewhere in the market. They tend to arrive already expecting that compliance is part of the engineering, not a department that arrives later. That expectation is what a regulated client actually buys, even when the conversation starts with a question about certificates.
One practical consequence of working this way is that the conversation with a regulated client starts further along.
When a team has delivered under ISO 27001 and has built systems subject to GDPR, the discussion about a new HIPAA or DORA project does not begin with explaining what an information security management system is, or why breach notification timelines constrain architecture. It begins with the specifics of this client's regulator and this client's risk posture. The shared vocabulary is already there. The engineers do not need to be taught that an access control decision is also a compliance decision, because in the environment they work in, it always has been.
This is also why the certificate question, the one clients often lead with, is the wrong place to start. A certificate is evidence that a discipline existed on the day of the audit. What a regulated client actually needs is a team for whom that discipline is the default working state between audits, when nobody is checking. That is harder to put on a procurement form, and it is the thing that most directly determines whether the software survives its first regulatory examination.
For a CTO or CIO evaluating a partner for regulated work, there is a question that tends to reveal the answer quickly. Ask how the team handles a compliance requirement that emerges mid-project, after the architecture is largely set.
A team that treats compliance as a property of the engineering will describe how they trace the requirement back into the design, what it forces them to reconsider, and how they document the change so it holds up later. A team that treats compliance as an end-stage activity will describe a process for adding it on. The difference in those two answers is the difference between a system that passes its audit and a system that has to be partially rebuilt to do so. In regulated industries, that is rarely a question of engineering talent. It is a question of whether the discipline was there from the first decision, or whether it arrived with the deadline.
