eAIS cheat sheet
eAIS · Keep the key ideas within reach.
Security Governance, Risk Management, and Compliance in eHealth
Governance triad: leadership accountability (board/CIO/CISO), documented policy hierarchy (policy → standard → procedure → guideline), and assurance (audit, metrics, third-party attestation).
Risk = likelihood × impact. Qualitative scales (e.g., 1–5) must be defined in a risk register with explicit acceptance thresholds and named risk owners.
Risk treatment options: mitigate, transfer (cyber insurance, contractual indemnity), avoid, accept. Residual risk must be formally signed off by an accountable executive.
Common assurance frameworks: ISO/IEC 27001 (ISMS requirements), ISO 27799 (health informatics security), NIST CSF (Identify-Protect-Detect-Respond-Recover), HITRUST CSF, SOC 2 Type II.
Regulatory overlap in eHealth: GDPR (EU), HIPAA Security and Privacy Rules (US), national eHealth/patient-record acts, medical-device regulation (EU MDR, US FDA premarket cybersecurity).
Segregation of duties: no single role should both approve and execute a change, or both administer access and audit it. Compensating controls apply where separation is impossible.
Key governance metrics: % critical assets with owners, % risks with treatment plans past due, audit findings closed within SLA, policy exception count and age.
Third-party risk: tier vendors by data sensitivity and system criticality; require security clauses, right-to-audit, breach notification timelines, and annual reassessment.
Compliance evidence must be retained per record-retention rules; evidence should be reproducible (configuration exports, logs, signed attestations), not narrative claims.
Health Information Privacy and Data Protection Law
GDPR lawful bases (Art. 6): consent, contract, legal obligation, vital interests, public task, legitimate interests. Health data is special category (Art. 9) and needs an additional Art. 9 condition.
HIPAA identifiers: 18 categories under the Safe Harbor de-identification method; the alternative Expert Determination method requires a qualified statistician's documented method.
Data subject rights (GDPR): access, rectification, erasure, restriction, portability, objection; response generally within one month, extendable by two further months for complex requests.
Breach notification clocks: GDPR - 72 hours to the supervisory authority after awareness, without undue delay to data subjects if high risk. HIPAA - 60 days from discovery for covered entities.
Minimum necessary principle (HIPAA) and data minimization (GDPR Art. 5) both limit collection, use, and disclosure to what the purpose requires.
Privacy by design and by default: data protection impact assessment (DPIA) is required for high-risk processing such as large-scale health data or systematic monitoring.
Roles: controller determines purpose and means; processor acts on documented instructions. A processor that exceeds instructions becomes a controller for that processing.
Cross-border transfers need a valid mechanism: adequacy decision, standard contractual clauses, binding corporate rules, or derogation. Schrems II requires transfer impact assessment.
Patient consent in eHealth must be specific, informed, granular, and revocable; consent records must capture version, timestamp, scope, and withdrawal.
Access Control, Identity Management, and Authentication
Access control models: DAC (owner discretion), MAC (labels/clearance), RBAC (role → permission), ABAC (attributes: user, resource, environment, purpose). Healthcare often uses ABAC or RBAC with break-glass.
Authentication factors: something you know, have, are. MFA requires factors from at least two different categories; two passwords are not MFA.
NIST SP 800-63B: memorized secrets should be at least 8 characters, checked against breached-password lists, and not forced into periodic rotation absent compromise evidence.
FIDO2/WebAuthn and passkeys are phishing-resistant authenticators; SMS OTP is vulnerable to SIM swap and interception.
Identity lifecycle: joiner-mover-leaver. Access must be provisioned on approved request, re-evaluated on role change, and revoked promptly on termination.
Least privilege and need-to-know: clinical staff access only the records required for the current care episode; access is logged and auditable.
Break-glass (emergency access) must be time-limited, reason-coded, alerted in real time, and reviewed retrospectively.
Privileged access management: separate admin accounts, just-in-time elevation, session recording, vaulted credentials, no shared generic accounts.
Periodic access recertification: managers attest to entitlements at defined intervals; orphaned and dormant accounts are disabled per policy.
Network Security and Infrastructure Protection
Segmentation: separate clinical device VLANs, medical IoT, guest, and corporate networks; enforce inter-zone traffic via firewalls with default-deny rules.
Zero trust principles: verify explicitly, least-privilege access, assume breach. Identity and device posture drive access, not network location alone.
TLS 1.2 minimum, TLS 1.3 preferred; disable SSLv3, TLS 1.0/1.1. Use strong cipher suites and HSTS for web-facing services.
VPN and remote access: strong authentication (MFA), split vs full tunnel decision, and endpoint posture checks before granting access.
Wireless: WPA2-Enterprise or WPA3 with 802.1X; separate SSIDs for clinical devices, staff, and guests.
DNS and email defenses: SPF, DKIM, DMARC for domain protection; DNS filtering to block known malicious infrastructure.
IDS/IPS placement: network sensors at perimeter and key internal chokepoints; alert tuning to reduce false positives in clinical environments.
Infrastructure hardening: disable unused services/ports, change default credentials, patch firmware on medical devices per vendor-coordinated schedule.
Network documentation and inventory: asset register with owner, location, firmware version, and network zone is prerequisite for effective segmentation.
Endpoint, Application, and Software Security
EDR capabilities: behavioral detection, process lineage, isolation, rollback, and threat hunting. Signature-only AV is insufficient against fileless and ransomware attacks.
Patch management SLA tiers: critical vulnerabilities typically remediated within days (e.g., 14 days), high within 30, medium within 90 - defined per organizational policy.
Secure SDLC: threat modeling at design, static analysis (SAST) in code, dynamic analysis (DAST) in test, dependency scanning (SCA) for third-party libraries.
OWASP Top 10 categories include broken access control, injection, cryptographic failures, insecure design, security misconfiguration, and vulnerable components.
Input validation and output encoding prevent injection; parameterized queries are the primary defense against SQL injection.
Medical device software: FDA premarket cybersecurity requires SBOM, vulnerability management plan, and coordinated disclosure; EU MDR requires similar evidence.
SBOM (Software Bill of Materials) formats: SPDX and CycloneDX; enables rapid identification of affected components when a CVE is published.
Application hardening: disable debug modes, enforce secure headers (CSP, X-Content-Type-Options), remove default accounts, and enforce session timeouts.
Endpoint encryption (full-disk) and application allowlisting reduce data loss from lost devices and unauthorized execution on clinical workstations.
Cryptography and Secure Health Data Exchange
Symmetric encryption (AES-256) for data at rest and bulk data in transit; asymmetric (RSA ≥ 2048-bit or ECC P-256+) for key exchange and digital signatures.
Hashing (SHA-256 or stronger) provides integrity, not confidentiality; passwords must use salted, slow hashes (bcrypt, scrypt, Argon2), never plain SHA.
Digital signatures provide authenticity, integrity, and non-repudiation; they rely on a trusted certificate chain and private-key protection.
PKI components: CA, registration authority, certificate lifecycle (issue, renew, revoke), CRL/OCSP for revocation checking.
HL7 FHIR security: OAuth 2.0 / SMART on FHIR for authorization, TLS for transport, and resource-level scopes for access control.
Key management lifecycle: generation, distribution, storage (HSM preferred), rotation, archival, destruction. Key rotation limits exposure window from compromise.
Interoperability security: HL7 v2, CDA, and FHIR exchanges must be authenticated, encrypted, and auditable; mTLS is common for system-to-system exchange.
Crypto agility: design systems to swap algorithms without re-architecture, given deprecation of legacy algorithms (SHA-1, RSA-1024, 3DES).
Data in use protection: confidential computing and enclaves protect health data during processing; tokenization reduces exposure of identifiers.
Security Operations, Monitoring, and Incident Response
SIEM function: log aggregation, correlation, alerting, and retention. Critical log sources include identity providers, EDR, firewalls, EHR audit logs, and cloud control planes.
Incident response phases (NIST SP 800-61): preparation; detection and analysis; containment, eradication, recovery; post-incident activity.
Severity classification drives escalation: define P1 (patient safety or active ransomware) through P4, with response-time SLAs and notification paths.
Healthcare-specific incident triggers: EHR downtime, medical device compromise, unauthorized PHI access, ransomware with encryption, and third-party breach.
Forensics: preserve volatile data first (memory, network connections), maintain chain of custody, and use write-blockers for disk imaging.
Detection coverage: map telemetry to MITRE ATT&CK techniques to identify blind spots; healthcare attacks frequently use phishing, RDP exposure, and valid-account abuse.
Threat intelligence and IOC feeds improve detection but must be tuned to avoid alert fatigue in 24/7 clinical operations.
Post-incident review: root cause analysis, corrective actions with owners and due dates, and lessons-learned updates to playbooks.
Regulatory reporting must be coordinated with legal/privacy; the technical response and the notification obligation run in parallel, not sequentially.
Business Continuity, Disaster Recovery, and Backup
RTO = maximum acceptable downtime; RPO = maximum acceptable data loss (measured in time). Both are set by business impact analysis, not by IT preference.
BIA output: critical clinical services ranked, dependencies mapped, and minimum service levels defined for degraded operation.
Backup 3-2-1 rule: at least 3 copies, on 2 different media, with 1 offsite or offline/immutable.
Ransomware resilience requires immutable or air-gapped backups and tested restore procedures; backups reachable from the domain are at risk.
EHR downtime procedures: paper forms, read-only backup access, and defined re-synchronization steps when systems return.
DR testing types: tabletop, simulation, partial failover, full failover. Untested plans are assumptions, not controls.
Recovery tiers: hot site (near-zero RTO), warm site (hours to days), cold site (days to weeks). Selection depends on BIA criticality.
Backup verification: restore tests at defined intervals, integrity checks, and documented evidence of successful recovery.
Crisis communications: pre-defined contact trees, patient-safety escalation, and public/regulator communication templates.
Emerging Technology and Security Awareness in Healthcare
AI/ML in healthcare: risks include model poisoning, data leakage in training, bias, and lack of explainability. Governance requires model inventory, validation, and monitoring.
LLM usage policy: prohibit entering PHI into unapproved public generative-AI tools; approved tools must have contractual data protections.
IoT and medical device security: inventory, network isolation, default-credential removal, firmware patching, and vendor security requirements in procurement.
Cloud shared responsibility: provider secures infrastructure; customer secures identity, configuration, data classification, and access. Misconfiguration is a leading breach cause.
Telehealth security: end-to-end encryption, authenticated sessions, secure recording storage, and consent capture for remote consultations.
Security awareness effectiveness: measure via phishing simulation click rates, report rates, and time-to-report - not completion percentages alone.
Social engineering in healthcare exploits urgency and authority (e.g., fake clinician requests for records); verification procedures must be defined and rehearsed.
Supply chain and third-party risk: require SBOM, vulnerability disclosure, and security attestations for connected medical devices and SaaS.
Emerging regulation: AI Act (EU) risk classification, medical device software guidance, and national cybersecurity directives for critical health infrastructure.