Cybersecurity and operational resilience for banks and NBFCs

Identify the services that matter to customers

Start with important business services rather than a list of servers. Examples may include accessing funds, processing repayments, disbursing approved loans or producing time-sensitive regulatory information. Define what successful delivery means from the user's perspective.

Map each service to its supporting people, processes, data, technology, premises and suppliers. Include interfaces between systems and organisations. A service can fail because a small dependency is missing even when its primary application remains available.

Assign a business owner for the service. Technology teams may operate the systems, but the business owner needs to understand customer consequences, acceptable workarounds and priorities during disruption. Shared ownership without clear decision rights can delay recovery.

Distinguish tolerances from recovery targets

A tolerance for disruption describes the level of disruption the institution seeks to remain within for a critical operation. Recovery targets describe intended restoration times or acceptable data-loss points for supporting systems. These concepts should be related, but they are not interchangeable.

A system restored within its target may still leave a service unavailable because another dependency is missing. Equally, a business workaround may temporarily support customers while technical recovery continues. Test the complete service outcome rather than only individual system timings.

Document assumptions behind the targets. They may depend on staffing, supplier availability, network access or the ability to reconcile delayed transactions. A target without those dependencies can create false confidence.

Control access throughout its lifecycle

Access should reflect legitimate job responsibilities and the sensitivity of the information or action. Establish a controlled process for granting, changing and removing access, including privileged permissions. Staff transfers and departures need timely treatment.

Review service accounts, integrations and supplier access as well as ordinary users. These identities can have broad permissions and may outlast the person who originally requested them. Each should have an owner and a justified purpose.

Evidence should show that required changes occurred. A manager's instruction to remove access is not the same as confirmed removal. Periodic review should examine actual permissions and significant exceptions, with a route for resolving inappropriate access.

Treat technology change as a risk event

A routine release can disrupt a service or weaken a control. Assess the effect of changes on security, data integrity, integrations, reporting and recovery. Testing should reflect the business consequences of failure, not only whether the new feature works.

Define rollback or recovery arrangements before deployment. Some changes cannot be reversed simply by restoring an earlier application version because data structures or external interfaces have changed. The plan should reflect those constraints.

Separate development, testing and production responsibilities as appropriate. Emergency changes may need a faster route, but they still require defined authority, evidence and subsequent review. Urgency should not erase the record of what changed and why.

A worked example: a repayment service outage

Suppose a hypothetical lender's repayment-processing service becomes unavailable during a busy collection period. The customer interface recovers quickly, but some payment confirmations were delayed and a subset of transactions remains unmatched.

Declaring recovery based only on the restored website would be premature. Operations needs to reconcile incoming payments, identify duplicates or omissions and prevent inappropriate collection activity against customers who have already paid. Customer communication should reflect what is known and what remains under investigation.

The incident closes only after the relevant service and data outcomes are verified. The example shows why technical availability, financial integrity and customer treatment need to be assessed together during recovery.

Build an incident process around decisions

Incident management should establish who coordinates, who investigates, who can authorise actions and who communicates with customers, management and relevant authorities. The reporting obligations and timelines must follow the applicable framework, rather than a generic internal target.

Maintain a chronology of detection, assessment, containment, recovery and significant decisions. Distinguish confirmed facts from working hypotheses. This supports both effective response and later review without forcing responders to produce a polished narrative during the most urgent period.

Define escalation based on consequences as well as technical severity. A relatively small system defect can have significant customer or regulatory effects. The incident classification should allow those effects to influence the response.

Test restoration, not just backup completion

A successful backup job indicates that a process ran. It does not prove that the institution can restore the right data, within the necessary time, to a trustworthy environment. Recovery testing needs to demonstrate those outcomes.

Select scenarios that challenge assumptions. Consider unavailable administrators, corrupted data, missing dependencies and supplier disruption. Verify that recovery instructions are accessible when normal systems are unavailable and that authorised substitutes can use them.

After restoration, reconcile important records and transactions. A system can be technically operational while containing incomplete or inconsistent information. Business validation should therefore be part of the recovery acceptance criteria, with named owners and retained evidence.

Include third-party dependencies in resilience planning

Critical services may depend on cloud platforms, communication providers, processors or specialist support. Understand where these dependencies overlap and what the institution can do if they fail. Several services may share one underlying provider even when their direct suppliers differ.

Compare the supplier's recovery commitments with the institution's needs. A contractual service level may not cover every disruption scenario or guarantee immediate access to support. Test communication and escalation routes rather than assuming they will work.

Retain alternatives where practical and assess their limitations. A manual workaround may handle a small volume but become unsafe at scale. Record capacity, data requirements and the point at which the workaround needs another decision.

Connect resilience with information protection

Recovery and continuity activities often involve copying data, granting temporary access or using alternative channels. These actions can introduce confidentiality and integrity risks. Plan appropriate controls in advance rather than weakening protection ad hoc during an incident.

Apply relevant data-handling and retention requirements to incident evidence. Logs and investigation files can contain personal information or security-sensitive details. Limit access and sharing to justified purposes, while preserving the records needed for investigation and required reporting.

The Basel operational-risk principles provide broader context for technology and change-related controls. ^[2] In practice, resilience and security teams need a shared understanding of how emergency actions will remain authorised, traceable and reversible where possible.

Distinguish a successful exercise from a controlled exercise

An exercise can finish successfully because participants received advance information, used staff who would not normally be available or skipped a difficult dependency. Those choices may be reasonable for a limited test, but they should be documented as limitations rather than hidden.

Define the exercise objectives and permitted assistance in advance. Record actual timings, decisions and unexpected workarounds. Observers should note where participants relied on personal knowledge that was absent from the plan.

Consider a sequence of tests with increasing realism. A document walkthrough can clarify roles, a technical recovery test can verify restoration and an integrated exercise can examine the service outcome. Each produces different evidence.

The final report should distinguish what was demonstrated from what remains untested. Management can then decide whether additional testing or remediation is needed. A simple pass label is less useful than a clear account of the capabilities established and the assumptions still requiring proof.

Learn from exercises and actual disruption

An exercise should identify decisions, dependencies and failure points, not merely demonstrate that participants know the plan. Record what did not work, assign corrective actions and verify them in later testing. Repeating the same exercise with the same unresolved defects creates little additional assurance.

After an incident, distinguish the immediate technical cause from contributing process weaknesses. An expired certificate may trigger failure, while incomplete ownership records and missed monitoring explain why it was not addressed. Remediation should cover both levels.

Operational resilience becomes credible when the institution can demonstrate service continuity or safe recovery under realistic conditions. Asset inventories, access reviews, incident plans and backups are inputs. The outcome is the ability to protect customers, preserve reliable records and make timely decisions when normal operations are disrupted.