Compliance is a design constraint, not a cleanup project

Every company that passes a SOC 2 or HIPAA audit on budget did it the same way: they designed for evidence, not for paperwork.

The pattern that fails: build the system first, discover the audit later, then spend a year retrofitting change-control, access reviews and logging into systems that were never designed to produce them. The auditor is the customer you can't defer.

The pattern that works is how I worked inside regulated banks and fintechs: define the control set early (access, change management, incident response, vendor risk), then make the system generate the evidence — tickets that tie deploys to approvals, access reviews as scheduled work, a risk register the board actually reads.

Practical consequence for a small company: your compliance budget is mostly architecture decisions made before you scale — a logging standard, an SSO rollout, a written RPO/RTO with a tested restore. Those decisions age well; a policy binder written in 2026 for the audit in 2027 does not.

If you're facing a compliance deadline, the question for your next architecture review is not "how do we pass the audit?" — it's "what does this system have to prove, and is it able to?"