Skip to main content

Sector Playbooks: ISO 27001 in Financial Services and Healthcare

"Context is not a luxury. It is the difference between a control that works and a control that merely exists."

  • ISMS practitioner maxim

Introduction: Why Sector Context Changes Everything​

ISO 27001 is sector-agnostic by design. Its risk-based philosophy deliberately avoids prescribing the same control set for a hospital and a hedge fund, a cloud provider and a water utility. The standard trusts organizations to understand their own context, assess their own risks, and select the controls that address those risks proportionately.

This trust is well-placed - but it places the burden of contextual intelligence on the practitioner. A GRC professional who has spent their career in financial services implementing an ISMS for the first time in a healthcare organization will find that the threat profile is different, the regulatory environment is different, the operational constraints are different, and the controls that represent best practice in one sector may be inadequate, impractical, or disproportionate in another.

This final chapter fills that gap. It delivers four sector-specific playbooks - Finance, Healthcare, Cloud Providers, and Critical Infrastructure - each structured as a complete practitioner guide: the sector's unique threat profile, its regulatory overlay, the ISO 27001 controls that matter most in its context, the implementation traps specific to that sector, and a comprehensive implementation checklist that practitioners can use as both a gap assessment tool and an audit preparation framework.

Playbook 1: Financial Services​

1.1 The Financial Sector Threat Profile​

Financial institutions are among the most intensively targeted organizations on earth. The reason is direct: they hold money, they process money, and they hold the credentials and account information that enable money to be moved. Threat actors range from opportunistic criminals exploiting commodity vulnerabilities to sophisticated nation-state actors conducting long-term espionage and sabotage campaigns.

Business Email Compromise (BEC): The most financially damaging attack category for financial services firms. Threat actors compromise or impersonate executive email accounts to redirect wire transfers, authorize fraudulent payments, or manipulate employees with financial authority. BEC attacks have resulted in losses ranging from tens of thousands to tens of millions in single incidents.

Ransomware targeting operational continuity: Financial institutions are high-value ransomware targets because their operational disruption cost is so high. A major bank that cannot process transactions for 24 hours faces losses that dwarf the ransom demand - creating leverage that operators exploit ruthlessly.

Credential theft and account takeover: Phishing, credential stuffing, and social engineering targeting customer-facing and internal authentication systems. Valid credentials are sold on dark web markets and used for direct financial theft or lateral movement.

SWIFT and payment system attacks: Sophisticated attacks targeting interbank payment infrastructure. The 2016 Bangladesh Bank heist - $81 million stolen through fraudulent SWIFT messages - demonstrated that even the messaging infrastructure underlying global finance is a viable target for sufficiently sophisticated actors.

Insider threat with access to financial data: Financial institutions hold high-value information - trading strategies, M&A intelligence, customer financial profiles. Employees under financial stress or with connections to criminal organizations represent a persistent and high-impact insider threat.

Fintech supply chain attacks: The rapid expansion of open banking, API-based services, and fintech integrations has dramatically expanded the supply chain attack surface for traditional institutions. Third-party fintech providers are systematically less security-mature than the regulated institutions they integrate with.

Advanced Persistent Threats: Nation-state actors conduct long-term operations against financial institutions, targeting strategic intelligence - currency policy, M&A activity, sanction circumvention - as well as direct financial theft.

1.2 The Financial Services Regulatory Overlay​

DORA (EU): Comprehensive ICT risk management, incident reporting, and third-party risk requirements applicable from January 2025. The most demanding sector-specific regulation for EU financial entities. Covered in detail in Chapter 9.

PCI DSS: Applies to any organization processing, storing, or transmitting cardholder data. PCI DSS v4.0 imposes 12 high-level requirements with hundreds of sub-requirements covering network security, access control, monitoring, cryptography, and vulnerability management.

EBA Guidelines on ICT and security risk management: Detailed implementation expectations for ICT and security risk management under EU financial regulations.

FCA/PRA requirements (UK): Operational resilience policy statements requiring important business services to be identified, impact tolerances set, and the ability to operate within those tolerances demonstrated during severe but plausible disruption.

SEC cybersecurity rules (US): Material cybersecurity incidents disclosed within four business days; annual disclosures on cybersecurity risk management strategy and governance for public companies.

1.3 Priority ISO 27001 Controls for Financial Services​

5.7 (Threat Intelligence): Sector-specific, current, and operationalized threat intelligence is not optional. FS-ISAC membership, ENISA sector briefings, vendor intelligence subscriptions, and dark web monitoring for financial institution-specific threats should all be active.

5.19 to 5.23 (Supplier controls): The fintech integration landscape has created a sprawling supply chain of third-party services. The tiering framework must be applied rigorously, with ICT service providers assessed under DORA-grade criteria - access profile, subprocessor chain, incident history, and contractual compliance.

5.24 to 5.28 (Incident management): DORA's 4-hour classification window demands automated detection pipelines, pre-drafted notifications, and pre-authorized response decisions. Incident response capability cannot depend on normal business hours.

8.2 (Privileged access rights): Trading systems, core banking platforms, and payment infrastructure are extremely high-value targets. Privileged access must be managed with zero tolerance - just-in-time access, session recording, behavioral monitoring, quarterly review of every privileged grant without exception.

8.5 (Secure authentication): MFA must be universal - not just for external access but for every system that touches financial data, payment processing, or trading infrastructure. Phishing-resistant MFA (FIDO2, hardware tokens) for the highest-risk roles.

8.8 (Technical vulnerabilities): Financial institutions are actively targeted by vulnerability exploitation. The remediation SLA for internet-facing and payment-adjacent systems should be measured in hours for critical vulnerabilities, not days.

8.15 and 8.16 (Logging and monitoring): Audit trail requirements for financial institutions are among the most demanding of any sector - regulators may require the ability to reconstruct trading activity, transaction flows, and system access over years. Log retention, integrity protection, and analytical capacity must be calibrated accordingly.

1.4 Financial Services Implementation Traps​

Trap 1: Parallel compliance programs. PCI DSS and ISO 27001 overlap substantially - the evidence consolidation approach in Chapter 9 should be applied aggressively. Running them as independent programs creates significant unnecessary overhead.

Trap 2: Scoping out trading systems. Trading technology operated by the front office is among the highest-value and most targeted assets in a financial institution. Excluding it from ISMS scope creates a critical gap that auditors - and threat actors - will find.

Trap 3: Underestimating DORA's operational demands. DORA's 4-hour incident classification requirement and ICT arrangements register are operationally demanding. Organizations that plan to address them with minor modifications to existing incident procedures typically discover the gap at the first significant incident.

Trap 4: Shadow IT in trading and risk functions. Quantitative analysts and risk managers frequently develop their own tools - spreadsheets, Python scripts, SQL queries - that process highly sensitive financial data entirely outside any IT governance process.

Financial Services Implementation Checklist​

Governance and Leadership​

  • Executive sponsor identified with explicit DORA/NIS2 management accountability documented
  • Board-level cybersecurity agenda item confirmed at least quarterly
  • CISO reporting line appropriate - direct to CEO or board-level committee
  • Information security committee includes trading, risk, compliance, IT, and legal representation
  • Personal liability obligations under DORA Article 20 communicated to management body members
  • Security budget reviewed and benchmarked against sector peers and regulatory expectations

Risk Management​

  • Risk methodology explicitly addresses ICT risk as defined by DORA
  • Risk assessment covers all in-scope systems including trading, payments, and customer-facing platforms
  • Threat intelligence program established - FS-ISAC membership, government subscriptions, dark web monitoring
  • BEC-specific risk assessed - wire transfer controls and executive impersonation treatment documented
  • Third-party risk assessment covers all ICT service providers against DORA criteria
  • SWIFT and payment system risks specifically assessed and treated
  • Insider threat risk formally assessed with documented treatment plan

Access Control​

  • Universal MFA enforced - no exceptions for any system accessing financial data or payment infrastructure
  • Phishing-resistant MFA (FIDO2/hardware tokens) for privileged accounts and high-value roles
  • Privileged access review conducted quarterly - documented with evidence retained
  • Just-in-time privileged access implemented for production system administration
  • Session recording deployed for all privileged sessions on critical systems
  • Quarterly user access review for all production systems
  • Service account inventory maintained - passwords rotated, access scoped to minimum required

Incident Management​

  • Incident classification scheme aligned with DORA severity criteria
  • 4-hour major incident classification capability demonstrated in tabletop exercise
  • DORA notification templates prepared and legal-reviewed
  • NCA/ESA contact details embedded in incident playbook
  • 72-hour DORA intermediate report template prepared
  • GDPR DPA notification process integrated with incident response
  • Out-of-hours incident response capability confirmed - named responders, escalation contacts
  • Annual tabletop exercises covering BEC, ransomware, and payment fraud scenarios

Supplier and Third-Party Risk​

  • ICT arrangements register maintained - all DORA-required data elements present
  • Critical ICT TPP designations monitored - ESA register checked quarterly
  • DORA-compliant contract clauses in all ICT service provider agreements
  • Fintech integration inventory complete - all API integrations documented and assessed
  • Annual security assessment for all Tier 1 ICT suppliers
  • Subprocessor change notification process confirmed with all critical suppliers
  • Exit provisions assessed for all critical ICT suppliers - data return and portability confirmed

Technical Controls​

  • Vulnerability management SLA for internet-facing systems: critical vulnerabilities within 24 hours
  • Trading and payment systems included in vulnerability scanning scope
  • Network segmentation separating trading, payments, and corporate IT environments
  • DLP deployed on email, web, and endpoint covering financial data classifications
  • SIEM deployed with financial sector threat detection rules - updated quarterly from threat intelligence
  • Log retention meets regulatory requirements - minimum 5 years for transaction logs
  • Encryption at rest and in transit for all confidential data and above
  • Annual penetration test by qualified external firm - scope includes payment infrastructure

Regulatory Compliance​

  • DORA gap assessment completed against all five pillars
  • TLPT schedule confirmed if significant entity under DORA
  • PCI DSS scope defined and controls mapped to ISO 27001 evidence base
  • SEC cybersecurity disclosure process established for US-listed entities
  • FCA/PRA operational resilience requirements addressed - impact tolerances defined and tested for UK entities
  • Integrated compliance calendar aligns all regulatory reporting and assessment timelines

Playbook 2: Healthcare​

2.1 The Healthcare Sector Threat Profile​

Healthcare is the most targeted sector for ransomware. In 2023 and 2024, healthcare organizations collectively suffered more ransomware incidents than any other sector. The reasons are structural: highly sensitive data, systems where availability failures have direct patient safety consequences, historically underinvested security posture, and technology environments of extraordinary complexity - clinical systems, medical devices, administrative IT, and research infrastructure.

Ransomware targeting operational systems: Healthcare ransomware attacks disrupt patient care. The 2020 Dusseldorf University Hospital attack - where a ransomware incident forced emergency ambulance diversion, contributing to a patient death - illustrated the life-safety dimension of healthcare security in the starkest possible terms. For healthcare ISMS professionals, availability risk is patient risk.

Medical device exploitation: Modern healthcare environments contain thousands of networked medical devices - infusion pumps, patient monitors, imaging equipment, ventilators - many running outdated software that cannot be patched, operating on unencrypted protocols, connected to clinical networks alongside fully managed IT systems.

Protected Health Information (PHI) theft: Health records sell for 10 to 40 times the price of credit card numbers on dark markets. They are used for insurance fraud, identity theft, and blackmail. The combination of high value and severe regulatory consequence makes PHI the primary confidentiality risk.

Third-party clinical software vulnerabilities: Healthcare organizations are heavily dependent on clinical software vendors whose products contain vulnerabilities, whose update cycles are slow, and whose security practices are often immature relative to the sensitivity of the data they process.

Insider threat with clinical data access: Healthcare workers have broad access to patient records as a clinical necessity. The same access that enables care also enables inappropriate browsing, data sale, or targeted access to records of public figures or personal acquaintances.

2.2 The Healthcare Regulatory Overlay​

GDPR - special category health data: Health data is explicitly classified as special category personal data under Article 9, requiring explicit consent or a specific Article 9(2) exception. The risk threshold for breach notification is lower, fines for non-compliance are higher, and data subject rights are more extensive than for standard personal data.

HIPAA (US): The Security Rule (technical, physical, and administrative safeguards for ePHI), Privacy Rule (permitted uses and disclosures), and Breach Notification Rule (notification to HHS and affected individuals within 60 days of discovery) collectively impose comprehensive security and privacy requirements that align substantially with ISO 27001.

NHS Data Security and Protection Toolkit (UK): Mandatory self-assessment framework for NHS organizations and their suppliers, aligning with the 10 National Data Guardian standards and mapping to both ISO 27001 and Cyber Essentials.

NIS2 - health sector as essential entity: Healthcare providers above defined thresholds are classified as essential entities under NIS2, imposing Article 21 security requirements and Article 23 incident reporting obligations on a sector historically underregulated for cybersecurity.

2.3 Priority ISO 27001 Controls for Healthcare​

5.30 (ICT readiness for business continuity): Business continuity is a patient safety imperative. The ISMS must include specific, tested plans for maintaining clinical operations when key systems are unavailable - paper-based downtime procedures, manual medication administration protocols, patient diversion procedures, and communication plans for clinical staff operating without digital support.

8.8 (Technical vulnerabilities - adapted for medical devices): Medical device vulnerability management is uniquely challenging. Devices cannot always be patched, must be validated before updates, and may be managed by clinical engineering rather than IT. A specific medical device vulnerability management process is required - distinct from standard IT vulnerability management.

8.22 (Segregation of networks): Clinical networks, medical device networks, administrative IT, and research networks must be segmented to prevent lateral movement. A compromised administrative workstation must not have network access to infusion pump controllers.

6.3 (Awareness - clinical context): Clinical staff have different security awareness needs than IT or administrative staff. Training must be designed for clinical workflows: recognizing phishing in clinical email, handling patient data on mobile devices, physical security in clinical areas, and what to do when a clinical system behaves abnormally.

5.9 (Asset inventory - medical devices): The medical device inventory is typically the most incomplete asset inventory in a healthcare organization. Devices are procured through clinical channels, connected without IT awareness, and managed by clinical engineering. Building a complete medical device inventory requires active collaboration between IT security, clinical engineering, and procurement.

2.4 Healthcare Implementation Traps​

Trap 1: Scoping out medical devices. Medical devices connected to clinical networks are information assets within ISMS scope - their network connections create information security risks that the ISMS must address. Excluding them because they are "clinical equipment" is a material scope gap.

Trap 2: Under-resourcing availability. Healthcare CISOs who focus primarily on PHI confidentiality and underweight availability risks will be unprepared for ransomware. An ISMS that cannot describe how clinical operations continue when the EHR is unavailable has a critical gap.

Trap 3: Inadequate downtime procedures. Downtime procedures - the clinical workflows that operate when key systems are unavailable - are a security control, not just an operational contingency. If downtime procedures are inadequate, the clinical impact of an incident creates pressure to pay ransoms or accept security shortcuts.

Trap 4: Ignoring researcher shadow IT. Research environments in academic health systems are frequently characterized by unsanctioned systems, personal devices, cloud storage accounts, and data sharing practices that would clearly violate the ISMS. Engaging the research community requires specific approaches rather than uniform control imposition.

Healthcare Implementation Checklist​

Governance and Leadership​

  • Clinical leadership engaged in ISMS governance - CMIO, CNO, or equivalent on information security committee
  • Patient safety and information security explicitly connected - clinical risk committee has security representation
  • Regulatory obligations mapped: GDPR health data, HIPAA if applicable, NIS2, NHS DSPT if applicable
  • Medical device security ownership defined - IT security and clinical engineering collaboration model documented
  • Security budget benchmarked against healthcare sector norms - typically 6 to 8% of IT budget
  • Executive sponsor briefed on ransomware-as-patient-safety-risk

Risk Management​

  • Risk assessment includes medical devices - network-based discovery combined with clinical engineering inventory
  • PHI and health data flows mapped - all systems storing, processing, or transmitting patient data identified
  • Ransomware-specific risk assessment completed - business impact analysis addresses patient care continuity
  • Medical device vulnerability assessed - manufacturer security advisories tracked
  • Insider threat risk specifically assessed for patient data access scenarios
  • Third-party clinical software vendor risk assessed - EHR, laboratory, radiology, pharmacy systems
  • Research data risk assessed - anonymization processes, data sharing agreements, researcher practices

Asset Management​

  • Medical device inventory complete - device type, manufacturer, firmware version, network connection, clinical owner
  • Medical device network connections documented - VLAN assignment, data flows, clinical purpose
  • PHI data inventory complete - all systems, locations, and access paths documented
  • Shadow IT assessment conducted in research and administrative environments

Access Control​

  • Role-based access control implemented for EHR - minimum access based on clinical role
  • Emergency access (break-glass) procedure documented, logged, and reviewed
  • Access reviews conducted quarterly for privileged accounts, semi-annually for clinical staff
  • Terminated staff access revocation confirmed - including contractor and locum access
  • Remote access for clinical staff secured - VPN or zero-trust with MFA required
  • Medical device default credentials changed - manufacturer defaults eliminated

Medical Device Security​

  • Medical device vulnerability management process documented - separate from standard IT VM process
  • Medical device patching process includes clinical validation step before deployment
  • Medical device network segmentation implemented - clinical device VLAN isolated from corporate IT
  • Medical device behavioral monitoring implemented where technically feasible
  • End-of-support device risk formally accepted with compensating controls documented
  • Manufacturer security advisories monitored - H-ISAC and medical device ISAC subscriptions
  • New medical device procurement process includes mandatory security assessment step

Incident Management​

  • Clinical downtime procedures documented for each critical clinical system
  • Downtime procedures tested annually - simulation exercise conducted
  • Patient safety impact assessment included in incident severity classification
  • GDPR special category data breach notification procedure - accelerated timeline for health data
  • NIS2 incident notification procedure implemented if essential entity classification applies
  • Clinical leadership included in incident escalation path
  • Ransomware-specific playbook including decision criteria for ransom payment escalation to board

Technical Controls​

  • Clinical network segmentation implemented and tested - medical devices, clinical IT, administrative IT separated
  • Backup strategy tested specifically for ransomware recovery - isolated backups, timed restoration verified
  • EHR and clinical system backup recovery tested - RTO/RPO confirmed against clinical requirements
  • Endpoint protection deployed on all manageable clinical workstations
  • USB and removable media controls - clinical necessity exceptions formally documented
  • PHI encryption at rest for all data stores - portable devices encrypted
  • Audit logging for EHR access - patient record access logged with anomaly monitoring enabled

Training and Awareness​

  • Clinical staff security awareness training - content designed for clinical context, not generic IT security
  • Phishing simulation includes clinical email scenarios - EHR alerts, clinical notifications, scheduling
  • Downtime procedure training included in clinical staff onboarding and annual refresher
  • Incident reporting mechanism communicated to clinical staff - accessible, one-step reporting
  • Medical device security training for clinical engineering and procurement staff

Continues in Chapter 10B: Cloud Providers and Critical Infrastructure playbooks

© ISO 27001 Wiki - For CISOs, Security Analysts, and GRC Professionals