A good firewall policy is a written, owned and reviewed set of rules: block everything by default, allow only the traffic a business need justifies, log what matters, route every change through an approval process, and review the whole rulebase on a schedule. Most firewall problems in small and mid-size businesses do not come from missing technology. They come from rules that nobody can explain, temporary exceptions that were never removed, and changes made in a hurry with no record. This guide walks through how to write the policy, how to write the rules, how to manage change, what to log, and when SSL inspection is worth the effort.
TL;DR
- Start with a documented policy based on risk, then deny all traffic that is not expressly permitted.
- Write narrow rules: specific sources, destinations, ports and applications, each with an owner and a business reason.
- Treat every change as a request with an approval, a test, a record and a rollback path, including emergency changes.
- Send logs to a central, protected location and review the rulebase on a fixed schedule to remove stale exceptions.
- Use SSL/TLS inspection only where you have a documented need, and define exclusions before you turn it on.
Table of Contents
- What a firewall policy is, and what it is not
- Start from default deny
- Writing firewall rules that stay manageable
- Firewall policy examples to adapt
- Firewall change management
- Logging and monitoring
- The firewall rule review process
- SSL inspection and decryption: when it is worth it
- Our perspective
- Let us manage your firewall policy
- FAQ
- Sources
What a firewall policy is, and what it is not
People use "firewall policy" and "firewall rules" as if they were the same thing. They are not. The policy is the business-level document. The rules are its technical expression on the device.
NIST SP 800-41 Revision 1 describes a firewall policy as the rules for handling inbound and outbound traffic by IP addresses and ranges, protocols, applications and content types, based on the organization's security policy and a risk analysis. That definition has two useful consequences:
- The policy comes from risk, not from whatever the device ships with. You decide what must be protected and what the business needs to do, then you write rules to match.
- The policy covers more than the perimeter. It applies to internal segments, remote users and systems that connect from outside.
The same logic applies on endpoints. Microsoft's Basic Firewall Policy Design explains that host firewalls protect against traffic that bypasses perimeter defenses and traffic that originates inside the network, and that unmatched traffic is dropped. A perimeter firewall alone does not protect a laptop that is plugged into a hotel network or a server that an infected workstation can reach.
What a written policy should contain
For a company of 20 to 500 people, a policy of two to four pages is enough if it answers these questions:
- Which networks and zones exist (users, servers, guest Wi-Fi, voice, cameras, management), and what is the default posture between them?
- Which inbound services are allowed from the internet, to which hosts, and who approved them?
- Which outbound traffic is allowed, and what is blocked by category?
- Who may administer the firewall, from where, and with what authentication?
- How are changes requested, approved, tested, documented and reversed?
- What gets logged, where it is stored and who reviews it?
- How often the rulebase is reviewed, and by whom?
If your policy cannot answer these in plain language, the device configuration is the only record of your security decisions, and that record is usually incomplete.
Start from default deny
The single most repeated recommendation in firewall guidance is deny by default. NIST's guidance says that traffic not expressly permitted by the firewall policy should generally be blocked, because that traffic is not needed and blocking it reduces both attack risk and unnecessary network load. The CIS Essential Guide on firewalls and port restrictions says the same thing in practical terms: block by default, allow-list the traffic you require, and review the rules on a set schedule.
In practice, default deny means the last rule in each zone-to-zone direction is an explicit deny with logging turned on. It also means you build upward from nothing instead of downward from "allow any". Teams that begin with a broad allow rule and promise to tighten it later almost never do.
Microsoft's Windows Firewall rules guidance applies the principle to hosts: keep inbound connections blocked by default, restrict remote addresses where appropriate, and create exceptions only for legitimate applications and services.
Writing firewall rules that stay manageable
A rule is a decision with a cost. Every rule you add widens what an attacker can try and what an administrator must understand. These practices keep rules defensible.
Be specific on every field
NIST advises making rulesets as specific as possible. A rule that reads "allow any to any on port 443" is technically a rule, but it is not policy. Compare these two:
| Weak rule | Better rule |
|---|---|
| Allow any source to any destination on TCP 443 | Allow the user VLAN to the proxy or approved web categories on TCP 443 |
| Allow remote desktop from anywhere to the file server | Allow RDP only from the VPN address pool to the named admin jump host |
| Allow SQL from the office network | Allow TCP 1433 only from the two application servers to the database server |
| Allow the vendor in for support | Allow the vendor's fixed address to one device, on one port, until a named date, then remove |
The last row matters. Microsoft's guidance advises constraining exceptions by program, port, profile and remote address, and recording enough context that someone can administer and review the rule later.
Use identity and application context where the platform supports it
Ports and IP addresses are blunt. Modern firewalls can also match on application, user, device and URL category, and combining criteria narrows the scope of a rule. If your firewall supports it, a rule that permits a named application for a named group is stronger than a rule that opens a port to a whole subnet. Our article on next-generation firewall features and encrypted traffic visibility covers which of these capabilities are worth paying for.
Name objects and write comments
Every rule should carry three pieces of metadata: the business reason, the owner, and a review or expiry date. Use a naming convention for address objects and groups so that "SRV-SQL-01" means the same thing in every rule. When the person who wrote a rule leaves, the comment is often the only explanation that survives. CIS Control 11.2 explicitly requires documenting traffic configuration rules.
Order rules deliberately
Firewalls evaluate rules in sequence, and the first match usually wins. Keep the most specific rules first, group them by zone pair, and put the explicit deny last. A broad rule placed above a narrow one makes the narrow one "shadowed": it never matches, yet it sits in the rulebase and misleads anyone reading it.
Firewall policy examples to adapt
The examples below are patterns, not configurations to paste. Your addresses, applications and risk analysis will differ.
Example 1: Internet-facing services in a DMZ. CISA's guidance on hardening recommends placing externally facing DNS, web and mail services in a DMZ and enforcing strict default-deny access control lists with denied traffic logged. For a small business this usually means the public web server or mail gateway sits in its own zone. That zone may receive traffic from the internet on the required ports only, and may not initiate connections to the internal user or server networks.
Example 2: Segmented internal network. Separate users, servers, guest Wi-Fi and building systems such as cameras and printers. The default between segments is deny. Specific flows are then allowed: users to the file and application servers on required ports, servers to backup targets, nothing from guest to anything internal. Our 30/60/90 day segmentation plan shows how to phase this in without breaking line-of-business applications.
Example 3: Administrative access. CISA recommends managing network devices only from trusted, dedicated administrative workstations. Translate that into a rule: the firewall's management interface accepts connections only from one management subnet or jump host, with multi-factor authentication, and is never exposed to the internet.
Example 4: Outbound control. Outbound traffic gets less attention than inbound, but it is how malware calls home and how data leaves. Permit the protocols users need, block known-risky categories, and consider web filtering with exceptions handled through the change process. We describe how to do that without disrupting work in our piece on web content filtering for IT teams.
Example 5: Database access for regulated data. Banks and mortgage companies often run SQL servers holding sensitive customer records. The rule set is short: only the application tier reaches the database port, administrators reach it only through the jump host, and every other path is denied and logged.
Firewall change management
Most outages and most accidental exposures come from changes, not from attacks. A repeatable process is the cheapest control you can add. NIST's guidance on managing firewall changes points to a consistent set of steps, and you can run them with a ticketing system and a shared document.
- Request. A written business reason, the exact traffic needed (source, destination, port, application), a named owner and a duration if it is temporary.
- Assess. A security review of the impact: does this open a path to sensitive systems, and is there a narrower way to meet the need?
- Approve. A designated approver who is not the person making the change.
- Test. Validate the change before production where possible, and confirm that it does not break existing flows.
- Implement. Use a controlled change window, with a tested rollback or restoration path ready if the change fails.
- Record. Save the resulting configuration and update the documentation.
- Verify and monitor. Confirm the change works as intended and watch for operational effects or unauthorized changes.
Emergency changes still need a record and a later review. The risk is that urgent work becomes the normal path, so measure how many changes are emergencies each quarter.
CISA's configuration and change management resource stresses planning roles, responsibilities, procedures and documentation, and being able to roll back changes that do not work as planned. CISA's December 2024 hardening guidance goes further: investigate firewall and ACL changes made outside change management, store configurations centrally, and alert on unauthorized changes. If you already use ITIL-style requests for other systems, our change management guide with RFC templates can be reused for firewall requests.
Teams that automate configuration testing in a pipeline can borrow ideas from CI/CD security testing practices, where every change has an assigned owner, an automated check and a defined way back before it ships.
CIS Control 11 frames the reason clearly: network device configurations need rigorous configuration management and change control, because insecure defaults and temporary exceptions persist and become exploitable gaps. Control 11.3 recommends automated tools that compare devices against the approved standard and detect changes.
Logging and monitoring
A firewall that blocks traffic but records nothing leaves you blind during an incident. Decide what to log before you need it.
- Log denied traffic, especially on the final deny rule, so that scanning and misconfigurations are visible.
- Log administrative actions, including logins, configuration changes and rule edits.
- Centralize the logs. CISA recommends secure, centralized and correlated logging, encrypted transport for remote logs, off-site copies, and logging at the network, operating system and application levels.
- Protect the logs. An attacker who controls the firewall can erase local logs, which is why off-device copies matter.
- Mind performance. Logging every allowed connection on a busy device can be costly. Log what you will actually review or need for investigations and compliance, and size storage accordingly.
Correlation is the point. A firewall deny followed by an endpoint alert and an unusual sign-in tells a story that none of the three tells alone. That is why we pair firewall management with endpoint detection and 24/7 monitoring rather than treating each device as a separate project.
The firewall rule review process
Rules age. Applications are retired, vendors change, projects end, and the exceptions remain. CIS recommends reviewing firewall rules on a set schedule, and NIST says to periodically review or test rulesets for continued compliance with organizational policy. Pick a cadence that fits your risk and your compliance obligations: many organizations review quarterly or twice a year, and your framework may specify more. Check the exact requirement in your own regulation or contract.
A workable review covers:
- Unused rules. Use hit counts and logs to find rules that have not matched in a long period. Confirm with the owner, then disable before deleting.
- Shadowed and redundant rules. Remove rules that can never match or duplicate another.
- Expired exceptions. Any rule with a past expiry date should be removed unless renewed through the change process.
- Overly broad rules. Look for "any" in source, destination or service and narrow it.
- Orphaned objects. Delete address objects and groups that no rule uses.
- Owner confirmation. Every remaining rule has a current owner and a business reason.
- Firmware and access. Confirm the firewall software is updated on a schedule and administrative access is limited. Our patch management strategy for SMBs covers the update side.
We saw what neglected rulebases look like in practice. Our business firewall cleanup case study describes how a review reduces clutter and risk.
SSL inspection and decryption: when it is worth it
Most web traffic is now encrypted, which is good for privacy and bad for any control that depends on seeing content. NIST's firewall guidance notes that firewalls cannot inspect encrypted application data or traffic they do not understand, so organizations need a policy for authorized encrypted and tunneled traffic, including whether to permit or block it. The original NIST publication is clear that this is a policy decision.
NIST's SP 1800-37, published in September 2025, adds that TLS 1.3 forward secrecy can interfere with the passive decryption some enterprises use for visibility. It presents standards-compliant ways to keep monitoring and analytics working. The message is to plan for visibility deliberately instead of assuming passive inspection will continue to work.
Decide first, then configure
Turn on SSL/TLS inspection when you have a documented security or compliance reason to see inside encrypted traffic, and you can manage the consequences:
- Privacy and consent. Employees should know what is inspected. Exclude categories such as personal banking and healthcare portals, and involve legal counsel if you handle regulated data.
- Certificates and keys. The firewall acts as a trusted intermediary, so its signing certificate must be deployed to managed devices and its private key protected like a crown asset.
- Compatibility. Certificate-pinned applications, some update services and sensitive systems can break under inspection. Test, then define exclusions. Do not inspect indiscriminately.
- Performance. Decryption is resource-intensive. Size the hardware for it.
- Exceptions process. Exclusions are firewall changes. Run them through the same request and approval path.
For businesses without a clear need, a more modest approach can work: DNS and category filtering, endpoint detection on every device and strict outbound rules provide meaningful protection without decrypting everything.
Our perspective
We manage firewalls for small and mid-size businesses across Southern California, and the same pattern appears again and again. The device is rarely the weak point. The weak point is that nobody owns the rulebase. A clinic opens a port for a vendor, an accounting firm adds an "any" rule to fix a printing problem, and a year later no one remembers why.
Our approach is preventative rather than break-fix. We start with a written policy that matches the business, enforce default deny, keep rules narrow and documented, and review them on a schedule so that exceptions expire instead of accumulating. For healthcare providers, law firms, banks and mortgage companies, the firewall policy also becomes evidence for HIPAA, SEC-aligned and similar compliance reviews, so documentation is not optional.
Our advice is simple. If you cannot explain a rule in one sentence and name its owner, it should not be in the rulebase.
— Alex
Let us manage your firewall policy
Secure Techies designs, documents and monitors firewall policy as part of our network security solutions, backed by 24/7 monitoring and compliance-focused reviews. If you want an outside review of your current rulebase, or ongoing management so changes, logs and audits are handled for you, our team can help. You can also see how firewall work fits into our wider managed IT services.
FAQ
What is a basic firewall policy?
A basic firewall policy is a documented set of rules that says which traffic may enter and leave your network, defined by addresses, protocols, applications and content types, and based on a risk analysis. Its foundation is deny by default: anything not expressly permitted is blocked. It should also say who may change the rules and how.
What are the best practices when implementing firewall security policies?
Two matter most. First, deny by default and allow only what the business needs, with specific rules rather than broad ones. Second, manage the rulebase over time: require approved and tested changes, log denied traffic centrally, and review rules on a schedule so stale exceptions are removed.
How often should firewall rules be reviewed?
Guidance from NIST and CIS calls for periodic review on a set schedule, without a single universal interval. Many organizations choose quarterly or twice a year. If you fall under HIPAA, PCI or another framework, check its specific requirement and set your cadence to meet or beat it.
Should a small business use SSL inspection?
Only when there is a documented security or compliance need and you can handle certificates, privacy, performance and exclusions. Inspection can break certificate-pinned applications, so test first and exclude sensitive categories. Without that need, strong endpoint protection and outbound filtering often give a better return.
Sources
- NIST SP 800-41 Revision 1, Guidelines on Firewalls and Firewall Policy
- NIST, Guidelines on Firewalls and Firewall Policy (publication PDF)
- NIST SP 1800-37, Addressing Visibility Challenges with TLS 1.3
- CISA, Enhanced Visibility and Hardening Guidance for Communications Infrastructure
- CISA, CRR Supplemental Resource Guide: Configuration and Change Management
- CIS Essential Guide, Firewalls and Port Restrictions
- Microsoft Learn, Windows Firewall Rules
- Microsoft Learn, Basic Firewall Policy Design