Keeping the critical system walled off.
DORA's Art. 9 (protection and prevention) is about protecting the security of ICT systems and minimising the impact of ICT risk, including by segmenting and isolating systems so that a problem in one place does not spread to a critical function. For a financial entity that isolation is built in code and configuration: the network boundaries, firewall rules, and security groups that keep a payments or core system walled off.
The shapes the same control failure takes.
Protection erodes when a change flattens a boundary that was keeping a critical system isolated. The recurring shapes:
Segmentation between zones is flattened
A boundary that separated a critical financial system from the general network is opened up, so a compromise elsewhere can now reach it.
A protective deny rule is widened
A firewall or security-group rule that allowed only a narrow source is broadened to a whole subnet or VPC, removing the isolation it provided.
A critical function becomes broadly reachable
A core system is made directly reachable from a wide zone rather than a specific, vetted source.
Egress controls are dropped
Restrictions on what a critical system can reach out to are removed, so a compromised component can call out freely.
An isolation mechanism is removed
A control that would have contained an incident (a separate subnet, a bastion, a deny-by-default boundary) is taken out for convenience.
A payments subnet opened to the whole VPC.
A payments service runs in a segmented subnet reachable only from a narrow gateway. To make a new internal integration work quickly, a change opens the subnet to the entire VPC. The integration works, and the isolation that contained a compromise to one zone is gone.
ingress { from_port = 443- security_groups = [aws_security_group.payments_gateway.id]+ cidr_blocks = ["10.0.0.0/16"] # the whole VPC}Opening the payments subnet to the entire VPC removes the segmentation that kept the critical system isolated, so a compromise anywhere in the network can now reach it. Art. 9 (protection and prevention) expects measures like segmentation to protect ICT systems. Scope the rule to the specific gateway that needs access.
Protection is checked against how critical systems are isolated.
Supervision under DORA looks at how a financial entity protects and isolates its ICT systems, especially the ones supporting critical functions: segmentation, access boundaries, and the controls that would contain an incident. A change that flattened a boundary or widened a protective rule is the concrete weakening of that, and it is visible in the diff to the network or infrastructure config.
A review, not your network architecture.
heygrc flags changes that touch a DORA protection obligation and cites the article so the fix happens in the pull request. It does not design your network or run your segmentation. It catches the moment a change flattens a boundary that kept a critical system isolated, at the diff. heygrc is in early access.