Cybersecurity & Fraud Analytics

Chapter 4
Cybersecurity Governance, Risk and Compliance

Post Graduate Program in Banking
Cybersecurity & Fraud Analytics   •   Post Graduate

Cybersecurity Governance, Risk and Compliance

Introduction and Context

Cybersecurity in banking is a governance problem as much as a technical problem. Banks operate interconnected payment, lending, treasury, customer-service, cloud and third-party environments. A weakness in one environment can affect confidentiality, integrity, availability, financial stability and public confidence. Consequently, cybersecurity decisions must be linked to business strategy, risk appetite, regulatory obligations and board oversight.

Cybersecurity governance is the system by which an institution directs, controls and monitors information and technology risk. It determines who has authority, how risk decisions are made, what evidence is required, and how management demonstrates that controls are effective. Compliance is narrower: it concerns conformity with laws, regulations, contractual requirements and recognised standards. Compliance is necessary but not sufficient. An organisation may satisfy a checklist while remaining exposed to an attack that its risk assessment failed to anticipate.

This chapter examines the relationship between governance, risk and compliance (GRC), with particular attention to the NIST Cybersecurity Framework (CSF), ISO/IEC 27001, COBIT, the three-lines model, Basel operational-risk principles, PCI DSS, the SWIFT Customer Security Programme (CSP), privacy requirements and board accountability.

Learning Objectives

By the end of this chapter, the learner should be able to:

  1. Explain cybersecurity governance and distinguish it from cybersecurity management and compliance.
  2. Apply NIST CSF, ISO/IEC 27001 and COBIT to banking control environments.
  3. Analyse the three-lines model and allocate responsibilities appropriately.
  4. Interpret regulatory expectations concerning operational resilience, outsourcing, payment security and privacy.
  5. Construct a risk-based compliance and assurance approach for a bank.
  6. Evaluate board and senior-management accountability for cyber risk.

1. The Governance–Risk–Compliance Relationship

Governance establishes direction and accountability. Risk management identifies uncertainty, assesses its potential effect on objectives, selects responses and monitors residual exposure. Compliance translates external obligations into internal requirements and tests whether those requirements are met.

A useful conceptual relationship is:

Governance → risk appetite and accountability → risk management → controls and treatment → assurance and reporting → governance decisions.

Cybersecurity governance should answer five questions:

  • What information and services are critical?
  • What level of disruption or loss is acceptable?
  • Who may accept residual risk?
  • What controls and capabilities are required?
  • What evidence will demonstrate that controls work?

A control is not merely a policy statement. It includes a design, an owner, an operating process and evidence of operation. For example, a privileged-access policy is incomplete unless the bank identifies privileged accounts, approves access, records activity, reviews access periodically and removes unnecessary privileges.

Risk terminology

Inherent risk is exposure before considering controls. Control effectiveness concerns whether a control is suitably designed and operates as intended. Residual risk is the remaining exposure after controls. Risk appetite is the amount and type of risk an institution is willing to accept in pursuit of its objectives. Risk tolerance is the acceptable variation around a specific objective or service level.

A simple qualitative model is:

Risk rating = Likelihood × Impact

Likelihood and impact may be scored on ordinal scales, such as 1 to 5. This multiplication is a prioritisation convention, not a statistical probability calculation. It assumes that the scales have been defined consistently and that decision-makers understand their limitations. A score of 15 does not mean that the event has a 15 percent probability.

Where reliable data exist, expected loss may be estimated as:

Expected annual loss = Event frequency × Loss per event

Event frequency is measured in events per year and loss per event in currency; therefore expected annual loss is expressed in currency per year. This estimate is useful for comparing alternatives but can be unreliable for rare, dependent or rapidly changing cyber events.

2. The NIST Cybersecurity Framework

The NIST CSF is a risk-management framework rather than a prescriptive control catalogue. Its core functions provide a common language for discussing cybersecurity capability:

FunctionBanking interpretation
GovernEstablish strategy, roles, policy, risk appetite and oversight
IdentifyUnderstand assets, services, dependencies, risks and suppliers
ProtectApply safeguards for access, data, platforms, training and processes
DetectIdentify anomalous activity and control failure
RespondContain, analyse, communicate and manage incidents
RecoverRestore services, learn lessons and improve resilience

The Govern function links cybersecurity to enterprise governance. It includes organisational context, risk-management strategy, roles and responsibilities, policy, oversight and supply-chain risk. The other functions describe the life cycle of managing risk.

A bank can use the CSF to create a current profile and a target profile. The current profile describes existing practices; the target profile describes desired outcomes. A gap analysis then identifies priorities, owners, resources and time frames. Tiers can be used to characterise the sophistication and consistency of risk governance, but they should not be treated as a universal performance score.

The strength of the CSF is flexibility. It can align technology, business and board discussions. Its limitation is that it does not, by itself, specify every control, test procedure or legal obligation. Banks normally map it to more detailed standards, regulations and internal policies.

3. ISO/IEC 27001 and the Information Security Management System

ISO/IEC 27001 specifies requirements for an Information Security Management System (ISMS). An ISMS is a management system, not simply a collection of technical safeguards. It requires context, leadership, planning, support, operation, performance evaluation and continual improvement. The organisation determines its information-security risks, selects treatment options and documents the applicability of relevant controls.

The Statement of Applicability is particularly important. It records which controls are applicable, why they are included or excluded, and their implementation status. This creates a traceable connection between risk assessment, control selection and assurance.

ISO 27001 supports certification by an independent certification body, but certification does not guarantee that a bank is secure or that every cyber risk is eliminated. Certification provides evidence that a defined management system has been assessed against the standard’s requirements and scope. Scope must therefore be examined carefully: a certificate covering a small data centre does not automatically cover mobile banking, cloud services or outsourced payment processing.

ISO 27001 complements NIST CSF. The CSF provides outcome-oriented language and profiles; ISO 27001 provides a formal management-system structure. A bank may use the CSF to communicate capability objectives and ISO 27001 to operate a controlled, auditable ISMS.

4. COBIT and the Governance of Enterprise Information and Technology

COBIT is an enterprise governance and management framework for information and technology. Its central distinction is between governance and management. Governance evaluates stakeholder needs, sets direction and monitors performance and conformance. Management plans, builds, runs and monitors activities in accordance with that direction.

COBIT is valuable where cybersecurity decisions involve investment, service quality, regulatory compliance and business outcomes. Its governance system includes components such as processes, organisational structures, information, people, skills, policies, services and technology. Design factors allow the system to be adapted to an institution’s strategy, threat environment, compliance requirements and sourcing model.

In banking, COBIT can help a board or executive committee connect objectives such as secure digital growth and resilient payments to governance and management objectives. It can also support responsibility assignment, performance measures and control maturity assessment. However, COBIT is not a substitute for a detailed technical standard, incident-response plan or legal analysis.

Comparing the frameworks

FrameworkPrimary contributionTypical use
NIST CSFCommon cybersecurity outcomes and profilesRisk communication and capability improvement
ISO/IEC 27001Auditable information-security management systemFormal governance, risk treatment and certification
COBITEnterprise governance and management of information and technologyBoard oversight, accountability and performance
PCI DSSPrescriptive protection of payment-card dataCardholder-data environments and service providers
SWIFT CSPSecurity controls for SWIFT-related operationsProtection of the SWIFT customer environment

Frameworks should be mapped, not accumulated mechanically. A control library can map one control to several framework outcomes while preserving the stricter requirement where obligations differ.

5. The Three-Lines Model

The three-lines model clarifies accountability without creating three separate risk-management systems.

First line—management and operational functions: Own risks and controls. Technology, payments, product, branch and operations teams identify exposures, operate safeguards, manage incidents and remediate weaknesses.

Second line—risk, compliance and specialist oversight: Provide expertise, challenge and monitoring. These functions define policies, interpret obligations, advise on risk, review assessments and report independent views to management. They do not take ownership away from the first line.

Third line—internal audit: Provides independent and objective assurance on governance, risk management and controls. Internal audit should have unrestricted access, appropriate competence and direct access to the audit committee.

The board and executive management are not a fourth operational line. They remain accountable for governance, strategy, risk appetite and ensuring that the lines are adequately resourced and independent.

A common failure is “responsibility diffusion”: everyone is said to be responsible, so no one is accountable. A responsibility assignment matrix should name the accountable executive, control owner, reviewer, evidence owner and escalation authority for each material risk.

6. Regulatory Expectations and Basel Operational Risk

Banking supervisors generally expect a proportionate, risk-based framework with board oversight, clear accountability, effective internal controls, reliable information, incident reporting, resilience testing and management of third-party dependencies. Exact legal requirements differ by jurisdiction, so institutions must maintain a regulatory obligations register and obtain jurisdiction-specific legal advice.

Basel’s operational-risk principles treat failures of processes, people and systems, and external events, as sources of loss. Cyberattack, technology outage, fraud, processing error and vendor failure therefore belong within operational-risk governance, even when specialist cyber teams manage the technical response.

Important supervisory themes include:

  • The board approves strategy and risk appetite and receives decision-useful reporting.
  • Senior management implements the framework and maintains competent resources.
  • Critical operations and dependencies are identified.
  • Controls are tested, deficiencies are escalated and remediation is tracked.
  • Outsourcing does not transfer ultimate accountability.
  • Business continuity and disaster recovery are tested against severe but plausible scenarios.
  • Operational incidents and near misses are analysed for systemic lessons.

A mature resilience programme focuses on important business services, impact tolerances, dependencies and recovery capability rather than only on individual systems. A service may be technically available while customers cannot authenticate, settle payments or access accurate balances; resilience must therefore be measured from the customer and business perspective.

7. PCI DSS and the SWIFT Customer Security Programme

PCI DSS applies to entities that store, process or transmit payment-card account data, and to environments that can affect the security of that data. Scope determination is foundational. Segmentation can reduce scope only when it is properly designed, maintained and validated. Typical requirements address network security, secure configuration, account protection, access control, vulnerability management, logging, testing, policy and service-provider oversight.

PCI DSS compliance is not equivalent to complete cybersecurity. It focuses on cardholder-data protection and does not necessarily address every risk to core banking, employee identity, market infrastructure or privacy.

The SWIFT CSP is designed to strengthen the security of institutions using the SWIFT environment. Its architecture includes mandatory and advisory controls, with expectations concerning secure environment protection, operational risk reduction, identity and access management, anomaly detection, vulnerability management and incident response. Institutions must distinguish the SWIFT customer environment from the wider corporate network and ensure that local implementation and attestation requirements are current.

Both programmes illustrate a broader principle: security obligations are often ecosystem-specific. A bank should maintain an authoritative inventory of payment connections, data flows, in-scope assets, service providers and evidence requirements.

8. Privacy and Data Governance

Privacy requirements govern the lawful and fair use of personal data, not merely its technical protection. Core concepts commonly include purpose limitation, data minimisation, accuracy, retention limitation, transparency, rights of individuals, security safeguards and accountability. The exact obligations depend on the applicable jurisdiction and the bank’s role as controller, processor or equivalent entity.

Cybersecurity and privacy overlap but are not identical. A security log may be essential for detecting fraud but may contain personal data. Fraud analytics may be legitimate and socially beneficial, yet require clear purpose, proportionality, access restrictions, retention rules, bias testing and human review of consequential decisions.

Privacy by design should be integrated into product and control development. A privacy impact assessment may examine data sources, purposes, data flows, access, retention, transfers, automated decision-making and potential harms. Breach-notification duties are often time-sensitive, so incident-response plans should identify legal, regulatory and customer-communication decision points before an incident occurs.

9. Board Accountability and Cybersecurity Reporting

Boards need information that supports decisions, not a large volume of unprioritised technical metrics. Effective reporting combines:

  • exposure: critical assets, material suppliers and threat scenarios;
  • capability: control maturity, detection and recovery performance;
  • incidents: actual events, near misses and lessons learned;
  • assurance: audit findings, testing results and unresolved exceptions;
  • risk decisions: accepted risks, investment choices and overdue actions.

Useful measures may include privileged-access review completion, critical-vulnerability ageing, recovery-test results, mean time to contain, control exceptions and concentration of third-party dependency. Metrics require definitions and context. For example, a low mean time to detect may reflect improved monitoring, but could also reflect a reduction in the number of alerts being generated.

Board accountability does not mean that directors must configure firewalls. It means they must understand material cyber risk, challenge management, ensure competence and resources, approve risk appetite, oversee resilience and verify that independent assurance is credible. Minutes should demonstrate substantive challenge and decisions, not merely receipt of a presentation.

10. Integrated Implementation Approach

A practical bank-wide programme can proceed as follows:

  1. Establish governance: approve roles, committees, escalation routes and risk appetite.
  2. Define scope and critical services: include legal entities, technology, data, suppliers and payment environments.
  3. Build an obligation register: map laws, supervisory expectations, contracts, PCI DSS, SWIFT CSP and internal policies.
  4. Assess risk: identify threats, vulnerabilities, dependencies, control effectiveness and residual exposure.
  5. Select a framework architecture: use NIST CSF for outcomes, ISO 27001 for the ISMS, COBIT for enterprise governance, and specialised standards where applicable.
  6. Design and implement controls: prioritise identity, privileged access, secure development, segmentation, resilience, monitoring, response and supplier controls.
  7. Validate: conduct control testing, penetration tests, recovery exercises, red-team activity where appropriate and independent audit.
  8. Report and improve: track remediation, reassess material changes and feed incidents and near misses into governance.

Control evidence should be reliable, attributable, time-stamped and retained according to policy. Automated evidence collection can improve timeliness, but automation does not prove that a control is well designed or that an exception was appropriately resolved.

Applied Case: Meridian Bank’s Payment-Security Breakdown

This is an illustrative case.

Background

Meridian Bank operates retail banking, card acquiring and international payments. It uses a cloud-based customer-service platform and maintains a separate SWIFT environment. The board receives quarterly cybersecurity reports showing high policy-compliance percentages.

Problem

A contractor’s dormant privileged account was used to access a customer-service environment. The attacker obtained customer information and used social engineering against payment operations. Investigation found that the account review process was incomplete, network segmentation was poorly documented, supplier logs were retained for too short a period, and the board report excluded unresolved control exceptions. No payment settlement loss occurred, but customer data and operational confidence were affected.

Analysis

The incident exposed governance weaknesses rather than a single missing technology. Under the three-lines model, operations owned access reviews but had not completed them; the second line accepted management assertions without sufficient testing; and internal audit had not followed up a prior exception. Under NIST CSF, Identify and Govern were weak because the asset and supplier inventories were incomplete. Protect and Detect were weakened by excessive privilege and inadequate logging. ISO 27001 evidence was inconsistent with the stated risk treatment, and the scope of assurance did not include the outsourced platform. The incident also raised privacy, contractual and regulatory-notification questions.

Approach and solution

The board required management to establish a critical-service inventory, revoke dormant privileges, enforce multifactor authentication, improve privileged-session monitoring and validate segmentation. The second line created a regulatory and control map covering NIST CSF, ISO 27001, PCI DSS and relevant privacy obligations. Internal audit independently tested the remediation. The supplier contract was amended to require logging, incident notification, evidence access and tested recovery capabilities. Board reporting was redesigned to show open high-risk exceptions, control effectiveness and accepted residual risk.

Outcome and learning points

Meridian reduced unnecessary privileged access, improved evidence quality and identified that customer-service availability and data confidentiality were dependent on the same supplier. The principal lesson is that compliance percentages can conceal material exposure. Governance must connect scope, ownership, control evidence, supplier dependency and board decisions.

Challenges, Limitations and Contemporary Developments

Framework proliferation can create duplicated assessments and conflicting terminology. Mapping should therefore be risk-led and supported by a single control library. Another limitation is maturity scoring: a higher score may reflect better documentation rather than stronger real-world resilience. Testing should include realistic scenarios, control failure and recovery, not only document inspection.

Cloud concentration, software supply-chain attacks, ransomware, identity compromise and artificial intelligence create changing risk patterns. Generative AI can assist with triage, control mapping and anomaly analysis, but it introduces risks involving confidential data, model manipulation, hallucinated advice, explainability and accountability. Human approval, access restrictions, model monitoring and documented use cases are essential.

Threat intelligence should inform decisions without causing uncontrolled reaction to every alert. Cyber insurance, external intelligence and automated tools supplement rather than replace internal accountability. Ethical governance requires proportional surveillance, protection of employee and customer privacy, non-discrimination in fraud analytics and transparent escalation of material concerns.

Chapter Summary

Cybersecurity governance aligns cyber risk with business objectives, regulatory obligations and board accountability. Risk management distinguishes inherent and residual risk and requires explicit ownership and evidence. NIST CSF provides flexible cybersecurity outcomes; ISO/IEC 27001 provides an auditable ISMS; and COBIT connects information and technology to enterprise governance. The three-lines model separates operational ownership, oversight and independent assurance.

Basel operational-risk principles place cyber, technology, fraud and third-party failure within a broader operational-resilience perspective. PCI DSS and SWIFT CSP provide specialised ecosystem requirements, while privacy governance addresses lawful, proportionate and accountable use of personal data. Effective boards focus on critical services, material exposure, control effectiveness, resilience testing and unresolved decisions. No framework guarantees security: sustainable protection depends on clear scope, competent people, tested controls, independent challenge and continual improvement.

Key Terms

Governance: Direction, oversight and accountability for achieving organisational objectives.

Cybersecurity governance: Governance applied to protection and resilience of information and technology.

Risk appetite: Amount and type of risk an organisation is willing to accept.

Risk tolerance: Acceptable variation around a defined objective or service level.

Inherent risk: Exposure before considering controls.

Residual risk: Exposure remaining after controls and treatments.

Control owner: Person accountable for operating or maintaining a control.

NIST CSF: Framework of cybersecurity outcomes organised around Govern, Identify, Protect, Detect, Respond and Recover.

ISO/IEC 27001: Standard specifying requirements for an information-security management system.

ISMS: Information Security Management System.

Statement of Applicability: Document explaining applicable, excluded and implemented security controls.

COBIT: Framework for governance and management of enterprise information and technology.

Three-lines model: Allocation of operational ownership, oversight and independent assurance.

Operational risk: Risk of loss arising from inadequate or failed processes, people and systems, or external events.

PCI DSS: Payment Card Industry Data Security Standard.

SWIFT CSP: Customer Security Programme for organisations using the SWIFT environment.

Privacy by design: Integrating privacy safeguards into systems and processes from the outset.

Residual-risk acceptance: Formal approval to retain a known remaining exposure.

Operational resilience: Ability to deliver important services through disruption and recover effectively.

Control evidence: Reliable information demonstrating that a control was designed and operated as required.

Review Questions

Short Answer Questions

  1. Distinguish cybersecurity governance from cybersecurity management.
  2. What is the purpose of a Statement of Applicability?
  3. Identify the responsibilities of the second line in the three-lines model.
  4. Why is PCI DSS compliance not equivalent to complete cybersecurity?
  5. Define residual risk and risk appetite.

Long Answer Questions

  1. Compare NIST CSF, ISO/IEC 27001 and COBIT in a banking environment.
  2. Explain how Basel operational-risk principles apply to cyberattack and third-party technology failure.
  3. Discuss the responsibilities of the board, senior management and internal audit for cyber risk.
  4. Explain how privacy governance and cybersecurity governance interact in fraud analytics.
  5. Design an integrated governance and assurance approach for a bank operating card, SWIFT and cloud services.

Analytical / Application Questions

  1. A bank has excellent policy-compliance scores but repeated privileged-access exceptions. Analyse the governance failure and propose actions using the three-lines model.
  2. A critical cloud supplier refuses to provide security logs during an incident. Evaluate the risk, contractual and regulatory issues and recommend a response.
  3. Map a ransomware scenario across the NIST CSF functions and identify the board-level decisions required before and after the event.

Multiple Choice Questions with Answers

Question 1

Which NIST CSF function establishes cybersecurity strategy, roles, policy and oversight?

A. Govern

B. Protect

C. Detect

D. Recover

Correct Answer: A. Govern

Question 2

What is the primary purpose of an ISO/IEC 27001 Statement of Applicability?

A. To list every cyber incident in the organisation

B. To explain which controls apply, and why

C. To calculate annual expected loss

D. To certify a payment-card environment

Correct Answer: B. To explain which controls apply, and why

Question 3

Which line owns and operates day-to-day cybersecurity controls?

A. First line

B. Second line

C. Third line

D. External regulator

Correct Answer: A. First line

Question 4

Which framework most directly distinguishes governance from management of enterprise information and technology?

A. PCI DSS

B. COBIT

C. SWIFT CSP

D. ISO 22301

Correct Answer: B. COBIT

Question 5

A risk score calculated as likelihood multiplied by impact should generally be interpreted as:

A. A guaranteed percentage probability

B. A prioritisation measure based on defined scales

C. An audited financial loss

D. A legal conclusion

Correct Answer: B. A prioritisation measure based on defined scales

Question 6

Which statement about PCI DSS is correct?

A. It eliminates all operational risk

B. It applies only to unrelated marketing data

C. It focuses on payment-card account-data environments

D. It replaces privacy law

Correct Answer: C. It focuses on payment-card account-data environments

Question 7

Under the three-lines model, internal audit primarily provides:

A. Operational control ownership

B. Independent and objective assurance

C. Vendor sales support

D. The board’s risk appetite

Correct Answer: B. Independent and objective assurance

Question 8

Why is outsourcing not a transfer of ultimate accountability for a bank?

A. The supplier becomes the bank’s board

B. The bank remains responsible for governed services and risks

C. Regulators supervise only suppliers

D. Contracts cannot contain security requirements

Correct Answer: B. The bank remains responsible for governed services and risks

Question 9

Which issue is most directly associated with privacy by design?

A. Integrating data minimisation and access safeguards during system development

B. Increasing data retention without purpose

C. Removing all human review from automated decisions

D. Publishing customer logs publicly

Correct Answer: A. Integrating data minimisation and access safeguards during system development

Question 10

Which board report is most decision-useful?

A. A list of all security alerts without context

B. Only the percentage of completed policies

C. Material exposure, control effectiveness, incidents and accepted risks

D. A technical inventory with no ownership information

Correct Answer: C. Material exposure, control effectiveness, incidents and accepted risks

Cybersecurity & Fraud Analytics
Chapter 4 of 15