ISO 27400 Foundation common mistakes
ISO 27400 Foundation · Understand the traps and how to avoid them.
Treating ISO 27400 as a device-hardening checklist and answering questions by naming specific technologies (TLS, secure boot, patching) when the question asks which principle or concept the scenario illustrates.
Candidates arrive from engineering backgrounds where 'security' means controls, so they pattern-match to the most technical-sounding option instead of identifying the underlying concept being tested.
What to do instead
Before choosing, restate the stem in one sentence: is it asking about a concept (e.g. the nature of an IoT system, trust, lifecycle) or a control? If conceptual, eliminate options that are pure product or protocol names and select the option describing the principle.
Describing IoT security as simply 'applying existing IT security to devices' and missing the distinctive characteristics of IoT systems (physical coupling to the real world, long service life, constrained devices, scale, heterogeneity, unattended operation).
The IT mental model dominates prior experience, and these distinctive traits are exactly what the foundational domain tests; candidates underestimate how often the 'just like IT' option is the distractor.
What to do instead
Memorise a short list of IoT-specific characteristics and, for each, one security or privacy consequence. When an answer option ignores physical-world impact, longevity, or constrained resources, treat it as suspect.
Conflating security and privacy, answering a privacy question with a security control (encryption, access control) or vice versa, instead of addressing the privacy harm described.
The two are taught together and overlap in practice, so candidates treat them as synonyms and pick any protective-sounding measure.
What to do instead
Use a decision rule: security questions concern unauthorised access, integrity, availability and misuse of the system; privacy questions concern personal data, observability of persons, consent, purpose limitation and linkability. Ask 'whose interest is harmed, and how?' before selecting.
Ignoring the risk-source dimension of a scenario and jumping straight to a control, so the answer names a mitigation when the question asks what the source of risk is (or vice versa).
Stems often describe a situation rather than labelling it, and candidates read 'what should be done' into questions that actually ask 'what is the underlying risk'.
What to do instead
Underline the interrogative in the stem. If it asks for the source, cause or nature of the risk, choose the option describing the actor, condition or weakness; only choose a control when the stem asks for a response or measure.
Attributing IoT risk only to malicious attackers, overlooking non-malicious sources such as misconfiguration, unintended data collection, function creep, device repurposing, or physical environment and wear.
Threat-centric study habits make 'attacker' options feel correct, and the everyday operational sources of harm are less memorable.
What to do instead
Build a risk-source taxonomy with at least three branches: adversarial (attackers, insiders), non-adversarial (misconfiguration, error, obsolescence, environment) and data-related (over-collection, secondary use, re-identification). Practise classifying scenarios into these branches.
Choosing 'encrypt everything' or a single silver-bullet control as the answer to any control question, rather than selecting the control matched to the lifecycle stage and the specific harm.
Encryption is the most familiar control and appears plausible in most stems, so it survives elimination even when it does not address the described problem.
What to do instead
For each scenario, identify the lifecycle stage (concept, design, development, deployment, operation, maintenance, decommissioning) and the asset at risk. Reject controls that do not act on that asset at that stage, even if they are generally good practice.
Treating privacy as satisfied by anonymisation alone, missing that IoT data is often pseudonymous and re-identifiable through correlation of sensor streams, location traces and metadata.
Candidates equate 'no names stored' with 'not personal data' and underestimate linkability, which is a recurring theme in IoT privacy reasoning.
What to do instead
When a stem involves sensor, location or behavioural data, assume linkability until shown otherwise. Prefer options that address purpose limitation, data minimisation, aggregation or retention limits over options that merely remove direct identifiers.
Answering questions about roles and responsibilities by assigning everything to the device manufacturer, or everything to the user, without distinguishing the different parties across the IoT system.
Real-world debates about device makers dominate the narrative, so candidates default to manufacturer-centric answers even when the stem concerns an operator, service provider or user.
What to do instead
Map the scenario to explicit roles (device provider, service provider, network operator, deployer/user) and ask which party has the ability and information to act. Choose the option consistent with that allocation rather than a blanket assignment.
Misreading normative wording: treating 'should' as mandatory or 'shall' as advisory, and failing to notice 'except', 'not', or 'least' in the stem, leading to selection of the opposite of the required answer.
Speed-reading under time pressure, plus unfamiliarity with the convention that standards use 'shall' for requirements and 'should' for recommendations.
What to do instead
Slow down on modal verbs and negatives; mark them as you read. Before committing, re-read the stem with the chosen option substituted in to confirm the sentence answers exactly what was asked.
Answering from personal product experience rather than from the conceptual framing the exam expects, choosing the option that matches a familiar vendor implementation over the option describing the general principle.
Practitioners with hands-on IoT experience trust their intuition, and vendor-specific answers are written to look authoritative and concrete.
What to do instead
Prefer the option that generalises across devices and contexts. If an option names a specific product, protocol version or vendor, treat it as a distractor unless the stem itself supplies that specificity.