One forgotten firewall rule can sit for years, then become the gap that slows your CMMC assessment. When I help small contractors with lean IT teams, I treat firewall reviews as one of the fastest ways to cut risk and improve evidence.
A practical CMMC firewall checklist keeps the work tight. It helps you protect CUI boundaries, close old access paths, and show that your controls are managed on purpose. That’s where I start.
Why firewall rule reviews matter for Level 2
As of April 2026, CMMC Level 2 still maps to the 110 NIST SP 800-171 requirements. For firewalls, the key issue is boundary protection. I don’t assume a device is “covered” because a firewall exists. I want proof that traffic at external and internal boundaries is limited, reviewed, and justified.
Small contractors often inherit messy rulebases. A vendor needed quick access two years ago. An admin opened a port during a crisis. A temporary VPN exception never expired. Over time, that turns the firewall into a junk drawer.
I see the same pattern across Small Business IT projects, from Cloud Infrastructure and Office 365 Migration work to Data Center Technology upgrades. If a company also depends on Restaurant POS Support or Kitchen Technology Solutions, I keep those systems segmented from any enclave that stores or processes CUI.
Good reviews also strengthen Cybersecurity Services, Endpoint Security, Device Hardening, and Cloud Management. For a plain-English refresher on how the 110 controls fit together, I like this CMMC Level 2 requirements explanation. It helps small teams connect firewall cleanup to the bigger compliance picture.
The CMMC firewall checklist I use with small contractors
I keep the review simple enough to repeat. First, I export the full rulebase. Then I match each rule to a real system, owner, and business need. If I can’t tie a rule to current work, it moves to the top of my review stack.

If a rule has no owner, no ticket, and no business need, I treat it as a removal candidate.
This is the working checklist I use:
- Confirm the default stance is deny, then allow only the traffic the business truly needs.
- Verify every rule has a written business justification, a named owner, and a related system or service.
- Remove stale or unused rules after checking hit counts, asset status, contract changes, and decommission records.
- Restrict any-any rules. If one must stay, I document why and apply tight compensating controls.
- Validate source, destination, port, and protocol values. Broad objects often hide risk.
- Review temporary rules and expiration dates. When the project ends, the rule should end too.
- Confirm change approvals, implementation dates, and rollback notes for every firewall change.
- Check logging on critical rules, admin paths, VPN gateways, internet-facing services, and traffic into CUI segments.
- Review alerting for repeated denies, odd outbound connections, and access to management interfaces.
- Review outbound filtering, not only inbound access. Many small firms miss this and leave easy exit paths.
- Segment CUI environments from office users, guest Wi-Fi, test gear, shared vendor systems, and cloud admin networks.
- Review remote access and VPN exposure, including unused public IPs, third-party support paths, and risky direct RDP exposure.
When a control can’t be tightened right away, I document the compensating controls and link them to a risk decision or POA&M. I also validate my approach against current official CMMC and NIST guidance. For the boundary requirement itself, I often cross-check control 3.13.1, then review NIST’s publication page because revision history and assessment references can change.
Evidence that turns a rule review into audit-ready proof
A good review is only half the job. The other half is keeping evidence that shows the review happened, findings were tracked, and weak rules were fixed or accepted with clear risk notes.

I keep segmentation evidence close at hand because assessors care about key internal boundaries, not only the edge firewall. That matters even more if your company is pushing Digital Transformation projects, building Secure Cloud Architecture, or expanding remote work.
These are the artifacts I try to keep in one folder:
| Evidence | Why it matters |
|---|---|
| Rule review log with dates, reviewers, and findings | Shows the review is periodic and accountable |
| Screenshots or rule exports before and after changes | Proves what existed and what changed |
| Approval records and change tickets | Connects each rule to formal change control |
| Network diagrams, VPN settings, and segment maps | Shows where CUI boundaries sit |
| POA&M entries and compensating-control notes | Explains gaps that still need remediation |
The takeaway is simple: screenshots alone rarely carry the story. I want review logs, approval records, and change tickets that line up with the actual rulebase.
As of April 2026, the DoD rollout is still in Phase 1, with Level 2 self-assessments tied to many new contract actions, and broader C3PAO certification requirements starting in Phase 2 on Nov. 10, 2026. I often organize remediation with a CMMC Level 2 readiness checklist, but I treat outside checklists as helpers, not the final authority.
When I work as a Business Technology Partner, I tie firewall cleanup to broader Technology Consulting, Infrastructure Optimization, and Managed IT for Small Business goals. That keeps IT Strategy for SMBs grounded in Business Continuity & Security. It also turns vague claims about Innovative IT Solutions into Tailored Technology Services that an assessor can verify.
The forgotten rule is usually the risky one. When I review firewalls with ownership, approvals, logging, segmentation, and evidence in mind, I reduce exposure and make Level 2 preparation easier.
That is why this checklist matters. It helps me turn routine firewall maintenance into proof that CUI traffic is controlled, reviewed, and defended.
Discover more from Guide to Technology
Subscribe to get the latest posts sent to your email.
