How to Prove Firewall Is Enabled on Every Laptop (SOC 2)

Ask an auditor about firewalls and most teams reach for a network diagram. Then the auditor asks about the laptops, and the answer is a screenshot someone took in March.

Most guidance online covers cloud security groups and perimeter appliances. The firewall on each workstation gets one line, if that. This post is about that line.

How do you prove a firewall is enabled on every laptop?

Read the effective firewall state from each device on a schedule, compare it with a written policy sentence, and keep the dated readings for the whole audit period. The proof is a per-device record with a timestamp, not a single screenshot.

That means three things you can hand over: a definition of "enabled", a reading per device that matches it, and an exceptions list. Agency's evidence guide says evidence "must be collected contemporaneously, meaning at the time the control was operating," and that you "cannot recreate or backfill evidence for a period that has already passed." Start the readings before you need them.

Does SOC 2 require a firewall on employee laptops?

SOC 2 does not name a laptop firewall setting. Agency's firewall guide says the framework "does not prescribe specific firewall products, architectures, or rule configurations," and calls CC6.6, the criterion about threats from outside the system boundary, the most directly relevant one.

So the requirement comes from your own description of the system and your own policy. If your policy says laptops run a host firewall, you have promised to prove it. If it says nothing, an auditor can still ask how you protect devices that leave the office network, and a host firewall is the usual answer.

Why do most firewall explainers miss the laptop?

They are written about network boundaries. The same Agency guide lists the evidence auditors want for firewalls: an architecture diagram, rule exports, change records, sample logs and periodic rule reviews. None of that is about a laptop.

Tooling shows the same split. Drata's Test 119 inspects firewall configuration files to confirm the default is to deny traffic that is not explicitly allowed, and its text concerns the perimeter firewall. It does not mention laptop or endpoint firewalls.

That is not a flaw in the test. It is a reminder that "we have a firewall" can be true and still say nothing about the machine in a coffee shop.

What does "enabled" mean on Windows and macOS?

Define it per platform, because the two systems report state differently.

On Windows, the firewall is configured per network profile. Microsoft documents that Get-NetFirewallProfile displays information from the Windows Firewall with Advanced Security properties page, "with the tabs for Domain, Private, and Public profiles." A laptop can have the Domain profile on and the Public profile off. A check that reads one profile can pass a machine that is exposed on hotel Wi-Fi.

On macOS, Apple's instructions are to open System Settings, choose Network, select Firewall and turn it on. The same page cautions that "certain apps that don't appear in the list may have access through the firewall," including system apps, services and processes.

A checkable policy sentence therefore reads: "On every in-scope laptop the host firewall is on for all network profiles, and the reading is taken from the device."

Where does the Windows reading actually come from?

From the effective policy, not the stored one. Microsoft's page explains that running the cmdlet without a policy store retrieves the persistent store, while the ActiveStore "contains the currently active policy," the sum of all policy stores that apply to the computer, including group policy objects.

Two readings can therefore disagree. The persistent store shows what was set locally. The active store shows what is in force after group policy is applied. For audit evidence the active state is the one that answers the question "was the firewall on."

This is the same lesson as screen lock: "the policy was pushed" and "the device behaves that way" are different claims, so read the device.

What can go wrong between the policy and the laptop?

Four failures show up often enough to test for before fieldwork:

1. One profile covered, two not. The Domain profile is on because that is what the office network uses, while the Public profile was never checked.
2. Local override. A user, an installer or a script turns the firewall off to fix a connection problem and never turns it back on.
3. A second product in charge. Another security tool manages the firewall, and the built-in setting reads off even though protection exists, or reads on while rules are wide open.
4. Silent devices. The laptop has not reported in weeks, so the dashboard shows its last good value.

None of these appears if you only confirm that a profile or policy exists. Each appears when you read effective values from the device on a schedule.

What should a per-device firewall record contain?

Enough that an auditor can sample a row and not come back with a question. Six fields cover it:

1. A stable device identifier, such as a serial number.
2. The state of each firewall profile or the platform equivalent.
3. The source of the reading: the device itself, a management tool, or a manual upload.
4. A capture timestamp.
5. The owner, so a failing laptop has a person attached.
6. The policy version the reading was tested against.

The source field matters. Agency's guide says auditors "prefer structured exports (CSV, JSON, PDF reports) over screenshots," and that any screenshot should include timestamps and a system identifier. A record that labels its own source lets the auditor decide how far to trust it.

We use the same shape for EDR coverage, so one evidence pipeline can serve several controls.

How do you handle laptops you cannot manage?

Record them as exceptions, with a reason and a compensating control, instead of leaving them out. Some teams have no device management tool for every laptop. One vendor's guide for unmanaged Windows devices asks employees for screenshots that show their name for sign-in options, device encryption and antivirus. It does not mention the firewall, so if you rely on screenshots, add the firewall page to your own instructions and confirm the format with your auditor.

Treat every exemption as a record with an owner, a reason, a review date and a note on what covers the risk. An auditor accepts a kiosk that runs without a host firewall if you can show why. They do not accept one they discover.

How do you show the control held for the whole period?

Keep the history, not just the latest value. Agency's firewall guide states that "auditors need to see ongoing operation throughout the observation period, not just current state." If your console shows only today's compliance, export on a schedule and store the files where they will not expire.

Then keep the exceptions trail: a dated detection, an owner, a fix and a fix date for every laptop that drifted. A year with no exceptions invites the question of whether anything was looking.

Completeness is the last piece. Readings about the laptops you can see say nothing about the ones you cannot, which is the subject of our piece on what auditors check in a SOC 2 device inventory. A device that has not reported should show as unknown, never as a pass.

What should you do before the audit window opens?

A short list for the week before:

1. Write the policy sentence so it names the profiles or platform settings that must be on.
2. Read the effective state, not the stored one, from a sample of laptops and compare it with the policy.
3. List every exempt device with its reason and compensating control.
4. Start scheduled exports now, because past periods cannot be rebuilt.
5. Agree the evidence format with your auditor, including how unmanaged devices are handled.

Key takeaway

Perimeter firewall evidence does not cover laptops. Define "enabled" per platform, read the effective state from every device, record exceptions before anyone finds them, and keep dated readings for the full period. Search results do not rank how auditors weigh these; confirm the format and sample size with yours.

See how SAUTERA scores device evidence from live telemetry, including the honest "unknown" — start free with 10 devices for 30 days, no card.