Security work is mostly unglamorous. It is reading carefully, asking who can reach what and why, and writing the answers down so the next person does not have to guess.
The failures that cost businesses money are rarely ingenious. They are an old credential nobody revoked, a permission granted for one afternoon three years ago, a dependency that stopped being maintained without anyone noticing. Finding those is a matter of diligence rather than cleverness.
What the work involves
- Review. The code, the infrastructure, the access model, and the paths data actually takes through the system.
- Access. Who can reach production, by what route, and what becomes of that access when they leave.
- Data. What is held, where it rests, for how long, and on what basis it is held at all.
- Hardening. Closing what should be closed, without rendering the system unusable for the people who need it.
- Dependencies. What the system inherits from other people's code, and how that is kept current.
- Documentation. The written record that answers an auditor, an insurer, or an acquirer without a scramble.
Most breaches are not clever. They are something obvious that nobody was responsible for.
Written to be read by outsiders
The output is a findings document ordered by consequence rather than by how interesting each item was to discover. Every finding states the risk in plain terms, what exploiting it would actually require, and what we recommend doing about it. Where something is a reasonable risk to accept, we say so, and we say why.
It is written on the assumption that someone outside your business will read it eventually: a buyer's technical adviser, an insurer, a regulator.