Network security for small business: a practical checklist

Most small business network security gaps are not exotic. They are not nation-state attackers exploiting zero-days, and they are not complex social engineering campaigns. They are firewalls running 2019 firmware. They are guest WiFi sharing the same VLAN as the file server. They are unused switch ports left open in a conference room a salesperson plugs into during a meeting. They are a remote-access tool installed during a vendor project in 2022 and never removed. They are a default password on a managed switch the previous IT person never changed.

The good news is that this kind of risk is enumerable. A clean network security baseline is roughly 18 items long, and a small business that gets through it once and audits it quarterly is well outside the easy-target zone for opportunistic attackers.

This is that checklist. It is meant to be printed, walked through item by item, and used as the basis for a documented remediation plan. It pairs with the Microsoft 365 security audit checklist – run both for a complete picture, because identity and network are the two halves of small business attack surface and gaps in either one undo the work in the other. The operational discipline that keeps every item on this list maintained between audits is what managed network services actually deliver.

How to use this checklist

Print it out, walk the network, work through each item. For each one, document the current state, whether it meets the target, who is responsible, and the remediation deadline if it does not. The output is a written report you can hand to leadership, an MSP, or an auditor.

A few framing notes before you start. First, this is verification work, not new construction – it assumes you have a business firewall, managed switches, and business-grade WiFi in place. If you do not have those baselines, the network assessment is the right starting point, not this audit. Second, every item maps to a real attack pattern – this is not a paperwork exercise; the items are here because they are how breaches actually happen at SMB scale. Third, the audit cadence should be quarterly minimum, with a full re-walk annually. Networks drift. Drift is what gets exploited.

Network security checklist at a glance

#	Item	Why it matters	Audit cadence
1	Firewall firmware current and supported	EOL firmware has known unpatched vulns	Monthly check, quarterly verify
2	Firewall rule set documented and pruned	Stale allow rules accumulate over years	Quarterly
3	Default-deny outbound posture	Default-allow lets malware phone home freely	Quarterly
4	IDS/IPS enabled and tuned	Off-by-default on many SKUs	Quarterly
5	Geo-blocking on inbound and outbound	Most attack traffic comes from a small list of countries	Quarterly
6	Network segmentation via VLANs	Flat networks let one infection spread laterally	Annually + on change
7	Guest WiFi fully isolated	Guest WiFi on the corporate VLAN is a backdoor	Annually + on change
8	WiFi encryption at WPA3 (or WPA2-Enterprise minimum)	WPA2-Personal is increasingly weak	Annually
9	Default credentials changed everywhere	Default admin passwords are publicly documented	Annually + on new device
10	Unused switch ports administratively shut	Open ports in lobbies/conf rooms are walk-up access	Annually
11	Remote access tools inventoried and minimized	Old vendor tools become persistent backdoors	Quarterly
12	VPN with MFA and logging	VPN without MFA is the #1 ransomware entry point	Quarterly
13	DNS filtering deployed	Blocks malware C2 and phishing at the DNS layer	Annually
14	Network monitoring with alerting	Outages and intrusions need detection, not discovery	Quarterly
15	Log retention with offline copy	Attackers delete local logs first	Quarterly
16	Patch cadence for switches/APs/firewall	Network gear gets patched least, attacked most	Monthly
17	Wireless intrusion detection	Rogue APs and evil-twin attacks are real	Quarterly
18	Documented and tested incident response runbook	First 10 minutes of an incident decide everything	Annually + after incident

The checklist is grouped into five sections: perimeter, segmentation, access control, monitoring, and operations.

Perimeter security

The firewall is the most-attacked, most-overlooked device in most small business networks. Almost every item below is true at most SMBs the first time anyone looks.

1. Firewall firmware is current and on a supported version

Open the firewall management interface and check three things: the running firmware version, the latest available version from the vendor, and the end-of-life date for your hardware model. Firmware older than 12 months is a flag. Firmware on an end-of-life hardware model is a non-negotiable replacement project.

What to look for: firewalls running firmware from before the most recent two minor releases, hardware models with announced or near EOL dates, and any firewall where firmware updates have been deferred “until we have time” for more than a quarter. Critical CVEs in firewall firmware are not theoretical – the last several years have seen multiple SonicWall, Fortinet, Cisco, and Palo Alto bugs actively exploited within days of disclosure. Firmware currency is the single highest-leverage item on this list.

2. Firewall rule set is documented and pruned

Export the firewall rule set. Read every rule. For each one, answer: does this rule still apply, what business need does it serve, and who approved it. Rules that nobody can explain should be removed (cautiously, with rollback plan). Rules with overly broad scope (any-source-to-any-destination, broad port ranges, allow-all egress) should be tightened.

What to look for: rules added “temporarily” years ago, rules referencing IP addresses or vendors that no longer apply, allow-all rules that were meant to be replaced with specific ones, and orphaned port-forward rules to internal hosts that no longer exist. A typical SMB firewall accumulates 30 to 60 percent stale rules over five years.

3. Default-deny outbound posture (or close to it)

Most SMB firewalls allow all outbound traffic by default. This is convenient, and it is also how malware phones home, exfiltrates data, and downloads second-stage payloads. A meaningful step up: deny outbound by default, allow specific categories (web, email, DNS, business apps).

The realistic SMB version is not full default-deny – that is enterprise hardening territory and breaks too much. The realistic version is: block outbound on dangerous protocols (SMB, RDP, NetBIOS, Telnet) at the firewall edge, restrict outbound on high-risk ports (Tor, common malware C2 ports), and use category-based filtering to block known-malicious destinations. The firewall setup article walks through the specific rules.

4. IDS/IPS enabled and tuned

Most modern SMB firewalls have intrusion detection and prevention features (IDS/IPS) included in the license. They are often disabled by default or running with old signature databases. Verify both: the IDS/IPS engine is on, signatures are current, and the alerts are going somewhere a human reviews.

Tuning matters more than people expect. An untuned IDS/IPS produces hundreds of low-quality alerts per week, which gets ignored, which means real alerts get missed. Acceptable tuning targets: high-fidelity alerts (critical and high) reach the IT generalist or MSP within minutes; medium and low alerts get reviewed weekly; informational alerts are aggregated and looked at monthly.

5. Geo-blocking on inbound and outbound

Most SMBs do not have a legitimate business reason to receive traffic from China, Russia, Iran, or North Korea, or send traffic to them. Configure the firewall to block inbound and outbound traffic from countries the business does not deal with. Most modern SMB firewalls have geo-blocking built into the license.

What to look for: geo-blocking enabled but only on inbound (outbound matters too – exfiltration often goes to specific countries), geo-blocking with overly broad whitelists (“allow North America” missing the malicious-traffic regions inside it), and geo-blocking that has not been updated as the business expanded into new markets. This single setting cuts inbound attack noise by 50 to 80 percent for most SMBs.

Segmentation and isolation

A flat network is one infected device away from a full compromise. Segmentation is the difference between “the receptionist’s PC got malware” and “the receptionist’s PC got malware and now the file server is encrypted.”

6. Network segmentation via VLANs

The network has separate VLANs for separate trust zones. At minimum: corporate, guest, IoT/cameras, voice (VoIP), and management. Each VLAN has explicit firewall rules controlling what can talk to what. The VLAN article covers the design in detail.

What to look for: a single flat VLAN with everything on it (most common SMB finding), VLANs configured but with permissive inter-VLAN rules that effectively flatten the network anyway, IoT devices and cameras on the corporate VLAN where they can talk to file servers, and management interfaces (firewall admin, switch admin, hypervisor admin) on the same VLAN as user workstations. Management interfaces should be on a dedicated VLAN that requires explicit access from a jump host, not a regular workstation.

7. Guest WiFi is fully isolated

Guest WiFi traffic should reach the internet and nothing else. Specifically: guest devices cannot reach corporate VLANs, cannot reach printers, cannot reach the file server, cannot reach VoIP phones, cannot reach the firewall management interface, and cannot see other guest devices.

Verify this empirically. Connect a laptop to guest WiFi, run a network scan, and confirm what is reachable. Then try to access internal resources by name (\\\\fileserver, intranet.company.local). If anything resolves or responds, the segmentation is broken.

What to look for: guest WiFi configured but on the same VLAN as corporate, guest WiFi with permissive inter-VLAN rules, guest WiFi where client isolation is not enabled (guests can see each other, which means a malicious guest can attack other guests), and guest WiFi with a generic password on a sticker that has not changed in years.

8. WiFi encryption at WPA3 (or WPA2-Enterprise minimum)

Corporate WiFi should use WPA3-Enterprise where the access points support it, WPA2-Enterprise as the realistic floor. WPA2-Personal (a single shared password) is no longer sufficient for business use – the password leaks the first time it gets shared with a contractor or written on a whiteboard, and there is no way to revoke access without changing it for everyone.

What to look for: corporate WiFi running WPA2-Personal with a shared password, WPA-Personal or no encryption (still happens), WiFi configured with weak ciphers (TKIP instead of AES), and WPA2-Enterprise configured but with weak certificate validation (clients accepting any RADIUS server).

WPA3 hardware support has been standard on business APs since 2019. If your APs do not support WPA3 in 2026, they are due for replacement anyway.

Access control

9. Default credentials changed on every device

Walk through every network device – firewall, switches, access points, NAS, IP cameras, VoIP gateway, UPS management cards, printers – and verify the default admin credentials have been changed. Default admin passwords are published in vendor manuals and indexed by attackers. A device with a default password is one Shodan search away from compromise.

What to look for: any device still using vendor-default credentials (admin/admin, admin/password, root/root, the model number as password), shared credentials reused across multiple devices (one breach compromises all of them), and devices where the password was changed but documented in plain text in a shared OneNote or Google Doc that anyone in the company can read.

Use a password manager with team sharing for network device credentials. Each device should have a unique strong password stored in the password manager. The breakroom-printout-with-passwords approach should be retired permanently.

10. Unused switch ports administratively shut

Walk the office. Note every visible network jack – in conference rooms, in reception areas, at empty desks, behind printers, in the IT closet, under unused work surfaces. On the switches, verify that any port not currently connected to a known device is administratively shut, not just unused.

The attack: a visitor sits in a conference room during a sales meeting, plugs a small device (a Raspberry Pi, a malicious USB-Ethernet adapter, an attacker laptop) into the conference room jack. If the port is in the user VLAN with no protection, they have full access to the corporate network as long as they can sit there. If the port is administratively shut, plugging in does nothing.

What to look for: ports active in unused conference rooms, ports active in lobbies and reception areas, ports active under unoccupied desks, ports where 802.1X is not enforced, and switches where the default behavior is “any unused port joins the user VLAN.”

For higher-risk locations (lobbies, conference rooms with external visitors), consider 802.1X port authentication so even an active port requires a valid corporate credential to use.

11. Remote access tools are inventoried and minimized

List every tool currently installed on any internal system that allows remote access from outside the network. This includes: VPN clients, RDP exposed through the firewall (should not exist), TeamViewer, AnyDesk, ScreenConnect/ConnectWise Control, Splashtop, LogMeIn, NinjaRMM, vendor-specific remote tools, browser-based remote tools, and any “I will install this so you can help me” tool from a previous support engagement.

What to look for: multiple unrelated remote-access tools (consolidate to one), tools left over from prior MSPs or vendors that nobody is currently using, tools without audit logging or MFA, tools that an end-user installed without IT approval, and any RDP or VNC ports exposed directly to the internet (this is how ransomware gets in).

Every legitimate remote-access tool should have: MFA enforced, session logging, an inventory of who has access, and a documented removal process when access is no longer needed.

12. VPN with MFA and logging

If the business uses a VPN for remote access, verify three things: MFA is enforced on every VPN account (not optional, not just for admins), VPN authentication and session activity is logged, and inactive VPN accounts have been disabled.

The VPN setup article covers the configuration. The VPN-vs-ZTNA comparison covers when ZTNA is the better answer.

What to look for: VPN with username/password only, no MFA (this is the #1 ransomware entry vector at SMB scale), VPN accounts for ex-employees still active, shared VPN credentials used by multiple people, and split-tunnel configurations leaking corporate DNS to the public internet.

If the VPN is used heavily and the workforce is mostly remote, ZTNA is increasingly the right answer. If the VPN is used occasionally for office-side access, VPN with MFA is fine.

13. DNS filtering deployed at the network edge

Configure DNS filtering to block known-malicious domains, malware C2 infrastructure, and phishing destinations at the DNS layer. Options range from free (Cloudflare 1.1.1.1 for Families, Quad9) to commercial (Cisco Umbrella, DNSFilter, Cloudflare Gateway, NextDNS). DNS filtering catches a meaningful fraction of attacks before any traffic reaches the endpoint, and it works even for devices without local agents (IoT, printers, cameras). The full deployment depth is in DNS filtering for small business: what it is and why it matters.

What to look for: ISP-default DNS in use (no filtering at all), DNS filtering configured but only on the corporate VLAN (skipping guest, IoT, voice), DNS filtering applied but with categories that should be blocked left allowed (cryptomining, anonymous-proxy categories), and DNS filtering applied on workstations only (so attacker traffic from compromised IoT bypasses it).

Set DNS filtering on the firewall or on the DHCP-distributed DNS so every device on every VLAN inherits it. Bypass attempts (devices hardcoded to 8.8.8.8) should be redirected back through the filter at the firewall.

Monitoring and detection

You cannot respond to what you cannot see. Most SMBs discover incidents from end-user complaints or from a third party (insurer, ISP, customer). Both are too late.

14. Network monitoring with alerting

Critical infrastructure (firewall, core switch, internet circuit, key servers) is monitored for availability and performance, with alerts going to someone who responds. The threshold for “responds” is “within minutes during business hours, within an hour after hours” for critical alerts.

What to look for: no monitoring at all (still common at small SMBs), monitoring configured but alerts going to an unmonitored mailbox, monitoring covering the basics (ping/uptime) but missing application-layer health (DNS resolution, internet path latency, VPN responsiveness), and monitoring without on-call rotation so weekend incidents are discovered Monday.

For most SMBs, monitoring is delivered as part of managed IT services – it is not worth standing up an internal monitoring stack at SMB scale unless the business has dedicated IT staff with capacity. The depth on what specifically to watch and how to keep the alert layer tuned is in network monitoring for small business: what to watch and how.

15. Log retention with offline copy

Critical devices are forwarding logs to a central location, and that central location has an offline or write-once copy that an attacker cannot delete after compromise. Minimum retention: 90 days for general traffic logs, 12 months for authentication logs, indefinite for security incidents.

What to look for: devices logging only locally (attacker first move is to wipe local logs), logs forwarded to a central syslog server but with no offline copy (attacker second move is to wipe the syslog server), logs retained for 7 to 14 days only (any incident discovered later cannot be investigated), and logs that exist but are not searchable (a 10 GB pile of plaintext logs is not useful at incident time).

For SMBs, options range from free (basic syslog forwarding to a NAS with snapshots) to managed (SIEM-as-a-service from an MSP/MSSP). The bar to clear is “an attacker who fully compromises the network cannot prevent forensic reconstruction of what they did.”

16. Patch cadence for switches, APs, and firewall

Network gear gets patched least and attacked most. Establish a documented cadence: switches and access points patched at least quarterly, firewalls patched within 30 days of stable release for routine updates and within 7 days for critical security advisories.

What to look for: switches running firmware from when they were installed (often 5+ years), access points running firmware that predates a major Wi-Fi security advisory, firewalls with auto-update disabled and no manual cadence, and patch cadence that exists on paper but has been quietly skipped for the last three quarters because “nothing was urgent.”

Patch cadence is one of those items that seems boring until the day a vendor publishes a critical CVE and the active exploitation window is 48 hours. Boring is the goal.

17. Wireless intrusion detection enabled

Modern business APs have wireless intrusion detection (WIDS) features that detect rogue access points (someone plugged an unauthorized AP into the corporate network) and evil-twin attacks (an attacker AP impersonating the corporate SSID to steal credentials). Enable these features on the AP controller or cloud dashboard.

What to look for: WIDS available but disabled, WIDS enabled but alerting nobody, rogue-AP detection that fires on every legitimate neighboring office AP (untuned), and rogue-AP alerts where the response is “we will look at it later” instead of “investigate today.”

A rogue AP on the corporate network is one of the most dangerous findings possible – either an insider plugged it in (policy violation, but solvable) or an attacker did (active intrusion). Either case warrants immediate response.

Operations

18. Documented and tested incident response runbook

Write down what happens when something goes wrong. Who gets called. In what order. What gets shut down. What gets isolated. Who talks to law enforcement, insurance, customers. What systems are off-limits to power-cycle (forensic preservation). Where backups are stored and how they get restored.

The first 10 minutes of an incident decide whether the response is controlled or chaotic. A documented runbook means people execute predictably under stress instead of improvising. The disaster recovery plan covers IT recovery; the incident response runbook covers the security-incident dimension specifically (containment, evidence preservation, notifications).

What to look for: no runbook at all, a runbook that exists but has not been read in two years, a runbook that names a person who left the company 18 months ago, a runbook with no testing exercises, and a runbook stored only on the network share that is encrypted during ransomware.

Test the runbook annually with a tabletop exercise: someone reads a scenario, the team walks through what they would do, gaps get found, runbook gets updated. This is two hours per year. It pays for itself the first time something real happens.

How this checklist relates to the rest of the security stack

Network security is one layer in a defense-in-depth posture, not the whole thing. The companion layers:

• Identity: the M365 security audit checklist covers the identity and email side. Network and identity gaps compound – a compromised account on a flat network is far worse than a compromised account on a segmented one, and a phishing email through an unhardened tenant lands on a workstation that may or may not have local protection.
• Endpoint: EDR catches what the network misses. Network controls are good at blocking opportunistic noise; targeted attacks often look like legitimate traffic until they execute on the endpoint.
• Backup and recovery: backups are what makes a successful attack survivable. The network checklist reduces probability; backups manage consequence.
• Monitoring and response: signs of network compromise covers the indicators this checklist’s monitoring should catch.

A small business that has the items on this checklist in good shape, M365 audited, EDR deployed, backups tested, and an incident response runbook is in roughly the top 10 percent of SMB security postures – not because it is doing exotic things, but because most SMBs have not done these foundational ones.

Common audit findings

The patterns that come up in nearly every first-time SMB network security audit, ranked by how often they appear.

1. Firewall firmware 12+ months old. Almost universal in SMBs without an MSP managing the firewall.
2. Default credentials on at least one device. Usually a switch, an AP controller, or a UPS card.
3. Guest WiFi not actually isolated. Either same VLAN as corporate, or VLANs exist but inter-VLAN rules are permissive.
4. No log retention beyond 7-14 days. Default settings on most devices.
5. VPN without MFA. Especially common with older Cisco AnyConnect or pfSense OpenVPN deployments.
6. Unused remote-access tools left over from prior vendors. Average SMB has 2-4 of these.
7. Open switch ports in conference rooms and lobbies.
8. Flat network with no VLANs. Or VLANs that are decorative rather than enforced.
9. WPA2-Personal corporate WiFi with a shared password.
10. No documented incident response runbook.

Finding even half of these in a first-time audit is normal. Fixing them is the work of one or two focused quarters with a network-aware MSP or an in-house IT generalist.

Time-to-remediate

Finding	Time to fix
Firewall firmware update	1-2 hours per firewall
Firewall rule cleanup	4-12 hours depending on rule count
Geo-blocking	30 minutes
Default credentials rotation	2-6 hours across all devices
Guest WiFi isolation	2-4 hours
WPA2-Personal to WPA2/WPA3-Enterprise	1-2 days for cutover
VLAN segmentation rollout	1-3 weeks for a typical SMB
Unused port shutdown	4-8 hours including walk-through
Remote-access tool inventory and cleanup	4-8 hours
VPN MFA enforcement	1-2 days
DNS filtering deployment	4-8 hours
Monitoring and alerting	1-2 days
Log retention with offline copy	1-3 days
Incident response runbook (first version)	1-2 days of writing + 2 hours tabletop

A focused 2-week engagement with an experienced network generalist closes the high-impact items (firmware, credentials, VPN MFA, guest isolation, DNS filtering, geo-blocking, log retention). The longer-tail items (VLAN segmentation, runbook, monitoring rollout) are project work over the following quarter.

Quarterly audit cadence

After the initial cleanup, the quarterly cadence is what keeps the posture from drifting back. A reasonable 90-day rhythm:

• Month 1: Firmware currency check across all devices. Patch what is due.
• Month 2: Firewall rule review. Prune stale rules. Verify geo-blocking and IDS/IPS state.
• Month 3: Access review (VPN accounts, remote tools, admin credentials). Log retention sample audit.
• Annual: Full re-walk of the checklist. Tabletop exercise. Document what changed and why.

The cadence is what separates “we did a security project two years ago” from “we have a security posture.” Most SMBs get the first one and skip the second.

How Sequentur runs this checklist for clients

We run versions of this checklist as part of managed IT engagements for small and mid-sized businesses across the 15-to-250-employee range, including general SMBs and regulated industries like healthcare, legal, financial services, and defense contractors. The first pass typically catches 8-12 of the items above as findings, the next 90 days remediate the high-impact ones, and the quarterly cadence keeps the posture stable from there. For businesses with compliance frameworks (HIPAA, CMMC, SOC 2), the checklist maps to specific control families and produces audit-ready documentation as a byproduct.

If you have not run a network security audit in the last year – or ever – and want to know where you actually stand, schedule a call and we will walk through the exposure honestly.