Introduction: ISO 27799 and the protection of Personal Health Information
ISO 27799:2016, Health informatics — Information security management in health using ISO/IEC 27002, is the definitive international standard for applying information security management to Personal Health Information (PHI). It is a sector-specific companion to ISO/IEC 27002, translating the generic control catalogue of the ISO/IEC 27000 family into the concrete operational realities of hospitals, clinics, diagnostic laboratories, insurers, pharmacies, telehealth providers, health-information exchanges and any organisation that creates, receives, stores, processes or transmits health data. Where ISO/IEC 27001 tells an organisation how to build an Information Security Management System (ISMS), and ISO/IEC 27002 provides the reference control set, ISO 27799 tells health organisations precisely how those controls must be selected, interpreted and reinforced when the asset being protected is a person's medical record.
The standard exists because health information is uniquely sensitive and uniquely demanding. A breach of PHI is not merely a privacy incident — it can lead to discrimination, denial of insurance or employment, social stigma, blackmail, and in the worst case direct harm to patient safety where availability or integrity is compromised (for example, a tampered allergy record or an inaccessible medication history during an emergency). ISO 27799 therefore elevates the classic confidentiality-integrity-availability triad and adds explicit emphasis on accountability, auditability and patient-safety-linked availability. It is designed to be implementable by organisations of any size and to interoperate with national health-privacy regimes such as HIPAA/HITECH (United States), the UK Data Protection Act 2018/UK GDPR and NHS Data Security and Protection Toolkit, the EU GDPR (with health data as a special category under Article 9), the Digital Personal Data Protection Act 2023 and the proposed Digital Information Security in Healthcare Act (DISHA) in India, and the ABDM/Ayushman Bharat Digital Mission ecosystem.
Copyright and licensing note
ISO 27799:2016 is a copyrighted international standard published by the International Organization for Standardization (ISO). The normative text, control wording and annexes are protected and must be purchased from ISO or an authorised national standards body (for example BIS in India, BSI in the UK, or ANSI in the United States) — they cannot be reproduced. This guide is an original, independent explanatory commentary written by CyberSigma auditors. It paraphrases requirements for educational and readiness purposes and does not reproduce the copyrighted normative text. Always work from a licensed copy of the standard (and of ISO/IEC 27002:2013/2022 which it references) when conducting a formal assessment or certification.
What is ISO 27799
ISO 27799 is an implementation guideline, not a certifiable standard in its own right. Organisations do not certify against ISO 27799; they certify their ISMS against ISO/IEC 27001 and demonstrate — through the Statement of Applicability, risk treatment and control implementation — that they have applied the health-sector guidance of ISO 27799 to the ISO/IEC 27002 controls. In effect, ISO 27799 is the sectoral lens through which a health organisation reads ISO/IEC 27002.
The current edition, ISO 27799:2016, was developed by ISO Technical Committee ISO/TC 215 (Health informatics) and aligned to the 2013 edition of ISO/IEC 27002 (14 control clauses, 35 control objectives, 114 controls). It supersedes the 2008 first edition. Note that ISO/IEC 27002 was substantially restructured in its 2022 edition (into 93 controls across four themes — organisational, people, physical and technological — with attributes), so mature implementers should map the ISO 27799 guidance forward to the 2022 control structure while awaiting a future revision of 27799 itself.
Key defining characteristics of the standard:
- It is scoped exclusively to the protection of Personal Health Information (PHI) — data about the physical or mental health of an identifiable individual, including data that becomes health-related through inference or linkage.
- It mandates that health organisations implement the minimum set of controls necessary to secure PHI in a manner proportionate to threats, and it explicitly names the security objectives PHI requires: confidentiality, integrity, availability, accountability, authenticity/non-repudiation and auditability.
- It provides health-specific implementation guidance for every relevant control clause of ISO/IEC 27002, including guidance on unique-patient identification, break-glass emergency access, pseudonymisation and anonymisation of health data, secondary use for research, and the handling of highly sensitive categories (mental health, sexual health, genetic and HIV/AIDS data).
- It defines the concept of the health information custodian/data controller and the duties of care owed to the data subject (the patient/service user).
- It is deliberately technology-neutral and applicable to paper, electronic and hybrid records, and to organisations of any size — from a single-practitioner clinic to a national health service.
Who must comply / scope of applicability
ISO 27799 applies to any organisation, and any role within it, that is responsible for or has access to Personal Health Information. Because health data flows across a complex ecosystem, applicability extends well beyond hospitals to the full chain of custodians and processors. The following table sets out the principal categories of organisation in scope and how the standard bites for each.
| Organisation type / role | Why in scope | Primary ISO 27799 obligations |
|---|---|---|
| Hospitals, clinics and health systems | Primary custodians of the electronic health/medical record (EHR/EMR) | Full ISMS with 27799 health interpretation; break-glass access; patient-safety-linked availability; unique patient ID |
| Diagnostic laboratories and imaging centres | Generate and transmit sensitive results (pathology, genetics, radiology) | Integrity and authenticity of results; secure transmission; result-release controls; audit trails |
| Health insurers and payers (TPAs) | Process claims containing diagnosis and treatment data | Purpose limitation; access minimisation; secondary-use controls; strong confidentiality for underwriting-sensitive data |
| Pharmacies and pharmacy benefit managers | Hold prescription and dispensing histories | Confidentiality of medication data; identity proofing; e-prescription integrity |
| Telehealth and digital-health / mHealth vendors | Capture PHI over consumer channels and cloud | Encryption in transit/at rest; device/endpoint security; consent and data-subject rights; cloud shared-responsibility |
| Health information exchanges (HIE) and interoperability hubs | Route PHI between multiple custodians | Federated identity; end-to-end integrity; consent enforcement; cross-border transfer controls |
| Research institutions and biobanks | Perform secondary use of health data | Pseudonymisation/anonymisation; ethics-approval linkage; re-identification risk management |
| Cloud, hosting and managed-service providers to health | Process PHI on behalf of custodians | Data-processing agreements; sub-processor control; segregation; audit rights; breach notification SLAs |
| Medical device and health-IoT manufacturers | Devices generate and store PHI | Secure-by-design; firmware integrity; identity; patch management; end-of-life data handling |
| Public-health authorities and registries | Aggregate PHI for surveillance | Legal basis; minimisation; disclosure controls; statistical-disclosure limitation |
- In scope regardless of format: paper case notes, electronic records, images, biosignals, genomic files, audio/video consultations and inferred health data.
- In scope regardless of organisation size: the standard explicitly supports small practices through to national programmes.
- Data processors (not only controllers/custodians) are bound through contract to apply equivalent controls; the custodian remains accountable.
- Employees, contractors, clinicians, volunteers and third parties with any access to PHI fall within personnel-security scope.
Structure of ISO 27799
ISO 27799:2016 is organised into normative clauses that first establish health-sector context and then map, clause by clause, onto the control structure of ISO/IEC 27002:2013. The following table summarises the architecture of the standard and the control domains it interprets. The 14 security-control clauses correspond to Clauses 5–18 of ISO/IEC 27002:2013 (114 controls in total).
| Clause / component | Title (paraphrased) | Purpose in ISO 27799 |
|---|---|---|
| Clauses 1–4 | Scope, references, terms, symbols | Establish scope (protection of PHI), define health-security terms and the CIA+ objectives |
| Clause 5 | Health information security | Sets out why health information needs protecting, the threats, and the security objectives for PHI |
| Clause 6 | Practical action plan for implementing ISO/IEC 27002 | Defines management commitment, planning, obtaining management support and operating the ISMS in a health context |
| Clause 7 (maps to 27002 §5) | Information security policies | Health-specific policy content: PHI, consent, disclosure, break-glass |
| Clause 7 (maps to 27002 §6) | Organization of information security | Roles: health information custodian, security officer, segregation of duties |
| Clause 7 (maps to 27002 §7) | Human resource security | Clinician screening, confidentiality undertakings, awareness on PHI |
| Clause 7 (maps to 27002 §8) | Asset management | Classification of PHI, media handling of records and images |
| Clause 7 (maps to 27002 §9) | Access control | Role-based access, minimum necessary, break-glass, unique user ID |
| Clause 7 (maps to 27002 §10) | Cryptography | Encryption of PHI at rest/in transit, key management, digital signatures on records |
| Clause 7 (maps to 27002 §11) | Physical and environmental security | Protection of records rooms, servers, devices, secure disposal |
| Clause 7 (maps to 27002 §12) | Operations security | Malware, backup of records, logging and monitoring of PHI access, change control |
| Clause 7 (maps to 27002 §13) | Communications security | Secure network and transfer of PHI, HIE messaging, email of clinical data |
| Clause 7 (maps to 27002 §14) | System acquisition, development and maintenance | Secure development of clinical systems, test-data protection |
| Clause 7 (maps to 27002 §15) | Supplier relationships | Managing cloud/BPO/device suppliers touching PHI |
| Clause 7 (maps to 27002 §16) | Information security incident management | Breach detection, response and notification for PHI |
| Clause 7 (maps to 27002 §17) | Business continuity (ISMS aspects) | Availability of PHI for patient care and disaster recovery |
| Clause 7 (maps to 27002 §18) | Compliance | Legal/regulatory compliance, records protection, privacy, audits |
| Annex A | Threats to health information security | Catalogue of health-specific threats used to justify controls |
| Annex B | Tasks and related documents of the ISMS | Guidance on documentation and ISMS operational tasks |
Master assessment checklist
This is the operational heart of the guide. It enumerates every control domain that ISO 27799 interprets from ISO/IEC 27002, with the health-specific security objectives layered on top. For each domain we list the concrete items an auditor must verify and the typical evidence that demonstrates conformity. Where ISO 27799 adds guidance beyond the base control (for example break-glass, patient identification, or secondary use), that guidance is called out. No control area is skipped.
5.x Health information security objectives (foundational)
| What to verify | Typical evidence |
|---|---|
| PHI is formally identified and inventoried across paper, electronic and hybrid holdings | Data inventory / record of processing; asset register flagged for PHI |
| The six security objectives (confidentiality, integrity, availability, accountability, authenticity, auditability) are documented as requirements for PHI | Information security objectives document; ISMS scope statement |
| Health-specific threats (Annex A) are reflected in the risk assessment | Risk assessment report referencing health threat catalogue |
| Duty of care to data subjects and the custodian role are defined | Data-protection policy; custodian appointment; RACI |
§5 (27002) Information security policies
| What to verify | Typical evidence |
|---|---|
| An approved information security policy set exists and explicitly addresses PHI, consent and disclosure | Signed policy suite with version control and approval dates |
| Policies define lawful bases for processing and rules for disclosure to third parties | Disclosure/consent policy; legal-basis register |
| Policies are reviewed at planned intervals and after significant change | Review log; management review minutes |
| Break-glass / emergency-access policy is documented | Emergency access policy referencing clinical override |
§6 (27002) Organization of information security
| What to verify | Typical evidence |
|---|---|
| A health information security officer / DPO and information custodian roles are assigned | Appointment letters; org chart; job descriptions |
| Segregation of duties prevents unilateral access to or modification of records | SoD matrix; access-review evidence |
| Contact with authorities (regulators, CERT) and special-interest groups is maintained | Regulator contact list; CERT-In/sectoral CERT registration |
| Information security in project management includes clinical-system projects | Project security checklists; SDLC gate records |
| Mobile device and teleworking policy covers clinician remote access to PHI | BYOD/MDM policy; teleworking agreements |
§7 (27002) Human resource security
| What to verify | Typical evidence |
|---|---|
| Pre-employment screening covers clinicians, contractors and volunteers with PHI access | Background-check records; verification logs |
| Confidentiality / non-disclosure undertakings signed by all with PHI access | Signed confidentiality agreements |
| Security and privacy awareness training is role-appropriate and repeated | Training records; completion metrics; content covering PHI |
| A disciplinary process exists for security/privacy breaches | Disciplinary policy; sanction records |
| Termination/role-change triggers timely revocation of PHI access | Leaver checklist; de-provisioning tickets |
§8 (27002) Asset management
| What to verify | Typical evidence |
|---|---|
| All PHI assets are inventoried with an assigned owner | Asset register with owners and PHI classification |
| An information classification scheme labels PHI and highly sensitive subsets (mental/sexual/genetic/HIV) | Classification policy; labelling examples |
| Acceptable-use rules for handling records and images are defined and communicated | Acceptable-use policy; acknowledgement records |
| Media handling and secure disposal of records, films and drives is controlled | Media-disposal certificates; destruction logs |
§9 (27002) Access control
| What to verify | Typical evidence |
|---|---|
| Access to PHI follows role-based access control and the minimum-necessary / need-to-know principle | RBAC role definitions; access-request approvals |
| Every user has a unique identity; shared/generic accounts are eliminated for PHI systems | IAM user list; exception register |
| Break-glass emergency access is technically constrained, logged and reviewed after the fact | Break-glass configuration; post-access review reports |
| User access rights are reviewed at defined intervals (recertification) | Access recertification reports |
| Strong authentication (MFA) protects remote and privileged access to PHI | MFA configuration; privileged-access records |
| Patient/service-user access to their own records is provisioned securely | Patient-portal identity-proofing; access logs |
§10 (27002) Cryptography
| What to verify | Typical evidence |
|---|---|
| PHI is encrypted at rest on servers, databases, endpoints and backups | Encryption configuration; disk/database encryption evidence |
| PHI is encrypted in transit across all networks including HIE and email | TLS configuration; message-security settings |
| A key-management policy governs generation, rotation, storage and destruction of keys | Key-management policy; HSM/KMS records |
| Digital signatures / integrity seals protect the authenticity of clinical records where required | Signature configuration; non-repudiation evidence |
§11 (27002) Physical and environmental security
| What to verify | Typical evidence |
|---|---|
| Secure areas protect records rooms, data centres and imaging/server equipment | Access-control logs; zoning plans |
| Clear-desk / clear-screen enforced in clinical areas where PHI is visible | Clear-desk policy; walkthrough audit notes |
| Environmental controls (fire, power, cooling) protect availability of records systems | UPS/generator/fire-suppression records |
| Secure equipment disposal ensures PHI is unrecoverable from decommissioned assets | Sanitisation/destruction certificates |
§12 (27002) Operations security
| What to verify | Typical evidence |
|---|---|
| Documented operating procedures exist for PHI systems and are kept current | SOP library; change history |
| Change management controls prevent uncontrolled changes to clinical systems | Change tickets; CAB minutes |
| Anti-malware protection is deployed and monitored on all PHI endpoints and servers | EDR/AV console reports |
| Backups of PHI are taken, encrypted, tested for restorability and retained per policy | Backup schedule; restore-test results |
| Access to PHI is logged; logs are protected, monitored and retained | Audit-log samples; SIEM alerting; retention policy |
| Technical vulnerabilities are identified and remediated on a risk basis | Vulnerability-scan reports; patch SLAs |
§13 (27002) Communications security
| What to verify | Typical evidence |
|---|---|
| Networks carrying PHI are segmented and protected (firewalls, segregation of clinical/guest networks) | Network diagrams; firewall rulesets |
| Information-transfer agreements govern electronic exchange of PHI with partners | Data-sharing agreements; interface specs |
| Email and messaging of clinical data is secured or restricted | Secure-email configuration; DLP policy |
| Electronic messaging integrity (HL7/FHIR/DICOM) is protected end to end | Interface security config; message-signing evidence |
§14 (27002) System acquisition, development and maintenance
| What to verify | Typical evidence |
|---|---|
| Security and privacy requirements are specified for new clinical systems | Requirements docs; security acceptance criteria |
| Secure development lifecycle practices apply to in-house/EHR customisation | SDLC policy; code-review and testing records |
| Test environments do not use live PHI, or PHI is masked/pseudonymised | Test-data policy; masking evidence |
| Security testing (SAST/DAST/pentest) precedes go-live of PHI systems | Test reports; remediation tracker |
§15 (27002) Supplier relationships
| What to verify | Typical evidence |
|---|---|
| Supplier/processor agreements include security, privacy and breach-notification clauses for PHI | Signed DPAs/BAAs; contract clauses |
| Cloud shared-responsibility for PHI is documented and understood | Responsibility matrix; cloud config baseline |
| Supplier security performance is monitored and periodically reviewed | Vendor assessments; audit reports; SOC 2/ISO certificates |
| Sub-processor changes are controlled and notified | Sub-processor register; change notifications |
§16 (27002) Information security incident management
| What to verify | Typical evidence |
|---|---|
| An incident-response plan defines detection, triage, containment and PHI-breach handling | IR plan; playbooks for PHI breach |
| Roles, reporting channels and escalation paths are defined | IR RACI; contact tree |
| Breach notification to regulators and affected individuals meets statutory deadlines | Notification templates; past notification records |
| Lessons learned feed back into controls and risk assessment | Post-incident reviews; corrective actions |
§17 (27002) Information security aspects of business continuity
| What to verify | Typical evidence |
|---|---|
| Availability requirements for PHI are set with RTO/RPO linked to patient safety | BIA; RTO/RPO definitions |
| Continuity and disaster-recovery plans cover clinical systems and downtime procedures | BCP/DRP; clinical downtime procedures |
| Continuity arrangements are tested and results actioned | DR test reports; exercise records |
| Redundancy is provided for critical PHI systems | HA/failover architecture evidence |
§18 (27002) Compliance
| What to verify | Typical evidence |
|---|---|
| Applicable legal and regulatory requirements (privacy, retention, e-signature) are identified | Legal register mapped to controls |
| Records (medical, audit, consent) are protected and retained per statutory periods | Retention schedule; records-management policy |
| Privacy and data-protection of PHI is demonstrably ensured | DPIA/PIA records; consent management evidence |
| Independent reviews and internal audits of the ISMS are conducted | Internal audit reports; management review minutes |
Scoping and materiality / tiering
Effective ISO 27799 adoption begins with disciplined scoping so that control rigour is proportionate to the sensitivity and volume of PHI and to the harm a compromise would cause. ISO 27799 encourages a risk-based, tiered approach rather than uniform maximum controls everywhere.
| Scoping / materiality dimension | How to determine tier | Effect on control depth |
|---|---|---|
| Data sensitivity | Standard PHI vs. highly sensitive (mental health, sexual/reproductive, genetic, HIV/substance-use) | Highly sensitive subsets warrant stricter access, enhanced logging and additional consent controls |
| Volume and aggregation | Single-patient view vs. bulk datasets / registries / research extracts | Larger aggregations raise re-identification and mass-breach risk; add statistical-disclosure and DLP controls |
| Patient-safety linkage | Whether unavailability/integrity loss can harm patients | Systems tied to care delivery get higher availability tiers, faster RTO and integrity assurance |
| Data-subject identifiability | Identified vs. pseudonymised vs. anonymised | Anonymised data may fall outside PHI scope; pseudonymised remains in scope with key-separation controls |
| Cross-border and third-party flow | Domestic vs. cross-border, in-house vs. processor/cloud | Cross-border transfer and processor controls, contractual safeguards and residency requirements apply |
| Regulatory overlay | Which regimes apply (HIPAA, GDPR Art. 9, DPDP Act, NHS DSPT, DISHA) | Determines mandatory breach timelines, consent model and certification expectations |
The materiality of a control gap should be judged by the potential harm to the data subject and to patient safety, not merely by system criticality. A gap in break-glass logging on a psychiatric records system is materially more severe than the same gap on a facilities database.
Implementation approach
CyberSigma recommends a phased implementation that layers the ISO 27799 health interpretation onto an ISO/IEC 27001 ISMS. Each phase below lists the core activities and the deliverables an assessor will expect to see.
Phase 1 — Initiate and mandate (weeks 1–4)
- Activities: secure executive sponsorship; appoint the information security officer, DPO and health information custodian; define ISMS scope covering all PHI; establish governance and steering committee.
- Deliverables: signed ISMS mandate; scope statement; governance charter; role appointments; project plan and RACI.
Phase 2 — Discover and assess risk (weeks 3–10)
- Activities: build the PHI data inventory and data-flow maps; classify data including highly sensitive subsets; conduct the risk assessment using the ISO 27799 health-threat catalogue; run DPIAs for high-risk processing.
- Deliverables: PHI asset register; data-flow diagrams; risk assessment report and risk register; DPIA records; gap analysis against ISO/IEC 27002 with 27799 guidance.
Phase 3 — Design controls and treatment plan (weeks 8–16)
- Activities: define the risk-treatment plan; draft the Statement of Applicability with health-specific justifications; author policies (access, break-glass, disclosure, retention, cryptography); design RBAC and logging architecture.
- Deliverables: risk-treatment plan; Statement of Applicability; approved policy suite; access-control and audit-logging designs.
Phase 4 — Implement and operationalise (weeks 14–30)
- Activities: deploy technical controls (encryption, MFA, EDR, SIEM, DLP, break-glass, backups); enforce SoD and recertification; roll out training; execute supplier/DPA remediation.
- Deliverables: control-implementation evidence; training completion records; updated supplier contracts; configured logging/monitoring.
Phase 5 — Measure, audit and improve (weeks 26–40)
- Activities: run internal audit and management review; test incident response and continuity; measure KPIs; remediate findings; conduct stage 1/2 certification readiness.
- Deliverables: internal audit report; management review minutes; DR/IR test results; corrective-action plan; certification-readiness pack.
Phase 6 — Sustain and mature (ongoing)
- Activities: continuous monitoring; periodic recertification of access; annual risk reassessment; surveillance-audit support; maturity uplift.
- Deliverables: continuous-improvement register; annual risk refresh; surveillance-audit evidence.
Maturity / capability model
While ISO 27799 does not itself prescribe a maturity scale, CyberSigma applies a five-level capability model (aligned to common ISMS maturity practice) to benchmark a health organisation's protection of PHI and to plan uplift.
| Level | Name | Characteristics for PHI protection |
|---|---|---|
| 1 | Initial / Ad hoc | PHI handled informally; no documented policy; access uncontrolled; reliance on individual discretion; no audit trail |
| 2 | Repeatable / Managed | Basic policies exist; some access control and encryption; inconsistent application; reactive incident handling |
| 3 | Defined | Documented ISMS with 27799 interpretation; RBAC, break-glass and logging in place; training delivered; risk assessment performed |
| 4 | Quantitatively managed | Controls measured via KPIs; access recertified; continuous monitoring and SIEM; DPIAs routine; supplier assurance operational |
| 5 | Optimising | Continuous improvement; threat-informed control tuning; automation of access review and breach detection; near-real-time assurance and full certification maintained |
Assessment and audit approach
A rigorous ISO 27799 assessment follows the ISO/IEC 27001 audit discipline with a health overlay. The recommended sequence is as follows.
- Confirm scope and objectives: agree the boundary of PHI processing, systems, sites and third parties to be assessed.
- Review documentation (stage 1): examine the ISMS scope, policies, Statement of Applicability, risk assessment and 27799-specific procedures for completeness.
- Perform data-flow and inventory validation: verify the PHI inventory and flows reflect reality, including cloud and processor touchpoints.
- Assess risk treatment: check that identified health-specific risks are addressed by selected controls with documented justification.
- Conduct control testing (stage 2): sample-test each control domain — access control, break-glass, encryption, logging, backup, incident response — against evidence and live configuration.
- Interview roles: interview clinicians, IT, custodian, DPO and suppliers to confirm operating effectiveness, not just design.
- Test incident and continuity readiness: review or observe an IR/DR exercise and breach-notification capability against statutory deadlines.
- Evaluate metrics and management review: confirm KPIs are tracked and drive improvement, and that management review closes the loop.
- Document findings and rate materiality: classify nonconformities (major/minor) and observations by patient-harm potential.
- Agree corrective actions and re-test: set remediation timelines, verify closure and issue the assessment report / certification recommendation.
Evidence request list
The following categorised evidence list is what CyberSigma requests at the outset of an ISO 27799 readiness or audit engagement.
- Governance and scope: ISMS scope statement; information security and privacy policies; role appointments (security officer, DPO, custodian); management review minutes.
- Risk and data: PHI data inventory and data-flow maps; data classification scheme; risk assessment and register; DPIA/PIA records; Statement of Applicability.
- Access control: RBAC role catalogue; access-request/approval records; access recertification reports; break-glass policy and post-access reviews; MFA configuration.
- Cryptography and data protection: encryption-at-rest and in-transit configuration; key-management policy; DLP policy and reports.
- Operations and monitoring: SOPs; change-management records; backup schedule and restore-test results; audit-log samples and SIEM alerting; vulnerability and patch reports.
- Human resources: screening records; signed confidentiality undertakings; training content and completion metrics; joiner/mover/leaver records.
- Supplier assurance: DPAs/BAAs; sub-processor register; vendor assessments and third-party certificates (SOC 2, ISO/IEC 27001).
- Incident and continuity: IR plan and playbooks; breach-notification templates and past records; BCP/DRP and test results; BIA with RTO/RPO.
- Physical security: secure-area access logs; media-disposal and equipment-sanitisation certificates; environmental-control records.
- Compliance: legal/regulatory register; records-retention schedule; internal audit reports; consent-management evidence.
Roles and responsibilities
| Role | Key responsibilities under ISO 27799 | Accountable for |
|---|---|---|
| Executive management / Board | Provide mandate, resources and risk appetite; approve ISMS | Overall accountability for PHI protection |
| Health information custodian / Data controller | Own the duty of care to data subjects; authorise disclosures | Lawful, secure handling of PHI |
| Information Security Officer / CISO | Design, operate and maintain the ISMS and controls | Control effectiveness and security posture |
| Data Protection Officer (DPO) | Ensure privacy compliance, DPIAs and data-subject rights | Regulatory privacy compliance |
| System / application owners | Implement controls on clinical systems; manage access | Security of their PHI systems |
| Clinicians and care staff | Follow acceptable use, minimum-necessary access, report incidents | Correct day-to-day handling of PHI |
| IT operations | Run backups, patching, monitoring, IAM and encryption | Operational control execution |
| Internal audit | Independently assess conformity and effectiveness | Assurance to management |
| Suppliers / processors | Apply contractually required controls; notify breaches | Security of PHI they process |
KPIs / metrics to track
- Percentage of PHI assets inventoried and classified (target 100%).
- Percentage of PHI systems with encryption at rest and in transit enforced.
- MFA coverage for remote and privileged access to PHI systems.
- Access-recertification completion rate and overdue count.
- Number of break-glass access events and percentage reviewed within SLA.
- Mean time to detect (MTTD) and mean time to respond (MTTR) for PHI incidents.
- Percentage of PHI breaches notified to regulators within the statutory deadline.
- Backup restore-test success rate and RTO/RPO achievement for critical systems.
- Security-awareness training completion rate for staff with PHI access.
- Percentage of suppliers processing PHI with a signed DPA/BAA and current assurance.
- Critical/high vulnerability remediation within SLA on PHI systems.
- Number of open nonconformities from internal/external audit and their ageing.
Readiness checklist
- ISMS scope covering all PHI processing is defined and approved.
- Security officer, DPO and health information custodian appointed in writing.
- Complete PHI data inventory and data-flow maps produced.
- Data classification distinguishes standard from highly sensitive PHI.
- Risk assessment using health-specific threats completed with a risk register.
- Statement of Applicability documents 27799-informed control selection.
- RBAC with minimum-necessary access enforced; generic accounts removed.
- Break-glass emergency access is constrained, logged and reviewed.
- Encryption at rest and in transit enforced across all PHI holdings.
- MFA protects remote and privileged access to PHI.
- Audit logging of PHI access enabled, protected and monitored via SIEM.
- Backups encrypted and restore-tested; RTO/RPO linked to patient safety.
- Incident-response and breach-notification procedures meet statutory deadlines.
- Business continuity and clinical downtime procedures tested.
- Confidentiality undertakings signed and role-based training delivered.
- Supplier DPAs/BAAs in place with breach-notification clauses.
- Retention and disposal schedules align with legal requirements.
- Internal audit and management review completed with corrective actions tracked.
Common gaps and findings
- Shared or generic clinical logins that defeat accountability and audit trails.
- Break-glass access implemented without after-the-fact review, so emergency overrides are never scrutinised.
- Incomplete PHI inventory — imaging archives (PACS), medical devices and shadow/legacy systems omitted from scope.
- Live PHI used in test and training environments without masking or pseudonymisation.
- Backups present but never restore-tested, or backups unencrypted.
- Audit logs enabled but not retained, protected or actively monitored.
- Supplier and cloud processing of PHI without a signed DPA/BAA or defined shared-responsibility model.
- Breach-notification processes that cannot meet statutory deadlines (e.g. GDPR 72 hours; HIPAA within 60 days).
- Highly sensitive categories (mental health, HIV, genetics) not given enhanced access and logging controls.
- Access recertification not performed, leaving orphaned and excessive entitlements.
- Patient-safety-linked availability not translated into concrete RTO/RPO and tested continuity plans.
- Awareness training generic and not tailored to PHI handling and clinical workflows.
ISO 27799 mapped to other frameworks
ISO 27799 rarely operates alone; health organisations must reconcile it with statutory privacy regimes and other security standards. The following mapping helps teams reuse a single control set across obligations.
| Framework / regulation | Relationship to ISO 27799 | Key point of alignment |
|---|---|---|
| ISO/IEC 27001 | ISMS management system that ISO 27799 operationalises | Certify against 27001; apply 27799 health guidance in the SoA |
| ISO/IEC 27002 (2013/2022) | Reference control set that 27799 interprets for health | Map 27799 guidance onto the 93 controls of the 2022 edition |
| HIPAA Security & Privacy Rules (US) | National health-privacy regime; complementary | Access control, audit, encryption, BAAs, breach notification (60 days) |
| HITECH Act (US) | Strengthens HIPAA breach and enforcement | Breach notification and safeguards for electronic PHI |
| EU GDPR (Art. 9 special category) | Overarching privacy law for health data | Lawful basis, DPIA, data-subject rights, 72-hour breach notice |
| UK DPA 2018 / NHS DSPT | UK privacy law and NHS assurance toolkit | Annual DSPT submission maps to 27799 control evidence |
| India DPDP Act 2023 / DISHA (proposed) | Indian personal-data and health-data regimes | Consent, data-fiduciary duties, breach notification to Data Protection Board |
| ABDM / Ayushman Bharat Digital Mission | Indian digital-health ecosystem standards | Health-ID, consent manager and data-security expectations |
| NIST SP 800-66 (HIPAA guidance) | US implementation guidance for health security | Cross-references NIST controls to health safeguards |
| ISO/IEC 27701 | Privacy extension to the ISMS | Adds PIMS controls for PHI as personal data |
| ISO 13606 / HL7 FHIR security | Health-informatics interoperability with security | Secure exchange of PHI across systems |
How CyberSigma helps
Partner with CyberSigma for ISO 27799 assurance
CyberSigma's CERT-In empanelled auditors and PCI QSAs deliver end-to-end ISO 27799 and ISO/IEC 27001 services for the health sector: PHI data-flow discovery and classification, health-threat risk assessment, DPIA facilitation, Statement of Applicability drafting with health interpretation, break-glass and RBAC design, encryption and logging architecture, supplier/BAA remediation, incident-response and breach-notification playbooks aligned to GDPR, HIPAA and the DPDP Act, and full internal-audit and certification-readiness support. We benchmark your maturity, close the gaps, and stand alongside your team through certification and surveillance audits — so your patients' data, and your patient safety, are provably protected. Contact CyberSigma to scope an ISO 27799 readiness assessment for your organisation.
Frequently asked questions
Is ISO 27799 separately certifiable?
It is guidance that supports ISO/IEC 27001 certification in a health context rather than a standalone certification.
Official documents
CyberSigma resources
Need help with ISO 27799?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.