eAIS common mistakes
eAIS · Understand the traps and how to avoid them.
Treating the security governance question as a general IT-management question: answering with the 'best practice' control (e.g., 'implement MFA everywhere') when the scenario asks who is accountable for accepting a residual risk, or what the information security management system requires before a new eHealth service goes live.
Governance scenarios read like technical scenarios, so candidates jump to the control they would deploy rather than to the role, artefact, or decision process being tested. The stem often contains a tempting technical detail that is not the question.
What to do instead
Before answering, identify the subject of the sentence: is it a person/role (accountable owner, data protection officer, clinical safety officer), a document (risk register, policy, statement of applicability), or a process (risk acceptance, management review, change approval)? Map it to the governance layer first, then choose the option that matches that layer. Practise writing one-line 'who decides / what artefact records it' summaries for each scenario.
Confusing the roles of risk owner, risk assessor, and control owner, and selecting an option in which the security team 'accepts' a clinical risk or the IT department owns a risk that sits with a clinical service.
In IT security exams the security function is often the implied decision-maker; in eHealth risk management, risk acceptance must sit with the accountable business or clinical owner who has authority over the asset and the impact.
What to do instead
Learn the rule: the risk owner is whoever is accountable for the asset and its impact, and only they can accept residual risk; the security team assesses, advises, and monitors. When an option gives acceptance authority to a team without budget or clinical accountability, eliminate it.
Applying a single legal regime to every privacy scenario, for example answering a cross-border telehealth or research-data question purely with GDPR lawful-basis reasoning when the scenario involves a different jurisdiction, a sector-specific health-records law, or a patient-rights provision that overrides the general basis.
Candidates memorise one framework (usually GDPR) and pattern-match keywords like 'consent' or 'personal data' to it, ignoring cues in the stem such as the country, the type of controller, or the presence of a national health-records statute.
What to do instead
Read the stem for jurisdiction and sector markers first and write them down. Then ask which obligation is actually being tested: lawful basis, data-subject access, retention, breach notification deadline, or cross-border transfer. Learn the distinctions between consent, vital-interest, public-health, and research bases, and how special-category health data tightens each of them.
Treating 'consent' as the default lawful basis for processing health data, and missing that in many eHealth contexts another basis (provision of care, public health, legal obligation) applies, or that consent must be specific, informed, granular, and withdrawable to be valid.
Consent is the most familiar concept, so it becomes the reflexive answer; candidates also conflate clinical consent to treatment with consent as a data-protection lawful basis.
What to do instead
Drill the difference between consent to treatment and consent to processing, and between the available lawful bases. For each scenario, test whether consent is genuinely required or merely one option, and whether the described consent meets the validity conditions (freely given, specific, informed, unambiguous, withdrawable).
Choosing the strongest authentication factor in isolation (e.g., 'add biometrics') instead of the control that fits the access-control model and the clinical workflow, or misreading role-based versus attribute-based access decisions in a break-glass scenario.
Candidates equate 'more security' with 'more factors' and ignore that the question is about authorisation design, least privilege, or emergency access, where the correct answer is often a scoped role, a time-limited elevation, or an audit trail rather than a new authenticator.
What to do instead
Separate the three questions: who are you (authentication), what may you do (authorisation), and how is it recorded (accountability). For break-glass scenarios, look for the option that grants time-bound emergency access with retrospective review, not one that permanently widens the role. Eliminate options that violate least privilege or clinical availability.
Answering network-security scenarios with a perimeter-only control (firewall rule, VLAN segmentation) when the scenario describes lateral movement, medical-device flat networks, or insider threat, and missing that the expected answer is segmentation of clinical/device networks plus monitoring and least-privilege egress.
Traditional network questions reward 'block at the firewall', so candidates stop there; eHealth scenarios often hinge on the fact that legacy medical devices cannot be patched or authenticated, making segmentation and compensating monitoring the only viable answer.
What to do instead
For each network scenario, ask what the asset can and cannot do (can it run an agent? support 802.1X? be patched?). Where it cannot, prefer compensating controls: dedicated device VLANs, restricted inbound/outbound flows, jump hosts, and traffic monitoring. Reject answers that assume controls the device cannot support.
Confusing secure software development practice with secure deployment: selecting 'penetration test before go-live' as the answer to a question about integrating security into the development lifecycle, or missing supply-chain and dependency risks in third-party clinical applications.
Pen testing is the most visible activity, so it absorbs every 'application security' question; candidates under-weight threat modelling, secure coding, dependency and vendor-component management, and configuration hardening.
What to do instead
Build a lifecycle map (requirements and threat modelling, secure coding, dependency and SBOM management, testing, hardened configuration, patch management, decommissioning) and match each scenario to the stage it describes. When a question mentions a third-party module or clinical app, check for supply-chain and update-path answers before choosing a test.
Treating encryption as a complete answer, or mixing up the purpose of hashing, encryption, digital signatures, and key management, for example proposing 'encrypt the audit log' when the requirement is tamper-evidence, or ignoring key custody and rotation in a health-information-exchange scenario.
Encryption is the best-known cryptographic control, so it is chosen whenever data protection is mentioned, even when the actual requirement is integrity, non-repudiation, or authenticated exchange between organisations.
What to do instead
For each scenario, name the security property required: confidentiality, integrity, authenticity, or non-repudiation. Then match the primitive (encryption, hash/MAC, signature, certificate) and add the key-lifecycle answer (generation, custody, rotation, revocation) whenever keys cross organisational boundaries such as an HIE.
Answering incident-response scenarios by jumping to containment or by focusing on technical eradication, while ignoring the notification and evidence obligations: who must be told, within what timeframe, what is logged, and how evidence is preserved for regulators and patients.
Candidates default to the technical playbook they know and forget that eHealth incidents carry regulatory reporting duties and clinical-continuity duties that shape the correct first action.
What to do instead
For every incident scenario, run a fixed checklist: detect and confirm, preserve evidence, contain, assess clinical impact, notify per legal and contractual deadlines, eradicate, recover, review. Choose the option that satisfies the obligation the stem emphasises, and reject answers that destroy evidence or delay mandatory notification.
Confusing backup with disaster recovery and business continuity: answering 'take regular backups' to a question about recovery-time objectives, failover of clinical systems, or restoring a validated, tested service, and missing that untested backups are not a recovery capability.
Backup is the most familiar continuity control, so it absorbs questions about RTO/RPO, downtime procedures, and restoration testing. Candidates also overlook that clinical continuity requires paper or alternate workflows, not just data restoration.
What to do instead
Learn the hierarchy: backup protects data, disaster recovery restores systems to a defined RTO/RPO, business continuity keeps clinical services running during the outage. For each scenario, identify whether the question is about data, system, or service, and prefer answers that include tested restoration and documented downtime procedures.
Dismissing emerging-technology questions with a generic 'do a risk assessment' or 'train staff', instead of naming the specific control for the technology (e.g., model and data governance for clinical AI, device hardening and network placement for IoT, verification and phishing-resistant authentication for remote care) or the specific awareness intervention the scenario needs.
These questions feel open-ended, so candidates retreat to generic governance language; they also under-estimate how much of the answer is technology-specific (data provenance, bias monitoring, human oversight, device lifecycle) or behaviour-specific (targeted, role-based awareness rather than annual slides).
What to do instead
Prepare a short technology-control card for each emerging area: AI (data provenance, validation, human oversight, drift and bias monitoring), connected devices (inventory, hardening, segmentation, patching limits), remote care (identity proofing, phishing-resistant authentication, endpoint posture). For awareness questions, choose role-specific, measured interventions over blanket annual training.