It usually starts with a sentence that sounds harmless: it is just a form. On screen, it is. Someone types in some details, someone else signs them off, and anyone who has moved a process from paper to digital has done it before. The video above is the full walkthrough. This is the written version, with the four things to do this month at the end.
What the Audit Asks
That familiarity is the trap. It makes the product look like any other business process: map it out, build the form, done in two weeks. Eighteen months later, someone sits down to audit you, and they do not ask about the form. They ask for three things:
- Who opened this record in March.
- Whether anything in it changed after it was signed.
- Proof, from outside your own systems, that you were scanning for vulnerabilities and patching them, month after month.
None of those is a feature you forgot. Each one is a decision you made, or did not make, before you started building.
What Can Wait, and What Cannot
Some compliance work you can always catch up on. Start it next month or next year and you will be fine. Some of it you never can, because it is about the past: it only counts if it was already running when the thing happened.
You can put a lock on the door tomorrow. You cannot write down who came in yesterday.
So the useful question is not “what do we have to comply with?” That list is long, and it will not tell you what to do first. The useful question is which of these you cannot catch up on.
You can catch up on these:
- Multi-factor login
- Password rotation
- Background checks on the team
- Monthly dependency reviews and vulnerability scanning
- Written policies and a tested recovery plan
All of it is real, and you will need every one. None of it has to exist before you write your first line of code.
One catch, and it is the same idea. You can start any of these tomorrow, but the proof that you have been doing them starts tomorrow too. The control is cheap to catch up on. Its history never is.
And here is the part a compliance consultant will not lead with: this list is most of what lands on your desk in week one. It is visible and satisfying to tick off, and it was never the part at risk.
These have to be running before real data arrives:
- Records that are never overwritten
- A trail of every read, write and export
- Encryption down to individual fields
- Separation between clients
Four Things to Build First
Each of the four is cheap on day one and either very expensive or close to impossible later.
Never Overwrite, Never Delete
In a normal product, editing a field replaces the old value. In a regulated one, the old value is evidence. So you do not overwrite and you do not delete: every change is a new row with a name and a timestamp, and deleting is a flag, not a removal.
You can switch to that model tomorrow. What you cannot do is get back the values you already wrote over. No migration brings them back.
What about the right to be forgotten? A person can ask you to erase their data, but under GDPR Article 17 that request does not reach records you are legally required to keep, or what you need to defend yourself later. Your duty to document what you did outranks it.
It is a window, though, not forever. When the retention period ends, keeping the data stops being a duty and deleting it becomes one. So you need two capabilities, not one: an immutable record, and a way to find and destroy one person across all of it, on a schedule. Most teams build the first and never the second, and pulling one person out of an append-only system that was not designed for it is a project of its own.
Log Every Access
This is the clearest thing you cannot catch up on. Every read, every write, every export, every failed login: who, what, when and from where.
An audit does not ask what your system does. It asks what it did, in March, to this record, by this person. With AI, building the trail is less than a week of work. But it starts recording on the day you build it, so if your logging began in the autumn, there is no answer about March, and no way to make one now.
“We don’t know” is what fails an audit. Not a weak control. No answer at all.
Encrypt the Fields
Everyone plans for encryption in transit and at rest. The part teams skip is individual columns: the name, the ID number, the diagnosis, encrypted as fields, so that reading the database is not the same as reading the data. The same applies on the device if your app works offline.
You can add this later: migrate, re-encrypt, and absorb a painful project. What you cannot fix is the past. Every backup taken before the migration still holds the data in the clear, and so does every log line where a developer printed a record while chasing a bug. Encryption fixes today forward. The best you can do for the past is keep it in cold storage and let a retention policy age it out.
Separate Every Client
This is the expensive one. Each client’s data lives in its own space with nothing crossing, which means every query, every join, every background job and every report carries that boundary.
Building for one client first is easy. Adding the second one later is not a feature, it is a breaking change: you edit every path in the system that touches data, and hope you found them all. And when you are done, you still cannot prove the boundary held before you built it.
Developers Without Real Data
On most regulated engagements, your developers will not be allowed near real data, and that changes how every bug gets fixed.
Usually it is the client’s contract that says so: the data does not leave the region, and often it does not leave their environment at all. People assume this is HIPAA. It is not, because HIPAA has no residency rule. Other rules do exist around it. Since April 2025, a US Department of Justice rule has restricted bulk transfers of Americans’ health data to a short list of countries of concern, and banned some kinds outright. Florida requires providers using certified electronic health record systems to keep patient data in the continental US, its territories or Canada. But mostly it is the contract, and the contract is usually stricter than any of them.
So when production breaks, the engineer does not pull a copy and debug it. They work through a VPN and a screen share with someone who is allowed to look, or against a made-up dataset that has the shape of the real thing and none of the content.
Budget for it. It is not a line in a policy, it is a tax on every bug you will ever fix. And the made-up dataset, or the anonymization job behind it, is real software that someone has to build and keep current.
Automation Needs a Name
In a regulated system every action carries a person’s name, and that quietly caps what you can automate. Who approved this. Who released this. Who exported this. Not an account, a person.
About a year in, someone says the obvious thing: this step is slow and boring, automate it. Or better, have the AI do it. Then you hit the wall. Put a service account on the action and an auditor sees a robot doing work that needed judgment, and asks who authorized each one. Put a person’s name on it and that person is now answerable for something they never did and never saw.
The fix is to record three things instead of one:
actor what did it: a person, a scheduled job, an agent
on_behalf_of which person it acted for
authorization the standing permission that allowed itThat is a schema decision. If your audit table has a single user column, your automation roadmap is already capped, and nobody has told you yet.
It matters now because everyone wants agents in the workflow. In a regulated space, the limit is not what the model can do. It is whether your system can say whose decision it was.
What to Do This Month
Four things, and all of them fit inside a month.
1. Write Down Your Rules
One page, listing what you are actually under. For healthcare in the US that is HIPAA, and NIST publishes guidance on implementing it (SP 800-66). In Europe it is GDPR, plus whatever your own country adds for health data.
Check two more things while you are there. First, if your software influences a clinical decision, it may be regulated as a medical device: a separate approval process on a different timeline, and not something to discover in year two. Second, if you are under HIPAA, much of what is described above sits in the rules as “addressable,” which people read as optional. An update proposed in January 2025 would make most of it mandatory. As of September 2026 it is still a proposal, pushed to 2027. Build it now anyway. It is the cheap version of a change that is coming.
2. Start the SOC 2 Clock
If you will ever sell to enterprises, treat SOC 2 as a day-one requirement. They will ask for it, or for a security review that covers the same ground. When a healthcare platform we built started winning enterprise clients, their reviews asked for multi-factor login, credential rotation and a full audit trail, and the platform had to be hardened before it could pass.
There are two kinds of SOC 2 report. Type I says your controls exist on a given day. Type II says they worked across a period, usually around six months for a first report, and it is the one enterprises want. You cannot move those dates backwards, so the clock starts the day you switch the controls on, not the day you decide you want the report. It is the logbook again: you cannot catch up on a period nobody was watching.
3. Insure Both Sides
Whoever builds the product should carry professional indemnity, for getting the work wrong, and cyber liability, for a breach. Underneath the insurance sits a contract: a Business Associate Agreement (BAA) in the US if they touch patient data, a data processing agreement in Europe. The contract makes them liable. The insurance makes that liability worth something, because a liability clause against an uninsured company is a piece of paper.
Get your own cover too. The regulator comes to you first, whoever caused it. And if a vendor does not know what a BAA is, you may already have your answer.
4. Ask What They Have Been Through
Not what your dev team knows. What they have been through. Ask:
1. Has any project of yours been through a SOC 2 or an ISO audit?
2. What came back?
3. What did you have to fix?
4. What has changed since then?A team that has done it answers straight away, and do not worry if the answer includes something embarrassing. A team that has not will tell you about its security practices. Those are very different answers.
The Takeaway
None of this is hard. It is just early.
Everything you cannot catch up on has to be running before you need it. Everything else can wait until Monday. Many teams do it the other way around: the visible half first, because it feels like progress, and the other half in a room with an auditor in it.