# IoT Security and Privacy Profile (ISO/IEC 27400 and 27402): [Organization name]

> Profile for organizations that design, buy, deploy or operate Internet
> of Things (IoT) systems: connected devices, gateways, IoT platforms and
> the applications that use their data. It records how the guidance in
> ISO/IEC 27400:2022 (IoT security and privacy guidelines) and the device
> baseline in ISO/IEC 27402:2023 are applied inside an ISMS that meets
> ISO/IEC 27001:2022 + Amd 1:2024, through risk treatment (6.1.3), the
> Statement of Applicability and procurement requirements. The EU Cyber
> Resilience Act is used as an example regulation. Replace every
> `[bracketed]` value and every row marked *Example*. This is a
> documentation format, not legal advice.

<!--
Guidance: How to use this template
- Use it when connected devices are inside the ISMS scope: industrial
  sensors, building systems, cameras, badge readers, kiosks, wearables,
  vehicles and trackers, smart meters, or devices you build and sell.
- Decide your role first (section 1): device user and operator,
  integrator, or manufacturer. The same device needs different controls
  depending on role, and regulation such as the EU Cyber Resilience Act
  places most product duties on manufacturers.
- Then fill the IoT system inventory (section 3) and the device baseline
  (section 5). The baseline becomes a procurement checklist for buyers
  and a design checklist for manufacturers.
- The main pitfall is buying devices first and asking about security
  later: default passwords, no update path and a short support period
  cannot be fixed after purchase. Put the baseline in the tender.
- Neither ISO/IEC 27400 nor ISO/IEC 27402 is certifiable as a
  management system. Certification is to ISO/IEC 27001.
- Related templates: `compliance/statement-of-applicability`,
  `compliance/risk-methodology`, `compliance/asset-inventory`,
  `isms/network-security-standard`, `isms/secure-configuration-baseline`,
  `isms/energy-27019-controls`, `isms/health-27799-controls`,
  `security/cra-vulnerability-handling`, `security/sbom-vex-policy`,
  `security/threat-model`, `compliance/privacy-by-design-review`.
-->

## Document control

<!-- Guidance: Owned by the person accountable for connected devices. For an operator this is often the IT or OT security lead; for a manufacturer, the product security lead. Procurement and privacy must review. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-111 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@iot-security-lead] |
| Approvers/reviewers | [@ciso], [@data-protection-officer], [@head-of-procurement], [@product-owner] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27400:2022; ISO/IEC 27402:2023; ISO/IEC 27001:2022 + Amd 1:2024 |
| Next scheduled review | YYYY-MM-DD |
| Our role | [Operator / Integrator / Manufacturer / Several] |
| IoT systems in scope | [List, or refer to section 3] |
| Products placed on the EU market | [Yes: see section 9 / No] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| IoT security lead (author) | [@iot-security-lead] | [Prepared] | YYYY-MM-DD |
| Data protection officer | [@data-protection-officer] | [Reviewed] | YYYY-MM-DD |
| Head of procurement | [@head-of-procurement] | [Reviewed] | YYYY-MM-DD |
| CISO | [@ciso] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@iot-security-lead] | First issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose, scope and role](#1-purpose-scope-and-role)
- [2. The IoT standards at a glance](#2-the-iot-standards-at-a-glance)
- [3. IoT system inventory and architecture](#3-iot-system-inventory-and-architecture)
- [4. Risk sources and scenarios](#4-risk-sources-and-scenarios)
- [5. Device security and privacy baseline](#5-device-security-and-privacy-baseline)
- [6. Lifecycle controls](#6-lifecycle-controls)
- [7. Mapping to Annex A](#7-mapping-to-annex-a)
- [8. Implementation table](#8-implementation-table)
- [9. Regulatory example: EU Cyber Resilience Act](#9-regulatory-example-eu-cyber-resilience-act)
- [10. Size tiers](#10-size-tiers)
- [11. Records and evidence](#11-records-and-evidence)
- [12. References](#12-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose, scope and role

<!-- Guidance: Write your role per IoT system. An auditor will check that the role matches contracts and, for manufacturers, product documentation. -->

This profile explains how [Organization name] manages security and
privacy risks of IoT systems. It:

- lists the IoT systems in scope and their architecture (section 3);
- records IoT-specific risk sources and scenarios (section 4);
- sets a device baseline used for design or procurement (section 5);
- defines controls for each lifecycle stage (section 6);
- maps the profile to Annex A of ISO/IEC 27001:2022 and to the
  Statement of Applicability, DOC-ISMS-011 (section 7).

| IoT system | Our role | Reason |
|---|---|---|
| [System name] | [Operator / Integrator / Manufacturer] | [We buy and run the devices / We assemble and support a solution / We design and sell the device] |
| Plant condition monitoring *(Example)* | Operator | Sensors bought from a supplier, run by plant engineering |

## 2. The IoT standards at a glance

<!-- Guidance: Describe the standards in your own words. Keep licensed copies with the document owner. -->

| Standard | Edition | What it gives you (summarised from the public catalogue) | How this profile uses it |
|---|---|---|---|
| ISO/IEC 27400 | 2022 (published 2022-06-07) | Guidelines on risks, principles and controls for security and privacy of IoT solutions | Sections 4, 6 and 7 |
| ISO/IEC 27402 | 2023 (published 2023-11-21) | Baseline ICT requirements for IoT devices to support security and privacy controls | Section 5 |
| ISO/IEC 27403 | 2024 | Guidelines for IoT domotics (home automation) | Only if you supply home devices |
| ISO/IEC 27404 | 2025 | Cybersecurity labelling framework for consumer IoT | Only for consumer products |
| ISO/IEC 30141 | 2024 | IoT reference architecture | Vocabulary for section 3 |

Other baselines often used alongside (cite by name, check versions):
ETSI EN 303 645 (consumer IoT baseline, V3.1.3 published 2024-09 at the
time of writing), NIST IR 8259A (IoT device cybersecurity capability core
baseline, 2020), and IEC 62443-4-2 for industrial components.

## 3. IoT system inventory and architecture

<!-- Guidance: Inventory devices as assets (DOC-ISMS-012) with attributes that matter for IoT: firmware version, update method, support end date, connectivity, data collected, owner. Unknown devices on the network are a finding. -->

### 3.1 Inventory

| System | Device types | Count | Connectivity | Data collected | Update method | Support ends | Owner |
|---|---|---|---|---|---|---|---|
| Plant condition monitoring *(Example)* | Vibration and temperature sensors, 3 gateways | 1,800 sensors | Wireless to gateway, gateway to cloud platform | Machine telemetry, no personal data | Gateway pushes signed firmware | 2032 | Plant engineering |
| Building access *(Example)* | Badge readers, door controllers | 120 | Wired building network | Badge ID, time, door | Vendor tool on site | 2029 | Facilities |
| [System] | [Types] | [n] | [Connectivity] | [Data] | [Method] | [Year] | [@owner] |

### 3.2 Reference architecture

```mermaid
flowchart LR
  DEV["IoT devices: sensors, actuators"] --> GW["Gateway or edge node"]
  GW --> PLAT["IoT platform: device registry, messaging, updates"]
  PLAT --> APP["Applications and analytics"]
  APP --> USR["Users and integrations"]
  MGMT["Device management: provisioning, firmware, certificates"] --> PLAT
  MGMT --> GW
```

Each arrow is a trust boundary. Record for each one: authentication
method, encryption, allowed direction, and who can change it.

## 4. Risk sources and scenarios

<!-- Guidance: List IoT-specific risk sources and score scenarios with the scale in DOC-ISMS-010 (likelihood 1 to 5 times impact 1 to 5; Low 1-4, Medium 5-9, High 10-16, Critical 17 to 25 (in practice 20 and 25)). The sources below are this template's examples; add those relevant to you. -->

| Risk source | Typical scenario | Affected properties |
|---|---|---|
| Default or shared credentials | Attacker logs in to devices with factory passwords and builds a botnet | Integrity, availability |
| No or slow updates | Known vulnerability stays open for years on long-lived devices | Confidentiality, integrity |
| Physical exposure | Device in a public or remote place is opened and its keys extracted | Confidentiality, integrity |
| Insecure communication | Telemetry or commands sent unencrypted and altered | Integrity |
| Excessive data collection | Device collects audio, video or location beyond the stated purpose | Privacy |
| Ownership transfer | Resold or returned device still holds the previous user's data and access | Privacy, confidentiality |
| Supplier end of life | Vendor stops updates or shuts down the cloud service | Availability |
| Cloud platform compromise | Attacker uses the platform to push malicious firmware to all devices | Integrity, availability, safety |

Worked scenario *(Example)*:

| Field | Value |
|---|---|
| Risk ID | R-074 *(Example)* |
| Scenario | Building access controllers use a default administrator password; an attacker on the building network unlocks doors |
| Inherent likelihood x impact | 3 x 4 = 12, High |
| Treatment | IOT-IMP-002 (unique credentials, building network segment, vendor update) |
| Residual likelihood x impact | 1 x 4 = 4, Low |
| Acceptance | Low residual risk accepted by the risk owner, the facilities manager |

## 5. Device security and privacy baseline

<!-- Guidance: This baseline is written by the template authors as an organizational checklist that covers the themes of ISO/IEC 27402 (risk management, basic security controls, basic privacy controls). Check your licensed copy and add any requirement it states that is missing here. Use the baseline as tender requirements (operators) or design requirements (manufacturers). -->

| Baseline ID | Requirement (our wording) | Theme | Verification |
|---|---|---|---|
| IOT-BASE-001 | No universal default passwords; unique credentials per device or set at first use | Security | Inspect device, supplier statement |
| IOT-BASE-002 | Device can be uniquely identified (logical and physical identifier) | Security | Registry record |
| IOT-BASE-003 | Software and firmware can be updated securely, with integrity and authenticity checks | Security | Update test, signature check |
| IOT-BASE-004 | Supplier states the minimum support period for security updates | Security | Contract clause |
| IOT-BASE-005 | Supplier operates a vulnerability disclosure and handling process | Security | Published policy, contract clause |
| IOT-BASE-006 | Communication protected with current cryptography; no unencrypted management interfaces | Security | Traffic capture, configuration review |
| IOT-BASE-007 | Unused interfaces and services disabled by default | Security | Port scan in a lab, configuration review |
| IOT-BASE-008 | Device logs security events and can send them to a central collector | Security | Log sample |
| IOT-BASE-009 | Device resists simple physical tampering and protects stored secrets | Security | Supplier evidence, lab test for high-risk devices |
| IOT-BASE-010 | Data collected is limited to the stated purpose; purpose documented | Privacy | Data flow review, DPIA where needed |
| IOT-BASE-011 | User can delete personal data and reset the device before transfer or disposal | Privacy | Reset test |
| IOT-BASE-012 | Software bill of materials available on request | Security | SBOM received |
| IOT-BASE-013 | Device keeps safe operation when connectivity is lost | Security | Failover test |
| IOT-BASE-014 | Supplier risk assessment for the device is documented | Risk management | Supplier documentation |

Baseline exceptions go through the security exception process
(`security/security-exception-request`) with an expiry date.

## 6. Lifecycle controls

<!-- Guidance: IoT devices live long and change hands. Define what happens at each stage and who does it. The auditor will sample a decommissioned device and ask how its data and credentials were removed. -->

```mermaid
stateDiagram-v2
  [*] --> Design
  Design --> Procurement
  Procurement --> Onboarding
  Onboarding --> Operation
  Operation --> Update
  Update --> Operation
  Operation --> Transfer
  Transfer --> Onboarding
  Operation --> Decommission
  Decommission --> [*]
```

| Stage | Controls | Owner | Record |
|---|---|---|---|
| Design (manufacturers and integrators) | Threat model (`security/threat-model`), privacy by design review, baseline section 5 as design input, secure development (DOC-ISMS-065) | Product security lead | Threat model, design review |
| Procurement (operators) | Baseline in tender, supplier assessment (DOC-ISMS-067), support period and update terms in contract | Procurement | Tender scoring, contract |
| Onboarding | Register in inventory, set unique credentials, issue device certificate, place in IoT network segment | Device owner | Inventory entry, onboarding checklist |
| Operation | Monitor device health and security events, review access, check for unknown devices | Operations | Monitoring reports |
| Update | Track vendor advisories, test updates, roll out in waves, verify version | Device owner | Change records, version report |
| Transfer of ownership | Factory reset, remove from registry and platform, revoke certificates, give new owner a clean device | Device owner | Transfer record |
| Decommission | Wipe or destroy storage, revoke credentials, update inventory (DOC-ISMS-057) | IT or facilities | Disposal record |

## 7. Mapping to Annex A

<!-- Guidance: This is the template's own mapping of IoT topics to ISO/IEC 27001:2022 Annex A, not a table from ISO/IEC 27400. Use it to check SoA coverage. -->

| IoT topic | Primary Annex A controls (short labels) |
|---|---|
| Device inventory and ownership | A.5.9 inventory of information and assets |
| Supplier and support period | A.5.19, A.5.20, A.5.21, A.5.22 supplier relationships and ICT supply chain |
| Cloud IoT platforms | A.5.23 security for cloud service use |
| Privacy of device data | A.5.34 privacy and PII protection |
| Device credentials and identity | A.5.16 identity lifecycle, A.5.17 authentication information, A.8.5 secure authentication |
| Physical protection of field devices | A.7.8 equipment siting and protection, A.7.9 assets used off-premises |
| Disposal and transfer | A.7.14 secure disposal or re-use of equipment, A.8.10 information deletion |
| Secure configuration | A.8.9 configuration management |
| Vulnerabilities and updates | A.8.8 technical vulnerability management, A.8.19 software installation |
| Logging and monitoring | A.8.15 logging, A.8.16 monitoring activities |
| IoT network segment | A.8.20 network security, A.8.22 network segregation |
| Encryption of telemetry and commands | A.8.24 use of cryptography |
| Secure product development | A.8.25 secure development life cycle, A.8.26 application security requirements, A.8.27 secure architecture, A.8.28 secure coding |
| Testing devices | A.8.29 security testing in development and acceptance |

## 8. Implementation table

<!-- Guidance: One row per item, linked to a baseline ID, lifecycle stage or risk ID. Evidence must be a sampleable record. -->

| Item ID | Link | What is done | Owner | Status | Due | Evidence |
|---|---|---|---|---|---|---|
| IOT-IMP-001 *(Example)* | IOT-BASE-001 to 014 | Baseline added to every IoT tender from 2027 | Procurement | Implemented | 2027-01-31 | Tender template v2 |
| IOT-IMP-002 *(Example)* | R-074 | Unique credentials on all 120 access controllers, building network segment, vendor update applied | Facilities | Partial | 2027-04-30 | Configuration report, change record |
| IOT-IMP-003 *(Example)* | Onboarding stage | Device certificates issued by internal PKI for all gateways | IoT security lead | Implemented | 2027-03-31 | Certificate register (DOC-ISMS-070) |
| IOT-IMP-004 *(Example)* | Operation stage | Network discovery runs weekly; unknown devices raise a ticket | Network team | Planned | 2027-09-30 | Discovery reports |
| IOT-IMP-005 | [Link] | [Action] | [@owner] | [Status] | YYYY-MM-DD | [Record] |

Status summary *(Example)*: 5 rows, of which 2 implemented, 1 partial,
1 planned and 1 blank row awaiting entries.

## 9. Regulatory example: EU Cyber Resilience Act

<!-- Guidance: The CRA is an example of product cybersecurity law. Use this section if you place products with digital elements on the EU market, or buy such products. Record the applicable laws in DOC-ISMS-014. Check the official text on EUR-Lex. -->

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), sets
cybersecurity requirements for products with digital elements placed on
the EU market. Main points for IoT, in summary:

| Topic | Summary | Applies to |
|---|---|---|
| Essential requirements | Security by design and default, and vulnerability handling, set out in Annex I | Manufacturers |
| Support period | Manufacturers determine and state a support period during which vulnerabilities are handled | Manufacturers |
| Reporting | Actively exploited vulnerabilities and severe incidents reported to the designated CSIRT and ENISA, applying from 11 September 2026, including for products already on the market | Manufacturers |
| Full application | Most other obligations apply from 11 December 2027 | Manufacturers, importers, distributors |
| Buyer side | Operators can rely on CE marking and the stated support period when selecting devices, and should keep them in procurement records | Operators |

Other examples of IoT rules: the radio equipment cybersecurity
requirements under Delegated Regulation (EU) 2022/30, applicable from
1 August 2025, and national consumer IoT labelling schemes. For
detailed CRA processes, see `security/cra-vulnerability-handling`,
`security/cra-technical-documentation` and `security/sbom-vex-policy`.

## 10. Size tiers

<!-- Guidance: The fictional settings give a size reference; IoT use cases are examples. Show what changes per tier. -->

| Aspect | Small (under 50 people) | Medium (50 to 500) | Large or multi-site (over 500 or several sites) |
|---|---|---|---|
| Size reference | Quillmere Analytics Ltd, 46 staff (38 employees, 8 contractors), part-time ISMS manager | Quillmere Health Systems, 320 staff, full-time ISMS manager and 3-person security team | Quillmere Group, 2,400 staff, 6 sites in 4 countries, CISO and 14-person security office |
| Typical IoT use *(Example)* | Office devices (cameras, printers, meeting room screens); ingests customer telemetry in the cloud platform | Badge readers and meeting room devices at two offices and the colocation suite; devices at hospital customers through its service | Industrial sensors and gateways at 3 plants, building systems at all 6 sites |
| Baseline use | Short procurement checklist (credentials, updates, support period) | Full baseline in tenders, IoT network segment per office | Full baseline, IEC 62443-4-2 for industrial components, central device registry |
| Monitoring | Router logs and quarterly device review | Network discovery and alerts from the SOC tool | Passive monitoring per site feeding a central SOC |
| Governance | ISMS manager | IoT owner per system, ISMS manager oversight | IoT and OT security function in the security office |
| Review cycle | Yearly | Yearly plus after new device types | Yearly per site, rolling group review |

## 11. Records and evidence

<!-- Guidance: Name the records that prove the profile operates and map them in isms/control-evidence-matrix. -->

| Record | Proves | Owner | Location | Retention |
|---|---|---|---|---|
| IoT inventory with firmware and support dates | A.5.9 applied to IoT | Device owners | DOC-ISMS-012 | [Current plus 3 years of snapshots] |
| Tender and contract records with baseline | Baseline used in procurement | Procurement | [Contract system] | [Contract term plus 6 years] |
| Onboarding and transfer records | Lifecycle controls | Device owners | [ITSM tool] | [Example: 3 years] |
| Update and version reports | A.8.8 for devices | Device owners | [Device management platform] | [Example: 3 years] |
| Disposal records | A.7.14 and A.8.10 | IT or facilities | DOC-ISMS-057 | [Example: 6 years] |
| Network discovery reports and tickets | Unknown devices are detected | Network team | [Monitoring tool] | [Example: 1 year] |
| Supplier support period statements and SBOMs | Supplier duties | Procurement | [Supplier register DOC-ISMS-066] | [Device life plus 2 years] |

Link each record to its control in `isms/control-evidence-matrix`
(DOC-ISMS-033).

## 12. References

<!-- Guidance: Check for new editions; ISO/IEC 30141 is being revised and IoT baselines change often. -->

| Reference | Edition and status | Use |
|---|---|---|
| ISO/IEC 27400:2022, IoT security and privacy guidelines | Current (https://www.iso.org/standard/44373.html) | Risks, principles and controls |
| ISO/IEC 27402:2023, IoT device baseline requirements | Current (https://www.iso.org/standard/80136.html) | Device baseline |
| ISO/IEC 27001:2022 + Amd 1:2024 | Current (https://www.iso.org/standard/82875.html, Amd 1: https://www.iso.org/standard/88435.html) | ISMS requirements, clause 6.1.3, Annex A |
| ISO/IEC 27002:2022 | Current (https://www.iso.org/standard/75652.html) | Control guidance |
| ISO/IEC 27403:2024, ISO/IEC 27404:2025, ISO/IEC 30141:2024 | Current (cited without link) | Domotics, consumer labelling, reference architecture |
| ETSI EN 303 645 | V3.1.3 (2024-09) at the time of writing; check the current version | Consumer IoT baseline |
| NIST IR 8259A | 2020 (https://csrc.nist.gov/pubs/ir/8259/a/final) | Device capability core baseline |
| Regulation (EU) 2024/2847 (Cyber Resilience Act) | OJ 20.11.2024 (https://eur-lex.europa.eu/eli/reg/2024/2847/oj) | Product cybersecurity example |
| Related templates | `compliance/statement-of-applicability`, `compliance/risk-methodology`, `compliance/asset-inventory`, `compliance/supplier-security-assessment`, `compliance/privacy-by-design-review`, `isms/network-security-standard`, `isms/secure-configuration-baseline`, `isms/cryptographic-key-register`, `isms/equipment-disposal-reuse-record`, `isms/energy-27019-controls`, `isms/health-27799-controls`, `isms/control-evidence-matrix`, `security/threat-model`, `security/security-exception-request`, `security/cra-vulnerability-handling`, `security/cra-technical-documentation`, `security/sbom-vex-policy` | Linked documents |

## Standard and licence note

Structure aligned with ISO/IEC 27400:2022, ISO/IEC 27402:2023 and
ISO/IEC 27001:2022 + Amd 1:2024 (clause 6.1.3 and Annex A). The risk
sources, baseline, lifecycle, mapping and examples are original. No
text, requirements, tables or definitions from ISO, IEC or ETSI
documents are reproduced; standard descriptions are short paraphrases of
public catalogue entries. You need licensed copies of the standards to
confirm the baseline. Check the current editions before use. Official
ISO text, purchase or licensed access:
https://www.iso.org/standard/44373.html,
https://www.iso.org/standard/80136.html and
https://www.iso.org/standard/82875.html. Regulatory summaries are short
paraphrases; this is a documentation format, not legal advice.

Template licence: MIT.