The classic model — build the system, then call the auditor — consistently produces the same result: a report with 40 findings, five of which cannot be resolved without architectural change.
What we move to the start
Threat modelling
A three-hour session during the architecture phase, where we ask systematically: who would want to attack this system, what would they gain and where would they get in. The output is a list of controls, not a compliance document.
The audit model
Which events must be recorded, how long they are kept, who can read them. It is far cheaper to decide that before writing the first line of code than to add logging to a system already live.
Data classification
Not all data carries the same sensitivity. When you know from the start which fields are special, encryption, log masking and retention rules become design decisions rather than remediation.
What we automate
- Static analysis with security rules, on every pull request
- Daily dependency scanning for known vulnerabilities
- Automated detection of secrets leaked into the code
- Tests confirming that authorisation rules do what they should
What is left for the audit
The external audit keeps its role, but becomes a confirmation rather than a discovery. Across the last five projects delivered with this process, independent audits reported an average of three minor findings and no critical ones.
The additional cost over the classic approach is roughly 4% of the project budget. The cost of fixing an architectural problem found after launch is usually an order of magnitude higher.