OR 8 – Cyber-resilience Range of practices

Cyber-resilience, in the sense used by the Basel Committee on Banking Supervision, follows the Financial Stability Board definition published in the FSB Cyber Lexicon on 12 June 2018. An organisation is cyber-resilient when it can keep delivering its mission through a cyber incident. It does that in two ways: before an attack, by anticipating cyber threats and adapting to changes in its environment; and during and after an attack, by withstanding the incident, containing its spread and recovering quickly. The definition is about continuity of the mission, not about preventing every intrusion, which is why resilience is a wider idea than security.

Why supervisors have made cyber a priority

G20 finance ministers and central bank governors warned in March 2017 that malicious use of information and communication technology (ICT) could disrupt financial services that national and international systems depend on, damage confidence and threaten financial stability. Behind that warning is a change in how banks operate. Banks now automate more processes and plug their systems directly into those of customers and service providers, so the attack surface keeps growing and can be reached from anywhere. A larger and more reachable target, in turn, gives attackers a reason to invest in better capabilities.

Third-party reliance changes the perimeter that a regulator cares about. When more data is stored or processed outside the bank, and many providers are granted access to the bank’s own environment, the perimeter becomes larger. Cloud adoption adds a further twist, because the same infrastructure is used by many firms at once, so the perimeter is also shared. Banks therefore have to build cyber-resilience in partnership with their providers rather than alone, and the rising frequency, severity and sophistication of incidents has pushed legislators, regulators and supervisors to act.

Cyber-risk management versus IT risk management

The Basel Committee draws a deliberate line between two related disciplines. Cyber-risk management deals with vulnerabilities and threats, that is, with the adversarial side of technology risk. IT risk management is broader: it also covers project failures, system capacity, change management and many other issues that have nothing to do with an attacker. Most jurisdictions still supervise cyber through the lens of IT risk and general operational risk, so cyber expectations often sit inside wider IT guidance. Practices relevant to the wider idea of operational resilience were also considered where they bear on cyber.

Where the evidence comes from

The Basel Committee set up the Operational Resilience Working Group (ORG) to look at resilience beyond operational risk management and the minimum capital rules. The ORG’s range-of-practices report, issued in December 2018, compares bank, regulatory and supervisory practices across jurisdictions. It drew on what members had told the FSB in a survey run in April 2017; that survey fed the FSB stocktake of cyber-security regulations and supervisory practices published in October 2017. Members added their own supervisory experience, and outreach to banks, utility and technology providers, consultancies and industry associations refined the findings. Nine case studies take deeper dives into practices that are new or address widely shared concerns.

The FSB stocktake produced two findings worth remembering. Banking is the only part of financial services for which every FSB jurisdiction has put out a cyber-security regulation, guidance or supervisory practice of some kind. And jurisdictions built their schemes from a small common pool of references: mainly the 2016 CPMI-IOSCO guidance for financial market infrastructures, the cyber-security framework published in the US by NIST and the ISO 27000 series.

At international level, three initiatives frame the debate. In October 2016 the G7 set out what it called fundamental elements of cyber-security for financial firms. In June 2016 the CPMI, the central banks’ committee on payments and market infrastructures, joined IOSCO, the global body of securities regulators, in issuing cyber-resilience guidance for financial market infrastructures (FMIs). In the European Union, the European Commission’s Fintech Action Plan invited the three European Supervisory Authorities (ESMA, the EBA and EIOPA) to consider guidelines that would bring convergence on ICT risk.

How national rule-books handle cyber

Most jurisdictions do not have a standalone cyber rule-book. Their expectations sit inside IT risk guidance that covers IT governance and risk management, information security, recovery of IT services and outsourcing of IT, so cyber-risk management is covered as a subset of these practices. Standards on general topics such as business continuity planning and outsourcing also matter for cyber. At the 2017 meeting of the Information Technology Supervisors’ Group (ITSG), many countries reported that they were updating their outsourcing standards, and the Australian Prudential Regulation Authority (APRA) was considering whether “service provider risk management” now describes bank supply chains better than “outsourcing”.

A smaller group has issued cyber-specific or information security guidance. Examples include Hong Kong SAR (effective cyber-security risk management), Singapore (detecting cyber intrusions early), Brazil (setting a cyber-security policy) and the EBA (common procedures for assessing ICT risk). Where no financial-sector cyber regulation exists, supervisors push firms to adopt international standards, and supervisory practice follows the lead of national cyber agencies. Key concepts are commonly borrowed from NIST, ISO/IEC and COBIT (Control Objectives for Information and Related Technologies, an IT governance framework from ISACA), and supervisory practice draws on the US FFIEC IT Examination Handbook and on CBEST in the UK.

Common foundations have not produced common tools. Even where expectations derive from the same framework, each authority designs its own questionnaires, so a bank answers broadly the same questions in slightly different formats for each supervisor. Harmonising both the expectations and the information requested would reduce this burden.

Case study: enforceable minimum requirements in Australia, Germany and the US

Some jurisdictions are moving from principles to enforceable cyber standards. The table sets four examples side by side.

CPS 234 seeks to make incidents less likely and less damaging to information assets, whether the harm falls on their confidentiality, integrity or availability, and it explicitly reaches assets that related or third parties manage for the bank. The German approach layers requirements: the German Banking Act asks for adequate technical and organisational resources and contingency planning, MaRisk gives a framework for all significant risks, and BAIT refines the Act for IT. The US proposal, issued jointly by the three US federal banking agencies (the Federal Reserve, the OCC and the FDIC), targets the kind of serious incident that could threaten safety and soundness.

Most regulators do not require a separate cyber-security strategy, yet every one of them expects an information security strategy approved by the board, backed by policy and procedures, as part of effective oversight of technology. Many jurisdictions, including Australia, Brazil and several in Europe, expect cyber-risk to be covered by the organisation-wide risk management framework or the information security framework, monitored by senior executives. Regulators generally have principles-based guidance or prescriptive rules of varying maturity, and they tend to address enterprise IT risk without specific rules for cyber-risk in critical business functions, interconnectedness or third parties.

Supervisory work mirrors that. Examiners usually review the information security strategy and plans and the state of cyber-security implementation, including the main initiatives and their timelines, and sometimes how the bank communicates with stakeholders. Very few evaluate a standalone cyber strategy. Even within one region, approaches differ: the FFIEC handbook does not specifically address building a cyber strategy, while Canadian self-assessment guidance asks whether a bank has a cyber strategy aligned with its business strategy and implementation plan. Mexico has no supervisory practice on cyber strategy but has issued rules directing banks to develop IT security strategies.

Three ways to enforce strategy requirements

Jurisdictions use three approaches, and because they are not mutually exclusive, one regulator can combine them.

The Saudi Arabian Monetary Authority (SAMA) shows how two approaches can work together: it required institutions to write their own cyber strategies while it built supervisory practices for checking how those strategies were implemented.

Almost every jurisdiction stresses that management roles and responsibilities sit at the heart of cyber-governance and key controls. Some have issued specific guidance or requirements on the duties that the board of directors (BoD) and senior managers carry, and most of that guidance puts the board and senior management first; a few give them an even larger role in overseeing all business technology risks. Other jurisdictions treat cyber as one more risk that banks must handle inside their existing risk management frameworks.

The level of prescription differs. In the US, the EU and Japan, high-level guidelines encourage global and domestic systemically important banks (G-SIBs and D-SIBs) to put in place clearly defined management frameworks that respond to risk, driven by the board. The EBA goes further with granular, prescriptive requirements that keep cyber regulation consistent across the European banking sector, and emerging market economies also tend to be granular and prescriptive.

Three lines of defence and the neglected third line

Most regulators assess cyber-security risks and controls through the three lines of defence (3LD) model: the business and IT operations own the risk, an independent risk and security function challenges them, and internal audit gives assurance. Most regulators do not, however, require banks to implement 3LD or prescribe how responsibilities are divided, because they expect each bank to define responsibilities clearly and leave no gaps between the lines. Supervisory practice on 3LD therefore varies widely. Across jurisdictions, supervisors concentrate on the first and second lines more than the third, which can weaken the checks and balances the model is meant to deliver. Only a few jurisdictions say anything about whether the chief audit executive should have a direct, independent line to the audit committee of the board.

Where the CISO should report

Large, globally active banks typically build their cyber governance on 3LD, with the chief information security officer (CISO) as the executive responsible for cyber-security management. The CISO acts as a circuit breaker, weighing the firm’s risk appetite against security considerations well before new digital services or products are launched or expanded.

The usual arrangement places the CISO beneath either the chief risk officer (CRO) or the chief information officer (CIO), leaving no separate path to the CEO or the board. Emerging governance thinking sees placement under the CRO as a poor fit because the two roles pull in different directions. CROs tend to emphasise compliance, while a CISO trying to introduce risk-based controls that make room for innovation through the plan-do-check-act (PDCA) cycle needs freedom to accept some measured risk. When compliance is prioritised over the benefits of innovation, the CISO cannot do the job effectively, so some global banks now give the CISO a direct line to the chief executive or the board.

SAMA’s principle-based cyber-security framework illustrates a supervisory answer. It assigns the CISO responsibilities across the cyber-security committee, strategy, architecture, risk-based solutions and operational security. It also requires a cyber-security function independent of IT, with its own budget and staff evaluations, reporting directly to the CEO or managing director or to senior management of the control function. Institutions must run periodic self-assessments against the framework, which SAMA reviews on-site and off-site to judge compliance and maturity.

Staff awareness of cyber-risk inside each bank, and a shared risk culture across the industry, are preconditions for a resilient sector. Regulators in most jurisdictions have published guidance stressing awareness and culture at every level, including board members and third-party employees, and requirements extend to raising awareness and cyber-related staffing. Some regulators require awareness training at each stage of employment, from recruitment to termination.

Managing the insider threat

People inside the firm can be a source of cyber-risk, so several controls target them directly. Banks may have to put non-disclosure clauses in staff agreements. Some jurisdictions require screening and background checks for new hires and periodic reverification for existing staff. Others assess whether the bank’s processes make sure employees, contractors and vendors understand their responsibilities, fit their roles and have the skills needed to reduce theft, fraud or misuse of facilities. Some regulators judge how much cyber-risk each bank is willing to take in light of its business model, core strategy and key technologies, and some treat cyber-security as a business function critical to the bank, because one attack could make a bank insolvent or disrupt the whole sector.

Architecture and standards

In most jurisdictions there are no general requirements on security architecture, or coverage is thin. Only a few countries give detailed guidance. The FFIEC handbook, for instance, tells examiners reviewing network architecture to confirm that diagrams are current, securely stored and consistent with a defence-in-depth design, meaning several layers of control so that one failure does not expose the whole network. In Saudi Arabia, architecture practices are covered by periodic self-assessment.

The cyber-security workforce

Workforce skills, the rules governing them and supervisory practice vary markedly. Where IT-specific standards exist, supervisors look at how teams are divided, the expertise and background checks of specialists, training processes and whether funding and resources are sufficient to deliver the cyber framework. Most jurisdictions are still early in monitoring cyber workforce skills: they require banks to manage risk but set no specific requirement on cyber skills and resources.

On-site inspection, with the chance to talk to specialists, is the main assessment tool, self-assessment questionnaires are becoming common, and training receives close scrutiny. Supervisors have raised concerns about the capability or qualifications of a bank’s head of IT or information security. Rules on IT and security staff roles take different forms: dedicated regulations (Argentina, Australia, the EU, Japan and Saudi Arabia), provisions inside a global governance framework (Switzerland), requirements folded into board and senior management duties (Mexico, the US and Saudi Arabia), or the national cyber-security strategy (South Africa). Only Hong Kong, Singapore and the UK have dedicated frameworks to certify cyber workforce skills.

FISC is presented as a model for jurisdictions moving from prescriptive regulation towards risk-based, incentive-compatible models, because supervisors leverage industry expertise instead of writing every rule themselves. The HKMA scheme was developed in partnership with a local bankers’ institute and ASTRI, a Hong Kong applied research body.

Supervisors start from risk. They look at cyber alongside a bank’s scale, complexity, business model and earlier findings, and often sort institutions into categories that decide which banks fall within the scope of a given supervisory initiative. A supervisory programme is then agreed that covers both financial and operational resilience, guided by the relevant international and national legislation. Half of the EU jurisdictions have internal guidance on when a competent authority should run a cyber-security review, with triggers that include the bank’s own risk assessment, findings from inspections or questionnaires, and incidents, for example a trend analysis of cyber incidents.

Risk specialists and the evidence they use

Specialist IT and cyber risk teams judge whether controls are adequate by drawing on documentary evidence such as survey responses, physical inspections, incident reports and meetings in person. Many expectations follow industry standards such as COBIT and NIST, yet the approach, depth and breadth of assessments differ from one jurisdiction to the next. Most jurisdictions combine off-site and on-site work. An on-site review usually means one or more meetings at the bank’s premises; an off-site review is done at a desk from documents, or in a meeting held at the regulator’s office. Reviews sit either within broad technology assessments or within wider risk management assessments.

Equipping front-line supervisors

Regulated populations, and the size of specialist teams at each regulator, vary widely, so specialists cannot examine every bank in depth. Australia, Brazil and Singapore, among others, give front-line supervisors the knowledge and tools to triage IT risk issues: guidelines on identifying and evaluating IT risk, questionnaires, risk assessments and tools that quantify those assessments. Triage lets a generalist spot when a specialist is needed. A number of jurisdictions, including Australia and the UK, can also appoint an auditor or another third party to report to the regulator on a specific part of a bank’s risk management, cyber included.

Engaging with industry

Supervisors increasingly engage with the industry, either to influence behaviour or to gather views that shape regulation. In 2018 the French ACPR issued a discussion paper on IT risk and the UK PRA one on operational resilience. Speeches at conferences and other public communications reach a wide audience, and some publications take the form of white papers, annual reports or letters to industry. Some jurisdictions bring third-party providers into the conversation: in the EU, the European Commission’s FinTech Lab and the EBA’s FinTech Knowledge Hub have held events that put regulators, supervisors, industry and providers in the same room, which can be a faster and more responsive channel than formal publication.

Testing only makes sense once a bank knows what it is protecting. Most jurisdictions, among them the US, Singapore, Hong Kong, the EU and Australia, see mapping and classifying business services, and the assets and services that support them, as the foundation of resilience. Knowing which services are critical and which data are sensitive lets a bank design testing and assurance around complete, end-to-end business services rather than isolated systems. This mapping is normally done during business impact analysis, recovery and resolution planning, reviews of critical services’ dependence on external third parties, and the scoping of assessments.

Supervisors in a number of jurisdictions assess how banks monitor emerging threats, including real-time detection, the ability to spot adversaries before they move between systems, and supporting continuity and control policies. Some run thematic reviews, such as Sweden’s review of access controls and the management of user access rights. Others extend existing international standards to new types of institution; South Africa, for example, applies the CPMI-IOSCO guidance for FMIs to banks.

Independent assurance

Independent assurance tells management and regulators whether the right controls have been implemented and are working. Regulators also use the management information that these assurance activities generate as an extra input to their own assessments, which saves them collecting the same evidence twice.

Penetration testing and threat-led red teams

Banks set cyber controls through risk-based decisions measured against their risk appetite, and then test the controls on hardware, software and data that are meant to prevent, detect, respond to and recover from incidents. Supervisors review and challenge how banks test their controls and how they fix what testing finds. Evidence includes survey responses, threat and vulnerability assessments, risk assessments, audit reports and control testing reports such as penetration tests and health checks.

A penetration test is an authorised, simulated attack on a system to find exploitable weaknesses. Programmes of penetration tests run by the regulator exist in five EU jurisdictions, and guidance for banks on how to test has come from three: the UK, the Netherlands and the ECB. These tests are usually voluntary, paid for by the bank and aimed at larger, more systemic institutions. Threat-led red team tests are spreading: an external threat intelligence provider builds a realistic picture of who would attack the bank and how, and a separate penetration testing provider then plays that adversary. Most directed tests examine protective and detective capabilities, and only a few also probe response and recovery.

In May 2018 the ECB published TIBER-EU, short for Threat Intelligence-based Ethical Red Teaming. It was the first framework covering all of Europe for controlled, custom-built attack simulations on financial firms, and it makes it easier to test a cross-border entity that answers to several authorities. The authorities and the entity decide whether and when a TIBER-EU test happens. Each test is tailor-made, and none ends in a pass or fail: the output is insight into strengths and weaknesses that helps the entity raise its cyber maturity.

Using a taxonomy of controls to find supervisory gaps

Reviewing controls is only one piece of building cyber-resilience, but it gives supervisors a ready way to engage with banks. Some jurisdictions use a taxonomy, a structured list of control types, to check whether their own supervisory approach covers everything it should. If the authority cannot assess a type of control, because it has no supervisory approach, no assessment method or not enough skilled staff, that control type is logged as a gap. These taxonomies are currently specific to each jurisdiction and do not rest on harmonised concepts and definitions.

Most regulators want banks to have a framework or policy that spans the whole cycle from prevention and detection to response and recovery, incident reporting included. The detail varies by authority and is mostly not cyber-specific; only a handful have written continuity or disaster recovery rules aimed specifically at cyber. A few jurisdictions, such as China and India, make a cyber incident response framework a key component of cyber-governance. US supervisory guidance on incident management covers identifying indicators of compromise, analysing and classifying events, and escalating and reporting incidents. In Japan, the JFSA (Japanese Financial Services Agency) and the central bank watch potential threats as well and push information-sharing, so that cyber incidents reach the authorities without delay.

What supervisors look at

Reviews of service continuity plans check alignment with the bank’s risk management framework, the chosen business continuity strategy, IT disaster recovery arrangements and data centre strategy. Reviews of incident response and recovery plans focus on four things: how a plan is triggered, whether the bank can actually execute it, how data are preserved, and what specific actions apply to critical technology. In Canada, supervisors check that internal and external communication plans include every relevant stakeholder, so that a failure to inform one party does not let the problem spread.

The US, Japan, Hong Kong, Belgium and Australia, among others, review post-incident learning. They do this by discussing the bank’s response and its root cause analysis with the bank, although no further standard practice has emerged beyond that discussion.

Exercising versus testing

An exercise differs from a test. A test checks whether a control or plan works; an exercise lets supervisors and banks practise how they would respond to an incident, so that roles, decisions and communication become familiar before a crisis. Cross-border exercises have raised the profile of this practice. Examples include the UK and US exercise Resilient Shield in 2015 and TITUS, a November 2015 exercise in crisis communication among euro area FMIs, and a G7 exercise that was being planned in 2018.

Resilient Shield brought UK and US supervisors, government departments, cyber agencies and leading global financial firms together to improve cooperation in responding to a cyber incident in the finance sector, covering information-sharing, incident handling and public communications. Domestic exercises are also well established. In the UK, the Sector Exercising Group, part of the industry forum CMORG (Cross Market Operational Resilience Group), runs an annual exercise programme with cyber scenarios; CMORG has two co-chairs, UK Finance and the Bank of England. In Japan, the JFSA ran tabletop exercises, which are discussion-based walk-throughs of a scenario, to improve communication and coordination. Over 100 institutions, including banks, credit unions, insurers and securities firms, took part in the 2017 exercise covering two cyber scenarios, and a summary of results was published so others could learn from it.

Cyber metrics are not yet mature. Jurisdictions that do assess or benchmark cyber-security and resilience build their view from on-site inspections, penetration test results, surveys and the incidents banks report. Nothing produced this way yields the kind of standardised numbers or risk indicators that supervisors take for granted with financial risks, where long, established data sets exist. The indicators that exist describe a bank’s approach to cyber-security and resilience more broadly, and the management information that banks produce for themselves, which supervisors also lean on, varies between firms and is still immature.

Why the past is a weak guide for cyber

Banks and supervisors mostly track backward-looking indicators of how the technology function has performed, presented to the board and executives as management information that regulators may review. Using past performance to predict future performance is reasonable when operations and the risk environment are stable and largely independent of outside forces. Cyber-risk breaks that assumption because the adversary is adaptive. Attackers respond to a bank’s defences and can change tactics within a single incident. Distributed denial of service (DDoS) attacks show this clearly: the volume and scale of disruptive traffic rose significantly over the two years before the report, and attackers keep adjusting their techniques to the defences they meet.

Backward-looking metrics remain useful, but jurisdictions increasingly recognise the need for forward-looking indicators, direct and indirect, that signal whether a bank is likely to be more or less resilient if a risk crystallises.

What banks report to their boards

Banks are also improving their own metrics. A sample of cyber-centric metrics that banks give their boards and board committees shows that the data usually support trend analysis, so reviewers can see whether the position is improving or deteriorating. Some metrics track compliance with internal policy and others measure inherent risk. Patch ageing, the length of time known security patches remain uninstalled, is widespread and comparable across banks, which makes it a rare candidate for benchmarking.

Regulators can review the metrics that banks collect to learn what might be gathered across the whole regulated population, building a richer set of measures of the state of cyber-resilience. Taken together, such indicators can show whether a bank’s cyber and operational resilience fit its business needs and risk appetite. No single metric is sufficient on its own, though, and no standard set of indicators yet offers a meaningful benchmark.

Survey analysis is another source of indicators. The US, the UK, Singapore, Hong Kong, the ECB-SSM, Canada and Australia, among others, analyse survey responses to judge banks’ capabilities and prioritise follow-up. The results are bank-specific findings and remediation plans that can be tracked over time, or thematic reports; run regularly, they reveal trends. Australia publishes its survey results to influence industry behaviour, and the UK often shares thematic findings with participating firms for the same reason.

Most Basel Committee jurisdictions have cyber-security information-sharing mechanisms, mandatory or voluntary, that connect banks, regulators and security agencies. The common purpose is to help each party defend itself against emerging threats. Practices are grouped into five types according to who shares with whom.

Banks sharing with peer banks (type 1), banks sharing with regulators (type 2) and sharing with security agencies (type 5) are the types most often observed. Sharing among regulators (type 3) is the least observed, partly because it is less systematic: it tends to happen ad hoc, bilaterally or within supervisory colleges, when specific circumstances call for it.

Rows ordered from most to least common. The “without” column is 100% minus the reported share. Source: Basel Committee on Banking Supervision.

What kind of information moves through each channel

Four main kinds of information are exchanged: cyber-threat information or intelligence, information on cyber-security incidents, regulatory and supervisory responses to incidents or identified threats, and good practices in cyber-risk management. The mix depends on the channel. Incident information dominates sharing from banks to regulators (20 observed practices) and sharing with security agencies (18), whereas threat intelligence is the most common content of sharing among banks (18). Full adoption of every type of arrangement within a single jurisdiction remains exceptional.

Channels that substitute for each other

Some channels appear to stand in for others. Jurisdictions with active bank-to-bank sharing show fewer practices of regulator-to-bank sharing, probably because an effective peer mechanism reduces the need for the regulator to pass information on. Similarly, jurisdictions where banks share with regulators show lower rates of sharing with security agencies, which may reflect how responsibilities for processing cyber information are split between regulators and agencies.

A jurisdiction can run mandatory and voluntary arrangements side by side for the same type, because the rule can differ by kind of information or by counterparty. In Singapore, financial institutions must report relevant cyber incidents to the Monetary Authority of Singapore (MAS), whereas MAS swaps threat information with Singapore’s Cyber Security Agency (CSA) on a voluntary basis. Other arrangements include public disclosure of incidents and cross-sector sharing. Non-bank critical infrastructure operators, third-party providers and customers can feed information to security agencies for onward distribution, or join groups such as joint-industry forums. The EBA’s SREP guidelines for assessing ICT risk, and its recommendations on moving activities to the cloud, took a healthy flow of IT risk information between banks and supervisors for granted, even though banks were under no specific duty to tell supervisors about security incidents.

Banks pass knowledge of threats to peer banks mainly so that peers can act sooner against similar attacks. There is no common standard for automated sharing, and in most jurisdictions regulators do not take part in bank-to-bank exchange directly. What they do is help set up voluntary mechanisms for sharing vulnerability, threat and incident information, and sometimes indicators of compromise, the technical traces such as malicious file signatures or addresses that reveal an attack. Some jurisdictions run public sector platforms, others encourage the private sector to build information-sharing organisations, and some have public-private forums or government-led centres outside the information-sharing and analysis centre model. Three jurisdictions, Brazil, Japan and Saudi Arabia, have made sharing among banks mandatory through regulation or statute.

Two obstacles stand out. Local data protection rules are sometimes seen as a barrier to sharing and may call for a specific dialogue between banks and their regulators. And sharing depends on culture and trust. Experience suggests a two-level structure works well: information is first shared person to person within a small, close group, and then exchanged at company level with a wider set of banks, which builds trust into the system step by step.

Case study: FS-ISAC

FS-ISAC (Financial Services Information Sharing and Analysis Center) was set up in 1999 as a non-profit to tell financial sector members about potential vulnerabilities and to send early, reliable warnings that members can act on, covering physical and operational threats as well as cyber-attacks. Its members include banks, credit unions, insurers, investment firms, financial regulators and law enforcement. Beyond sharing, it runs conferences, seminars and sector and cross-sector contingency exercises, and it is internationally recognised as a threat intelligence source.

Incident reporting from banks to regulators

What banks share with regulators is generally limited to incidents, driven by reporting rules. The rules serve four purposes: letting the regulator monitor systemic risk; helping it tighten requirements or adjust policy based on what it learns; enabling oversight of how incidents are resolved; and supporting onward sharing with industry and other regulators to build a cyber-risk response framework. Different authorities set rules for different ends, such as prudential supervision, consumer protection, or passing information to national cyber agencies for systemic operators.

Incident reporting is mandatory in many jurisdictions, with varying scope. Where it has existed for some time, it covers operational incidents broadly, cyber included. It can apply to all supervised institutions but more often covers only systemically important ones. Nearly all institutions regulated in the EU must report cyber incidents to competent authorities. The obligations come from national law, from the PSD2 and NIS directives, and from supervisory frameworks, the SSM’s cyber incident reporting framework being one. Some regimes also require a root cause analysis, a full post-mortem or lessons learnt. Most supervisors track only incidents that have already happened, but some require proactive monitoring of potential threats, because worry about reputational damage can tempt a bank to delay reporting.

The fragmentation problem

Reporting channels range from formal submissions to informal updates by email or phone. Frameworks differ in four ways: the taxonomy used, the reporting deadline (observed practice ranges from immediate notice, through windows of two hours and of four hours, up to 72 hours), the templates, and the threshold that triggers a report. A bank active in several jurisdictions, or answering to several authorities, may fill in many templates with different taxonomies, deadlines and thresholds, consuming significant compliance resources. An authority with several functions could even receive several reports in different formats from one bank about one incident.

All reporting processes flow one way, from bank to authority, though an informal flow back can alert firms to an incoming threat. Reciprocal mechanisms that make two-way exchange routine can remove the stigma attached to reporting and so encourage effective and timely reports.

Regulators share with fellow regulators at home and abroad under mandatory or voluntary arrangements, and the content can include regulatory actions, responses and measures. It is the least observed type of sharing, even though many informal and ad hoc channels probably exist through supervisory colleges and memoranda of understanding. The case for doing more is clear: cyber fraud is growing more sophisticated and crosses borders, and regulators who share can keep each other aware of the threat picture and give banks timely guidance.

Case study: the HKMA and MAS bilateral framework

The HKMA and MAS set up a bilateral cyber-security information-sharing framework in the first quarter of 2018 and have exchanged information on real cyber threats and regulatory responses since April 2018. The design covers governance, scope, a traffic light protocol, a standard taxonomy and dedicated communication channels, and it rests on four guiding principles.

The Effective principle is what sets this framework apart from a supervisory college or memorandum of understanding, which normally covers only firms with a presence in both jurisdictions. The Traffic Light Protocol is a labelling convention that tells the recipient how widely a piece of information may be passed on.

Sharing from regulators to banks

Regulators pass on information received from banks and other sources. Australia, China, Korea, Saudi Arabia, Singapore, Turkey and the US, among others, have clear standards for this: information flows from bank to regulator, the regulator assesses the risk to the industry, and it shares what is appropriate. Sensitive content, such as customer-specific or bank-specific details, is anonymised or summarised first. Regulators with such a mechanism more readily share public information such as best practice, using industry platforms and forums, meetings and informal communications. Non-public information goes to selected parties through informal routes, protecting the anonymity of the affected bank and preserving trust in the regulator.

Only a few jurisdictions, such as China, make regulator-to-bank sharing mandatory; a few others, such as Singapore and the UK, have voluntary practices. Many have no standard practice and no process or time frame for timely, risk-based sharing. Classifying information would help the right audience receive the right information and build trust.

Sharing with security agencies

An incident at a bank may well hit firms in other sectors, so telling security agencies spreads awareness quickly and strengthens collective defences. Where a Computer Emergency Readiness Team (CERT) or similar agency exists, it can serve as the focal point for incident notification and pass information across the public sector, civil society and the wider computing community. Most jurisdictions use a voluntary approach, a few mandate formal sharing, and some run multilateral platforms. In the US, an online portal lets organisations submit information to the National Cybersecurity and Communications Integration Center and US-CERT. Luxembourg’s CIRCL (its Computer Incident Response Center) runs a Malware Information Sharing Platform (MISP) where organisations share malware details and indicators to improve countermeasures and detection.

Canada, France, Singapore and Spain mandate sharing with national security agencies, generally bilaterally, and only for incidents affecting key critical infrastructure operators rather than every incident. In the UK, financial authorities can invoke the Authorities Response Framework to convene the FCA, the Treasury, the Bank of England, the National Cyber Security Centre and the National Crime Agency so that their response is coordinated.

The CSIRTs network exchanges information on services and capabilities, discusses incidents on request and voluntarily, identifies coordinated responses on request, supports member states with cross-border incidents voluntarily, issues guidelines on operational cooperation, explores further cooperation such as early warnings and mutual assistance, and can discuss a CSIRT’s preparedness at that CSIRT’s request.

Every jurisdiction acknowledges how hard it is to gain assurance over someone else’s cyber-resilience, whether that is a regulator looking at a bank or a bank looking at its provider. Heavy use of third parties makes it harder for both to see what controls exist and how much risk is being run. For cyber-resilience purposes, “third parties” is read broadly and covers three groups.

Six themes organise the analysis: how the links are governed, continuity and availability of service, keeping data confidential and intact, how visible the links are to the bank, audit and testing, and the people and skills involved. This section covers governance; the next covers the other five.

The outsourcing framework and the contract

Regulators commonly require a management-approved or board-approved outsourcing framework. It sets roles and responsibilities, which activities may be outsourced and on what conditions, which risks must be analysed before choosing a provider or materially amending or renewing an agreement, and recurring duties such as monitoring and regular risk assessment. A contractual framework sits alongside it, defining the rights, obligations and responsibilities of bank and provider, who reviews, approves and signs contracts (for example, involving the cyber-security function), the requirement for an official, written and detailed contract, and whether it applies to intragroup outsourcing too, which it typically does.

Expectations on risk assessments and contracts are fairly comprehensive in listing which risks to cover, though mostly in general terms. Besides the service description, expected results and each side’s responsibilities, they should address the risks below.

Concentration risk here is a firm-level idea. It is not about systemic risk to the whole industry; it describes a single bank losing control because it has placed several activities with the same provider. Information security, cyber and continuity frameworks should also identify and prioritise interconnections, classify and respond to third-party incidents according to service agreements, and communicate these policies to relevant external parties.

How supervisors check governance

Two practices are widespread: intrusive on-site inspections of cyber-risk in outsourcing, which review the framework, the processes and the completeness of risk assessments and contracts; and off-site receipt of periodic reports assessing the bank’s outsourcing policies, processes, risk assessments and contracts.

Extending the scope to the whole ecosystem

Some international standards recognise critical dependence on interconnections beyond outsourcing. The CPMI-IOSCO guidance looks at cyber-risk from the perspective of an FMI’s whole ecosystem, and ISO 27031 sets requirements covering hardware, software, telecoms, applications, third-party hosting, utilities and environmental factors (cooling, fire suppression and monitoring of the physical environment). A number of jurisdictions require a prior agreement with internet banking clients that sets out each party’s responsibilities for the technologies used to identify and authenticate the client and validate transactions.

In Europe, the MiFID II Directive provides legal mandates governing how institutions, third-party providers and supervisors deal with one another, and 12 competent authorities can review IT third parties directly. Requirements on data are emerging: identifying at least one data centre for cloud services within a country or region such as the EU; identifying and monitoring data ownership and control (Australia) and data location (Brazil and France). Germany, Singapore and Switzerland require a clause reserving the bank’s right to intervene at, or give directions to, the provider. Most jurisdictions require prior notification or authorisation of material outsourcing, especially cloud, often using questionnaires or templates that help document risk assessments locally but are not harmonised. New expectations for secure development and procurement, such as Japan’s security-by-design requirements for internet of things systems, help keep rules future-proof as devices become ever more interconnected.

Case study: regulated third parties in Luxembourg

Luxembourg regulates firms that supply specialised services to financial institutions, called financial sector professionals (PSFs), under the same authorisation and supervision regime as the institutions, overseen by the CSSF, Luxembourg’s financial supervisor. PSFs offering only operational services are support PSFs. The aim is to make outsourcing easier by assuring quality and professional confidentiality. Ultimate responsibility stays with the outsourcing institution, in line with CEBS guidelines, although some institutions are tempted to neglect monitoring and audit because they assume the supervisor does it.

Cloud service providers (CSPs) are not PSFs. When CSSF criteria for cloud-based IT outsourcing are met, CSSF circular 17/654 applies. A bank can contract with a CSP directly or through a support PSF or non-regulated entity in a chain, and a cloud officer must be appointed for the entity operating the cloud resources.

Supervisory practice and the supervisory college idea

Mandates to supervise providers differ, so supervisors rely on traditional tools. Thematic self-assessment questionnaires on cyber and IT outsourcing risk are typical. Providers can be reviewed on-site either under formal authority (Hong Kong, Singapore and the US) or with the provider’s cooperation. Australia, for instance, holds voluntary periodic meetings with systemically important providers that host critical systems; these focus on the provider’s systemic role, allow open discussion of strategy, governance and controls, reveal how well banks oversee their providers, and let the regulator convey expectations. In the Netherlands, for instance, supervisors have worked with cloud suppliers so that contracts offered to the financial industry carry a right to audit.

Some large cloud providers hold regulatory summits where staff present to supervisors, a panel of regulators chosen by the provider opens a dialogue, and discussion then opens to all; sessions are typically not recorded, but the provider’s staff take notes. Summits could equally be run by regulators or an independent body to deepen examiners’ understanding of products and controls. A supervisory college for large, internationally active providers, particularly cloud providers, could address the blind spots created by limited mandates and fragmented regulation.

To keep critical activities running through crises such as cyber-attacks, regulators ask banks to analyse those activities, design and implement plans, procedures and technical solutions, and test the mitigating measures. The analysis is usually a business impact assessment. It ranks activities, resources and services by criticality, traces what each depends on inside and outside the bank, sets how long a disruption can be tolerated, lists the natural or man-made scenarios that could cause one, and estimates the damage. Where critical activities depend on third parties, continuity planning at critical suppliers, and at their own subcontractors, should be aligned with the bank’s own continuity and security needs.

Recovery objectives and testing

Recovery and resumption objectives are commonly set for critical activities end to end. The CPMI-IOSCO guidance expects an FMI to design and test its systems so that it can bring critical operations back safely no later than two hours after they are disrupted, and finish that day’s settlement before the day ends, even under extreme but plausible scenarios; some banking supervisors expect the same of systemically important functions. Italy requires risk scenarios for systemically important processes to include catastrophic events affecting essential operators and third-party infrastructures, such as large-scale cyber-attacks. Regulators typically focus on cloud outsourcing, settlement processes and internet services offered to customers.

Plans should set out tasks and responsibilities for incident management, response and recovery, the information needed from and given to key stakeholders, and the resources required, including planned redundancy so that an outsourced activity can be moved promptly to another provider if service continuity or quality is threatened. Most regulators expect periodic testing of protective measures. Advanced regulators require tests for critical activities to use realistic and probable disruption scenarios, to run at least yearly, and to involve service providers and significant counterparties through collaborative, coordinated testing, complemented by audits and monitoring of vendors’ availability and security incidents. Current expectations focus on each bank’s standalone continuity, and their common ground creates an opportunity to extend testing to a coordinated form covering more of the ecosystem.

Information confidentiality and integrity

General data protection rules usually cover third-party confidentiality and integrity by requiring confidentiality agreements and security requirements in contracts, and banks must make sure providers protect bank and client information by verifying, assessing and monitoring their security practices. More and more jurisdictions now set rules specific to the cloud, ranging from contractual clauses for data moved to the cloud to requirements on data location, segregation, use limitations, security and exit. In Luxembourg, cloud provider staff may not access a bank’s data without the bank’s explicit agreement and without a mechanism that lets the bank detect and control the access. Many jurisdictions require outsourcing to comply with rules on personal data, confidentiality and intellectual property. Technical requirements are more scattered: some require encryption of confidential data under the bank’s control, some regulate data transfers abroad, and some require explicit client consent for third-party data handling.

Visibility of third-party connections

Many supervisors want to be told about material outsourcing agreements and require the bank to keep a minimum level of visibility over the outsourced function. Banks are commonly expected to list every outsourced function in an inventory and to get regular reports from providers on service level measurements and control performance. Some jurisdictions require sub-outsourcing to be visible too, so that its risks can be managed. Luxembourg extends inventories to IT assets, identifying hardware and software and the function each supports, even when outsourced, under CSSF Circular 01/27. The FFIEC handbook and the CPMI-IOSCO guidance focus on connections and information flows with external parties.

National expectations and international standards complement each other. Supervisors’ expectations fit classic cyber frameworks built around identify, protect, detect, respond and recover, whereas standard-setters take a process view: ISO IEC 27036-2 covers configuration management, information management and termination of outsourcing relationships, and ISACA COBIT addresses implementing an information security management system. ISO and the NIST framework recommend identifying, documenting and categorising suppliers, and COBIT 4.1 and 5 recommend categorising suppliers and contracts by type, significance and criticality to set up an evaluation process. The scope, format and content of supervisors’ information requests on material outsourcing still vary greatly.

Auditing and testing

Audit expectations align in two respects. Most rules require banks to secure rights to inspect and audit their providers; some require these rights to cascade to significant subcontractors, and France, Switzerland and Singapore grant the right directly to supervisors. And in several jurisdictions the audit opinion can rely on the provider’s external auditor’s report; others accept pooled audits organised by several institutions, or audits by the provider’s internal audit department if it meets regulatory conditions, and some specify recognised standards or adequately skilled auditors. In June 2018, eight European financial institutions jointly audited a cloud provider they all used. Audit rights still focus on traditional outsourcing, sometimes cloud, and on the strict banking sector, so shared, independent audit reporting on critical interconnections could make auditing more effective and efficient. Banks must monitor providers’ compliance with security requirements, but rules do not agree on how compliance should be verified. Supervisor-led or bank-led intelligence-based red teaming focused on interconnections is one option, and the scope of a TIBER-EU test appears to include critical functions outsourced to providers.

Resources and skills

The Basel Committee’s Sound Practices on the implications of fintech for banks and supervisors, published in February 2018, notes that banks may need specialist skills to judge whether their risk functions can oversee risks from new technology. Staff should have the expertise to monitor outsourced services and manage their risks beyond mere compliance, and banks should keep enough qualified people to stay in control if key staff leave, bringing in external experts proactively where in-house know-how or numbers fall short. Belgium requires a monitoring and replacement plan for scarce, hard-to-replace staff crucial to critical activities. Banks should also give internet banking clients documentation on security awareness and safe use. Supervisors usually assess staffing during on-site inspections, and where they can examine providers directly they check the providers’ staffing and background checks. Certified Information Systems Security Professionals, or a provider certified to ISO 9001 for quality management, can give additional assurance of competence.