Governance, Standards and Compliance

Introduction

IoT security is not achieved only by installing encryption, firewalls or security software. It is also a governance problem: an organisation must decide who is accountable, what risks are acceptable, which controls are required, how suppliers are managed, and how compliance is demonstrated. IoT systems are particularly demanding because they combine physical devices, embedded software, cloud services, mobile applications, communication networks, data-processing platforms and third-party components.

A governance failure can therefore produce consequences beyond information loss. A compromised medical sensor may affect patient safety; a manipulated industrial controller may interrupt production; a vulnerable consumer camera may expose private spaces; and an insecure smart meter may undermine public confidence. Governance connects business objectives, engineering practice, legal duties and assurance evidence.

This chapter explains how to develop IoT security policies, assign responsibilities, maintain risk registers, measure controls and construct assurance plans using NIST guidance, ISO/IEC 27001, ISO/IEC 27400, IEC 62443, ETSI EN 303 645 and relevant product-security regulation. Standards are not identical laws. They are structured sources of good practice, requirements and evidence that help an organisation demonstrate reasonable and systematic security.

Learning objectives

By the end of this chapter, a student should be able to:

1. Explain the relationship between governance, risk management, standards and compliance.
2. Compare the purposes of NIST guidance, ISO/IEC 27001, ISO/IEC 27400, IEC 62443 and ETSI EN 303 645.
3. Develop an IoT security policy and assign responsibilities using governance principles.
4. Construct and prioritise an IoT security risk register.
5. Define useful control metrics and distinguish measurement from assurance.
6. Design an assurance plan using audits, testing, reviews and evidence.
7. Recognise the implications of product-security regulations and responsible vulnerability management.

1. Governance as the organising system

Governance is the system by which an organisation is directed, controlled and held accountable. It establishes authority, decision rights, objectives, policies, oversight and reporting. Management operates within that system by planning and executing activities; governance determines whether those activities are appropriate and whether results are acceptable.

For IoT, governance should cover the complete lifecycle:

• concept and risk classification;
• procurement and supplier selection;
• secure design and development;
• manufacturing, commissioning and deployment;
• operation, monitoring and maintenance;
• incident response and recovery;
• decommissioning, disposal and data deletion.

A useful governance principle is accountability at the level of decision. The engineering team may implement a secure update mechanism, but a named product owner should remain accountable for ensuring that the mechanism exists, is funded and is maintained. Responsibility may be delegated; accountability should not become unclear.

Governance layers

Risk appetite describes the amount and type of risk an organisation is willing to accept. A company may tolerate a short service interruption in a home-energy dashboard but have almost no tolerance for unauthorised control of a safety-critical actuator. Risk acceptance must therefore consider safety, privacy, availability, resilience, legal exposure and reputation—not confidentiality alone.

2. Standards and guidance landscape

Standards should be selected according to the system boundary and the organisation’s purpose. A manufacturer, cloud operator and factory owner may use overlapping standards but will require different evidence.

NIST guidance

The NIST Cybersecurity Framework (CSF) provides outcome-oriented functions: Govern, Identify, Protect, Detect, Respond and Recover. The Govern function emphasises organisational context, risk management strategy, roles, policy and oversight. The other functions help an organisation describe desired cybersecurity outcomes rather than prescribe one technology.

NIST SP 800-53 provides a catalogue of security and privacy controls, while NIST SP 800-61 addresses incident handling and NIST SP 800-30 supports risk assessment. NISTIR 8259 and related publications provide IoT-specific considerations, including device cybersecurity capabilities and manufacturer documentation. NIST guidance is widely useful for tailoring controls, but it is not automatically a certification scheme.

ISO/IEC 27001

ISO/IEC 27001 specifies requirements for an information security management system (ISMS). An ISMS is a management system, not merely a collection of technical controls. It requires context, leadership, planning, support, operation, performance evaluation and continual improvement. The organisation defines its scope, assesses risks, selects treatment actions and maintains evidence.

The Statement of Applicability records which controls are applicable, their implementation status and the justification for exclusions. Certification, where sought, is performed by an independent certification body. Certification does not mean that every risk has disappeared; it indicates that the management system has been assessed against the standard’s requirements within a defined scope.

ISO/IEC 27400

ISO/IEC 27400 provides IoT security and privacy guidance. It addresses the distinctive characteristics of IoT, including heterogeneous devices, constrained resources, long lifetimes, physical exposure, data flows and relationships among manufacturers, service providers, users and operators. It complements an ISMS by helping an organisation interpret security and privacy practices in an IoT context.

IEC 62443

IEC 62443 is a family of standards for industrial automation and control systems (IACS). It separates concerns among asset owners, service providers and component or product suppliers. Its concepts include security levels, zones and conduits, secure product development and lifecycle processes. A zone groups assets with common security requirements; a conduit controls communication between zones. The model is particularly useful for factories, utilities and process-control environments.

Security levels express the capability needed to resist increasingly capable threats. They should not be treated as a universal ranking of product quality. The required level depends on the threat environment, consequence of compromise and architecture.

ETSI EN 303 645

ETSI EN 303 645 is a baseline for cybersecurity of consumer IoT products. Its provisions include avoiding universal default passwords, implementing a means to manage vulnerability reports, keeping software updated, securely storing sensitive security parameters, communicating securely, minimising exposed attack surfaces, protecting personal data, ensuring resilience, examining system telemetry and making installation and maintenance easier for users.

It is especially relevant to connected cameras, toys, home hubs, appliances and wearable devices. The standard emphasises secure-by-design product development and support throughout the product life.

Regulations and legal obligations

Regulation varies by jurisdiction and product category. Examples include data-protection laws, product-safety legislation, sectoral critical-infrastructure rules and emerging cybersecurity requirements for connected products. The European Union Cyber Resilience Act, for example, introduces cybersecurity obligations for products with digital elements, including requirements related to secure design, vulnerability handling, updates and reporting, subject to its scope and implementation timetable. The EU Radio Equipment Directive delegated requirements also address certain internet-connected radio equipment.

Legal applicability must be confirmed by competent legal and compliance specialists. A standard may be voluntary while a regulation is mandatory. Conversely, a regulation may refer to harmonised standards as one route to demonstrating conformity. Organisations should maintain a legal and regulatory register rather than assuming that one certification satisfies all obligations.

3. Building an IoT security policy

An effective policy is concise enough to guide behaviour and specific enough to support audit. It should not attempt to reproduce every technical procedure. A policy normally includes:

1. Purpose and objectives – for example, protecting IoT devices, services, people, data and physical operations.
2. Scope – devices, firmware, applications, networks, cloud services, suppliers, facilities and personnel included.
3. Principles – least privilege, secure by design, defence in depth, privacy by design, resilience and accountability.
4. Classification – criteria for identifying safety-critical, privacy-sensitive, mission-critical and ordinary assets.
5. Lifecycle requirements – security gates from design through retirement.
6. Responsibilities – named owners and escalation paths.
7. Minimum controls – identity, authentication, updates, logging, vulnerability handling, backup and recovery.
8. Exception management – documented justification, compensating controls, expiry date and approving authority.
9. Compliance and enforcement – monitoring, disciplinary consequences and review frequency.

Policy must be supported by standards and procedures. For example, the policy may require secure updates; a technical standard can define signed packages and rollback protection; a procedure can describe how an engineer tests and deploys an update.

A policy should also identify policy conflicts. A requirement for rapid patching may conflict with a safety validation process in an industrial environment. The correct response is not to ignore either requirement, but to define emergency-change procedures, compensating controls and risk-based approval.

4. Roles and responsibilities

A RACI matrix is a practical governance tool. Responsible means performing the work; Accountable means answerable for the outcome; Consulted means providing expertise; and Informed means receiving relevant information. Each important activity should have one clear accountable role, although several people may be responsible.

Other important roles include the asset owner, data-protection officer, safety manager, incident commander and executive risk owner. In a small organisation, one person may hold several roles, but incompatible duties—such as implementing and independently approving a control—should be separated where practical.

5. IoT risk assessment and the risk register

Risk assessment identifies threats, vulnerabilities, consequences and uncertainty. A practical IoT assessment considers:

• physical tampering and theft;
• weak credentials and unauthorised access;
• insecure interfaces and exposed services;
• vulnerable third-party software;
• unsafe or unavailable updates;
• privacy-invasive collection and inference;
• cloud or mobile-application compromise;
• supply-chain manipulation;
• denial of service and loss of connectivity;
• unsafe operation or environmental impact.

A qualitative model is often appropriate at diploma level. Define likelihood and impact on a scale from 1 to 5 and calculate a prioritisation score:

Here, R is the risk score, L is likelihood and I is impact. Both scales must be defined consistently; the score is a prioritisation aid, not a probability and not a monetary loss estimate. It assumes that the organisation accepts a simple multiplicative ranking and that the scales are sufficiently comparable.

For example, an exposed administrative interface may have likelihood 4 and impact 5, giving R = 4 × 5 = 20. A sensor outage may have likelihood 3 and impact 3, giving 9. The first risk receives priority, but the second may still require immediate treatment if it affects safety.

A risk register should contain:

Risk treatment options are avoid, reduce, transfer or accept. Transfer, such as using contractual insurance or a managed service, does not eliminate the organisation’s accountability for harm. Risk acceptance must be explicit, time-bounded and approved by an authority with an appropriate risk mandate.

6. Controls and control metrics

A control is a measure that modifies risk. Preventive controls reduce the chance of an event; detective controls identify events; corrective controls limit harm or restore service; directive controls establish expected behaviour. A signed firmware mechanism is preventive and integrity-protective; an anomaly alert is detective; tested restoration is corrective; a policy is directive.

Metrics should measure control performance rather than create the illusion of security. Useful examples include:

• percentage of devices with a current asset owner;
• percentage using unique device credentials;
• percentage of critical vulnerabilities remediated within the target time;
• median time from vulnerability disclosure to deployed mitigation;
• percentage of firmware releases with documented security review;
• percentage of critical systems with tested recovery plans;
• number of unsupported devices in production;
• percentage of suppliers providing software bills of materials where required;
• number and age of unresolved high-risk exceptions.

A coverage metric can be expressed as:

C is control coverage, n_compliant is the number of assessed items meeting the criterion and n_total is the number assessed. The denominator must be defined—for example, all production gateways, not only gateways sampled by an administrator. The metric is meaningful only when records are complete and the criterion is objectively tested. A 100% coverage result does not prove that the control is effective against every threat.

Metrics require targets, owners, data sources, frequency and escalation thresholds. A dashboard should show trends and exceptions, not only averages. For example, a good patch-compliance percentage may conceal ten critical devices that are offline and unprotected.

7. Assurance planning

Assurance is the justified confidence that governance, risk treatment and controls are suitable and operating effectively. Compliance asks, “Have stated requirements been met?” Assurance additionally asks, “Are they appropriate, reliable and effective?”

An IoT assurance plan should include:

1. scope and system boundaries;
2. criteria, such as policy clauses, ISO/IEC 27001 controls, IEC 62443 requirements or ETSI provisions;
3. risks and control objectives;
4. evidence required;
5. test methods and sampling approach;
6. responsible assessor and independence requirements;
7. schedule and reporting format;
8. remediation, retesting and escalation.

Evidence may include architecture diagrams, asset inventories, threat models, source-code review records, penetration-test reports, update logs, vulnerability tickets, supplier attestations, training records, incident exercises and recovery-test results. Evidence should be attributable, dated, protected from alteration and connected to a specific requirement.

Assurance methods differ in strength. A document review verifies that a process is described. An interview confirms understanding. Observation shows that a practice occurs. Inspection examines configuration or records. Technical testing provides stronger evidence about particular behaviours, but no test proves the absence of all vulnerabilities. Independent audit improves credibility, while continuous monitoring provides more timely evidence than an annual review alone.

A three-lines model can clarify assurance: operational teams own and operate controls; risk or security functions provide specialist oversight and monitoring; internal audit provides independent assurance. External certification or regulatory assessment may provide an additional layer but does not replace management responsibility.

8. Supply-chain and product governance

IoT security depends heavily on suppliers. Procurement should require security requirements proportionate to risk, including:

• vulnerability disclosure and response arrangements;
• supported product lifetime and end-of-support notification;
• secure update capability and update authenticity;
• security incident notification;
• component provenance and, where appropriate, an SBOM;
• independent test evidence and remediation obligations;
• data-processing, access-control and deletion commitments;
• subcontractor controls and audit rights.

An SBOM helps identify components and versions; it is not itself proof that components are secure. Supplier questionnaires are useful for initial screening but should be supported by evidence and risk-based verification. Contracts should define what happens when a supplier cannot patch a vulnerable component: mitigation, replacement, isolation or retirement must be planned.

Product governance should include security gates. Before release, the organisation should confirm threat modelling, abuse-case testing, secure configuration, credential handling, update and rollback behaviour, privacy review, logging, support commitments and residual-risk approval. A product that is secure at launch but unsupported after six months is not governed securely across its lifecycle.

9. Applied case: illustrative smart-factory gateway programme

Background

A medium-sized manufacturer deploys 600 gateways connecting programmable logic controllers to a cloud analytics platform. The gateways use cellular and Ethernet connectivity and are maintained by both the manufacturer’s staff and an external integrator.

Problem

An assessment finds shared administrative credentials, inconsistent firmware versions, internet-exposed management ports and no formally assigned asset owners. The plant manager wants rapid deployment, while the safety manager is concerned that automatic updates could disrupt validated control processes.

Analysis

The governance team maps the environment using IEC 62443 concepts. Controllers and safety-related assets are placed in protected zones; controlled conduits separate them from analytics services. The organisation uses the NIST CSF to describe outcomes and ISO/IEC 27001 processes to formalise risk treatment. ISO/IEC 27400 helps address device lifecycle and privacy considerations. ETSI EN 303 645 is used as a useful baseline for secure update, vulnerability handling and credential practices, although the factory is not primarily a consumer-IoT environment.

The highest risk is unauthorised gateway administration. Likelihood is assessed as 4 and impact as 5, producing a prioritisation score of 20. A second risk concerns update failure, assessed as likelihood 3 and impact 5, producing 15. The second risk is not solved by refusing updates; unpatched gateways remain exposed.

Approach and solution

The organisation assigns the product owner accountability, creates an asset register and replaces shared credentials with unique identities and privileged access management. Management ports are removed from the public network. Gateways are segmented into zones, and conduits permit only approved protocols. Firmware is signed, tested in a staging environment and deployed in phases with a documented rollback procedure. Emergency changes require approval by the operations and safety leads.

The supplier contract is amended to require vulnerability notification, support for five years, update integrity, incident cooperation and component information. Monthly metrics report asset ownership, firmware currency, critical vulnerability age and failed update rate. Quarterly assurance reviews sample gateways and inspect configuration, logs and update evidence. An annual recovery exercise tests replacement of a failed gateway without unsafe process interruption.

Outcome

The programme reduces exposure and makes exceptions visible to senior management. The organisation does not claim that certification or segmentation eliminates risk. Instead, it can demonstrate who owns each risk, which controls are implemented, how effectiveness is measured and what happens when a control fails.

Learning points

1. Technical controls are more reliable when supported by ownership and lifecycle policy.
2. Safety and cybersecurity requirements must be engineered together.
3. A standard should be mapped to evidence and responsibilities, not merely named in a policy.
4. Supplier obligations and support lifetime are part of product security.
5. Assurance must test operating effectiveness, not only the existence of documents.

10. Challenges, ethics and contemporary developments

Legacy and constrained devices

Many devices cannot support modern cryptography, logging or secure update mechanisms. Organisations should identify compensating controls such as isolation, protocol restrictions, monitoring and replacement plans. Compensating controls must be documented and periodically reassessed; they should not become a permanent excuse for unmanaged legacy risk.

Privacy and proportionality

IoT sensors can infer behaviour even when they do not directly collect names. Governance should define purpose limitation, data minimisation, retention, access rights and lawful processing. Continuous monitoring of workers or household occupants raises ethical concerns about consent, power imbalance and secondary use. Security monitoring should itself be proportionate and protected.

Artificial intelligence

AI may assist anomaly detection, vulnerability triage and control monitoring, but it can produce false positives, false negatives and opaque decisions. An AI-generated risk rating should not automatically accept or reject risk. Human review, traceable evidence, model governance and protection against manipulated data remain necessary.

Regulatory change

Product-security laws increasingly expect secure-by-design development, vulnerability disclosure, support periods and incident reporting. Organisations should monitor official regulatory sources, identify product categories and jurisdictions, assign legal owners and maintain conformity evidence. Compliance programmes should be designed to adapt rather than treating a standard’s current edition as permanent.

Best-practice checklist

• Define IoT scope, ownership and risk appetite.
• Maintain an accurate asset and data-flow inventory.
• Map applicable standards and laws to concrete requirements.
• Use lifecycle security gates from design to retirement.
• Prohibit universal default credentials and unmanaged privileged access.
• Provide authenticated, integrity-protected updates and a support policy.
• Maintain vulnerability-disclosure and incident-response processes.
• Segment high-consequence environments and control conduits.
• Measure control coverage, timeliness and exceptions.
• Preserve reliable evidence and perform independent assurance.
• Review suppliers, components, subcontractors and end-of-support risk.
• Treat safety, privacy and cybersecurity as connected governance concerns.

Chapter Summary

IoT security governance converts broad security objectives into accountable decisions, policies, controls and evidence. NIST guidance offers flexible risk and outcome models; ISO/IEC 27001 establishes an information security management system; ISO/IEC 27400 contextualises security and privacy for IoT; IEC 62443 supports industrial automation through roles, zones, conduits and security levels; and ETSI EN 303 645 provides a consumer-IoT baseline. Regulations impose jurisdiction-specific duties and must be assessed separately from voluntary standards.

A sound programme defines scope, ownership, lifecycle requirements, exceptions and supplier obligations. Risk registers record threats, consequences, controls, owners and residual risk. Control metrics must have clear denominators and evidence. Assurance plans combine reviews, observation, inspection, testing, audits and remediation. The central professional principle is that compliance is not a certificate or checklist: it is an ongoing, evidence-based demonstration that IoT risks are understood, treated and overseen.

Key Terms

Governance: Direction, oversight and accountability for achieving organisational objectives.

Risk appetite: The amount and type of risk an organisation is willing to accept.

ISMS: Information security management system established and operated under defined requirements.

IoT lifecycle: The stages from concept and design through operation, maintenance and retirement.

NIST CSF: A framework organised around Govern, Identify, Protect, Detect, Respond and Recover outcomes.

ISO/IEC 27001: A standard specifying requirements for an information security management system.

ISO/IEC 27400: Guidance addressing security and privacy in IoT environments.

IEC 62443: A standards family for industrial automation and control-system cybersecurity.

Zone: A group of industrial assets with common security requirements.

Conduit: A controlled communication path between zones.

ETSI EN 303 645: A baseline for cybersecurity of consumer IoT products.

Risk register: A managed record of identified risks, controls, owners and treatment status.

Residual risk: Risk remaining after controls and treatments are applied.

Control: A measure that modifies one or more risks.

Metric: A defined measurement used to monitor performance or condition.

Assurance: Justified confidence that governance and controls are suitable and effective.

SBOM: A software bill of materials identifying software components and versions.

Vulnerability disclosure: A process for receiving, assessing and responding to security weaknesses.

Statement of Applicability: An ISO/IEC 27001 document explaining applicable controls and exclusions.

Compensating control: An alternative measure used when the preferred control cannot be implemented.

Review Questions

Short Answer Questions

1. Distinguish governance from management in an IoT security programme.
2. What is the purpose of an ISO/IEC 27001 Statement of Applicability?
3. Define a zone and a conduit in IEC 62443.
4. Why should a risk register include residual risk?
5. State two examples of evidence that may support an assurance activity.

Long Answer Questions

1. Compare the roles of NIST CSF, ISO/IEC 27001 and ISO/IEC 27400 in an IoT security programme.
2. Explain how an organisation should develop, approve and maintain an IoT security policy.
3. Discuss how supplier governance affects the security of connected products.
4. Describe a complete assurance plan for a fleet of connected industrial gateways.
5. Explain why compliance with a standard does not prove that all IoT risks have been eliminated.

Analytical / Application Questions

1. A fleet contains 1,200 devices, of which 1,080 meet the defined secure-configuration criterion. Calculate control coverage using C = (n_compliant ÷ n_total) × 100%, and explain one limitation of the result.
2. A risk has likelihood 4 and impact 5, while a second risk has likelihood 5 and impact 3. Using R = L × I, compare their scores and explain why score alone should not determine treatment priority.
3. Design a governance response for a connected medical-device supplier that cannot provide timely security updates. Identify responsibilities, immediate compensating controls, contractual actions and assurance evidence.

Multiple Choice Questions with Answers

Question 1

Which NIST Cybersecurity Framework function focuses on organisational context, policy, risk strategy and oversight?

A. Govern

B. Protect

C. Detect

D. Recover

Correct Answer: A. Govern

Question 2

What is the primary purpose of an ISO/IEC 27001 Statement of Applicability?

A. To list every device serial number

B. To justify applicable and excluded controls

C. To replace incident-response procedures

D. To calculate vulnerability severity

Correct Answer: B. To justify applicable and excluded controls

Question 3

In IEC 62443, what is a conduit?

A. A group of assets with common requirements

B. A software bill of materials

C. A controlled communication path between zones

D. A risk-acceptance document

Correct Answer: C. A controlled communication path between zones

Question 4

Which practice is specifically associated with the ETSI EN 303 645 consumer-IoT baseline?

A. Using universal default passwords

B. Avoiding universal default passwords

C. Disabling vulnerability reporting

D. Removing update mechanisms

Correct Answer: B. Avoiding universal default passwords

Question 5

A risk has likelihood 4 and impact 5. Using R = L × I, what is its prioritisation score?

A. 9

B. 15

C. 20

D. 25

Correct Answer: C. 20

Question 6

Which statement about a control metric is most accurate?

A. A high percentage always proves effectiveness

B. The denominator and measurement criterion must be defined

C. Metrics remove the need for audits

D. Only financial measures are useful

Correct Answer: B. The denominator and measurement criterion must be defined

Question 7

Which role is accountable for the outcome in a RACI assignment?

A. Responsible

B. Accountable

C. Consulted

D. Informed

Correct Answer: B. Accountable

Question 8

What does an SBOM primarily provide?

A. A list of software components and versions

B. A guarantee that software is vulnerability-free

C. A physical network segmentation design

D. A legal risk-acceptance decision

Correct Answer: A. A list of software components and versions

Question 9

Which activity provides the strongest evidence that a control operates in practice?

A. Reading an unsigned policy draft

B. Assuming supplier compliance

C. Testing configurations and examining operating records

D. Counting the number of security policies

Correct Answer: C. Testing configurations and examining operating records

Question 10

Why should safety and cybersecurity requirements be considered together in industrial IoT?

A. Cybersecurity incidents can affect physical processes and safety

B. Safety systems never use networks

C. Cybersecurity controls always reduce safety

D. Industrial systems have no lifecycle concerns

Correct Answer: A. Cybersecurity incidents can affect physical processes and safety