ISO 27400 Lead Manager cheat sheet

IoT system is defined in ISO/IEC 27400 as a system of interacting physical and digital components that provides services involving sensing, actuation, and communication; security scope covers the whole system, not just devices.

Core security properties for IoT: confidentiality, integrity, availability, authenticity, accountability, and privacy; ISO/IEC 27400 treats privacy protection and resilience as first-class objectives alongside the classic CIA triad.

IoT risk differs from IT risk because of physical consequences of compromise: an exploited actuator can cause injury, environmental damage, or safety incidents, so impact assessment must include safety and physical harm.

Trust boundaries in IoT typically sit between device and gateway, gateway and cloud, and cloud and operator; each boundary crossing requires authentication and authorization decisions.

Constraint-driven design: many IoT devices have limited processing, memory, energy, and physical accessibility, so controls must be selected with feasibility and lifetime (often 10-20 years) in mind.

Lifecycle view: concept, development, production, deployment/operation, maintenance, and decommissioning; security requirements apply at every phase, including secure disposal of keys and data.

Common IoT threat categories include device tampering, physical theft, unauthorized configuration change, firmware substitution, credential theft, and denial of service through resource exhaustion.

Privacy principle: data minimization and purpose limitation apply because IoT sensors can continuously collect personal data; linkability of sensor data can re-identify individuals even when identifiers are removed.

Security is not solely a device property: it depends on the ecosystem including network, cloud services, mobile apps, supply chain, and users, so a single weak component can undermine the whole system.

ISO/IEC 27400 is structured around security controls grouped by area, covering device, communication, and system-level concerns; controls are guidance to be selected and tailored, not a certification checklist.

Risk assessment process: identify assets (devices, data, services, people), identify threats and vulnerabilities, estimate likelihood and impact, then determine risk treatment (mitigate, transfer, avoid, accept).

Control selection is risk-based: a control is applied when it addresses an identified risk and is feasible given device constraints; residual risk must be documented and accepted by an accountable owner.

Representative device controls: secure boot, hardware root of trust, signed firmware updates, disabling unused interfaces and services, and protection of cryptographic keys in tamper-resistant storage.

Representative communication controls: mutual authentication, encrypted channels, integrity protection, and network segmentation so that compromised devices cannot reach unrelated systems.

Representative system and management controls: identity and access management, logging and monitoring, patch management, secure configuration baselines, and supply-chain assurance for components.

Principle of least privilege and least functionality: each device, service, and user receives only the access and capability needed for its role, reducing attack surface.

Residual risk and defense in depth: layered controls (physical, network, host, application, data) are expected because no single control is sufficient for long-lived IoT deployments.

Planning starts with context: define the business purpose, the system boundary, stakeholders, applicable legal and regulatory obligations, and the risk appetite of the organization.

Produce a security policy and supporting standards that reference ISO/IEC 27400 control areas; the policy states objectives, while standards specify mandatory technical baselines.

Define a roles and responsibilities matrix (RACI) covering asset owners, security operations, engineering, suppliers, and executive risk owners; accountability must be named, not implied.

Establish an asset inventory and classification scheme before control selection; you cannot protect or monitor what has not been catalogued, including firmware versions and network addresses.

Build a risk register with threat scenarios, existing controls, likelihood, impact, treatment plan, owner, and target date; review it at defined intervals and on significant change.

Plan for the full lifecycle at design time: procurement requirements, secure development, factory provisioning, field deployment, maintenance windows, and end-of-support/decommissioning.

Set measurable objectives and metrics (patch latency, percentage of devices with current firmware, number of unmanaged devices) so that the program can be monitored and improved.

Define supplier and third-party requirements in contracts: security requirements, vulnerability disclosure expectations, update support duration, and incident notification timelines.

Provisioning: unique per-device credentials and keys generated in a trusted environment; never ship shared or default credentials, and rotate keys on compromise or at defined intervals.

Secure boot and firmware integrity: verify signatures at boot and before update, use staged rollout with rollback capability, and keep an auditable record of firmware versions per device.

Network implementation: segment IoT traffic, restrict inbound and outbound flows with allowlists, and place gateways in controlled zones so device compromise cannot pivot laterally.

Access management: strong authentication for administrative interfaces, role-based authorization, and removal of vendor maintenance accounts after commissioning.

Logging and monitoring: centralize device and gateway logs, define detection use cases for anomalous behavior (unexpected outbound traffic, repeated authentication failures), and set alert thresholds.

Vulnerability and patch operations: maintain a component inventory (SBOM), subscribe to advisories, triage by exploitability and exposure, and track patch deployment against defined service-level targets.

Physical and environmental controls: tamper detection, locked enclosures, and controlled physical access, because many IoT devices are reachable by untrusted people.

Incident response for IoT must include containment actions specific to devices (network isolation, remote disable, credential revocation) and coordination with safety and operations teams.

Monitoring covers technical telemetry (logs, alerts, health metrics), compliance indicators (control coverage), and risk indicators (open vulnerabilities, overdue patches, unmanaged assets).

Define review cadence: operational monitoring continuously, management review at planned intervals, and a full risk reassessment on significant change such as new firmware architecture or new supplier.

Internal audit and control testing verify that controls operate as intended; findings are tracked to closure with owners and dates, not just reported.

Metrics should be trended over time; a single snapshot is insufficient to show improvement, and thresholds should trigger corrective action rather than passive reporting.

Incident and near-miss review: root-cause analysis produces corrective actions and, where relevant, updates to risk assessment, controls, and design standards.

Change management ensures that firmware updates, configuration changes, and new integrations are assessed for security impact before deployment and recorded after.

Continual improvement follows a Plan-Do-Check-Act cycle: measure performance, identify gaps against objectives, implement corrective actions, and verify effectiveness in the next cycle.

End-of-life and decommissioning review: confirm data and key destruction, removal from monitoring and inventory, and migration of dependent services so that unsupported devices do not persist unmanaged.