Security Work for a Company Without a Security Team
The basics done properly, the compliance you can prove, and an incident plan short enough that people read it.
Almost nothing that happens to companies your size involves a clever exploit. It is a reused password, an invoice email that looked right, an admin account belonging to someone who left in March, or a backup nobody ever restored. The work that prevents those is unglamorous, finite, and mostly done once.
What we do first
- Identity. Multi-factor on every account that can move money, change DNS, deploy code or read customer data. This single item removes most of the realistic risk.
- Leavers. A list of who has access to what, and a process that removes it the day someone goes. Dormant accounts are the quietest way in.
- Backups, restored. We perform a restore, time it, and write down what was lost. Until that happens you have files, not a recovery plan.
- Least privilege on the systems that matter, so one compromised account is an incident rather than a catastrophe.
- Secrets out of the places they drift into: repositories, shared documents, chat history.
On the software we build
- Dependency updates as a scheduled habit rather than an emergency, because a framework reaches end of life every two to three years.
- The boring web basics: input validation, access checks on every endpoint rather than only in the interface, sensible session handling, security headers.
- Access control enforced where the data is read, not in the screen that displays it. A hidden button is not a permission.
- Logs that let you answer what happened, kept long enough to be useful and short enough to be lawful.
Compliance you can show
For most companies the requirement is evidence, not certification: a record of what personal data you hold and why, the agreements with the processors you use, a retention rule that is actually applied, and a plan for a breach notification you hope never to send. We produce those as documents you own, in plain language, rather than a policy PDF that contradicts what the system does.
- 1-2 weeks for the audit and a prioritised fix list
- 1 page incident plan, because a long one is not read
- 0 risks we hide from you
Security that only exists in a policy document is a story you are telling yourself.
Frequently asked questions
Are we too small to be a target?
Nothing that reaches you was aimed at you. Credential stuffing, phishing and automated scanning are indiscriminate: they find whatever answers. Being small does not lower the odds, it lowers the chance that anybody was watching when it happened, which is why the first thing we look at is whether you would even know.
Do we need a penetration test?
Not before the basics are in place. A pentest on an environment without multi-factor, patching or tested backups produces a report confirming what you already suspect, at a price. Once the fundamentals hold, a focused test on the application that handles money or personal data is worth doing, and we will scope it honestly rather than sell it by default.
Isn't our cloud provider handling this?
They secure the infrastructure; you remain responsible for your accounts, your permissions, your data and your code. That split surprises people during an incident, which is the worst moment to learn it. We write down which side of the line each risk falls on, so nobody assumes it is covered.