Your change window closed 72 hours ago. You have a signed-off ticket, a CAB approval, and a completed implementation note. What you probably don’t have is certainty that the only thing that changed on your firewall was the thing in that ticket. Change windows create a documented record of intent. They don’t create a verified record of reality.
This post covers the gap between change control policy and actual firewall state: why the gap exists, what it costs you during an audit or incident, and what it takes to close it.
Key takeaway: A change window is a process control. It governs when and how changes are supposed to happen. It does not detect what actually happened. Without continuous change detection layered on top of your change control process, your audit trail is a record of approvals, not a record of state.
What a Change Window Is Actually Supposed to Do
Change window (network security): A scheduled, pre-approved maintenance period during which configuration changes to network infrastructure may be made. Change windows are a process control designed to limit uncoordinated modifications, reduce the risk of production impact from unplanned changes, and create a documented record for audit purposes.
That definition is accurate as far as it goes. Change windows reduce the frequency of ad-hoc modifications, give teams a coordination point, and create a paper trail that satisfies documentation requirements in frameworks like PCI DSS v4.0 Requirement 1 and NIST SP 800-128. The problem is what they don’t do: they don’t verify that the only changes made during the window were the approved ones, they don’t catch changes made outside the window, and they don’t compare pre-change and post-change state unless someone explicitly runs that diff.
Most teams treat the closed ticket as proof the change was clean. It isn’t.
Misconfigurations Drive the Majority of Firewall Breaches
The reason this matters operationally is the breach data. Gartner has estimated that 99% of firewall breaches are caused by misconfigurations, not firewall flaws. That figure is not a rounding error. It reflects a structural reality: the firewall product is not the failure point. The management of it is.
Gartner estimates 99% of firewall breaches are caused by misconfigurations, not firewall flaws. The product isn’t failing. The change process is.
The Verizon 2025 Data Breach Investigations Report adds another dimension: exploitation of edge devices and VPNs surged nearly eightfold year-over-year, from 3% to 22% of breach entry vectors. Firewalls are edge devices. When attackers target them, they’re frequently exploiting permissive or misconfigured rules, not zero-day vulnerabilities in the firewall software itself. Many of those permissive rules exist because a change window opened them and nothing ever confirmed they were closed.
Three Ways a Change Window Fails You
These failures aren’t exotic. They happen on normal change nights at organizations with mature ITSM processes and signed CAB approvals.
1. The change was scoped wrong
The engineer implementing the change made reasonable judgment calls in the moment. A rule got added to make the primary change work. A temporary access policy got left in place because removing it was out of scope for that window. An object group got modified that wasn’t referenced in the ticket. None of this is malicious. All of it is undocumented. If your firewall policy review happens quarterly, these incremental deviations compound for 90 days before anyone looks at them.
2. The change happened outside the window
Production incidents don’t wait for Tuesday nights. When a critical application goes down at 2 PM Friday, someone is logging into the firewall to fix it. The change may be correct and necessary. It may even get backfilled into the ticketing system afterward. But the backfilled ticket was written after the fact, the change wasn’t peer-reviewed before it went in, and the firewall state has been different from your documented baseline since 2:17 PM Friday.
3. The change was never reversed
Temporary rules are the most persistent things in any firewall policy. A rule opened for a vendor engagement, a testing exception, a holiday support window: these go in with a plan to remove them and stay in because no one owns the cleanup. Change windows govern the insertion of changes. They rarely govern expiration. Over time, the delta between your firewall’s current state and its documented intended state grows purely through accumulation. This is exactly the failure mode behind the 2026 Marquis ransomware breach, where exposed firewall configurations tied to legacy SonicWall systems had been sitting undetected for months before attackers exploited them.
What Compliance Frameworks Actually Require
If you’re operating under PCI DSS, SOC 2, or ISO 27001, your change window process satisfies some requirements but not all of them. The gap is consistent across frameworks: change control covers the process of making changes, while detection and monitoring requirements exist separately and require active tooling to satisfy.
| Framework | What Change Windows Satisfy | What They Don’t Cover |
|---|---|---|
| PCI DSS v4.0 | Req 1.2.2: formal change process for firewall rules; approval records with business justification | Req 1.2.1: current and accurate network diagram; evidence that only approved changes were implemented |
| SOC 2 (CC6.8) | Change management procedures, approval records, CAB documentation | Detection of unauthorized changes; evidence that only approved changes were implemented |
| ISO 27001 (A.12.1.2) | Change management policy and procedures | Monitoring for unauthorized changes; formal review of changes against baseline |
| NIST SP 800-128 | Configuration change control processes, approval workflows | Continuous monitoring of configuration state against an approved, verified baseline |
The PCI DSS finding is particularly sharp. PCI DSS v4.0 strengthened Requirement 1 specifically because auditors kept finding documentation gaps: rules with no business justification, approval records that couldn’t be produced, and network diagrams that didn’t match current state. A CAB approval workflow in ServiceNow doesn’t produce evidence that an unauthorized change didn’t occur. An auditor asking for continuous monitoring evidence wants logs, alerts, and configuration diffs, not a policy document.
The Capital One Breach Is the Textbook Case
The 2019 Capital One breach is worth examining specifically because it involved a misconfigured firewall, not a zero-day exploit. The attacker, a former AWS engineer, exploited a misconfigured web application firewall that had been granted overly permissive IAM role permissions. The WAF could query the AWS EC2 metadata service and retrieve temporary credentials. Those credentials then accessed S3 buckets containing 106 million credit card applications.
The misconfiguration wasn’t introduced by an attacker. It was a legitimate change that left an excessive permission in place. The kind of change that passes a CAB review, gets documented in a ticket, and then sits in production indefinitely because no one diffed the post-change state against the intended baseline. The change window closed. The misconfiguration stayed open.
Risk note: Under PCI DSS v4.0 Requirement 10, audit log files must be protected from destruction and unauthorized modification and must be available for at least 12 months. If your only change record is a ticket system where someone backfilled or modified an entry after the fact, that record doesn’t satisfy the tamper-evidence requirement.
What Shadow Changes Look Like in Practice
Shadow changes are configuration modifications that occur outside the formal change control process. They aren’t always malicious. They’re often pragmatic decisions made under time pressure by people who have legitimate access to the firewall. The problem isn’t the intent. The problem is that they’re invisible to your change management system, your audit trail, and your compliance evidence package.
Common sources of shadow changes in enterprise environments:
- Emergency access rules opened during incidents and not cleaned up after resolution
- Vendor or contractor access granted directly by a network engineer without a formal ticket
- Policy adjustments made by a junior admin to resolve a connectivity complaint, below the threshold where they felt a formal ticket was warranted
- Automated scripts or orchestration tools that modify firewall policy as part of provisioning workflows, with no corresponding ITSM integration
- Firewall vendor management platforms (FortiManager, Panorama, FMC) pushing policy updates that aren’t reflected in the ticketing system
For MSPs managing firewall policies across multiple client environments, the exposure is multiplied. A shadow change in one tenant’s policy doesn’t appear in any other tenant’s audit trail, but if you’re managing shared infrastructure or overlapping address spaces, the ripple effects can cross boundaries in ways your change window process has no visibility into.
What Continuous Change Detection Actually Requires
NIST SP 800-128 describes Security-Focused Configuration Management (SecCM) as a continuous activity that monitors configuration state against an approved baseline throughout the system lifecycle. The key word is continuous. Quarterly configuration reviews don’t satisfy that requirement. A manual diff run before an audit doesn’t satisfy it either. The standard calls for ongoing monitoring with detection capabilities, not point-in-time snapshots.
The functional requirements for continuous change detection are:
- Baseline capture. A point-in-time snapshot of firewall configuration that represents known-good state, stored in a tamper-evident format external to the device itself.
- Continuous comparison. Automated polling or event-driven triggers that compare current configuration against the baseline and flag any delta in real time.
- Change correlation. The ability to map a detected configuration change to an open, approved change ticket. If there’s no ticket, the system alerts. If there’s a ticket, it logs the change as authorized. This is the automation that closes the gap between intent and reality.
- Out-of-window detection. Alerting specifically when a change is detected outside a defined change window, regardless of whether a ticket exists.
- Tamper-evident audit log. A record of every detected change, timestamped and stored independently of the firewall itself, so a compromised device can’t modify its own change history.
Closing the Gap: What to Actually Do
If you’re running a mature change management process and still don’t have continuous firewall change detection, here’s the practical remediation path:
- Establish a verified baseline. Don’t assume your current documented policy matches your actual running config. Pull the current config from every managed device and diff it against your last documented baseline. Treat any delta as an unauthorized change until proven otherwise.
- Define change windows in your detection tooling, not just your policy. Detection tools should know your change window schedule so they can classify changes as in-window vs. out-of-window automatically. Manual classification at review time is too slow and too error-prone.
- Integrate change detection with your ticketing system. Every detected change should automatically query your ITSM for an open, approved ticket in the relevant window. Unmatched changes generate an alert. Matched changes get logged as authorized. This is the closure mechanism your change window process is missing.
- Store configuration snapshots outside the firewall. Configuration history stored only on the managed device is not a reliable audit record. Store snapshots in an external, access-controlled system with versioned storage.
- Validate your rollback capability now, not during an incident. If you detect an unauthorized or incorrect change, how long does it take to restore known-good state? If the answer involves manually re-entering config, your rollback is a manual process. Automated rollback to a versioned, verified snapshot is the operational standard to work toward.
Key takeaway: Change windows manage the process of change. They don’t detect unauthorized changes, verify implementation accuracy, or produce the continuous monitoring evidence that PCI DSS, SOC 2, and NIST frameworks require. Until you have automated change detection correlated to your approval workflow, your change window is producing a record of approvals, not a verified audit trail.
CyberX is built specifically for this gap. It captures verified firewall configuration baselines, detects every change in real time, correlates changes against approved requests, and generates tamper-evident audit logs that satisfy the continuous monitoring requirements your change window process can’t address on its own. If you’re carrying compliance risk because your change records document approvals but not outcomes, that’s exactly what CyberX closes.