Security advice aimed at growing businesses tends to arrive as a 200-item checklist that nobody completes. Here is the shorter version: the controls that stop the attacks that actually happen.
1. Multi-factor authentication, everywhere it is offered#
The single highest-value change you can make. Most account compromise is a stolen or reused password, and MFA stops nearly all of it.
Start with email, then cloud accounts, then anything holding money or customer data. Email first, because email resets everything else.
2. Stop sharing accounts#
Shared logins mean you cannot tell who did what, and you cannot remove access when someone leaves. Individual accounts with appropriate roles cost slightly more and save you during an incident or an audit.
3. Backups you have actually restored#
Everyone has backups. Far fewer have ever restored one. An untested backup is a belief, not a control.
Test a restore. Write down how long it took. That number is your real recovery time, and it is usually longer than people assume.
4. Patch the things facing the internet#
Servers, VPNs, firewalls, CMS installations, plugins. Automated attacks scan for known vulnerabilities constantly and do not care how small you are.
A patch schedule that someone owns beats a plan that nobody runs.
5. Least privilege, especially in the cloud#
Most cloud breaches we read about involve credentials with far more access than the task required. If a service only needs to read one storage bucket, it should not have administrator rights on the account.
6. Know what you have#
You cannot secure an inventory you do not have. List the systems, who owns each one, what data it holds, and what it connects to.
This is unglamorous and it is the foundation everything else sits on.
7. Review code before it ships#
Most application vulnerabilities are introduced in normal development, not by exotic attacks: input that is not validated, queries built by string concatenation, secrets committed to a repository, authorisation checked in the UI but not on the server.
A second pair of eyes before release catches a surprising proportion of it.
8. Then, and only then, test it#
Penetration testing is valuable — after the basics are in place. Testing a system with no MFA and unpatched servers produces a report that tells you what you already knew.
When you do test, insist that the report is actionable: severity, reproduction steps, and a specific recommended fix per finding. A scanner dump with hundreds of low-severity items is not a security assessment; it is homework.
What "actionable" should look like#
For each finding you should be able to answer: how bad is it, how do I reproduce it, and what exactly do I change? If a report does not let your engineers act without a follow-up call, it was not written for you.
How we handle this#
Our security division reviews every release before it ships, and testing is always scoped and authorised in writing before it begins. Independent penetration testing is a separate engagement from development work, deliberately.
If you want an honest read on where you actually stand, get in touch.