Most incidents are not clever. They are a door left open
Least-privilege access. Secrets kept out of the repository. Storage that is not public by accident. Logs that outlive the incident, and a backup somebody has actually restored from.
In short: We work through the five things that account for most real incidents: access, secrets, storage, logging, backups. Then we restore one of your backups into a clean environment and time it, because that number is your actual worst-case downtime.
The unglamorous list is the one that matters
Security spending tends to follow the interesting threats. The incidents that actually happen to companies our size are duller than that. An access key in a public repository. A storage bucket someone opened for a one-off file transfer in 2023. An admin login with no second factor, belonging to a contractor who finished last spring. A database exposed to the internet because a firewall rule was widened during an outage and never narrowed again.
None of that needs a sophisticated attacker. It needs someone scanning, which is continuous and automated and costs nothing. So the work we do first is the work that closes those doors, in order of what an outsider could reach today. It is not exciting. It is the part that changes your odds.
Access scoped to the job
Roles per function rather than one shared administrator. Multi-factor on the accounts that can change billing or delete data. A removal step that runs when somebody leaves.
Secrets outside the repository
A managed secrets store, environment-scoped, read at run time. Plus a scanner on pull requests, because history keeps whatever gets committed even after it is deleted.
Storage private unless you said otherwise
Public access blocked at the account level, so an individual bucket cannot be opened by accident, and an alert if that setting ever changes.
Backups that have been restored
Copies held where the production credentials cannot delete them, and a restore that has been performed by a person, start to finish, with a stopwatch running.
An untested backup is a hope
A green tick in a backup console tells you a job finished. It does not tell you the file is readable, that the schema matches the application you would restore it into, that anyone has the key to decrypt it, or how long the process takes when the person doing it is tired and under pressure. Those are separate questions and each of them has ruined somebody’s week.
So we restore. Into a clean environment, from the backup you already hold, and we time the whole thing. What comes out is a number: this is how long you would be down, and this is how much data you would lose. Say it out loud in a room with the people who run the business. Sometimes the number is fine and everyone relaxes. Sometimes it is four hours longer than anyone assumed, and now there is a real conversation about what to change.
One more thing worth checking. If the same credentials that run your application can also delete your backups, you do not have backups so much as a second copy of the same risk.
Logging that survives the incident
Logs answer the questions you get asked afterwards. What was taken, when did it start, whose credentials were used, is it still happening. Answering those needs logs from before the event, which means retention has to be longer than the gap between something happening and somebody noticing. That gap is usually measured in weeks.
It also means the logs have to be somewhere the compromised environment cannot reach. Anyone who gets administrative access can clear a log stream in the account they are standing in. Shipping audit logs into a separate account with write-only permissions is a small piece of setup that makes an enormous difference on the worst day. Then a handful of alerts on the things worth waking someone for: root account use, permission changes, public access enabled, an unusual volume of data leaving. A dashboard nobody opens is not monitoring.
Least privilege people will actually keep
Permissions that are too tight get worked around, and the workaround is always worse than what it replaced. Somebody gets full administrator on a Friday afternoon to unblock a release, and nobody takes it back. Two years later there are eleven accounts with the power to delete everything and no one can say why.
The way out is to make the correct path fast. Roles that match the jobs people genuinely do, a short-lived elevation for the rare thing they cannot do otherwise, and a review that takes twenty minutes because the list is readable. Security that is inconvenient decays. Security that fits the way the team works tends to survive the next busy quarter.
What we won’t do
We won’t hand over a 200-page findings report and leave
A long list of everything a scanner noticed is easy to produce and nearly useless. We would rather fix the handful of things that matter and give you a short ordered list of the rest, with a name and an estimate against each one.
We won’t tell you we can make you compliant
We can close technical gaps and prepare the evidence an auditor asks for. The certificate is their decision, not ours, and any agency that sells it as a checkbox is describing something else.
We won’t tighten access on a system we have not mapped yet
Revoking permissions from a service whose dependencies nobody has traced is how a security project turns into an outage. Mapping first is slower, and we will still do it that way.
When did someone last restore one of your backups?
If nobody can name the date, that is where to start. We will run the restore, time it, and tell you what your worst case actually looks like.
They earn their keep once the basics are in place. Running one against a system with public storage and shared administrator logins mostly buys an expensive list of things you could have found yourself. Close the obvious doors first, then pay someone to look for the rest.
How often should backups be restored?
Often enough that the person doing it is not doing it for the first time, and again after any change to the data layer. What matters more than the interval is that a real restore happens on a schedule you keep, and that the duration gets written down.
Is our cloud provider responsible for security?
Partly. They secure the hardware and the managed services. Configuration, access control and your data sit on your side of that line, and that is where the common failures are. The division is documented by every major provider and it is worth reading once.
Can you work with our compliance requirements?
Yes. Frameworks such as SOC 2, ISO 27001 and HIPAA map onto much of the same technical work: access control, encryption, logging, retention, tested recovery. We do the engineering and prepare the evidence. Your auditor makes the call.
