8.1 An Overview of IoT Security
8.1.1 The Full Picture of IoT Security Threats
The security weaknesses of IoT devices belong not only to their owners — they can rebound on the entire public internet. From weak-password scanning to protocol-stack vulnerabilities to novel attacks on AI models, an attacker often needs to find only one weak link to pry the whole chain loose. Understanding threats is the starting point for designing defenses. This section sorts the security threats facing IoT systems layer by layer, starting from the attack surface.
Threat Distribution Seen from the Attack Surface
From end devices to cloud applications, an IoT system divides roughly into the sensing layer, network layer, platform layer, and application layer. Each layer has its own specific attack vectors.
Sensing layer (devices and sensors) faces the most direct threats. An attacker can physically reach a device, read its firmware through debug interfaces (JTAG/SWD), or simply pry open the enclosure and swap the storage chip. For devices without anti-tamper mechanisms, physical access equals total control. The mainstream attack technique is weak-password scanning — it relies on no advanced technology, only on the "undefended" factory configuration: default administrator accounts, no password expiry, no limit on attempts. The Mirai botnet that erupted in 2016 infected roughly 600,000 cameras and routers precisely by scanning for such default passwords, then drove those devices in a DDoS attack against DNS providers, causing widespread internet service disruption (for how to contain this kind of worm-like spread at the network-architecture level, Section 8.3.3 returns to this case). The secure-boot mechanism exists precisely to counter this class of threat — the bootloader verifies firmware signatures stage by stage, refuses to run anything whose signature fails, and blocks malicious firmware before boot.
Network layer (communication links) carries device data to the platform, potentially over Wi-Fi, ZigBee, LoRaWAN, or cellular networks along the way. Every hop gives an attacker a chance to eavesdrop, tamper, or replay. Unencrypted links are especially fragile: an attacker can deploy a sniffer near the gateway and copy off sensor data and device commands outright. This is exactly why DTLS (Datagram Transport Layer Security) was chosen as the security base for CoAP — facing UDP's nondeterminism, DTLS verifies each datagram's integrity individually at the record layer, blocking the common trick of splicing and replaying messages. In engineering terms, though, the asymmetric operations and certificate chain of a full TLS handshake still burden small devices, hence the compromise options that followed: TLS-PSK (Pre-Shared Key, PSK), session resumption, and lighter elliptic-curve algorithms.
Platform layer (cloud/edge) risks look more like traditional web security: weak authentication, privilege escalation, unthrottled APIs. The difference is that an IoT platform has physical devices behind it — a request that escapes its authority is no longer merely "seeing data it should not see" but "closing a valve it should not close." In multi-tenant scenarios, isolation must be made even stricter: a user permitted to read devices is not thereby permitted to read another tenant's device data. The authorization model usually adopts RBAC (role-based access control), binding subjects, roles, and resources together, and holds to least privilege and the fail-closed principle — if no permission is found, refuse; never allow by default.
Application layer (user interfaces and business logic) threats include cross-site scripting (XSS) in web back ends, insecure storage on mobile clients, and the new attack vectors that AI models introduce. As large language models (LLMs) are wired into operations — letting the model read and write device points or execute commands through Tool-Calling — prompt injection and jailbreak attacks have become a new practical concern. The threat is this: when a model can send a stop command to an MQTT broker through Tool-Calling, one prompt injection no longer means "blurting out words it should not say" — it means a standstill in the physical world. This section only categorizes AI security threats; the concrete defenses — prompt-injection filtering, output validation, and Tool-Use permission sandboxes — are developed in Section 8.5 of this chapter.
Threat Classification Diagram
This figure makes the "multi-layer" character of IoT security explicit: attackers usually do not operate on a single point. The typical attack path enters through a device-side weak password, takes over the device, and launches a network-layer DDoS; protocol-stack vulnerabilities exploit implementation defects and affect the entire chain from front end to back end.
Threat Evolution Trends
Traditionally, the core threats in industrial control and IoT security were physical attacks and network penetration. But several clear trends are reshaping that landscape.
Protocol vulnerabilities have become a high-incidence zone. Lightweight protocols are simple by design, but their implementations often skip security checks. For example, if a CoAP implementation does not verify the monotonic increase of message IDs, an attacker can disturb connection state by replaying old ACK messages; if the MQTT last-will feature is left unconstrained, a man-in-the-middle can exploit it for tampering. These attacks rely on no cryptographic break-in — only on protocol-logic defects.
The supply chain has become a weak link. When device manufacturers import firmware, SDKs, and protocol stacks from third parties, known vulnerabilities can ride along. Such vulnerabilities have a wide blast radius, while the vendor's response cycle — from vulnerability disclosure, to receiving incident notification, to pushing an upgrade package — usually lags badly. Testing is often not rigorous enough either: port-scanning and penetration-testing tools can detect whether key services such as Telnet, FTP, Finger, and TFTP are exposed, but many devices' factory tests do not include these checks.
The new attack surface AI introduces cannot be ignored. Model injection, data poisoning, prompt jailbreaking — these attacks exploit fragilities in the model's inference process, not missing perimeter defenses. When a model accesses platform resources through Tool-Calling, it operates on behalf of a user account. That means what the model can see and touch must never exceed that account's own privileges — cross-tenant data must be invisible to AI as well. In multi-tenant systems this is a hard constraint, not an option.
The Logical Starting Point from Threats to Defense
All the threats above share one characteristic: they rely on the "insecure by default" design assumption — devices have no unique root of trust, communication links have no built-in encryption, the platform does not verify the caller's tenant identity, and AI models place no constraints on their inputs. That is precisely the assumption that security design must correct, one by one.
Defense is not the elimination of all threats — engineering cannot achieve it, and the resources do not pay off. Defense is making the attacker pay a high enough price at every layer he crosses, until he stops. Seen this way, Figure 8-1 is also a flat projection of "defense in depth": every layer means one more chance to intercept.
8.1.2 Security Principles and Protection Strategies
The starting point of IoT security is not which encryption algorithm to choose, but a set of design principles that run through the system's entire lifecycle. These principles answer more fundamental questions: defend against what, to what degree, and what to do after a breach. "Security" without principle constraints tends to be scattered patchwork — close a port today, fix a firmware tomorrow, upgrade a protocol the day after, with no unified defensive baseline.
Defense in Depth: Deploy Across Layers, Do Not Bet on a Single Point
The core assumption of defense in depth is simple: any layer may sooner or later fall. Firewalls can be bypassed, encryption can be brute-forced, firmware signatures can be circumvented — so defenses are repeated across different layers, so that an attacker who breaches the first line still cannot get into the second.
A typical IoT defense-in-depth deployment covers multiple layers from physical security to application security:
- Physical security: tamper switches, the Secure Element (SE), the Trusted Execution Environment (TEE), locked-down debug interfaces. If a device cannot withstand physical contact, every software-layer defense above it is unreliable.
- Device firmware security: Secure Boot and mandatory over-the-air (OTA) signature verification, blocking the "flash malicious firmware" path.
- Communication security: TLS/DTLS encrypted tunnels, mutual certificate authentication, anti-replay mechanisms. Even an attacker who gets onto the network can neither eavesdrop nor impersonate.
- Identity and access control: JSON Web Tokens (JWTs), OAuth 2.0, RBAC permission models. Only subjects holding valid credentials can obtain the corresponding resources.
- Platform security: multi-tenant isolation, audit logs, rate limiting. A single tenant's vulnerability does not spread to the whole system.
- Data security: storage encryption and field-level data masking. Even after a database leak, the data itself remains protected by encryption.
- Application and AI security: the new attack surface brought by connecting large models, such as model-injection attacks and prompt hijacking. The threat classification here serves only as part of the security baseline; concrete defenses are developed in later chapters of this book.
Layers complement one another without depending on one another — an arrangement called a compensating control. For example, when a device lacks an SE/TEE hardware root of trust, stronger communication authentication (such as a hybrid scheme binding PSK with certificates) can compensate; when network-layer encryption is not strong enough, the platform side can add replay detection and anomalous-traffic alarms. Compensating controls are defense in depth's most practical engineering trade-off under resource constraints.
Least Privilege and Secure by Default
The Principle of Least Privilege requires every subject to hold only the minimum privileges necessary to complete its task — not one privilege more, whether for a device, a user, or a process. The RBAC model explicitly binds subjects, roles, and resources, and holds to fail-closed: if no permission is found, refuse; never allow by default. The same constraint applies to devices: a sensor that only needs to send uplink telemetry should have no downlink command channel open to it; an edge gateway that reads and writes many points should have no access to the management console.
Secure by Default requires that a system's factory configuration already be safe: insecure services (Telnet, FTP) off by default, no nonessential ports opened, weak passwords forcibly changed. What typical incidents keep exposing is exactly this kind of configuration — "ships with Telnet enabled, a default administrator account, and no password policy at all." The industry consensus is: deny by default, allow on demand. Devices may connect and permissions be assigned only after explicit configuration rules — not everything opened first and patched after the audit.
The Secure Development Lifecycle: Shift Security Left
Security is not something "added on" at one particular stage. Embedding security mechanisms into every step of software development is the path called the Secure Development Lifecycle (SDL).
- Requirements stage: do threat modeling. Draw the system's data flow diagram (DFD), mark the threats that may exist at each interaction point, classify them with the STRIDE model (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), and then decide which protection strategy each layer should adopt.
- Design stage: hold an architectural security review. Are there single points of failure? Is encryption end-to-end? Is authentication mutual? Is there an anti-rollback mechanism?
- Development stage: follow secure-coding standards, use secure function libraries, and never hard-code keys or credentials in source code.
- Testing stage: automated static code analysis (SAST) and dynamic security testing (DAST); manual penetration testing, verified item by item against an IoT security checklist.
- Deployment and operations stage: track vulnerability advisories continuously and push security updates promptly; retain audit logs and review security incidents regularly.
Security cost varies enormously with when a flaw is found. An architectural defect caught and fixed during threat modeling may require only a few pages of design-document edits; a command-injection vulnerability in firmware discovered only after tens of thousands of units have shipped means a single OTA upgrade whose cost and time dwarf the earlier fix. Doing SDL well is not merely about "passing the compliance review" — in engineering-economics terms it is the soundest investment.
Continuous Monitoring and Response
Isolation and encryption stop most generic attacks, but zero-day vulnerabilities or advanced persistent threats can still pierce layer after layer of defense. The final link of a security strategy is continuous monitoring and threat response.
In an IoT setting, monitoring is not "page operations whenever an alarm arrives." A three-layer noise-reduction mechanism is recommended to converge raw alarms into actionable events:
- Debouncing: no alarm for a single threshold crossing or a single failed command; trigger only when the same class of anomaly occurs a preset number of times within a continuous window — filtering out a one-off network jitter or transient interference.
- State machine: divide alarms into four states — "triggered → acknowledged → recovered → closed" — combined with active-connection keepalive and the last-will message mechanism, preventing devices from repeatedly firing false alarms during network fluctuation.
- Tiering and aggregation: classify by urgency. Critical events (such as a data leak or a compromised device) demand the fastest possible response; severe events (such as mass authentication failures or an expired certificate) must be handled within a short window; routine events (such as a single device disconnect or a port scan) go into the daily report. Alarms of the same type, time window, and region aggregate into one incident record, instead of one pop-up per message.
Response strategy should favor automation: when a malicious IP scanning a specific port is detected, add it to the firewall blacklist automatically; when a device's firmware-signature verification fails, quarantine the device and cut its external communication automatically, while pushing a notification to operations staff. This echoes the "blocking" capability in defense in depth — on detecting an anomaly, block first under preset policy, then complete the process with a post-hoc audit.
Core Principles at a Glance
Table 8-1 IoT security core principles at a glance
| Principle/Strategy | Core Idea | Engineering Example | Typical Applicable Scenarios |
|---|---|---|---|
| Defense in depth | Deploy across layers, no reliance on a single point | Physical encryption → TLS → identity authentication → application security | High-value devices, critical infrastructure, remote operations |
| Least privilege | Only necessary privileges, fail-closed | RBAC model, sensors uplink-only, no downlink opened | Multi-tenant platforms, factory lines with complex permissions |
| Secure by default | Insecure features off at the factory | Disable Telnet/FTP, default passwords must be changed on first use | Consumer IoT devices, newcomers onboarding to a platform |
| Secure development lifecycle | Shift security left, embed across the whole process | Threat modeling, SAST/DAST, OTA signature verification | New product design, compliance certification scenarios |
| Continuous monitoring and response | Real-time detection → noise reduction → blocking → audit | Debounced alarms, state-machine tiering, automatic IP blacklists | IoT platforms with millions of messages per day, unattended data centers |
Table 8-1 Every principle has its boundary of applicability. It is rare for "every principle to be pushed to the extreme on every device" — the constraints come from cost, compute, power, and time to production. Engineers can take this table as the basis for a design review early in the project: How many layers of defense does the system deploy? Are device privileges drawn tight enough? Is the factory default configuration safe? Does the monitoring-and-response latency fit the business tolerance? Answering these questions before entering concrete implementation is far more effective than adjusting as you go.
These principles point in the same direction as industry-recognized security guidance (such as the NIST IoT security framework and the IEC 62443 series) when setting a security baseline: all of them list defense in depth, least privilege, and secure by default as the starting points. Normative clauses may differ across industries, but the underlying logic is shared: security is not a feature of a single product but a full set of strategic arrangements that must run through the system's entire lifecycle — any missing link becomes the whole system's weak point.
8.1.3 An Overview of Security Regulations and Compliance Requirements
The two preceding sections approached IoT security from threats and from principles, sketching its design boundary. But when a security plan lands, there is one more layer of external constraint — regulation. It may not tell you which encryption algorithm or authentication protocol to use, but it draws the bottom line of "what must be protected" and "to what degree." For an engineering team, understanding regulatory requirements is not just the legal department's business — it directly shapes system architecture, data flows, and time to market. A system that ignored the data-minimization principle at design time may be forced to rework its data-storage module after launch, at a cost that usually far exceeds that of building compliance in from the start.
GDPR: Centered on Personal Data
The EU's General Data Protection Regulation (GDPR) is one of the most influential regulatory systems in data privacy today. It does not target IoT specifically, yet IoT systems are precisely heavy producers of personal data: smart homes collect living habits, wearables capture physiological indicators, connected vehicles record location traces. As long as the data a device processes can identify a person directly or indirectly — face images, MAC addresses, unique device identifiers — it falls under GDPR's jurisdiction.
GDPR has several direct effects on engineering architecture. The data-minimization principle requires a system to collect only the minimum amount of data that serves an explicit purpose. If a smart-bulb vendor also collects Wi-Fi signal strength and ambient noise, users have reason to ask: what do these data have to do with "turning on the light"? User consent and the right to know require explicit authorization before collection, and users may withdraw it at any time. That means the platform must build in a consent-management module and be able to show users clearly "who collected what data, when, and why." The data-breach notification duty requires notifying the regulator within a set deadline — which in turn requires real-time audit and alarm capability: if you do not know when data left the boundary, you cannot compute where the notification deadline starts.
One of GDPR's most forceful clauses is the Right to Erasure: when a user requests deletion of their personal data, the system must thoroughly purge every copy, including fragments inside backups. This is a real engineering challenge for IoT's distributed data storage — data may sit simultaneously in device-side caches, edge nodes, cloud databases, and data warehouses, and deletion must be coordinated across layers. A poorly designed system may simply be unable to perform a complete deletion, ending up as a compliance defect. Experience across multiple projects shows that teams often defer this requirement at design time to "later optimization," only to discover at assessment that the residual data in backups cannot be cleaned out at all.
MLPS 2.0: The National Standard for IoT Security
In China, the Cybersecurity Multi-Level Protection Scheme 2.0 (MLPS 2.0) has been extended to IoT scenarios. Its core idea is to grade systems into five levels by the harm caused once they are compromised, with corresponding security requirements and assessment criteria per level. The IoT portion rests mainly on the IoT security extension requirements in GB/T 22239-2019, "Information Security Technology — Baseline for Classified Protection of Cybersecurity." MLPS 2.0 covers several IoT priorities: sensing-layer device security requires devices to carry identity marking, tamper resistance, and firmware-verification capability; network communication security requires transport encryption and access authentication, and in star topologies the aggregation node (gateway) must be prevented from being used for lateral attacks; data security concerns the confidentiality and integrity of every stage — collection, transmission, and storage — and the implementation of personal-information protection measures.
For enterprises operating IoT platforms in China, MLPS 2.0 is a mandatory gate in compliance review. Engineering teams need to check their designs against each security level's requirements at design time, not cram before the assessment — the rework cost of the latter usually rises exponentially. Note that MLPS grading of IoT often hits boundary questions in real assessments: if a device connects to both the cloud and a local management platform, which system governs its security level? Architects need to align these judgments with the assessment body early.
Industry-Specific Regulations: Healthcare and Industrial
Different industries have their own regulatory frameworks. When an Internet of Medical Things system processes electronic protected health information on behalf of a HIPAA-regulated entity or its business associate, it must implement administrative, physical, and technical safeguards, including access control, audit controls, integrity protection, authentication, and transmission security. Under the current HIPAA Security Rule, encryption is an "addressable" implementation specification: an organization must assess whether it is reasonable and appropriate based on risk; if it does not adopt encryption, it must document the reason and implement an equivalent measure. The law therefore cannot simply be described as unconditionally mandating encryption for all data at rest and in transit. Industrial control systems, meanwhile, commonly use the IEC 62443 series to establish security lifecycles, zones and conduits, access control, and component security requirements. A cross-industry platform should first identify the applicable entities, data types, and jurisdictions, and only then map compliance requirements to tenant-level and system-level controls.
New EU Regulations: the CRA, the Data Act, and NIS2
Three recent pieces of EU legislation extend the regulation of IoT from data processing to the product itself, and teams delivering to the EU market need to track them separately. The Cyber Resilience Act (CRA) entered into force in December 2024; unlike GDPR, it regulates the product directly — IoT gateways, edge boxes, and platform software all fall within the scope of "products with digital elements." The timeline has two steps: from September 11, 2026, actively exploited vulnerabilities and severe incidents must be reported as required; from December 11, 2027, the full obligations take effect, with manufacturers obliged to keep providing security updates throughout the declared security support period and to maintain an SBOM alongside the product. This is the regulatory face of the same thing as the device lifecycle governance and SBOM practice in Section 8.2.4 of this chapter. The Data Act applies from September 12, 2025, giving users of connected products the right to access and share the data their use of the product generates — smart-home and connected-vehicle platforms need to provide data export and sharing interfaces for this. In addition, the member-state transposition deadline of the Network and Information Security Directive (NIS2) passed in October 2024, bringing more digital-infrastructure operators under risk-management and incident-reporting obligations.
Compliance Checklist: From Regulation to Engineering Actions
Regulatory clauses are dense; landing them in engineering needs a checklist verified item by item. The table below consolidates the common requirements of GDPR, MLPS 2.0, and the industry regulations, giving architects and developers a starting point for a compliance self-review at design time — it does not replace professional legal assessment, but it helps the team map abstract clauses into executable engineering checks.
Table 8-2 Compliance checklist
| Security Domain | Check Item | Corresponding Regulation |
|---|---|---|
| Device security | Devices carry unique identity marking and support firmware signature verification and secure boot | MLPS 2.0, IEC 62443 |
| Communication security | Transport channels use encrypted protocols, complete mutual authentication, and carry anti-replay mechanisms | MLPS 2.0, HIPAA |
| Data security | Personal-data collection scope is defined, and a real-time deletion mechanism (Right to Erasure) is designed in | GDPR, MLPS 2.0 |
| Identity and access control | Deny-by-default policy, role-based fine-grained permission management, audit-log support | MLPS 2.0, IEC 62443 |
| Operations and audit | Real-time data-leak detection and alarm capability, meeting the notification deadlines set by regulation | GDPR, MLPS 2.0 |
This checklist is not a complete physical-exam tool, but it exposes the set of questions an engineering team must answer at design time: What personal data does the system store? Can it be thoroughly deleted when necessary? Is sensitive data encrypted in transit and at rest? Who may access which data — and is that permission allow-by-default or deny-by-default? Waiting until the product is live to answer these questions costs far more than writing them into the architecture document at design time.
Regulatory compliance is not a bonus point — it is a prerequisite for market entry. More important, good security design tends to sit naturally close to compliance requirements: encryption, audit, and least privilege, as engineering elements, all find matching clauses in the regulatory frameworks. The next section starts from device identity and puts these engineering practices in place layer by layer.
8.1.4 NIST AI RMF: Bringing Agent Risk into the Governance Loop
Traditional security controls usually start from vulnerabilities, identities, and network boundaries, but agent risk also depends on the usage scenario, tool privileges, degree of autonomy, and physical consequences. The same model used to generate weekly reports and used to submit device commands carry entirely different risk levels. The NIST AI Risk Management Framework (AI RMF 1.0) organizes AI risk management with four functions — GOVERN, MAP, MEASURE, and MANAGE; GOVERN runs through the other functions and is well suited to connecting scattered controls into a continuous governance loop (NIST AI RMF). AI RMF is a voluntary risk-management framework and should not be written up as a mandatory regulation or a product certification.
GOVERN: First Make Clear Who May Decide How Much the System Delegates
The governance layer establishes accountability, policy, and evidence requirements. The organization should maintain an AI asset inventory recording models, prompts, RAG indexes, tools, permission policies, evaluation sets, and vendor versions; assign, for each scenario, a business owner, a security owner, a release approver, and an incident responder; and define autonomy levels such as read-only, advisory, constrained execution, and automation-prohibited.
Prohibited scenarios should be written down clearly before development, for example: the LLM does not enter PLC/SIS real-time safety loops directly, does not approve irreversible actions on its own, and does not call business tools when tenant identity is missing. Model or vendor changes should also go through change management — the same model ID cannot be treated as behavior frozen forever.
MAP: Put the Abstract Model Back into Real Physical Scenarios
MAP's goal is to understand the system's context, stakeholders, impacts, and risk sources. An AIoT scenario must at least map:
- whether input data comes from users, RAG, devices, or third-party systems;
- which tenants, devices, and historical data the agent can see;
- whether tools are queries, business mutations, device control, or irreversible operations;
- whether actions can be rolled back, and whether failure causes data errors, downtime, or human risk;
- which steps require human or external policy approval;
- which people, devices, production lines, and organizations are affected;
- how the system degrades under network loss, model timeout, stale data, and missing receipts.
Risk cannot be scored on model capability alone. A read-only question-answering assistant of mediocre accuracy may be safer than an agent that answers more accurately but holds general-purpose HTTP/SQL tools.
MEASURE: Turning "Trustworthy" into Checkable Evidence
MEASURE should draw on the RAG Eval and Agent Eval of Chapter 7, and add security red-teaming, bias, robustness, privacy, and explainability checks. For high-risk agents, at minimum measure: cross-tenant privilege escalation, writes without approval, out-of-range parameters, indirect prompt injection, tool timeouts, refusal accuracy, human takeover, duplicated side effects, and stop-command effectiveness.
Every metric should be tied to an evaluation set, a version, a threshold, and the raw trace. A capability that has not been measured cannot be summarized as "safe and controllable"; it should be written explicitly as unverified, experimental, or barred from production.
MANAGE: Accept, Reduce, or Reject Risk Based on Evidence
Management decides, based on measurement results, to accept, mitigate, transfer, or prohibit a risk. Common measures include shadow traffic, canary tenants, read-only tools first, external approval for high-risk actions, budget and step limits, degrading to Copilot mode, disabling a specific tool, rolling back the model/prompt/index, and triggering the kill switch.
After an incident, preserve the inputs, retrieval evidence, tool catalog, parameter summaries, permission decisions, actions, receipts, final states, and the version manifest, for post-mortem and re-assessment. Fixing one prompt does not substitute for governance; risks of the same class should be written back into the threat model and the regression set.
Table 8-3 Mapping agent risks to controls and evidence (illustrative)
| Risk | Control | Metric | Evidence | Owner |
|---|---|---|---|---|
| Cross-tenant data reads | Four-part authorization and retrieval filtering | Privilege-escalation rate = 0 | Policy logs and attack set | Platform security owner |
| High-risk writes | External approval with action confirmation | Execution-without-approval rate = 0 | Actions, receipts, and traces | Business owner |
| Stale knowledge | Version filtering and time validity | Stale-document false-hit rate | RAG Eval results | Knowledge owner |
| Model/tool changes | Version manifest and regression gate | Regression pass rate | Release records | AI release owner |
| Loops and runaway cost | Step/time/spend budgets | Over-budget rate | Traces and cost bills | Operations owner |
The four functions are not a linear one-shot process. Scenario changes call for re-MAP, version updates call for re-MEASURE, incidents and evaluation results drive MANAGE, and governance policy is then updated by GOVERN. The value of this framework lies not in claiming "adoption of some model," but in settling the correspondence among risks, controls, metrics, evidence, and owners into auditable documents and processes — when an incident happens, it can answer "who made what decision, on what evidence."