Planning an IoT Security Program Based on ISO/IEC 27400
The exam tests whether you can design a program - scope, governance, sequencing, funding and measures - rather than recite a control list.
Planning sequence
- Define context and scope: which devices, sites, services and data, and which business and safety outcomes matter.
- Build an inventory and classify by criticality, data sensitivity and safety impact; devices you cannot see cannot be governed.
- Set governance: accountable owner, roles across IT, OT or engineering, product, legal and privacy; policy aligned to the ISMS; risk appetite and who may accept risk.
- Assess gaps against ISO/IEC 27400 principles and controls, covering suppliers and legacy fleets.
- Produce a risk-based roadmap: safety-critical and internet-exposed systems first, quick wins such as removing shared default credentials, then structural work such as update capability and segmentation.
- Embed requirements in procurement and contracts: identity, update support, logging, vulnerability disclosure and end-of-support terms.
- Resource competence, incident response, metrics and review points.
Worked example
A manufacturer plans security for connected production equipment. Reasoning: scope covers plant devices plus the vendor cloud service; classification puts a safety interlock system first; the gap assessment finds no asset register and shared passwords. The roadmap therefore starts with discovery and credential rotation, then contractual update clauses, then segmentation in the next budget cycle. Each step carries an owner and a metric so management can see progress.
Traps that cost marks
Buying products before scope and risk; copying the IT policy verbatim onto constrained operational devices; no named owner; ignoring legacy equipment that cannot be replaced; a plan with no measurable milestones or funding line.