The most common IT security mistakes growing businesses make

Why growing businesses are disproportionately exposed

SMEs sit in an awkward middle ground. They're large enough to hold data that's worth stealing – customer records, payment information, commercially sensitive contracts – but rarely have the security infrastructure that larger organisations take for granted. No dedicated security team. No formal patch management process. IT decisions made by whoever happens to be most technically confident, not by people with security expertise.

Attackers know this. Automated scanning tools probe millions of IP addresses continuously, looking for known vulnerabilities in unpatched software. Credential stuffing attacks test stolen username and password combinations across hundreds of services. Phishing campaigns are sent at scale with minimal effort. None of this requires a sophisticated attacker with a specific target in mind – it's opportunistic, and growing businesses are often the easiest targets available.

The good news is that the most commonly exploited weaknesses are also the most straightforward to address. You don't need a six-figure security budget to close them.

Weak access controls and credential management

Poor credential management is one of the most consistent findings in security audits of growing businesses. The problems are predictable: default passwords left unchanged on network equipment, shared login credentials for systems that should have individual accounts, and – critically – no offboarding process that removes access when someone leaves.

That last one is more common than it should be. A former employee whose account remains active weeks or months after they leave represents a genuine risk – whether or not you trust that individual. Their credentials may have been compromised without either of you knowing.

The fix isn't complicated. Audit active accounts regularly. Ensure every user has their own credentials for every system they access. Remove access on the day someone leaves, not when someone remembers to do it. Use a password manager to generate and store strong, unique passwords rather than relying on people to create their own.

Neglected patching and software updates

Unpatched software is one of the primary attack vectors in data breaches. When a vulnerability is discovered in a piece of software – a known CVE (Common Vulnerability and Exposure) – details often become public before the patch is widely applied. That window, sometimes days but often weeks or months for businesses without a patching process, is when attacks happen.

Ad hoc patching – relying on individuals to run updates when they think of it – doesn't work at scale. Patches get missed, endpoints fall out of date and the exposure compounds over time.

A structured patching cycle matters. Monthly is a reasonable baseline for most businesses, with critical patches applied more urgently. Patch management tooling – Automox, NinjaRMM and Microsoft Intune are common choices – automates this across your estate and gives you visibility into what's current and what isn't. Without that visibility, you're guessing.

No MFA on critical systems

Multi-factor authentication (MFA) – requiring a second form of verification beyond a password when logging in – is the single highest-impact security control available to most businesses. Microsoft's research suggests MFA blocks around 99.9% of account compromise attacks. That figure alone should end the conversation about whether to implement it.

And yet it's frequently absent, or present only on some systems. Email is protected but the CRM isn't. The VPN requires MFA but cloud file storage doesn't. The gaps matter because attackers will find them.

MFA should be enabled on every system that supports it, with priority given to email, remote access, financial systems and anything containing sensitive customer data. Authenticator apps (Google Authenticator, Microsoft Authenticator) are preferable to SMS-based codes, which can be intercepted via SIM-swapping attacks. The implementation is straightforward – the barrier is usually inertia, not technical complexity.

Shadow IT and unmanaged devices

Shadow IT refers to software and services used within a business without IT's knowledge or approval. It's more widespread than most IT teams realise. Staff use personal Dropbox accounts to share files too large for email. WhatsApp becomes the de facto channel for operational communications. Someone signs up for a SaaS tool on a company card because procurement takes too long.

The risk isn't that your staff are being reckless – they're usually trying to get their jobs done. The risk is what happens to the data. Files in a personal cloud account sit outside your security controls. Conversations in a consumer messaging app aren't covered by your data retention policies. An unapproved SaaS subscription may be storing customer data in a jurisdiction that creates compliance exposure.

Unmanaged devices compound this. A personal laptop used to access business email or customer systems is a device you can't patch, can't enforce policies on and can't wipe if it's lost or compromised.

The response isn't to lock everything down so tightly that people resort to workarounds – that just drives shadow IT underground. It's to make the approved tools good enough that people use them, have a clear and practical process for requesting new software and enforce a mobile device management (MDM) policy for any device that accesses business systems.

Poor backup practices

Most businesses have backups. Far fewer have backups that would actually work when needed.

The 3-2-1 rule is the baseline: three copies of your data, on two different media types, with one stored offsite. It's a useful framework but it doesn't account for one of the most important considerations in a ransomware scenario: whether your backups can themselves be encrypted or deleted by an attacker who has access to your systems.

Immutable backups – backups that cannot be altered or deleted for a defined retention period – address this directly. If ransomware encrypts your primary systems and your live backup target, an immutable backup stored separately remains usable. Without it, you may find your recovery options are limited to paying the ransom.

The other critical gap is testing. Many businesses have a backup process running but have never actually restored from it. A backup you've never tested is a backup you don't know works. Schedule restore tests – quarterly is reasonable – and document what you can recover and how long it takes. That information will matter if you ever need it.

Insufficient network segmentation

A flat network – one where every device can communicate with every other device – is a significant risk once an attacker gains an initial foothold. From a compromised endpoint, they can move laterally across your network, escalating privileges and accessing systems far beyond the original point of entry.

Network segmentation limits that blast radius. Separating guest Wi-Fi from your corporate network is the most basic version, and it's still absent in many businesses. But segmentation goes further than that: isolating finance systems from the rest of the network, separating HR data, keeping operational technology (OT) separate from IT systems in manufacturing environments where both exist.

The principle is simple. If an attacker compromises one segment, the damage should be contained to that segment rather than spreading across your entire estate. Implementing VLANs (virtual local area networks) and firewall rules between them achieves this without requiring separate physical infrastructure.

No incident response plan

Most SMEs have no documented plan for what to do when a security incident occurs. That absence is itself a significant risk – not because it makes incidents more likely, but because it makes the consequences far worse.

When a ransomware attack hits a business with no incident response plan, the result is panic. Decisions get made under pressure by people who haven't thought through the options. Systems get shut down in ways that destroy forensic evidence. Communications to customers, staff or regulators are delayed or inconsistent. Recovery takes longer and costs more than it needed to.

An incident response plan doesn't need to be long. It needs to answer a handful of specific questions: who makes decisions during an incident, who gets notified and in what order, which systems get isolated and how, who handles external communications, and what the process is for engaging specialist help if you need it. Running a tabletop exercise – walking through a hypothetical scenario with the relevant people in a room – will identify the gaps in your plan before a real incident does.

Under GDPR, a personal data breach that's likely to result in risk to individuals must be reported to the ICO within 72 hours of becoming aware of it. Without a documented process, hitting that deadline is difficult. With one, it's manageable.