Protecting ICT Systems

Protecting ICT systems means putting controls in place that reduce the chance of a disruption and limit its effect when disruption happens. Protection covers access control, secure configuration, patching and vulnerability handling, network separation, data protection, and the secure design of systems and changes. The controls are chosen from the risk picture for a service, so that effort goes where interruption or compromise would hurt that service most.

Protection is preventive, but it is not absolute. No set of controls removes risk entirely, and DORA treats protection as one part of a framework that also detects, responds, and recovers. A protection story that claims completeness misses the point. The useful question is whether protection, for this service, makes disruption less likely, less widespread, and easier to recover from.

Protection is chosen by working from the service map and its risks. Systems that carry sensitive customer data, that process payments, or that sit on the path of several services attract stronger protection than isolated, low impact systems. That differentiation is deliberate. Treating every system identically spreads effort thinly and leaves the most consequential systems no better protected than the least consequential ones.

Choice also involves trade offs that are worth naming. Stronger access control can slow legitimate work if it is designed without regard for how staff actually use a system. Network separation can complicate recovery if restored systems cannot reach the data they need. Protection design therefore involves the people who run the service and the people who recover it, not only the people who design the control. A control that hinders recovery has protected a system at the expense of the service.

Access control decides who, and what, can reach a system, a data store, or a privileged function, and under what conditions. It includes identity management, the separation of duties between those who build, approve, and operate a system, and the careful handling of privileged accounts that can change or disable protections. Where access is broad or long lived, a single compromised account can turn a local incident into a service wide one.

Secure configuration and patching keep systems in a known, supportable state. Configuration standards define how a system is built and hardened, patching and vulnerability handling address known weaknesses, and change discipline prevents a well configured system from drifting into an unknown state. Drift is a quiet risk. A system that was secure when it was built can become exposed through a series of small, individually reasonable changes that were never reviewed together.

Data protection within ICT risk management is about preserving the integrity, confidentiality, and availability of data that a service depends on. Encryption, access restrictions, and data handling rules protect data in storage and in transit. Backups, where they are part of protection as well as recovery, protect against loss and corruption, provided the backups themselves are protected, separated from the live environment, and tested for restoration.

The data lens also changes how protection is prioritised. Corrupted data can be harder to recover from than an unavailable system, because a system can be restarted while corrupted data may propagate through processing before anyone notices. Protection therefore pays attention to data flows, to the points where data is transformed or shared with a supplier, and to the ability to return to a known good state. Those points are often where a service is most fragile.

Protection reaches its limits at the boundary of knowledge and at the boundary of the entity. Unknown vulnerabilities cannot be patched before they are known. A supplier system cannot be hardened directly by the entity that depends on it, only influenced through contract, assurance, and contingency planning. A determined attacker may find a route around a well designed control. Those limits are not a reason to weaken protection. They are the reason detection, response, and recovery exist alongside it.

Overconfidence is the more subtle limit. A control that has never been tested under realistic conditions can look strong while harbouring a flaw in its configuration or its coverage. Testing, incident experience, and review are how protection claims are checked against reality. A protection narrative that rests only on the existence of controls, without evidence that they operate as intended for the service, is incomplete under the DORA framework.

Protection shapes detection by defining what normal looks like for a service and its systems. When access patterns, configuration, and data flows are known, unusual activity stands out more clearly. Conversely, detection findings feed protection, because an alert that reveals a bypassed control or an unpatched weakness points directly to the protection gap that needs closing. The two parts improve each other when their findings are shared.