A security review at the end of a project can find missing headers, weak configuration and unvalidated input. What it cannot find — because it is too late to change — is an architecture where the permission model does not match how the organisation assigns responsibility, or where sensitive data was denormalised into places it should never have reached.
The permission model is a design artefact
In systems holding clinical, financial or personal data, the permission model is one of the most consequential design decisions in the project. It determines what each role can see, what the audit trail can prove, and whether staff will work within the system or around it.
It has to be built from actual organisational responsibility, which means talking to the departments rather than reading the org chart. And it has to be enforced in one place — a permission check duplicated across the application is a permission check that will eventually disagree with itself.
Cryptography is not a feature you enable
Applied cryptography inside business systems — signing documents, handling tokens, exchanging data securely with an external authority — has a lifecycle. Keys are issued, rotated and revoked. Tokens expire. Credentials need somewhere to live that is not a configuration file in the repository.
- Where do credentials live, and who can read them?
- What happens when a token expires mid-operation?
- How is rotation performed without downtime?
- What is logged, and does the log itself now contain something sensitive?
The last question catches more teams than it should. Diagnostic logging added during integration work is a common way for sensitive data to end up somewhere it was never meant to be.
Integrations are where trust boundaries actually sit
Every integration is a trust boundary. Data crossing it should be validated on the way in regardless of the source’s reputation, and what is exposed on the way out should be the minimum the other side needs. This is straightforward to design in and awkward to retrofit, because by then other systems depend on the current shape.
Security has to survive maintenance
Systems are not breached in the state they were delivered in. They are breached after two years of changes made under time pressure by people who were not in the original design conversations. That is why the security model has to be simple enough to be understood quickly, enforced centrally, and documented in a way that makes the intent obvious.
A complicated security design that is correct at launch is worse than a simpler one that stays correct for five years.