Financial services companies have spent years building security controls and processes around the systems responsible for moving money and keeping customer accounts and services running. Identity and access management (IAM), multi-factor authentication (MFA), network security, vulnerability management, and logging are all familiar parts of that environment.
The Digital Operational Resilience Act (DORA) places greater emphasis on how those controls support the continued operation of critical services as conditions change. Reviews and assessments provide a point-in-time view of an organization’s protections. Operational resilience depends on keeping those protections effective between assessments.
Access governance has to keep pace with change
Employees move between business units, and contractors rotate through projects. But temporary exceptions can remain in place long after their work is completed. Over time, changes can leave access to critical systems misaligned with what people actually need.
An employee moving from payments into another business unit, for example, may stop working with transaction processing immediately while retaining permissions to the underlying system. Across a large institution, accumulated role changes and exceptions can leave sensitive access increasingly disconnected from current responsibilities.
Identity and security teams need governance processes that update permissions as those responsibilities change, alert security administration to anomalies, and help maintain least privilege over time. Privileged access warrants particular scrutiny because administrative permissions can provide broad access to critical systems, while MFA strengthens assurance around the identities exercising sensitive access.
Those practices also need to reach every system involved in the underlying business process. A payment workflow may pass through newer applications protected by modern IAM and MFA, and then into a long-standing host environment governed through a different access model. Consistent governance across that path reduces gaps created by differences in technology.
Containment protects the rest of the service
A critical vulnerability discovered in a component supporting online banking can force operations and security teams to act quickly. They may need to isolate the affected component or otherwise limit its impact while keeping unaffected customer services available.
Network segmentation can limit the blast radius by reducing the number of systems an affected component can communicate with. Combined with secure configurations, it can reduce unnecessary paths through the environment and help teams focus remediation on the systems and services most at risk.
Those protections determine how precisely teams can intervene. An architecture that allows a component to be isolated gives responders a way to address the immediate risk while preserving unaffected parts of the service. Tightly coupled dependencies can make the same intervention much more disruptive.
Understanding those dependencies before an incident occurs gives security and operations teams more practical options when they have to act. They can make containment decisions based on the services actually at risk and preserve more of the surrounding operation during remediation or recovery.
Visibility turns incident data into operational decisions
Suppose monitoring detects unusual activity involving customer records on a core system. Responders need to establish what occurred and how far it reached before operations teams can determine the appropriate response. One needs answers to questions such as:
- Which user or process accessed the records?
- What actions were taken?
- Did the activity extend into connected applications or networks?
- Which customer services may be affected?
When identity events, host activity, application logs, and network events are managed separately, assembling those answers can consume time that responders need for containment and recovery.
Centralized alert management and continuous monitoring help connect activity across systems, while tamper protection preserves evidence teams can rely on during an investigation. With that context, responders can target containment around the systems and activity involved and determine which services can continue operating safely. The record created during that response also supports DORA’s governance and reporting requirements.
The ability to establish what happened quickly therefore serves both an immediate operational need and a longer-term governance one. Teams can act on reliable information during disruption while preserving a defensible account of how the institution managed it.
Resilience becomes part of operating critical services
DORA brings security architecture, operations, and governance closer together around the services the institution needs to preserve, including the host systems that remain central to many critical financial workflows. Rocket Secure Host Accesshelps financial services teams extend centralized access management, MFA support, and visibility into host access activity across those environments. Rocket z/Assurance offers the risk evidence and validation that provides leadership with defensible governance.
For CIOs, DORA makes operational resilience an ongoing architecture and management responsibility. Technology estates will continue to evolve, and the dependencies supporting critical financial services will evolve with them. Building resilience into those environments helps teams make changes with a clearer understanding of how they could affect the services the business needs to keep running.
Learn how to strengthen mainframe resilience and support ongoing DORA compliance with Rocket Software’s DORA Action Guide
Read More from This Article: What continuous operational resilience looks like under DORA
Source: News
