ISO 27001 and ISO 27799 for Healthcare Security

ISO 27001 and ISO 27799 solve different parts of the healthcare-security problem. ISO/IEC 27001 supplies the requirements for an information security management system (ISMS): governance, risk, operation, evaluation and improvement. ISO 27799:2025 provides health-sector security controls and implementation guidance based on ISO/IEC 27002:2022.

Together they allow a hospital, clinic, insurer, laboratory, health platform or health-information custodian to manage security systematically while addressing clinical workflows, health data and healthcare technologies. ISO 27799 does not replace the ISMS requirements, and ISO 27001 certification does not by itself prove conformity with every healthcare law or contractual obligation.

Use the current ISO 27799 edition

Older guidance may discuss ISO 27799:2008 or 2016. ISO lists both as withdrawn and identifies ISO 27799:2025 as the current edition. The 2025 standard provides information-security controls and implementation guidance for health organisations and is based on ISO/IEC 27002:2022.

Confirm the edition in policies, crosswalks, supplier clauses and audit criteria. An inherited mapping to an older ISO/IEC 27002 structure should not be carried forward without review.

Give each standard a clear role

ISO/IEC 27001 answers management-system questions:

• What organisational and external context affects security?
• Which interested parties and requirements matter?
• What is inside the ISMS scope?
• Who leads, owns and accepts risk?
• How are risks assessed and treated?
• How are controls operated and changed?
• How is performance audited and reviewed?
• How are failures corrected and the system improved?

ISO 27799 adds healthcare-specific control guidance. ISO/IEC 27002 remains a general information-security control resource. Use the three coherently rather than building separate programmes for each publication.

Define the healthcare scope around care and information flows

A scope based only on the IT department will miss clinical reality. Map:

• patient registration, consultation and care delivery;
• electronic health records and clinical applications;
• diagnostic imaging, laboratory and pharmacy systems;
• connected and software-enabled medical devices;
• telehealth, patient portals and mobile use;
• health-information exchange and referrals;
• insurers, revenue-cycle and claims processes;
• research, analytics and artificial intelligence;
• paper, voice, video and physical media;
• cloud, managed service and equipment suppliers; and
• emergency and downtime workflows.

Identify legal entities, sites, interfaces and dependencies. A system can be outside the certification boundary yet still create a dependency or risk that the scoped service must manage.

Model healthcare-specific risk scenarios

Healthcare risk extends beyond confidentiality. Integrity and availability can affect clinical decisions and patient safety, while inappropriate disclosure can cause personal and legal harm.

Useful scenarios include:

• an incorrect patient identity causing records to be associated with the wrong person;
• unavailable clinical systems delaying time-critical care;
• altered medication or diagnostic information influencing treatment;
• excessive employee access exposing sensitive records;
• ransomware disrupting devices and care pathways;
• remote vendor access being misused;
• data exchanged with a partner using incorrect permissions;
• an emergency override remaining open after the event; or
• research data being reused beyond authorised conditions.

Describe the event, weakness, affected information or service, consequence, existing safeguards and owner. Involve clinical, privacy, biomedical engineering, technology, facilities and business leaders.

The risk-register guide explains how to build decision-ready scenarios. The risk score calculator can support consistent evaluation if it fits the approved method.

Integrate control selection once

Create one controlled control architecture:

1. identify obligations and risk-treatment needs;
2. compare necessary controls with ISO 27001 Annex A;
3. use ISO 27799:2025 for health-specific guidance;
4. use ISO/IEC 27002 for broader implementation guidance;
5. record applicability, implementation status and evidence; and
6. address gaps through treatment plans.

Do not assume that every ISO 27799 control is automatically required by ISO 27001 certification. Conversely, do not exclude health-specific safeguards merely because an Annex A title is broad. Applicability is determined through risks and requirements.

Use the Annex A control lookup to explore control themes before confirming decisions against licensed publications.

Focus on identity and clinical access

Healthcare access design needs to support routine care, multidisciplinary teams, emergency access, temporary staff and specialist systems.

Define:

• authoritative workforce and patient identities;
• role and context-based access decisions;
• privileged and service-account ownership;
• emergency or break-glass conditions;
• segregation where conflicts create risk;
• authentication appropriate to clinical conditions;
• rapid removal after role or contract change;
• audit logging and review; and
• response to inappropriate viewing or disclosure.

Emergency access should be available where justified, attributable, limited, monitored and reviewed. A clinical need for speed does not justify shared accounts with no accountability.

Treat medical devices as service components

The current ISO 27799 scope explicitly includes medical devices containing health software. Build joint ownership between clinical engineering, security, technology, procurement and clinical services.

Evidence may include:

• device inventory, owner and clinical criticality;
• software or firmware status;
• network placement and permitted communication;
• vendor remote-access controls;
• vulnerability and compensating-control decisions;
• maintenance and change records;
• security event integration;
• backup or configuration recovery; and
• safe isolation and downtime arrangements.

Where patching is constrained by safety or vendor approval, document the risk, alternatives, monitoring, authority and review date. “Cannot patch” is a condition requiring treatment, not a completed decision.

Design availability around patient care

Recovery targets should come from clinical and operational impact, not only technology preference. Consider patient safety, maximum tolerable interruption, manual workarounds, data reconciliation and return to normal operation.

Test realistic combinations such as identity-service failure during peak care, loss of a clinical network segment, unavailable cloud records, imaging outage or ransomware isolation. Observe how staff access critical information, communicate, document care and reconcile later.

The data-centre security controls guide provides additional evidence considerations for infrastructure and resilience.

Govern suppliers and data exchange

Healthcare services depend on cloud platforms, device manufacturers, laboratories, claims processors, transcription, support providers and health-information exchanges.

Define:

• information and system access;
• purpose and permitted use;
• security and privacy obligations;
• subcontracting and location;
• incident notification and cooperation;
• remote maintenance;
• evidence and assurance rights;
• continuity and exit; and
• deletion, return or transition of information.

Review provider assurance scope and exceptions. Certification held by a supplier does not establish that your configuration, data flow or complementary responsibilities are controlled.

The supplier audit guide explains how to test outsourced controls proportionately.

Connect security incidents with clinical response

Security incident processes should integrate clinical escalation, privacy assessment, biomedical engineering, continuity and communications. Classification should consider patient-safety and care consequences as well as technical severity.

Exercise decisions such as whether to isolate a device, disable an account, divert patients, invoke downtime records or notify partners. Retain timelines, authority, evidence handling, lessons and corrective action.

The incident management evidence guide provides a traceable response model.

Build an integrated evidence map

Healthcare area	Design evidence	Operating evidence
Clinical access	Role design and emergency-access rules	Access changes, override events and review
Medical devices	Ownership, architecture and treatment decisions	Maintenance, monitoring and exception follow-up
Availability	Recovery design and clinical dependency analysis	Exercises, outages and reconciliation results
Data exchange	Approved flow and partner requirements	Transfer monitoring, access review and incidents
Suppliers	Contract and responsibility model	Assurance review, service results and actions
Workforce	Role competence and communication plan	Completion, observed behaviour and remediation

Keep evidence in authoritative systems where possible. Protect patient and security-sensitive records, and provide auditors with the minimum necessary information.

Audit sampling approach

Select samples by clinical criticality, data sensitivity, recent change and known weakness. A useful audit can:

• trace a clinician joiner, role change and departure;
• inspect an emergency-access event;
• sample a vulnerable medical device and its treatment;
• follow a supplier’s remote session from approval to logs;
• test a downtime or recovery scenario;
• trace a health-data exchange to agreement and monitoring; and
• follow an incident lesson into control improvement.

Interview clinical and operational owners, not only security personnel. Compare the documented process with work during real care conditions.

Pass

The organisation used one risk-governed ISMS, incorporated current health-specific guidance, assigned clinical and technical owners, and retained operating evidence across critical workflows and suppliers.

Partial

Core controls worked, but older mappings remained in use and two medical-device exceptions lacked clear review dates and compensating-control evaluation.

Fail

The ISMS covered corporate IT only. Clinical devices, emergency access, health-information exchange and key suppliers had no accountable risk treatment or reliable evidence.

Common gaps

Avoid:

• using a withdrawn ISO 27799 edition;
• treating healthcare security as confidentiality alone;
• excluding clinical workflow owners from risk assessment;
• allowing shared clinical accounts without attribution;
• accepting unpatchable-device statements without treatment;
• testing system recovery without patient-care workflow;
• assuming supplier certification transfers accountability; or
• duplicating separate control registers that drift apart.

The practical conclusion

ISO 27001 supplies the management system; ISO 27799:2025 supplies current healthcare-focused controls and guidance. Integrate them through one scope, risk method, applicability decision process, ownership structure and evidence model.

Focus on clinical identity, information integrity, service availability, medical devices, suppliers and emergency operation. When clinical and technical teams can trace risks to controls and controls to operating evidence, the combined approach supports both audit confidence and dependable care.

The subject perspective was informed by Advisera’s article on ISO 27001 and ISO 27799 in health organisations, updated for ISO 27799:2025 using ISO’s current publication information.