HIPAA and PCI-DSS Compliance Requirements

The HIPAA Security Rule, codified at 45 CFR Parts 160 and 164, requires covered entities and business associates to implement safeguards that protect electronic protected health information (ePHI) against reasonably anticipated threats and impermissible uses. The rule is organised into three safeguard categories. Within each category, individual specifications are labelled either required (must be implemented as stated) or addressable (must be implemented if reasonable and appropriate, or documented and replaced with an equivalent alternative).

Administrative safeguards are the largest category, covering nine standards. They include: a security management process (risk analysis and risk management are both required), assigned security responsibility (a designated security official is required), workforce security (authorisation and supervision are addressable), information access management, security awareness and training, security incident procedures, contingency planning (data backup and disaster recovery plans are required; testing and applications criticality analysis are addressable), evaluation (periodic technical and non-technical evaluation is required), and business associate contracts. A risk analysis under this category must identify all ePHI the organisation creates, receives, maintains, or transmits, catalogue threats and vulnerabilities, assess current controls, and determine residual risk.

Physical safeguards govern physical access to facilities and devices holding ePHI. They include facility access controls (contingency operations and maintenance records are addressable; facility security plans and access control and validation procedures are addressable), workstation use (required), workstation security (required), and device and media controls (disposal and media re-use are required; accountability and data backup and storage are addressable). The workstation security standard requires physical safeguards to restrict access to workstations that access ePHI, which in practice means locked rooms, screen privacy filters, and cable locks in shared spaces.

Technical safeguards address the technology that protects ePHI and controls access to it. Access control (unique user identification is required; automatic logoff and encryption are addressable), audit controls (required, with no further specifications, giving flexibility in implementation), integrity controls (addressable), and transmission security (addressable, but encryption of ePHI in transit is the expected implementation). The absence of a specific encryption mandate in some specifications is intentional: the rule is technology-neutral and performance-based. OCR auditors assess whether the organisation chose controls commensurate with its risk analysis.

PCI-DSS version 4.0, published in 2022 and mandatory from April 2024, reorganised its requirements under six principal goals. Each goal contains one to three numbered requirements, giving twelve in total. The standard applies to any entity that stores, processes, or transmits cardholder data or sensitive authentication data. Sensitive authentication data includes full track data, card verification values, and PINs; unlike cardholder data (primary account number, cardholder name, expiration date, service code), sensitive authentication data must never be stored after authorisation, even if encrypted.

Version 4.0 introduced a customised approach alongside the defined approach. Under the defined approach, an entity implements controls exactly as specified. Under the customised approach, an entity can implement alternative controls that meet the stated objective of each requirement, provided it documents and justifies the alternative and has it validated by a QSA. The customised approach is intended for mature organisations with sophisticated security programmes, not a workaround for avoiding inconvenient controls.

PCI-DSS compliance cost and complexity scale directly with the size of the cardholder data environment. Every system component in scope must satisfy all applicable requirements. Scope reduction is therefore the primary cost-control strategy for organisations subject to PCI-DSS: if a system cannot see, touch, or affect the CDE, it is out of scope. Segmentation is the mechanism: firewall rules, VLANs, and network architecture that prevent any out-of-scope system from communicating with the CDE effectively remove those systems from assessment.

Requirement 12.5.2 of PCI-DSS 4.0 requires organisations to document and confirm the accuracy of their PCI-DSS scope at least once every twelve months and on significant changes to the environment. The scoping exercise must identify all account data flows, all system components that store, process, or transmit account data, all system components that connect to the CDE, and all network segmentation controls. A QSA will verify scope accuracy as a preliminary step before assessing individual requirements.

HIPAA scoping works differently. There is no formal CDE equivalent: the obligation applies to all ePHI the organisation holds, regardless of system or location. A HIPAA risk analysis must catalogue all ePHI across all systems, media, and locations, including paper records that have been digitised and cloud storage used by workforce members. The practical challenge is that healthcare organisations often have sprawling, heterogeneous IT estates with ePHI in clinical systems, billing platforms, email, mobile devices, and third-party portals simultaneously.

PCI-DSS has a formal tiered assessment structure tied to transaction volume. Card brands (Visa, Mastercard, American Express, Discover, JCB) each publish their own merchant level definitions, but the common structure is: Level 1 merchants (over six million transactions per year for Visa) must undergo an annual on-site assessment by a QSA, producing a Report on Compliance (RoC) and a quarterly network scan by an Approved Scanning Vendor (ASV). Lower-level merchants may complete a Self-Assessment Questionnaire, of which several variants exist based on how the merchant accepts cards (e.g., SAQ-A for merchants who have fully outsourced card processing, SAQ-D for merchants with a full CDE).

The QSA conducts the on-site assessment by interviewing personnel, observing system configurations, reviewing documentation, and testing controls. Evidence types include system-generated logs, configuration files, network diagrams, policies and procedures, penetration test reports, and ASV scan results. The QSA records findings in a RoC using the PCI SSC's standardised reporting template, rating each requirement as In Place, Not In Place, Not Applicable, or Not Tested. A compensating control worksheet must be completed for any requirement met by an alternative control rather than the specified one.

HIPAA has no equivalent certification scheme or assessor designation. The OCR conducts compliance reviews (targeted or desk audits) and investigates complaints. When a breach of 500 or more individuals is reported, OCR typically opens an investigation. OCR's audit protocol, publicly available since 2016, identifies the documentation and evidence it expects organisations to produce: the most commonly cited deficiencies in OCR resolution agreements are missing or inadequate risk analyses, missing Business Associate Agreements, and insufficient access controls. Healthcare organisations sometimes engage third-party consultants with HIPAA expertise to conduct gap assessments in preparation for potential OCR scrutiny, but there is no required third-party certification.

Internal Security Assessors (ISAs) are an alternative PCI-DSS path for organisations that want internal assessment capability. An ISA is an individual employed by the assessed organisation who has completed PCI SSC training and can conduct PCI-DSS self-assessments for their employer. ISA certification does not authorise assessments of other organisations; that remains the QSA's domain. The ISA programme is designed for Level 2-4 merchants and for preparation before a QSA assessment.

HIPAA enforcement is government-administered. The OCR within the US Department of Health and Human Services investigates complaints and self-reported breaches. Civil monetary penalties are tiered by culpability: unknowing violations carry a minimum of $100 per violation and a calendar-year cap of $25,000 per violation category; violations due to wilful neglect that are not corrected carry a minimum of $50,000 per violation and a calendar-year cap of $1.9 million per violation category. The DOJ handles criminal enforcement for knowing and intentional violations, with penalties up to $250,000 and ten years imprisonment.

PCI-DSS penalties are contractual, not statutory. Card brands can fine acquiring banks for non-compliance by merchants in their portfolio; acquiring banks pass those fines to merchants. In the event of a card data breach, the merchant or service provider may face forensic investigation costs (the card brand mandates use of a PCI Forensic Investigator), fines per compromised card account, card replacement costs, and potential termination of card acceptance privileges. The largest recorded fines following data breaches have reached tens of millions of US dollars. Unlike HIPAA, there is no government regulator imposing PCI-DSS penalties directly.

Other jurisdictions impose analogous obligations. The EU's General Data Protection Regulation (GDPR) applies to health and payment data held on EU residents, with penalties up to 4% of global annual turnover or 20 million euros. India's Digital Personal Data Protection Act 2023 (DPDP Act) establishes obligations for data fiduciaries handling personal data, with a Data Protection Board adjudicating complaints and penalties scaling to 250 crore rupees for significant failures. The UK retained a GDPR-equivalent (UK GDPR) after Brexit, with the ICO as enforcement authority. These regimes overlap with HIPAA and PCI-DSS for multinational organisations: a US hospital with EU patients, or a payment processor handling Indian cardholder data, may face simultaneous obligations under multiple frameworks.

Both HIPAA and PCI-DSS address a subset of the controls found in general security frameworks. Organisations subject to HIPAA or PCI-DSS that also hold ISO 27001 certification or follow the NIST Cybersecurity Framework will find significant overlap, but neither regime can be satisfied by pointing to an ISO 27001 certificate alone. Each has specific requirements that a general ISMS may not address in sufficient detail.

For HIPAA, the most direct mapping is to the NIST SP 800-66 publication (Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide), which maps HIPAA specifications to NIST SP 800-53 controls. Organisations already implementing 800-53 at a moderate baseline will satisfy most HIPAA technical requirements, but the administrative requirements (notably the specific risk analysis, assigned responsibility, and contingency planning standards) require discrete documentation that goes beyond what a general controls catalogue provides. The CIS Controls also publish a HIPAA mapping, with Implementation Group 1 covering most required specifications.

For PCI-DSS, the PCI SSC publishes an information supplement mapping PCI-DSS requirements to ISO/IEC 27001:2013 controls. The mapping is useful for organisations that want a single integrated compliance programme, but PCI-DSS is more prescriptive in specific areas (particularly Requirement 11 on penetration testing frequency and methodology, Requirement 3 on prohibited data storage, and Requirement 4 on cipher suite requirements) than ISO 27001 demands. An organisation with a certified ISMS still needs PCI-DSS-specific procedures for those areas. For auditors, understanding these gaps is the practical value of framework mapping: it identifies where ISO 27001 certification provides evidence and where PCI-DSS-specific evidence must be collected separately.