Healthcare organizations and critical infrastructure operators face information security challenges that differ fundamentally from commercial enterprises. The consequence of a security failure is not financial loss or reputational damage — it is patient harm, or disruption of services that millions of people depend on for their safety and welfare. A ransomware attack on a hospital in Indonesia is not a data breach — it is a patient safety emergency. A cyberattack on a power grid is not an IT incident — it is a national security event.
ISO 27001 is the right governance foundation for these environments — its risk-based approach, documented controls, and independent audit capability are exactly what regulators (Kemenkes, BSSN, ESDM) and operational stakeholders (clinical leadership, grid operators, infrastructure managers) need to see. But a standard ISO 27001 implementation designed for a commercial organization is insufficient. The risk weightings, the control implementations, and the incident response design all require adaptation for environments where availability is paramount, operational technology systems cannot be patched on IT schedules, and manual fallback procedures are not optional.
This article covers the key differences that make these sectors distinctive, healthcare-specific ISMS control implementations with clinical context, the Indonesian critical infrastructure sector map with BSSN requirements, the IT/OT security architecture model for industrial environments, and the high-availability ISMS design adaptations that make the standard suitable for these specialized contexts.
Why These Sectors Are Different
Healthcare and critical infrastructure share one characteristic that distinguishes them from all other sectors: the direct connection between security failures and physical harm to human beings. This is not a theoretical risk — Indonesian hospitals have experienced ransomware attacks that temporarily disabled clinical systems, and critical infrastructure in the region has been targeted by state-sponsored threat actors. Understanding the dimensions of difference helps practitioners calibrate the ISMS appropriately:
| Dimension | Healthcare | Critical infrastructure |
| Consequence of security failure | Direct patient harm — ransomware on a hospital system can delay surgery, medication errors, or disable ICU monitoring. Data breaches expose medical records that cannot be changed and carry stigma (mental health, HIV, reproductive health). | Societal disruption — a cyberattack on power grid infrastructure can affect millions of people simultaneously. Physical safety consequences for operators and public. Cascading failures across dependent sectors. |
| Availability vs. confidentiality priority | Availability is often the primary concern in clinical settings — a doctor who cannot access a patient's medication history in an emergency faces a patient safety risk. Confidentiality is critical but secondary to keeping systems running. | Availability is existential — energy, water, and telecommunications infrastructure must operate continuously. Security controls that prioritize confidentiality at the expense of availability are inappropriate for operational technology (OT) environments. |
| Regulatory environment | Ministry of Health (Kemenkes) regulations, BPJS Kesehatan data requirements for national health insurance, UU PDP (medical data as specific personal data), provincial health authority requirements. Evolving — healthcare digital transformation is ahead of the regulatory framework in many areas. | Presidential Regulation 82/2022 on Critical Infrastructure Protection, BSSN guidelines, sector-specific requirements (Ministry of Energy, Ministry of Telecommunications). BSSN plays a central coordination role for critical infrastructure cybersecurity across all sectors. |
| Operational technology (OT) environment | Medical devices — infusion pumps, patient monitors, MRI machines, ventilators — run proprietary software and may not be patchable. Clinical networks mix IT (administrative) and OT (medical device) traffic in ways that create significant security challenges. | Industrial Control Systems (ICS), SCADA, DCS, PLCs are the backbone of energy, water, and manufacturing infrastructure. These systems were designed for operational reliability, not security, and often run unpatched or unpatchable firmware. |
| ISO 27001 relevance | ISO 27001 directly addresses: patient data confidentiality, clinical system availability, medical device network security governance, staff awareness, and the regulatory compliance framework. Strong alignment with healthcare security needs. | ISO 27001 addresses the organizational governance, IT security, and documented information aspects of critical infrastructure security. OT/ICS security may require supplementary frameworks (IEC 62443) beyond what ISO 27001 covers. |
| THE AVAILABILITY-FIRST PRINCIPLE | In most commercial organizations, the CIA triad is implemented roughly in order: Confidentiality first (data protection), Integrity second (accuracy), Availability third (uptime). In healthcare and critical infrastructure, this order must be reversed: Availability first (the system must work when needed), Integrity second (the data must be accurate), Confidentiality third (important but secondary to the other two when in conflict). An ISMS that implements strong confidentiality controls at the cost of availability — locking down access so tightly that a doctor cannot quickly access a patient record in an emergency — has failed in these sectors, regardless of what the audit report says. |
Healthcare: Key Controls and Clinical Context
Healthcare organizations implementing ISO 27001 must adapt five control areas to reflect clinical reality — patient safety, medical device constraints, and the specific personal data categories that medical information occupies under UU PDP. The table below provides healthcare-specific implementation guidance for each:
| Control area | Healthcare context | Implementation guidance | Evidence required | Reg. link |
| Medical data classification (5.12) | Medical data spans multiple UU PDP categories simultaneously. Patient identity data (general personal data), diagnosis and treatment records (specific personal data — health category), genetic and biometric data (specific personal data), and mental health records (heightened stigma sensitivity). Classification must reflect UU PDP categories, not just generic sensitivity levels. | Add UU PDP-aligned classification levels: Public (non-patient general health information), Internal (non-identifiable administrative data), Confidential (patient demographic and administrative records), Restricted (medical history, diagnosis, treatment records, mental health, HIV/AIDS, substance use records). Restricted classification triggers the highest access controls, encryption, and breach notification priorities. | Classification policy with UU PDP health data categories explicitly defined. Asset inventory identifying each data store with its classification level. Staff training records showing clinical staff understand classification requirements. | UU PDP Art. 5–6 (specific personal data — health); Kemenkes electronic medical record regulations |
| Clinical system availability (5.29, 5.30, 8.13, 8.14) | Clinical systems must be available when clinicians need them — not at 99.5% availability over a month, but at any given moment a clinician is treating a patient. Planned maintenance must be scheduled outside peak clinical hours. Failover must be clinical-grade — not just technical. | Define clinical system tiers: Tier 1 (cannot wait — ICU monitoring, pharmacy dispensing, operating room systems: RTO ≤ 15 minutes); Tier 2 (critical but brief interruption tolerable — inpatient EHR, radiology, laboratory: RTO ≤ 2 hours); Tier 3 (administrative systems — outpatient scheduling, billing: RTO ≤ 24 hours). Design DR architecture and test to Tier 1 standards. Manual fallback procedures for every Tier 1 system — paper records, laminated quick-reference protocols. | Clinical system tier classification. RTO/RPO targets per tier. DR test records demonstrating Tier 1 RTO achievement. Manual fallback procedure for each Tier 1 system. Scheduled maintenance window policy. | Kemenkes hospital standards (akreditasi); BPJS Kesehatan system availability requirements for claim processing |
| Medical device network security (8.20, 8.22, 8.8, 8.1) | Medical devices — infusion pumps, patient monitors, ECG machines, imaging systems — are networked but often cannot be patched. They run proprietary OS versions no longer supported by manufacturers. They must not be isolated from clinical networks entirely, but they must be isolated from administrative and external networks. | Network segmentation: create a dedicated medical device VLAN (or multiple device-type VLANs for device categories) isolated from administrative networks and internet-accessible systems. Medical device VLAN: allow only the traffic required for clinical function (DICOM for imaging, HL7 for data exchange, device management). Vulnerability management for medical devices: maintain a device inventory with manufacturer, model, OS version, and patch status. For unpatched devices: compensating controls (network monitoring for anomalous behavior, enhanced alerting, no direct internet connectivity). Penetration testing must explicitly exclude medical devices unless manufacturer authorization is obtained. | Network architecture diagram showing medical device VLAN. VLAN firewall rules evidence. Medical device inventory with patch status. Compensating controls documentation for unpatched devices. Medical device exclusion in penetration test scope. | BSSN healthcare cybersecurity guidelines; Kemenkes digital health security requirements; IEC 80001-1 for medical device IT network risk management |
| Patient data breach response (5.26, UU PDP Art. 46) | A breach of patient medical records is among the highest-impact personal data breach scenarios under UU PDP — medical data is specific personal data, affected individuals cannot change their health history, and the potential for discrimination and stigma is severe. The 14-day KOMINFO notification window is not generous when a hospital must simultaneously manage clinical operations and an incident. | Healthcare-specific breach response procedure: (1) Immediate containment of affected clinical systems without disrupting patient care (critical priority — patient safety trumps evidence preservation when in conflict); (2) Clinical leadership notification within 1 hour of confirmed breach; (3) KOMINFO notification preparation begins at breach discovery — do not wait for investigation completion; (4) Patient notification assessment: all medical data breaches should be presumed high-risk to data subject rights, triggering patient notification; (5) Designate a DPO (if applicable under UU PDP) as the breach response lead for privacy obligations. | Healthcare-specific incident response procedure with patient safety prioritization. Clinical leadership notification protocol. KOMINFO notification checklist with 14-day countdown tracking. Patient notification procedure and template. DPO appointment documentation (if applicable). | UU PDP Art. 46 (14-day KOMINFO notification); UU PDP Art. 5–6 (specific personal data breach heightened obligations); Kemenkes patient rights regulations |
| Healthcare staff awareness (6.3) | Clinical staff security awareness has unique challenges: high staff turnover (locum doctors, rotating residents, contract nurses), 24/7 shift patterns making training difficult to schedule, time pressure that creates workarounds (sharing login credentials to save time), and a clinical culture that may deprioritize security relative to patient care. | Clinical security awareness program: just-in-time training rather than annual e-learning (short security messages at login, micro-learning modules at shift start). Role-specific content: doctors (protect login credentials, no photo of patient records on personal phone), nurses (medication system security, report suspicious device behavior), administrative staff (patient data handling, phishing recognition). Annual phishing simulation with clinical scenarios (fake email from 'hospital management' requesting credential verification). No-blame reporting culture explicitly extended to clinical staff — security events must be reported even when care continues uninterrupted. | Role-specific clinical awareness training records. Clinical phishing simulation results. Incident report volume from clinical staff (as proxy metric for reporting culture). Annual competence verification for clinical staff with system access. | UU PDP Art. 35 (appropriate measures including staff awareness); Kemenkes hospital HR requirements |
| The medical device security paradox: Medical devices that are networked (infusion pumps, patient monitors, CT scanners) but cannot be patched represent one of the most challenging security problems in any sector. The ISO 27001 response is not to exclude them from the ISMS — it is to address them through compensating controls: network isolation (dedicated medical device VLAN with no direct internet connectivity), passive monitoring (OT network detection that identifies anomalous behavior without active scanning that could disrupt devices), and enhanced physical security (device access restricted to clinical staff, manufacturer-authorized service only). The device inventory must record patch status — 'unpatched by manufacturer design' is a documented risk, not an undocumented gap. |
Indonesian Critical Infrastructure: Sector Map and BSSN Requirements
Presidential Regulation 82/2022 designates 11 critical infrastructure sectors in Indonesia and establishes BSSN as the national cybersecurity authority for all of them. Each sector has distinct operational technology environments, sector-specific regulators, and BSSN cybersecurity requirements that apply alongside ISO 27001:
| Sector | Regulator | OT/ICS systems | ISO 27001 scope | Critical controls | BSSN requirement |
| Energy (electricity, oil and gas) | Ministry of Energy and Mineral Resources (ESDM), BPH Migas, PLN regulatory framework, BSSN | SCADA for power generation and distribution, DCS for refinery operations, EMS (Energy Management Systems), ICCP for grid interconnection, substation automation | IT systems (corporate networks, enterprise applications, operational support systems), OT boundary protection and monitoring. Direct OT control systems typically require IEC 62443 supplementary to ISO 27001. | 8.22 (network segmentation — IT/OT DMZ mandatory), 8.16 (monitoring — OT network anomaly detection), 5.30 (ICT readiness for BCM — grid restoration procedures), 5.26 (incident response with BSSN notification for critical infrastructure cyber incidents) | BSSN Presidential Regulation 82/2022 critical infrastructure protection — cybersecurity assessment, incident reporting to BSSN within 1×24 hours of critical infrastructure cyber incident. |
| Water and wastewater | Ministry of Public Works and Housing (PUPR), regional water authorities (PDAM), BSSN | SCADA for treatment plant operations, pump station controls, remote terminal units (RTUs), water quality monitoring systems, SCADA for distribution network | Corporate IT systems and the SCADA supervisory layer. RTUs and field devices often require IEC 62443 controls or compensating controls given limited patching capability. | 8.22 (IT/OT segmentation), 8.8 (vulnerability management for SCADA hosts), 5.29 (IS during disruption — manual treatment procedures), 8.13 (backup of SCADA configurations and historian data) | BSSN critical infrastructure classification — water systems are designated critical infrastructure. Incident reporting to BSSN. Periodic cybersecurity assessment required. |
| Telecommunications | KOMINFO, BRTI (Indonesian Telecommunications Regulatory Body), BSSN | Telco network operations (BSS/OSS), core network infrastructure, data center operations, submarine cable systems, satellite ground stations | ISO 27001 broadly applicable to telco operations. Telco-specific ISO standard: ISO/IEC 27011 provides telecommunications-specific guidance within the ISO 27001 framework. | 8.14 (redundancy — N+1 for core network elements), 8.22 (network segmentation — subscriber, management, signaling planes), 5.26 (incident response — KOMINFO service disruption reporting), 5.23 (cloud — for cloud-native telco NFV deployments) | BSSN critical infrastructure — telco is classified critical. KOMINFO has separate service continuity and cybersecurity reporting requirements. KMK/PM KOMINFO compliance alongside BSSN. |
| Transport (aviation, ports, railways) | Ministry of Transportation (Kemenhub), DGCA (aviation), BSSN, sector-specific safety authorities | Air Traffic Management (ATM) systems, airport operations systems (FIDS, baggage handling), port terminal operating systems (TOS), rail signaling and traffic management | Administrative and operational IT systems. Aviation and railway OT systems have safety-critical characteristics — ICAO and CENELEC safety standards apply alongside ISO 27001 for cybersecurity. | 8.32 (change management — safety-critical systems require enhanced change controls), 5.29 (IS during disruption — operational continuity plans for physical transport), 5.26 (incident response — aviation: mandatory ICAO cybersecurity reporting; ports: port authority notification) | BSSN critical infrastructure designation for major airports, ports, and rail networks. Cybersecurity assessment and incident reporting to BSSN. |
| Government / public administration | BSSN (primary cybersecurity authority), Kemenpan-RB (government IT governance), ministry-specific IT authorities | Government data centers (PDNS), e-government platforms, citizen data registries, tax and customs systems, national ID systems | ISO 27001 directly applicable to government IT systems. BSSN's national cybersecurity framework (SNSIK) is built on ISO 27001 as its management system foundation. | 5.34 (privacy — citizen personal data is some of the most sensitive data in the national system), 5.12 (classification — government data classification system must align with national classification standards), 5.35 (independent review — government IT audit requirements), 8.15 (logging — audit trail for government system access) | BSSN SNSIK (Sistem Nasional Keamanan Informasi dan Komunikasi) framework — government entities must implement BSSN cybersecurity framework, which is aligned to ISO 27001. National assessment program through BSSN. |
The 24-hour BSSN incident notification requirement (for designated critical infrastructure operators) is the most demanding notification timeline in the Indonesian regulatory landscape — faster than BI's 2-hour payment incident window (which applies only to payment system incidents), faster than OJK's 3×24-hour IT incident window, and far faster than KOMINFO's 14-day personal data breach window. Critical infrastructure operators must have automated incident detection and a clear notification trigger criterion to meet this timeline without ambiguity.
BSSN and the National Cybersecurity Framework
BSSN (Badan Siber dan Sandi Negara) is Indonesia's national cybersecurity authority, established under Presidential Regulation 28/2021. Its role in critical infrastructure cybersecurity is central and growing. Understanding the BSSN framework helps critical infrastructure operators align ISO 27001 implementation with national requirements:
| BSSN framework element | Requirement | ISO 27001 connection |
| Presidential Regulation 82/2022 | Establishes BSSN as the national cybersecurity authority for Indonesia. Designates 11 critical infrastructure sectors (energy, transportation, water, banking and finance, health, ICT, food, defense, oil and gas, government, and maritime). All designated critical infrastructure operators must implement BSSN's cybersecurity requirements. | ISO 27001 is referenced in BSSN's implementation guidelines as a recognized framework for satisfying the management system requirements of Presidential Regulation 82. Critical infrastructure operators that hold ISO 27001 certification benefit from recognition in BSSN assessments. |
| BSSN Cybersecurity Assessment Framework (SNSIK) | BSSN's Sistem Nasional Keamanan Informasi dan Komunikasi framework maps to the NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover) while incorporating Indonesian regulatory requirements. Assessment is conducted by BSSN-authorized assessors. | ISO 27001 Annex A controls map across all five NIST CSF functions. ISO 27001 Organizations can map their SoA against the BSSN SNSIK framework to identify coverage and gaps. The 5 new Annex A attribute categories (Identify, Protect, Detect, Respond, Recover) introduced in 2022 provide direct mapping to NIST CSF/BSSN SNSIK. |
| BSSN Incident Reporting | Critical infrastructure operators must report significant cyber incidents to BSSN within 1×24 hours of discovery. BSSN operates the national Computer Security Incident Response Team (CSIRT) — ID-CSIRT — and coordinates incident response for critical infrastructure. Incident reports submitted through the BSSN portal. | ISO 27001 5.26 incident response procedure must include BSSN as a mandatory notification recipient for critical infrastructure operators. The 24-hour BSSN notification window is more demanding than the OJK 3×24-hour and the KOMINFO 14-day windows — it is the fastest mandatory notification obligation in the Indonesian regulatory landscape. |
| BSSN Security Assessment Obligation | Critical infrastructure operators must undergo periodic BSSN cybersecurity assessments. Assessment frequency and scope are determined by the criticality tier of the operator. Government entities: minimum annual assessment. Private critical infrastructure: minimum every 2 years. Assessment covers: governance, risk management, access control, network security, incident response, BCM. | ISO 27001 internal audit and the Stage 2 certification audit both produce evidence that directly satisfies BSSN assessment objectives. Organizations that maintain a current ISO 27001 certificate typically experience more efficient BSSN assessments — the assessor can review audit reports rather than testing controls from scratch. |
| Sector Coordination | BSSN coordinates with sector ministries (Kemenkes for health, ESDM for energy, etc.) on sector-specific cybersecurity requirements. Each sector has or is developing sector-specific cybersecurity guidelines built on the BSSN national framework. Critical infrastructure operators must monitor both BSSN and their sector ministry for applicable requirements. | ISO 27001 Clause 4.1/4.2 (context and interested parties) explicitly requires identification of applicable regulations and interested party requirements. For critical infrastructure operators, BSSN, the sector ministry, and any sector-specific CSIRT must all be listed as interested parties with their specific IS requirements documented. |
| ISO 27001 and BSSN SNSIK alignment: BSSN's national framework (SNSIK) is built on three pillars that directly correspond to ISO 27001 components. Pillar 1 (Governance): corresponds to ISO 27001 Clauses 4–7 — leadership, context, planning, support. Pillar 2 (Risk Management): corresponds to ISO 27001 Clause 6 and 8 — risk assessment, risk treatment, and the control implementation framework. Pillar 3 (Security Operations): corresponds to ISO 27001 Clauses 9–10 and the operational Annex A controls — monitoring, incident response, improvement. An organization that builds a compliant ISO 27001 ISMS and maps it explicitly to the BSSN SNSIK framework satisfies both simultaneously — with the ISO 27001 certificate providing the independent verification that BSSN assessments look for. |
IT/OT Security Architecture: The Four-Zone Model
Critical infrastructure operators and industrial healthcare environments (large hospital campuses with building management systems, medical gas networks, and laboratory automation) operate both IT and OT environments. The key security design challenge is creating appropriate segmentation between these zones while maintaining the operational data flows that enable efficient operations. The four-zone model provides the architecture baseline:
| Network zone | Systems | Security approach | Connectivity rules | ISO 27001 controls |
| Enterprise IT Zone | Corporate email, ERP, HR systems, enterprise applications, internet connectivity, cloud workloads | Standard ISO 27001 controls apply fully. MFA for all users, endpoint protection, vulnerability management, SIEM, DLP. Standard patching cadence (monthly critical, quarterly general). | Internet-connected. Can connect to DMZ systems with controls. Must not directly access OT zone. | Full Annex A Domain 8 applies. 8.22 (segmentation from OT), 8.5 (MFA), 8.8 (vuln mgmt), 8.16 (monitoring). |
| IT/OT DMZ (Demilitarized Zone) | Historian servers, engineering workstations (jump servers for OT access), data diodes (one-way data flow from OT to IT), SCADA supervisory servers | Strict access controls — access from IT zone requires MFA and VPN. No direct internet access. All connections logged. Jump server for any access to OT zone. Firewall with whitelist-only rules between IT and OT. | Receives data from OT zone (often unidirectional via data diode). Allows controlled access from IT zone. Never direct connection from internet to OT. | 8.22 (network segmentation — the DMZ is the core implementation), 8.2 (privileged access for jump server), 8.15 (logging all DMZ access), 5.3 (segregation of duties for IT/OT access approval). |
| OT / ICS Zone | SCADA, DCS, PLCs, RTUs, HMIs, field devices (sensors, actuators), industrial networking equipment | Patching on manufacturer schedule (may be years). Antivirus only where manufacturer-approved. Monitoring via passive network monitoring (no active scanning that could disrupt OT). Change management is safety-critical — every change requires engineering review before implementation. | No direct internet connection. Receives commands from DMZ jump servers only through controlled channels. OT-specific protocols (Modbus, DNP3, IEC 61850) within OT zone only. | 8.22 (isolation from IT), 8.32 (change management — engineering-level rigor), 8.8 (passive vulnerability monitoring only — no active scanning), 5.29 (IS during disruption — manual operations fallback procedures), 8.9 (configuration management for OT baselines). |
| Safety Systems (where present) | Safety Instrumented Systems (SIS), Emergency Shutdown Systems (ESD), Fire and Gas Systems (FGS) | Completely air-gapped from all other networks including OT zone. Physical access controls only. No remote access. Changes require independent safety engineering sign-off per IEC 61511 or equivalent. ISO 27001 controls apply only to physical security and access documentation. | Air-gapped — no network connectivity to any zone. Physical access only. | 7.1–7.3 (physical security perimeters), 7.2 (physical entry controls), 5.3 (segregation of duties for safety system access), 5.28 (evidence collection for any access or change). |
The IT/OT DMZ is the most important architectural element and the one most frequently absent in Indonesian industrial environments. Organizations that have connected OT systems to corporate IT networks without a properly implemented DMZ — often because 'we needed to access the SCADA data from the office' — have created an attack path from the internet to industrial control systems. The historian server in the DMZ, receiving real-time data from OT through a data diode and making it available to the IT zone, achieves the business need (operational data access) without creating the IT-to-OT attack path.
High-Availability ISMS Design Adaptations
The standard ISO 27001 implementation methodology produces an ISMS well-suited to commercial environments where the primary consequence of a security failure is financial or reputational. Adapting this methodology for healthcare and critical infrastructure requires five design principle modifications that reweight the standard's assumptions toward availability:
| Design principle | Standard ISMS approach | High-availability sector adaptation |
| Availability as the primary risk dimension | Standard ISO 27001 implementation treats Confidentiality, Integrity, and Availability as equally weighted CIA properties. Risk scoring applies the same L×I formula to all three. | For healthcare and critical infrastructure, Availability risks must be weighted more heavily in the risk scoring formula — a 1-hour clinical system outage affecting patient safety is a CRITICAL risk even at low likelihood. Adjust the impact scale to reflect operational consequences: patient harm (healthcare), service disruption affecting thousands of people (critical infrastructure). |
| Operational continuity over security isolation | Standard risk treatment might suggest isolating a compromised system. ISO 27001 5.26 focuses on containing, eradicating, and recovering. | In healthcare and critical infrastructure, the incident response decision tree must include a 'maintain operations' branch before 'isolate system.' A hospital cannot shut down its ICU monitoring network to contain malware — it must maintain patient care while managing the incident. The incident response procedure must document approved degraded-operation modes for every critical system. |
| Manual fallback as a control | ISO 27001 5.29 and 5.30 address IS during disruption and ICT readiness for BCM — but the specific fallback procedures are left to the organization. | For healthcare: every Tier 1 clinical system must have a documented, tested manual fallback procedure — paper medication charts, laminated emergency protocols, manual vital signs recording. For critical infrastructure: manual control procedures for SCADA systems must be maintained and operators must practice them. Fallback procedures are ISMS controls, not just BCM artifacts. |
| Change management at engineering rigor | ISO 27001 8.32 requires a formal change management procedure with security review. Standard implementation focuses on IT change management. | For OT/ICS environments and safety-critical clinical systems: change management must meet engineering-level rigor. Every change requires impact assessment on physical operations, not just IT systems. For OT: changes require SCADA engineer sign-off, safety assessment, and may require planned shutdown. For clinical systems: changes require clinical informatics and clinical safety review before implementation. |
| Vendor and manufacturer dependency management | ISO 27001 5.19–5.22 address supplier security management. Standard implementation focuses on data processing suppliers and IT vendors. | For medical devices: the manufacturer is a critical dependency for patching, support, and security guidance — but may have end-of-life or end-of-support schedules that create unmitigable vulnerabilities. For OT equipment: industrial equipment manufacturers may have 20+ year lifecycle expectations incompatible with security patching cycles. The ISMS must explicitly address manufacturer lifecycle risk and compensating controls for unsupported equipment. |
| ISO 27001 and IEC 62443: For industrial control system environments, ISO 27001 provides the organizational and management system layer while IEC 62443 provides the OT-specific technical security requirements. The two standards are designed to complement each other: ISO 27001 for the ISMS governance framework (risk assessment, policy management, audit, management review), IEC 62443 for OT network zone definitions, component security requirements, and system security levels. Critical infrastructure operators in Indonesia who are implementing both should structure the relationship as: ISO 27001 ISMS includes IEC 62443 OT security requirements as a specialized control domain, with the SoA referencing IEC 62443 security level requirements for OT zone classifications. |
Healthcare Digital Transformation: Special Considerations
Telemedicine and remote patient monitoring
Indonesia's healthcare system is deploying telemedicine at scale — driven by geographic distribution across 17,000 islands and the COVID-19 acceleration of digital health adoption. Telemedicine platforms handle sensitive medical data over consumer internet connections — creating a specific security challenge. The ISMS scope for a telemedicine platform must include the patient-facing endpoints as an uncontrolled environment, with controls compensating for the lack of corporate network protection: end-to-end encryption for all consultations, session management preventing unauthorized recording, and data minimization limiting what health data is transmitted versus stored.
BPJS Kesehatan data integration
BPJS Kesehatan (the national health insurance program) requires integration with all accredited healthcare providers for claims processing. This integration creates a data flow involving sensitive personal health data (diagnoses, treatments, medication) between private healthcare providers and the national health insurance system. The ISO 27001 supplier security controls (5.19–5.22) apply to the BPJS integration — with DPA requirements under UU PDP, because BPJS processes patient personal data as a processor on behalf of the healthcare provider and vice versa.
AI and clinical decision support security
Indonesian healthcare organizations are increasingly deploying AI-powered clinical decision support systems — diagnostic imaging analysis, medication dosage recommendations, sepsis prediction. These systems introduce new security considerations: integrity of the training data, security of the model inference endpoints, and audit trail for AI-assisted clinical decisions. The ISO 27001 risk assessment must explicitly include AI system risks — model poisoning, adversarial inputs, unauthorized access to clinical AI outputs — as a distinct risk category, and the SoA should include 8.26 (application security requirements) and 8.28 (secure coding) for AI system development.