The uncomfortable pattern in incident write-ups is how ordinary the entry points usually are: an account without multi-factor authentication, a device missing a patch that had been available for months, a service account with far more rights than its job needed, or a backup that had never been restored from. None of those are solved by buying something.
None of this argues against security tooling. Detection and response platforms earn their place, and there is a point in an organisation's growth where they become necessary. The argument is about sequence. Tooling layered on top of weak fundamentals produces alerts about problems you could have prevented, and the four controls below are the ones we would want in place first.
1. Multi-factor authentication, applied where it matters most
Passwords leak. They are reused across services, captured by phishing pages that render perfectly on a phone screen, and bought in bulk. Multi-factor authentication does not make an account unbreakable, but it removes the single most common path in: a valid username and password in somebody else's hands.
Where organisations get this wrong is scope. MFA gets enabled for the executive team and the IT department, and stops there. The gaps that remain are usually the ones worth closing first:
- Every account with administrative rights, without exception — including the break-glass accounts, which need a documented, tested access procedure rather than an exemption.
- All remote access. VPN, remote desktop gateways, and any management interface reachable from the internet.
- Service accounts and shared mailboxes, which frequently cannot take a second factor and therefore need compensating controls: restricted sign-in locations, conditional access policies, or removal in favour of managed identities.
- Standard users, phased sensibly. Blanket enforcement without communication generates a support queue and a workaround culture.
The method matters too. App-based approval and hardware keys resist interception in ways SMS codes do not. If SMS is the only practical option for part of the user base, treat it as a stepping stone rather than the destination, and prioritise moving privileged users off it first.
MFA also has a failure mode worth planning for: approval fatigue. A user who receives repeated prompts will eventually approve one to make it stop. Number matching and limits on repeated requests address this, and are worth enabling at the same time as the policy itself.
2. Patch and vulnerability management as a routine, not a project
Patching is unglamorous, and it is where a great deal of real exposure lives. The problem is rarely that an organisation disagrees with patching. It is that patching is treated as something done when there is time, rather than a scheduled operational routine with an owner.
A workable programme covers more than Windows updates on laptops:
- Server and client operating systems, including anything still running an unsupported version — which needs a documented plan, not another exception.
- Applications, especially browsers, PDF readers, Java runtimes and line-of-business software that updates outside the operating system's mechanism.
- Network devices: switches, routers, wireless controllers and access points.
- Firewalls and remote access appliances. Internet-facing management planes attract attention quickly once a vulnerability is public.
- Hypervisors and the management layer around them, which are often the longest-uptime systems in the estate for exactly the wrong reasons.
- Endpoint security agents themselves, which are software like anything else.
The cycle that works is identify, prioritise, apply, verify. Identification needs a source of truth — an asset register that reflects reality, and scanning that covers the whole estate rather than the part that is easy to reach. Prioritisation should weigh exposure, not just severity score: an internet-facing system with a medium-rated flaw often deserves attention before an internal one rated critical.
Verification is the step most often skipped. A patch that failed to apply, or a server that never rebooted, looks identical to a patched one on a report unless somebody checks. Closing that loop is what turns patching from an activity into a control.
3. Least privilege and access control
Access tends to accumulate. Somebody moves between roles and keeps both sets of rights. A contractor is granted administrative access for a migration and it is never withdrawn. A service account is given domain administrator because that made the installer work on a Friday afternoon.
Each of those is individually defensible and collectively serious, because they determine how far an intruder gets after the first compromise. The difference between one compromised laptop and a domain-wide incident is usually the rights attached to the account that was on it.
- Base access on roles rather than individuals, so that joining a team grants a known set of rights and leaving it removes them.
- Separate administrative identities from day-to-day accounts. Nobody should read email from an account that can reconfigure the directory.
- Remove standing local administrator rights on endpoints. Where elevation is genuinely needed, make it time-bound and logged.
- Run a real joiner, mover and leaver process with HR, not just an IT ticket. The mover case is the one that quietly builds up entitlement.
- Review access on a schedule, with the business owner of each system confirming who should still have it. IT cannot answer that question alone.
This is also where POPIA obligations and security work start to overlap usefully. Being able to show who had access to personal information, when, and on what basis, is both an access control question and a compliance one. Doing it once serves both.
4. Backup and recovery, tested rather than assumed
Security is not only about keeping attackers out. It is about the organisation's ability to carry on when something gets through. Ransomware made this concrete: the question stopped being whether data was backed up and became whether it could be restored, at what speed, and whether the backups themselves could be reached and encrypted by the same intruder.
- Agree recovery objectives before designing the solution. How much data the business can afford to lose, and how long it can afford to be without a system, are business decisions that determine the technical design.
- Keep copies that cannot be altered or deleted within their retention period. Immutability is what stops a backup platform becoming another target.
- Separate backup credentials from production identity. A backup system that trusts the same directory as everything else shares its fate.
- Keep a copy off the production platform and, where the data warrants it, off site.
- Test restores on a schedule, including a full system rather than a single file, and record how long it actually took.
A restore test is the only evidence that a backup works. Everything else is a green tick on a job that has never been asked to do the thing it exists for. The first time a recovery procedure is exercised should not be during an incident, with the executive team watching.
Where this leaves the tooling conversation
These four controls share a characteristic: none of them are a purchase. They are operational disciplines with owners, schedules and evidence. They are also the controls most often cited in insurance questionnaires, client security reviews and procurement due diligence — which means getting them right tends to be commercially useful as well as technically sound.
Once they are consistently enforced, security tooling becomes a genuine force multiplier rather than a compensating control. Detection is more meaningful when the noise floor is lower. Monitoring is more useful when the estate is known. The sequence is what makes the investment work.
Security maturity is built from consistent operational controls, not from the number of security products deployed.
Key takeaways
- Enforce MFA on every privileged account and all remote access first, then extend to the wider user base in a planned way.
- Treat patching as a scheduled routine with an owner, covering network devices, firewalls and hypervisors — not only desktops.
- Separate administrative identities from daily accounts, and review access with the business owner rather than inside IT alone.
- Agree recovery objectives with the business, keep immutable copies, and test a full restore on a schedule.
- Introduce detection and response tooling after these controls are consistent, not instead of them.
