A security review at the end of a project finds problems at the most expensive possible moment: when the design is fixed, the deadline is close and every fix means rework. So we don't treat security as a phase. It is a set of habits that start with the first commit.
Access is modelled per record
Permissions are designed into the data model, not bolted onto screens. If a user shouldn't see a record, the API won't return it, whatever the interface does.
Security isn't a phase. It's a set of habits that start with the first commit.
Everything is encrypted, everywhere
In transit and at rest, with managed key rotation. It is a default in our project templates, not a ticket someone has to remember.
Every change is attributed
Audit logging records who did what and when, and it is queryable. The question “who changed this?” should take seconds to answer.
Backups are tested, not assumed
Automated backups only count if a restore has actually been rehearsed. We schedule restore drills, and we write down how long they took.
Dependencies are watched
Automated scanning flags vulnerable packages, and we keep a patch cadence. Most real-world breaches start with a known, unpatched dependency.
Environments stay separate
Development, staging and production are isolated, and production data does not leak into the others. It is the simplest rule on this list and the one most often broken.
