Markdown Editor

IoT Security and Privacy Profile Template (ISO/IEC 27400, 27402)

IoT role, inventory and architecture, risk sources, device security and privacy baseline, lifecycle controls, Annex A mapping, EU CRA example

ISMS 与 ISO/IEC 27001完整ISO/IEC 27400:2022; ISO/IEC 27402:2023; ISO/IEC 27001:2022 + Amd 1:2024 6.1.3 and Annex A (cited only); EU CRA as exampleiot27400security

使用方法: Use it when connected devices are in the ISMS scope, whether you buy, integrate or manufacture them. Fill your role, the IoT inventory and the device baseline first, and put the baseline into every tender. The main pitfall is buying devices before asking about default passwords, update paths and support periods, which cannot be fixed after purchase.

预览

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.

Document control

FieldValue
Document IDDOC-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 updatedYYYY-MM-DD
Classification[Internal]
Standard and editionISO/IEC 27400:2022; ISO/IEC 27402:2023; ISO/IEC 27001:2022 + Amd 1:2024
Next scheduled reviewYYYY-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

RoleNameDecisionDate
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

VersionDateAuthorChange
1.0YYYY-MM-DD[@iot-security-lead]First issue
[x.y]YYYY-MM-DD[@author][Change summary]

Contents

1. Purpose, scope and role

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 systemOur roleReason
[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)OperatorSensors bought from a supplier, run by plant engineering

2. The IoT standards at a glance

StandardEditionWhat it gives you (summarised from the public catalogue)How this profile uses it
ISO/IEC 274002022 (published 2022-06-07)Guidelines on risks, principles and controls for security and privacy of IoT solutionsSections 4, 6 and 7
ISO/IEC 274022023 (published 2023-11-21)Baseline ICT requirements for IoT devices to support security and privacy controlsSection 5
ISO/IEC 274032024Guidelines for IoT domotics (home automation)Only if you supply home devices
ISO/IEC 274042025Cybersecurity labelling framework for consumer IoTOnly for consumer products
ISO/IEC 301412024IoT reference architectureVocabulary 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

3.1 Inventory

SystemDevice typesCountConnectivityData collectedUpdate methodSupport endsOwner
Plant condition monitoring (Example)Vibration and temperature sensors, 3 gateways1,800 sensorsWireless to gateway, gateway to cloud platformMachine telemetry, no personal dataGateway pushes signed firmware2032Plant engineering
Building access (Example)Badge readers, door controllers120Wired building networkBadge ID, time, doorVendor tool on site2029Facilities
[System][Types][n][Connectivity][Data][Method][Year][@owner]

3.2 Reference architecture

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

Risk sourceTypical scenarioAffected properties
Default or shared credentialsAttacker logs in to devices with factory passwords and builds a botnetIntegrity, availability
No or slow updatesKnown vulnerability stays open for years on long-lived devicesConfidentiality, integrity
Physical exposureDevice in a public or remote place is opened and its keys extractedConfidentiality, integrity
Insecure communicationTelemetry or commands sent unencrypted and alteredIntegrity
Excessive data collectionDevice collects audio, video or location beyond the stated purposePrivacy
Ownership transferResold or returned device still holds the previous user's data and accessPrivacy, confidentiality
Supplier end of lifeVendor stops updates or shuts down the cloud serviceAvailability
Cloud platform compromiseAttacker uses the platform to push malicious firmware to all devicesIntegrity, availability, safety

Worked scenario (Example):

FieldValue
Risk IDR-074 (Example)
ScenarioBuilding access controllers use a default administrator password; an attacker on the building network unlocks doors
Inherent likelihood x impact3 x 4 = 12, High
TreatmentIOT-IMP-002 (unique credentials, building network segment, vendor update)
Residual likelihood x impact1 x 4 = 4, Low
AcceptanceLow residual risk accepted by the risk owner, the facilities manager

5. Device security and privacy baseline

Baseline IDRequirement (our wording)ThemeVerification
IOT-BASE-001No universal default passwords; unique credentials per device or set at first useSecurityInspect device, supplier statement
IOT-BASE-002Device can be uniquely identified (logical and physical identifier)SecurityRegistry record
IOT-BASE-003Software and firmware can be updated securely, with integrity and authenticity checksSecurityUpdate test, signature check
IOT-BASE-004Supplier states the minimum support period for security updatesSecurityContract clause
IOT-BASE-005Supplier operates a vulnerability disclosure and handling processSecurityPublished policy, contract clause
IOT-BASE-006Communication protected with current cryptography; no unencrypted management interfacesSecurityTraffic capture, configuration review
IOT-BASE-007Unused interfaces and services disabled by defaultSecurityPort scan in a lab, configuration review
IOT-BASE-008Device logs security events and can send them to a central collectorSecurityLog sample
IOT-BASE-009Device resists simple physical tampering and protects stored secretsSecuritySupplier evidence, lab test for high-risk devices
IOT-BASE-010Data collected is limited to the stated purpose; purpose documentedPrivacyData flow review, DPIA where needed
IOT-BASE-011User can delete personal data and reset the device before transfer or disposalPrivacyReset test
IOT-BASE-012Software bill of materials available on requestSecuritySBOM received
IOT-BASE-013Device keeps safe operation when connectivity is lostSecurityFailover test
IOT-BASE-014Supplier risk assessment for the device is documentedRisk managementSupplier documentation

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

6. Lifecycle controls

StageControlsOwnerRecord
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 leadThreat model, design review
Procurement (operators)Baseline in tender, supplier assessment (DOC-ISMS-067), support period and update terms in contractProcurementTender scoring, contract
OnboardingRegister in inventory, set unique credentials, issue device certificate, place in IoT network segmentDevice ownerInventory entry, onboarding checklist
OperationMonitor device health and security events, review access, check for unknown devicesOperationsMonitoring reports
UpdateTrack vendor advisories, test updates, roll out in waves, verify versionDevice ownerChange records, version report
Transfer of ownershipFactory reset, remove from registry and platform, revoke certificates, give new owner a clean deviceDevice ownerTransfer record
DecommissionWipe or destroy storage, revoke credentials, update inventory (DOC-ISMS-057)IT or facilitiesDisposal record

7. Mapping to Annex A

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

8. Implementation table

Item IDLinkWhat is doneOwnerStatusDueEvidence
IOT-IMP-001 (Example)IOT-BASE-001 to 014Baseline added to every IoT tender from 2027ProcurementImplemented2027-01-31Tender template v2
IOT-IMP-002 (Example)R-074Unique credentials on all 120 access controllers, building network segment, vendor update appliedFacilitiesPartial2027-04-30Configuration report, change record
IOT-IMP-003 (Example)Onboarding stageDevice certificates issued by internal PKI for all gatewaysIoT security leadImplemented2027-03-31Certificate register (DOC-ISMS-070)
IOT-IMP-004 (Example)Operation stageNetwork discovery runs weekly; unknown devices raise a ticketNetwork teamPlanned2027-09-30Discovery 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

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:

TopicSummaryApplies to
Essential requirementsSecurity by design and default, and vulnerability handling, set out in Annex IManufacturers
Support periodManufacturers determine and state a support period during which vulnerabilities are handledManufacturers
ReportingActively exploited vulnerabilities and severe incidents reported to the designated CSIRT and ENISA, applying from 11 September 2026, including for products already on the marketManufacturers
Full applicationMost other obligations apply from 11 December 2027Manufacturers, importers, distributors
Buyer sideOperators can rely on CE marking and the stated support period when selecting devices, and should keep them in procurement recordsOperators

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

AspectSmall (under 50 people)Medium (50 to 500)Large or multi-site (over 500 or several sites)
Size referenceQuillmere Analytics Ltd, 46 staff (38 employees, 8 contractors), part-time ISMS managerQuillmere Health Systems, 320 staff, full-time ISMS manager and 3-person security teamQuillmere 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 platformBadge readers and meeting room devices at two offices and the colocation suite; devices at hospital customers through its serviceIndustrial sensors and gateways at 3 plants, building systems at all 6 sites
Baseline useShort procurement checklist (credentials, updates, support period)Full baseline in tenders, IoT network segment per officeFull baseline, IEC 62443-4-2 for industrial components, central device registry
MonitoringRouter logs and quarterly device reviewNetwork discovery and alerts from the SOC toolPassive monitoring per site feeding a central SOC
GovernanceISMS managerIoT owner per system, ISMS manager oversightIoT and OT security function in the security office
Review cycleYearlyYearly plus after new device typesYearly per site, rolling group review

11. Records and evidence

RecordProvesOwnerLocationRetention
IoT inventory with firmware and support datesA.5.9 applied to IoTDevice ownersDOC-ISMS-012[Current plus 3 years of snapshots]
Tender and contract records with baselineBaseline used in procurementProcurement[Contract system][Contract term plus 6 years]
Onboarding and transfer recordsLifecycle controlsDevice owners[ITSM tool][Example: 3 years]
Update and version reportsA.8.8 for devicesDevice owners[Device management platform][Example: 3 years]
Disposal recordsA.7.14 and A.8.10IT or facilitiesDOC-ISMS-057[Example: 6 years]
Network discovery reports and ticketsUnknown devices are detectedNetwork team[Monitoring tool][Example: 1 year]
Supplier support period statements and SBOMsSupplier dutiesProcurement[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

ReferenceEdition and statusUse
ISO/IEC 27400:2022, IoT security and privacy guidelinesCurrent (https://www.iso.org/standard/44373.html)Risks, principles and controls
ISO/IEC 27402:2023, IoT device baseline requirementsCurrent (https://www.iso.org/standard/80136.html)Device baseline
ISO/IEC 27001:2022 + Amd 1:2024Current (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:2022Current (https://www.iso.org/standard/75652.html)Control guidance
ISO/IEC 27403:2024, ISO/IEC 27404:2025, ISO/IEC 30141:2024Current (cited without link)Domotics, consumer labelling, reference architecture
ETSI EN 303 645V3.1.3 (2024-09) at the time of writing; check the current versionConsumer IoT baseline
NIST IR 8259A2020 (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 templatescompliance/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-policyLinked 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.

相关模板