The Hierarchy of Remediation: A Practical Cybersecurity Framework for SMBs

How small and medium-sized businesses can move beyond endless patching and build real cyber resilience

Small and medium-sized businesses face a harsh cybersecurity reality. They now use enterprise-grade cloud platforms, SaaS tools, remote access systems, and connected devices. At the same time, they are targeted by enterprise-grade threats.

The difference is resources.

Most SMBs do not have large security teams, 24/7 monitoring, mature asset management, or unlimited budgets. Yet they are expected to respond to the same vulnerabilities, ransomware campaigns, phishing attacks, and supply chain risks as much larger organisations.

For years, the default answer has been simple: patch everything.

Patching is still essential, but it is no longer enough. The pace of vulnerability disclosure, the persistence of legacy systems, the growth of shadow IT, and the rise of unpatchable operational technology mean many organisations are stuck in a cycle of reactive work.

The better question is not always, “How quickly can we patch this?”

Sometimes the better question is, “Why does this risky system still exist?”

That is where the Hierarchy of Remediation helps.

What is the Hierarchy of Remediation?

The Hierarchy of Remediation is a cybersecurity framework that ranks risk treatment options from most effective to least effective. It is adapted from the industrial safety Hierarchy of Controls, which prioritises removing hazards before relying on human behaviour or protective equipment.

In cybersecurity, the hierarchy helps organisations decide whether to remove, replace, isolate, govern, or tolerate a risk.

The five levels are:

• Elimination: Remove the hazardous asset, service, protocol, data, or application.
• Substitution: Replace the hazardous item with a safer alternative.
• Engineering controls: Isolate the hazard using technical controls.
• Administrative controls: Manage the hazard through policies, procedures, governance, and access rules.
• Personal Protective Equipment: Use last-line protections that reduce harm after exposure.

The higher the control sits in the hierarchy, the more reliable it usually is. Higher-level controls do not depend as heavily on users making perfect decisions under pressure.

Why patching alone is not enough

The traditional vulnerability management model is reactive. It usually follows this pattern:

• Identify a vulnerability.
• Wait for a vendor patch.
• Test the patch.
• Deploy the patch.
• Repeat the process for the next vulnerability.

This process matters, but it has serious limitations. Many SMBs operate systems that are no longer supported. Some operational technology cannot be patched without disrupting production. Some vendors are slow to respond. Some systems are exposed to attack before a patch exists. In many cases, the business does not even have a complete inventory of what it owns.

This creates a dangerous gap between known risk and practical remediation. Patching treats the vulnerability. It does not always treat the hazard.

For example, a vulnerable FTP server might be patched today, but the organisation still depends on an outdated and risky file transfer model. The patch reduces immediate exposure, but the underlying problem remains.

The Hierarchy of Remediation helps teams move from reactive patching to strategic risk reduction.

Quick answer: How should SMBs prioritise cybersecurity remediation?

SMBs should prioritise remediation in this order:

• Remove unnecessary systems, software, accounts, protocols, and data.
• Replace high-risk technologies with safer alternatives.
• Isolate unavoidable hazards with segmentation, WAFs, EDR, and access controls.
• Govern residual risk through policies, risk registers, approvals, and reviews.
• Use awareness training, insurance, and password managers as last-line protections.

This approach reduces the number of risks the organisation must continuously patch, monitor, and defend.

The five levels of the Hierarchy of Remediation

The hierarchy is easiest to understand as a decision-making model. When a risk is identified, start at the top. Only move down the hierarchy when the higher-level option is not feasible. This does not mean lower-level controls are useless. It means they should not be the first or only line of defence.

1. Elimination: Remove the hazard entirely

Elimination is the strongest form of remediation. It means removing the risky asset, service, protocol, account, application, or data set from the environment.

If the vulnerable system no longer exists, it cannot be exploited. If an exposed service is shut down, it cannot be attacked. If sensitive data has been deleted under a defensible retention policy, it cannot be stolen.

Examples of elimination in cybersecurity

Common elimination strategies include:

• Decommissioning unused servers
• Removing unsupported applications
• Disabling SMBv1
• Closing exposed management ports
• Retiring inactive user accounts
• Deleting redundant, obsolete, or trivial data
• Removing unused SaaS tools
• Eliminating unnecessary browser extensions
• Disabling risky macro behaviours

The objective is simple: reduce the attack surface.

Attack surface reduction for SMBs

Many SMB environments contain years of technical debt. Old servers stay online because nobody knows what they do. Applications remain installed long after a project ends. Cloud tools are purchased by business units without IT oversight. Test systems quietly become permanent.

Attackers do not care whether a system is forgotten. If it is exposed or vulnerable, it is useful to them.

Attack surface reduction means reducing the environment to the smallest practical set of systems, services, applications, accounts, and data required to operate the business.

The less you have, the less you have to secure.

Application rationalisation: remove software you no longer need

Application rationalisation is the process of deciding which applications should be retained, replaced, consolidated, or retired.

For SMBs, it should be treated as a security activity, not just a licensing clean-up.

Every application creates work. It must be patched, configured, monitored, backed up, reviewed, and included in incident response planning. Applications outside IT visibility are even riskier because they often sit outside standard controls.

A practical application rationalisation process includes three steps.

Step 1: Discover what exists

You cannot remove what you cannot see.

Start by identifying:

• Installed software
• SaaS applications
• Browser extensions
• Internet-facing systems
• Legacy hardware
• Unsupported operating systems
• Inactive virtual machines
• Unused cloud resources

Use endpoint management tools, vulnerability scanners, SaaS discovery, DNS logs, identity logs, firewall logs, and cloud inventory where available.

Step 2: Assess business value against security risk

For each application or asset, ask:

• Does it support a current business function?
• Who owns it?
• Is it still supported?
• Is there a safer alternative already available?
• What data does it process?
• What access does it require?
• What is the cost of securing it properly?
• What would happen if it were removed?

The aim is not reckless removal. The aim is to stop protecting systems the business no longer needs.

Step 3: Decommission safely

Where ownership is unclear, use controlled decommissioning.

A “scream test” can help. Disable a service or restrict access for a defined period. If nobody reports an issue, back it up if required, document the decision, and retire it permanently.

This should be managed through change control. A careless scream test can break important processes. A controlled one can expose forgotten systems with no remaining value.

Eliminating SMBv1

SMBv1 is a good example of a technology that should be eliminated, not tolerated.

It is an old file sharing protocol from a very different security era. It has been associated with severe exploitation pathways and major ransomware incidents. Many organisations kept it enabled because older printers, scanners, and network storage devices depended on it.

That convenience is not worth the exposure.

A practical SMBv1 elimination plan should include:

• Audit whether SMBv1 is enabled.
• Identify systems that depend on it.
• Replace or isolate those systems.
• Disable SMBv1 using central policy.
• Monitor for breakage and attempted use.

Some technologies cannot be made acceptably safe. They need to be removed.

Data minimisation: remove data before it becomes breach impact

Data is a liability when it is kept longer than needed.

Many SMB file shares contain years of redundant, obsolete, or trivial data. Old exports, duplicate folders, historic contracts, forgotten archives, and unnecessary personal information can all increase breach impact.

Data minimisation applies elimination to information assets.

A defensible data minimisation strategy should include:

• Retention rules based on legal, regulatory, and business requirements
• Automated deletion after retention periods expire
• Review of stale file shares and archives
• Removal of excessive permissions
• Secure disposal of retired systems and backups

If attackers cannot access historic data because it no longer exists, the risk has been eliminated.

2. Substitution: Replace the hazard with a safer alternative

Substitution means replacing a risky asset, protocol, process, or design with something safer.

It does not always remove risk entirely. It changes the risk into something easier to manage.

Examples of substitution in cybersecurity

Common substitution strategies include:

• Replacing FTP with SFTP or a secure file portal
• Replacing on-premise Exchange with Microsoft 365
• Replacing legacy authentication with modern authentication
• Replacing NTLM dependencies with Kerberos where feasible
• Replacing standard service accounts with managed service accounts
• Replacing broad VPN access with Zero Trust Network Access
• Replacing unsupported operating systems with supported platforms

The objective is to stop depending on fragile, high-risk mechanisms.

SaaS as a substitution strategy

For many SMBs, moving from on-premise infrastructure to SaaS is one of the most important substitutions available.

Take an on-premise mail server as an example. Running it requires the business to manage operating system security, application patching, certificates, remote access, backups, logging, web exposure, and incident response.

That is a heavy burden for a small team.

Migrating to a mature SaaS platform does not remove all risk. It changes the risk. The main concern often becomes identity security, especially account takeover. That still requires strong controls such as MFA, conditional access, logging, and user lifecycle management.

However, securing cloud identities is usually a more manageable problem for an SMB than defending an internet-facing mail server against active exploitation.

Replace unsafe protocols

Protocol substitution is one of the most practical ways to reduce risk.

Examples include:

• Replace FTP with SFTP, HTTPS-based transfer, or a secure portal.
• Replace insecure remote access with identity-aware access.
• Replace legacy authentication with modern authentication.
• Replace unnecessary SMB exposure with safer access models.

The goal is not to adopt new technology for its own sake. The goal is to reduce exposure to protocols and designs that are no longer suitable.

Replace VPN overreach with Zero Trust Network Access

Traditional VPNs often provide broad network-level access. Once connected, a user device may be able to reach far more internal systems than it needs.

That creates risk. If the user device is compromised, the VPN can become a path into the internal network.

Zero Trust Network Access changes the access model. Instead of placing a user inside the network, ZTNA brokers access to specific applications based on identity, device posture, policy, and context.

The user does not need broad network visibility. They need access to a defined application.

This reduces the blast radius of a compromised account or endpoint.

Replace static service accounts with managed service accounts

Many SMBs run services using ordinary user accounts. These accounts often have static passwords, excessive privileges, and “password never expires” enabled to avoid outages.

That is a poor security trade-off.

Group Managed Service Accounts are a safer alternative in Active Directory environments. Passwords are managed automatically, rotated by the domain, and not known by administrators. These accounts are designed for service use and reduce the risk of credential theft and misuse.

Where supported, replacing standard service accounts with managed service accounts materially improves identity security.

3. Engineering controls: Isolate the hazard

Engineering controls isolate people, systems, or data from the hazard. They are built into the technical environment and do not depend primarily on users remembering to do the right thing.

This makes them more reliable than policy alone.

Examples of engineering controls in cybersecurity

Common engineering controls include:

• Network segmentation
• Firewalls and access control lists
• Web Application Firewalls
• Endpoint Detection and Response containment
• Application allow-listing
• Privileged access workstations
• Jump hosts
• Email filtering and attachment detonation
• Conditional access enforcement
• Backup isolation

Engineering controls are especially important when elimination or substitution is not immediately possible.

Network segmentation: reduce lateral movement

A flat network is convenient for administrators and attackers.

In a flat environment, a compromised printer, camera, workstation, or test server may be able to reach critical systems. Segmentation limits this movement.

A practical SMB segmentation model may include:

• Server network
• Workstation network
• Guest network
• IoT network
• Management network
• Backup network
• OT or production network

Access between these networks should be explicitly allowed only where required.

For example, workstations may need HTTPS access to a business application. IoT devices should not be able to initiate connections to servers.

Segmentation turns the network into compartments. If one area is compromised, the attacker does not automatically gain access to everything else.

Protecting unpatchable OT and ICS systems

Manufacturing, logistics, healthcare, and engineering businesses often run operational technology that cannot be patched easily. These systems may depend on vendor support, specialised hardware, old operating systems, or strict uptime requirements.

In these cases, strict isolation is often the only realistic defence.

Controls may include:

• Dedicated OT network segments
• Industrial firewalls
• No direct inbound internet access
• Controlled access from IT to OT
• Jump hosts in a demilitarised zone
• MFA for administrative access
• Logging of remote access sessions
• Vendor access windows with explicit approval

The goal is not to pretend the legacy system is safe. The goal is to contain it so compromise is harder and impact is limited.

Virtual patching with WAFs

Virtual patching protects a vulnerable system before the underlying code is fixed.

For example, if a critical vulnerability is disclosed in a web application and the vendor patch will not be ready for 48 hours, a Web Application Firewall rule may block known exploit patterns before they reach the application.

The application remains vulnerable, but the exploit path is interrupted.

For SMBs, cloud-based WAFs are useful because they can often be deployed quickly without new hardware.

Virtual patching should not become a permanent substitute for fixing the underlying issue. It is a bridge over the exposure window.

Endpoint containment with EDR

Modern Endpoint Detection and Response tools can take automated action when suspicious behaviour is detected.

If ransomware starts encrypting files on a laptop, the EDR agent may isolate the endpoint from the network while keeping it connected to the management console.

This limits spread to file servers and other systems while the incident is investigated.

Speed matters. Automated containment can reduce damage in the first minutes of an attack.

4. Administrative controls: Govern the risk

Administrative controls change how people work. They include policies, standards, procedures, approvals, access reviews, training schedules, risk registers, and governance processes.

They are necessary, but they are weaker than technical controls because they rely on consistent human behaviour.

Examples of administrative controls in cybersecurity

Common administrative controls include:

• Acceptable use policies
• Access review procedures
• Risk registers
• Risk acceptance forms
• Change management
• Vendor security reviews
• Incident response plans
• Backup testing schedules
• Security training programmes
• Approval workflows for privileged access

Administrative controls help ensure risk is understood, owned, and reviewed.

Least privilege

The Principle of Least Privilege means users and systems should have only the access they need to perform their role.

In many SMBs, this principle is weakened by convenience. Users are local administrators. Shared admin accounts exist. Old permissions are not removed. Service accounts gain excessive privileges over time.

These shortcuts increase the impact of compromise.

A practical least privilege programme should include:

• Removal of local administrator rights from standard users
• Separate user and administrator accounts
• Periodic access reviews
• Role-based access control
• Strong approval processes for exceptions
• Privileged access management where feasible

The decision is administrative. Enforcement should be technical wherever possible.

Just-in-time privileged access

Standing privilege is dangerous.

If an administrator account has high-level access all day, every day, compromise of that account can become catastrophic.

Just-in-time access reduces that exposure. Administrators operate with standard accounts by default. When elevated access is needed, it is requested, approved, time-bound, logged, and then removed automatically.

The benefit is clear: stolen credentials are less useful outside the approved access window.

Risk registers

A risk register records known risks, affected assets, current controls, planned remediation, owners, due dates, and decisions.

For SMBs, the risk register does not need to be complex. It does need to be maintained and reviewed by leadership.

Useful fields include:

• Risk ID
• Asset or process
• Vulnerability or hazard
• Threat scenario
• Current controls
• Likelihood
• Impact
• Risk rating
• Treatment decision
• Owner
• Due date
• Review date
• Residual risk

The most important function of a risk register is accountability. It turns technical concerns into business decisions.

Risk acceptance

Not every risk can be fixed immediately. Sometimes the cost of elimination or substitution is too high. Sometimes a dependency is too complex to remove quickly.

That may be acceptable, but it must be explicit.

Risk acceptance should be documented and signed by the appropriate business owner or executive. It should not be quietly absorbed by IT.

A good risk acceptance record should state:

• What the risk is
• What asset or process is affected
• What could happen
• What controls are currently in place
• Why remediation is being deferred
• Who owns the risk
• When the decision will be reviewed

This prevents serious risks from being accepted by silence.

Vendor risk management

SMBs increasingly rely on managed service providers, SaaS platforms, consultants, and outsourced IT providers. Those vendors can become part of the attack surface.

Basic vendor risk management should ask:

• Does the vendor use MFA?
• What access will they have?
• How is access monitored?
• Do they have relevant security certifications or assurance reports?
• How quickly must they notify us of a breach?
• Do they subcontract key services?
• Can access be revoked quickly?
• Are security requirements included in the contract?

Vendor risk is business risk. It should be governed accordingly.

5. Personal Protective Equipment: Last-line protection

In this framework, PPE refers to controls that reduce harm after exposure. These controls are useful, but they are the least reliable because they often depend on user behaviour or only respond after a threat has made contact.

Examples of cybersecurity PPE

Cybersecurity PPE includes:

• Security awareness training
• Phishing simulations
• Password managers
• Cyber insurance
• User-facing warning banners
• Manual reporting processes
• Recovery playbooks

These controls should support the strategy. They should not carry the strategy.

Security awareness training

Security awareness training is important, but it is often oversold.

A hard hat does not stop a brick from falling. It reduces injury if the brick hits. In the same way, training does not stop phishing emails from arriving. It reduces the chance that a user will click, enter credentials, approve a fraudulent payment, or ignore a warning.

Training should be:

• Continuous
• Relevant to the user’s role
• Practical rather than theoretical
• Non-punitive
• Supported by technical controls
• Updated for current attack techniques

Training is necessary, but it should never be the main control protecting a critical process.

Cyber insurance

Cyber insurance protects financial resilience after an incident. It may help cover legal costs, notification, forensic investigation, recovery support, and business interruption.

It does not prevent the breach. It does not restore reputation. It does not guarantee recovery of stolen intellectual property. It also does not remove the need for MFA, backups, logging, incident response planning, and tested recovery processes.

Insurance is a safety net, not a security strategy.

Password managers

Password managers reduce the risk of weak and reused passwords. They are valuable, especially for SMBs using many SaaS applications.

However, they still depend on correct use. The master password must be strong. MFA should be enabled. Shared vaults need governance. Offboarding must remove access promptly.

A password manager is a strong supporting control. It does not replace identity governance.

Applying the hierarchy to an unpatchable system

The value of the hierarchy becomes clearest when a business faces a system that cannot be patched.

Consider a manufacturing business with a critical CNC machine. The controller runs Windows XP Embedded. The vendor no longer exists. The machine is essential to revenue.

A patch-first approach fails immediately:

• There are no vendor patches.
• Antivirus support is limited or unavailable.
• The system is vulnerable by design.
• Replacing the machine may be expensive or operationally disruptive.

The hierarchy gives the business a better decision path.

Elimination

Can the machine be removed from service?

If it is no longer required, decommission it. If it is essential to revenue, elimination is not currently viable.

Substitution

Can the controller be replaced with a supported platform? Can the machine be upgraded? Can the process move to another system or supplier?

If replacement is feasible, build the business case. If it is not feasible immediately, record the risk and move down the hierarchy.

Engineering controls

Isolate the machine aggressively.

Possible controls include:

• Place it on a dedicated OT VLAN
• Block internet access
• Block direct access from the corporate network
• Allow only required ports and source systems
• Use a jump host with MFA for administration
• Disable USB where possible
• Monitor traffic to and from the segment
• Use application allow-listing if supported
• Keep offline backups of machine configurations and production files

Administrative controls

Define strict operating procedures.

Examples include:

• Approved maintenance windows
• Named authorised users only
• Vendor access by exception
• Change control for configuration updates
• Documented incident response steps
• Periodic review by business leadership

PPE

Use last-line protections where available.

Examples include:

• Operator training
• Clear reporting procedures for unusual behaviour
• Cyber insurance where relevant
• Manual recovery instructions
• Offline copies of critical production files

This does not make the system safe. It makes the risk visible, contained, and actively managed.

Cybersecurity remediation checklist for SMBs

Use this checklist to apply the Hierarchy of Remediation.

Elimination checklist

• Remove unused servers and virtual machines.
• Disable obsolete protocols such as SMBv1.
• Delete inactive accounts.
• Retire unsupported applications.
• Remove unnecessary SaaS tools.
• Delete data outside retention requirements.
• Close unnecessary internet-facing ports.

Substitution checklist

• Replace FTP with secure file transfer.
• Replace on-premise services with mature SaaS where appropriate.
• Replace legacy authentication with modern authentication.
• Replace static service accounts with managed service accounts.
• Replace broad VPN access with application-specific access.
• Replace unsupported operating systems with supported platforms.

Engineering controls checklist

• Segment servers, workstations, IoT, guests, backups, and OT.
• Use WAF protection for internet-facing web applications.
• Deploy EDR with automated isolation.
• Enforce conditional access.
• Use jump hosts for sensitive environments.
• Isolate backup infrastructure.
• Monitor traffic between network segments.

Administrative controls checklist

• Maintain a risk register.
• Document risk acceptance decisions.
• Review privileged access.
• Test incident response plans.
• Review vendor access.
• Define change control for critical systems.
• Conduct regular access reviews.

PPE checklist

• Run practical awareness training.
• Use phishing simulations carefully and constructively.
• Deploy password managers with MFA.
• Maintain cyber insurance where appropriate.
• Keep recovery playbooks available.
• Encourage fast reporting without blame.

Common questions about the Hierarchy of Remediation

Is patching still important?

Yes. Patching remains essential. The hierarchy does not replace patching. It helps reduce the number of systems, applications, and services that require constant patching.

What is the best remediation strategy for SMBs?

The best strategy is to remove unnecessary risk first, then replace unsafe technologies, then isolate what remains. Policies, training, and insurance should support those controls, not replace them.

What is the difference between remediation and mitigation?

Remediation fixes or removes the underlying issue. Mitigation reduces the likelihood or impact without necessarily fixing the root cause. For example, patching a vulnerability is remediation. Placing a WAF rule in front of a vulnerable application is mitigation or virtual patching.

What should SMBs do with systems that cannot be patched?

Start at the top of the hierarchy. Remove the system if possible. Replace it if feasible. If neither option is realistic, isolate it with strong engineering controls, document the risk, restrict access, monitor activity, and define recovery procedures.

Why are administrative controls weaker than engineering controls?

Administrative controls rely on people following rules consistently. Engineering controls are built into the environment and are usually more reliable. A firewall rule does not get tired. A user does.

From cyber hygiene to cyber resilience

Cyber hygiene is important, but hygiene alone is not strategy.

A patch-centric model keeps teams busy. A hierarchy-centric model helps them become strategic.

The practical lesson for SMBs is clear: reduce the number of hazards that require constant attention.

Eliminate what you do not need. Substitute where the current design is too risky. Engineer controls that work even when people make mistakes. Govern the remaining risk through clear ownership and documentation. Use training, insurance, and password managers as supporting controls, not as the foundation of the security programme.

In the post-patching era, resilience is not about fixing every flaw before attackers find it. That is not realistic.

Resilience is about designing an environment where individual flaws do not collapse the business.

The Hierarchy of Remediation gives SMBs a practical way to do exactly that.