ISO 27400 Lead Manager common mistakes
ISO 27400 Lead Manager · Understand the traps and how to avoid them.
Treating ISO/IEC 27400 as a certifiable management-system standard and answering that an organisation can be 'certified to 27400' or audited against it as a normative requirements document.
Candidates transfer habits from ISO/IEC 27001, which is a requirements standard with certification. ISO/IEC 27400 is guidance - it presents controls and risk-treatment guidance for IoT, not auditable 'shall' requirements, so the mental model is wrong from the first question.
What to do instead
Memorise the document type before studying content: 27400 is guidance/controls advice, not a management system specification. When a stem asks what an organisation can claim, distinguish 'implements guidance from 27400' from 'certified'. Pair it mentally with 27001 (the certifiable ISMS) and 27002 (the control guidance it parallels).
Applying generic IT security controls to IoT devices unchanged, e.g. recommending host-based antivirus and full-disk encryption as the primary answer for constrained sensors.
Most candidates come from enterprise IT and default to familiar controls. IoT constraints - limited CPU, memory, power, no user interface, long physical lifetime - make many IT controls infeasible or ineffective.
What to do instead
For every control you propose, run a feasibility check against device class: constrained vs. gateway vs. rich device. Shift controls to the network/gateway layer when the endpoint cannot host them (e.g. network segmentation and monitoring instead of endpoint agents). State the constraint explicitly in your justification.
Confusing the device lifecycle phases and placing controls in the wrong phase - for example recommending secure boot key injection at decommissioning, or vulnerability disclosure only at manufacturing.
Candidates learn controls as a flat list rather than mapping each to conception, design, production, deployment, operation, maintenance, and disposal. Exam stems often describe a phase and ask which control applies.
What to do instead
Build a lifecycle matrix: rows = phases, columns = control families (identity, update, crypto, logging, disposal). Place each control deliberately (e.g. unique per-device credentials at production, secure wipe and credential revocation at disposal). Practise identifying the phase from the stem's cues before choosing a control.
Choosing 'encrypt all IoT traffic end-to-end with mutual TLS on every device' as the default answer without weighing device capability, key management burden, and gateway-terminated alternatives.
Encryption is the intuitive 'secure' answer, and candidates fear picking an option that looks weaker. But constrained devices often cannot sustain per-device TLS with rotation, and the exam rewards fit-for-purpose risk-based choices.
What to do instead
Justify cryptographic choices with three tests: does the device support it, who manages and rotates keys, and what does it protect against. Accept gateway-terminated TLS with a secured backhaul as a legitimate answer where endpoint crypto is impractical, and say why in your reasoning.
Treating IoT risk assessment as a one-off pre-deployment activity and answering that residual risk is 'closed' after go-live.
Project-style thinking - assess, deploy, done - carried over from waterfall IT projects. IoT devices stay in service for a decade or more, with changing threats, firmware, and environments.
What to do instead
Frame IoT risk as continuous: re-assess on firmware changes, new threat intelligence, incident findings, and end-of-support milestones. When a question mentions long field life or a vendor ending support, expect the answer to involve re-assessment and a documented risk decision, not silence.
Ignoring the operational-technology and physical context - answering as if IoT devices sit in a data centre, and missing physical tampering, side-channel, or environmental risks.
Candidates default to IT threat models (malware, phishing, network intrusion) and overlook that IoT devices are often physically accessible in the field, in untrusted locations, or in safety-relevant processes.
What to do instead
For each scenario ask: who can physically reach the device, what happens if it is stolen or tampered with, and does it affect safety or physical processes. Include physical and supply-chain threats in your risk lists, and prefer controls like tamper detection, secure enclaves, and attestation where physical access is plausible.
Recommending a full security programme rollout in one phase - all controls, all device types, immediately - instead of a risk-prioritised, phased plan with owners and milestones.
Candidates equate thoroughness with completeness and fear that a phased answer looks like it omits controls. Exam scenarios reward realistic sequencing tied to risk and capability.
What to do instead
Structure programme answers as: scope and inventory, risk assessment, prioritised control roadmap (quick wins first, e.g. asset inventory, default-credential elimination, segmentation), owners, budget, and review gates. Explicitly justify why lower-risk items are deferred.
Treating firmware update as a purely technical patch process, omitting signed updates, rollback capability, staged rollout, and an end-of-support/obsolescence policy.
Update questions look like IT patch-management questions, so candidates answer 'patch promptly' and stop. IoT update failure modes - bricked devices, unsigned images, unsupported devices in the field - are the real exam targets.
What to do instead
Answer update questions with the full chain: signed and verified images, secure delivery channel, rollback/recovery, staged deployment with monitoring, and a documented end-of-support date with a migration or compensating-control plan for devices that can no longer be updated.
Designing monitoring that only collects logs centrally, without defining what is normal for IoT behaviour, alert thresholds, or who acts on alerts.
Candidates confuse 'logging enabled' with 'monitoring', a common IT habit. IoT monitoring depends on behavioural baselines (traffic patterns, command frequency, outbound destinations) that differ from user-centric IT monitoring.
What to do instead
For monitoring questions, specify: data sources (device, gateway, network flow), the baseline being compared against, alert thresholds, escalation owner, and the review cadence feeding continual improvement. Mention anomaly detection on outbound traffic and unexpected configuration changes as IoT-specific signals.
Answering supply-chain and third-party questions by focusing only on contractual clauses, without addressing device provenance, component integrity, vendor security capability, and ongoing vendor vulnerability disclosure.
Candidates treat procurement as a legal exercise and forget that IoT assurance depends on the manufacturer's development and update practices, which the buyer must assess before purchase and monitor afterwards.
What to do instead
Cover the full chain: pre-procurement security requirements, evidence of secure development and vulnerability handling, bill-of-materials/component transparency, acceptance testing, and contractual rights to updates and disclosure timelines. Pair each clause with the technical verification you would perform.