Verification, Safety, Security and Responsible AI Governance

Introduction

Intelligent control systems combine sensors, computational models, optimization, machine learning and actuators to influence physical processes. Their usefulness is accompanied by a distinctive engineering responsibility: an incorrect recommendation in software may be inconvenient, but an incorrect control action can damage equipment, injure people or destabilize an entire process. Verification, safety, security and responsible governance therefore form one integrated engineering activity rather than four independent compliance tasks.

Verification asks whether the implemented system satisfies specified requirements. Validation asks whether those requirements represent the intended operational need. Safety limits unacceptable physical harm; cybersecurity protects the system from malicious or unauthorized influence; responsible AI governance addresses transparency, accountability, privacy, fairness and human control. These concerns overlap. For example, a compromised perception model is a cybersecurity problem, an unsafe controller output is a functional-safety problem, and an unexplained automated decision may be a governance problem.

This chapter presents a lifecycle approach suitable for mechatronics engineers. It covers requirements, simulation, testing, uncertainty, formal assurance, functional safety, cybersecurity, explainability, human oversight, privacy, bias, accountability, standards and regulatory compliance.

Learning objectives

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

1. Distinguish verification, validation, testing and assurance.
2. Construct a verification strategy using simulation, software-in-the-loop, hardware-in-the-loop and physical testing.
3. Quantify uncertainty and interpret confidence and robustness measures.
4. Explain the principles of functional safety and risk reduction.
5. Identify cybersecurity threats to intelligent control systems and select appropriate controls.
6. Evaluate explainability, human oversight, privacy, bias and accountability requirements.
7. Relate engineering practice to major safety, cybersecurity, quality and AI-governance standards.
8. Develop a defensible assurance argument for an intelligent mechatronic system.

1. Assurance begins with a precise claim

A system requirement should be observable, testable and bounded by operating conditions. The statement the robot shall be safe is not verifiable. A stronger statement is: under specified payload, speed, surface and sensor conditions, the robot shall enter a safe stop within 0.25 s after detection of a protective-field violation.

Verification demonstrates conformance to specified requirements. Validation establishes that the system solves the intended problem in its real context. Testing is an evidence-producing activity, whereas assurance is the structured argument that the evidence is sufficient and credible.

A useful assurance claim has four components:

• Claim: what must be true.
• Context: operating conditions and assumptions.
• Evidence: analyses, tests, inspections, simulations or formal proofs.
• Argument: why the evidence supports the claim and what limitations remain.

This structure prevents a common error: treating a successful demonstration in one nominal scenario as proof of safe operation in all relevant scenarios.

Requirements and traceability

A verification-ready requirement normally includes an identifier, measurable behavior, operating conditions, acceptance criterion, priority, hazard or stakeholder rationale, and verification method. A traceability matrix links each requirement to design elements, tests and results.

Requirements should also define what happens when assumptions fail. An AI perception system should not merely output a class; it should specify behavior for low confidence, sensor disagreement, missing data and out-of-distribution inputs.

2. Verification across the development lifecycle

No single test method is sufficient. Verification should proceed from inexpensive, highly observable activities toward increasingly realistic activities while retaining regression tests.

Model-in-the-loop and software-in-the-loop

In model-in-the-loop testing, mathematical models of the plant and controller are evaluated together. It is useful for exploring stability, transient response, disturbances and parameter variation. Software-in-the-loop executes the actual control software against a simulated plant, exposing implementation errors such as numerical overflow, scheduling faults and data-conversion mistakes.

A simplified discrete-time plant may be represented as:

Here, x_k is the plant state at sample k, u_k is the control input, w_k is process disturbance, y_k is the measured output, v_k is measurement noise, and f and h are the state-transition and measurement functions. The model is applicable only within its stated physical assumptions, sampling interval and parameter range.

Hardware-in-the-loop and physical testing

Hardware-in-the-loop connects real controllers, sensors or communication devices to a real-time simulated plant. It enables repeatable testing of timing, saturation, network delays, sensor faults and emergency behavior without exposing expensive equipment to every fault scenario. Physical testing is still necessary because friction, wiring, electromagnetic interference, structural flexibility, thermal effects and human interaction are often incompletely represented in simulation.

A credible test programme includes:

1. nominal operating cases;
2. boundary and stress cases;
3. fault and degraded-mode cases;
4. environmental cases;
5. adversarial or cybersecurity cases;
6. recovery, restart and maintenance cases;
7. regression tests after every significant change.

Test independence is important for high-consequence systems. The person who designed a function should not be the sole person deciding that it has passed.

Performance measures

Common control measures include error, overshoot, settling time, energy use, computation time and constraint violations. For a reference r_k and output y_k, the root-mean-square error over N samples is:

The variables y_k and r_k must use the same units; RMSE has those units. The measure is meaningful only when the sampling interval, reference trajectory and treatment of transients are specified. A low average error does not prove safety because a rare, large excursion may be hidden by averaging.

For classification or perception components, accuracy should be supplemented by precision, recall, confusion matrices, calibration and performance across relevant operating groups. In a safety-related system, the cost of a false negative may be much greater than that of a false positive, so a single aggregate accuracy value is inadequate.

3. Uncertainty, robustness and statistical evidence

Intelligent systems operate with uncertain plant parameters, noisy sensors, incomplete models, changing environments and imperfect labels. Verification must therefore distinguish three questions:

• What does the model predict?
• How sensitive is that prediction to assumptions?
• How much evidence supports the prediction in the intended operating domain?

Sources of uncertainty

Aleatory uncertainty represents inherent variability, such as sensor noise or random arrival times. Epistemic uncertainty results from limited knowledge, such as uncertain friction coefficients or insufficient training data. The distinction matters because more measurements may reduce epistemic uncertainty, whereas aleatory variability may require robust design and margins.

For a measured quantity x with observations x₁,...,x_N, the sample mean and sample standard deviation are:

The denominator N−1 in s provides the usual unbiased estimate of population variance under independent, identically distributed observations with finite variance. These statistics do not establish normality, independence or representativeness; those assumptions must be examined.

A 95% confidence interval for a population mean, when observations are approximately independent and the relevant distributional assumptions are reasonable, can be written as:

The interval expresses uncertainty in the estimated mean, not a guarantee that 95% of future individual observations lie inside it. For safety-critical rare failures, ordinary confidence intervals based on a small number of successful tests are especially weak evidence.

Sensitivity and Monte Carlo analysis

Sensitivity analysis varies one or more parameters across credible ranges and observes changes in outputs. Monte Carlo analysis samples uncertain parameters repeatedly and estimates an output distribution. Results should report the input distributions, number of trials, random seed or reproducibility method, model limitations and tail behavior.

Robustness means acceptable behavior despite specified variation. It should be expressed as a bounded claim, such as: for mass between 8 and 12 kg, communication delay below 20 ms and sensor bias below 1°, the tracking error remains below the specified limit. Robustness is not the same as universal reliability.

4. Formal methods and assurance arguments

Formal verification uses mathematical techniques to establish that a model satisfies a property under explicit assumptions. Examples include invariant proofs, reachability analysis, model checking, satisfiability solving and theorem proving. Formal methods are particularly valuable for finite-state supervisory logic, interlocks, communication protocols and safety monitors.

An invariant is a property that remains true over system execution. If an initial state satisfies an invariant and every permitted transition preserves it, the property holds for all reachable states represented by the model. The conclusion applies only to the model, assumptions and implementation correspondence that have been established.

Formal methods are not a replacement for physical testing. Continuous dynamics, uncertain human behavior, complex learned models and unmodeled hardware may make exhaustive proof impractical. A practical strategy combines formal analysis for critical discrete logic with simulation, fault injection and physical testing for the remaining behavior.

A safety case can be organized as:

• top-level claim: the system is acceptably safe for the defined use;
• subclaims: hazards are identified, risks are reduced, safety functions behave correctly, and residual risks are communicated;
• evidence: hazard analyses, requirements, design reviews, test records, formal results and field monitoring;
• assumptions and weaknesses: conditions under which the argument may fail.

5. Functional safety

Functional safety concerns the ability of a system to respond correctly to hazardous conditions and failures. It is not identical to ordinary reliability. A component can be reliable yet unsafe if its failure mode produces a dangerous command; conversely, a component can fail frequently but safely if failures lead to a controlled stop.

The conventional lifecycle is:

1. define the intended function and operating environment;
2. identify hazards and hazardous events;
3. estimate risk;
4. specify safety functions;
5. allocate safety integrity targets;
6. implement independent or sufficiently separated safeguards;
7. verify, validate and maintain the safety lifecycle.

Risk is commonly considered through the combination of severity, exposure and possibility of avoiding harm. Qualitative risk graphs are often used in industry, but their categories must be defined consistently. A risk matrix is a decision aid, not a physical law or a substitute for engineering judgment.

Typical safety functions include emergency stop, protective separation monitoring, speed and torque limitation, safe direction control, safe brake control, watchdog supervision and transition to a defined safe state. The safe state depends on the machine: removing torque may be appropriate for a collaborative robot, while controlled braking may be necessary for a high-speed axis.

Important design principles include:

• fail-safe behavior where practical;
• independent monitoring of critical commands;
• diagnostic coverage and proof testing;
• redundancy or diversity for common-cause failure control;
• separation between non-safety AI and a deterministic safety layer;
• controlled reset that prevents unexpected restart;
• protection against systematic design errors.

Relevant standards include IEC 61508 for functional safety of electrical, electronic and programmable electronic systems; ISO 12100 for machinery risk assessment and risk reduction; and ISO 13849 for safety-related parts of control systems. Application-specific standards may impose additional requirements. The applicable edition, jurisdiction and sector must always be confirmed.

6. Cybersecurity of intelligent control systems

A mechatronic controller has a cyber-physical attack surface: sensors, actuators, engineering workstations, firmware, wireless links, cloud services, maintenance ports and supply-chain components. The consequences of compromise include unsafe motion, denial of service, intellectual-property loss, privacy breaches and falsified evidence.

Threat analysis should identify assets, actors, attack paths, vulnerabilities, consequences and mitigations. A useful approach combines a system data-flow diagram with threat modelling and hazard analysis. Security objectives commonly include confidentiality, integrity, availability, authenticity, accountability and resilience. In industrial control, integrity and availability often have immediate safety significance.

Controls should be layered:

• secure boot and signed firmware;
• strong identity and least privilege;
• network segmentation and controlled remote access;
• authenticated and integrity-protected communications;
• patch and vulnerability management;
• logging, time synchronization and anomaly detection;
• backups and tested recovery procedures;
• supplier assurance and component provenance;
• incident response and coordinated disclosure.

Security must not undermine safety. For example, a security update that unexpectedly changes timing or a denial-of-service response that removes braking power may create a new hazard. Safety and security engineers should therefore review shared failure scenarios.

IEC 62443 provides a family of industrial automation and control-system cybersecurity standards. ISO/IEC 27001 supports an information-security management system, while the NIST Cybersecurity Framework and NIST AI Risk Management Framework provide widely used risk-management structures. These frameworks guide practice; they do not automatically certify a particular controller as safe or secure.

7. Responsible AI governance

When machine learning influences sensing, diagnosis, planning or control, governance must address both model behavior and the surrounding sociotechnical system.

Explainability and interpretability

Interpretability is the degree to which a model’s operation can be understood. Explainability concerns communicating reasons for a particular output. A feature-importance plot may be useful for debugging but is not necessarily a faithful causal explanation. Post-hoc explanations can be unstable, incomplete or misleading.

The appropriate explanation depends on the stakeholder. An operator may need a confidence indication, detected object, operating limit and recommended action. A maintainer may need sensor traces and model version. An auditor may need training-data provenance, test results, approval records and change history. Explanations should support decisions rather than create a false impression of certainty.

Human oversight

Human oversight is meaningful only when the person has sufficient authority, time, information, competence and a feasible intervention mechanism. A nominal override that is too slow to prevent harm is not effective oversight. Automation bias may cause operators to accept an AI recommendation even when contrary evidence is visible; training, interface design, escalation rules and workload management are therefore safety controls.

Oversight modes include human-in-the-loop approval, human-on-the-loop supervision and human-out-of-the-loop operation. The last mode may be acceptable only when the system has demonstrated adequate autonomy, bounded operating conditions, independent safeguards and a defined fallback.

Privacy and data governance

Sensors in intelligent machines may collect faces, voices, locations, biometric characteristics, work patterns or proprietary process data. Data governance should specify purpose, minimization, lawful basis where applicable, retention, access, encryption, de-identification, deletion and cross-border transfer controls. De-identification reduces risk but does not guarantee anonymity.

Training data should be documented by source, consent or authorization status, collection conditions, labels, preprocessing, known gaps and permitted uses. Data collected for one operational purpose should not automatically be reused for unrelated profiling.

Bias and performance disparity

Bias may enter through sampling, labels, measurement devices, deployment context or the objective function. A model may have equal aggregate accuracy while failing disproportionately for a particular lighting condition, skin tone, body size, language group or operating shift. Engineers should evaluate relevant subgroups and intersectional cases, but subgroup comparisons require adequate sample sizes and technically justified metrics.

Fairness is context-dependent. In an industrial controller, the principal concern may be unequal exposure to unsafe false negatives among worker groups. In a personnel-monitoring application, privacy and discrimination concerns may dominate. There is no single fairness metric that resolves every trade-off.

Accountability and governance controls

Accountability requires named responsibility, not merely an abstract statement that an algorithm made the decision. A governance record should identify the system owner, safety authority, security authority, data steward, approval authority, operator responsibilities and escalation route.

Useful controls include model cards or system cards, data sheets, version control, change-impact assessment, independent review, audit logs, incident reporting, post-deployment monitoring and a documented decommissioning plan. Every operational output should be attributable to the model version, configuration, input conditions and human actions that produced it.

Regulatory requirements differ by jurisdiction and application. The European Union AI Act uses a risk-based framework with obligations that depend on the system and use case; other jurisdictions use sectoral product-safety, privacy, employment, medical-device or critical-infrastructure rules. Engineers must consult current legal sources and competent authorities rather than treating a general AI framework as legal advice.

8. Integrated assurance workflow

A practical workflow for an intelligent control project is:

1. Define intended use, prohibited use, operating domain and stakeholders.
2. Capture functional, performance, safety, security, privacy and governance requirements.
3. Perform hazard analysis and threat modelling together where cyber events can cause physical harm.
4. Allocate functions between learned components, deterministic control and independent safety mechanisms.
5. Establish data, model, software and hardware configuration control.
6. Verify components using analysis, simulation, static checks and unit tests.
7. Verify integrated behavior using software-in-the-loop and hardware-in-the-loop.
8. Conduct fault injection, adversarial testing, environmental testing and physical validation.
9. Review uncertainty, edge cases, subgroup performance and residual risk.
10. Compile the safety and assurance case, including limitations and assumptions.
11. Deploy with monitoring, operator training, incident response and rollback capability.
12. Reassess after software, data, environment, supplier or regulatory changes.

The workflow is iterative. A field incident may reveal an omitted hazard, invalid model assumption or inadequate human interface, requiring changes to requirements and evidence rather than only a software patch.

9. Illustrative case: autonomous mobile robot in a warehouse

Background

Consider an illustrative autonomous mobile robot that transports containers among warehouse stations. It uses lidar and cameras for perception, a learned planner for route selection and a conventional motor controller for wheel speed. Workers and manually operated vehicles share parts of the environment.

Problem

The project team reports excellent average navigation performance in simulation. However, the robot occasionally misclassifies a reflective plastic sheet and continues moving toward a pedestrian-accessible area. A wireless diagnostic service also uses a default password. The system has no documented model version in its event log.

Analysis

The perception failure is a safety concern because a false negative may delay protective action. It is also a verification gap: the simulation environment did not represent reflective surfaces. The default password creates a cybersecurity vulnerability that could lead to unauthorized motion. Missing model provenance prevents reliable incident reconstruction and weakens accountability.

Approach and solution

The team defines a safety requirement that an independent protective field, not dependent solely on the learned classifier, shall command a stop when a person or obstacle enters the specified zone. The protective function is tested using calibrated targets, lighting variation and sensor occlusion. The planner is constrained to a validated operating domain and must transition to a low-speed or stopped state when confidence, sensor agreement or localization quality falls below threshold.

The diagnostic service receives unique credentials, role-based access, encrypted authenticated communication and network segmentation. Firmware is signed, logs include time, controller state, sensor-health indicators, model identifier and operator intervention, and logs are protected against unauthorized alteration. Hardware-in-the-loop tests inject packet loss, stale sensor data and delayed commands. Physical trials include reflective materials, unusual clothing, partial occlusion and mixed human–vehicle traffic.

Outcome

The robot retains efficient autonomous travel in the validated domain, while independent protective sensing handles the highest-consequence obstacle cases. The project does not claim that the learned model is infallible. Instead, it demonstrates bounded performance, defined degraded modes, traceable evidence and recoverable failure behavior.

Learning points

The case illustrates four principles: safety should not depend on a single learned component; cybersecurity events can become physical hazards; simulation validity depends on scenario coverage; and auditability is part of engineering quality rather than an administrative afterthought.

10. Challenges and limitations

Assurance of intelligent control is difficult because models may change with data, operating environments are open-ended and rare hazardous events are hard to observe. Simulation can create unwarranted confidence when its assumptions are undocumented. Formal verification may prove the wrong abstraction. Statistical testing cannot establish zero probability of failure. Explainability tools may rationalize rather than reveal model behavior. Standards can provide disciplined processes but cannot substitute for competent engineering or eliminate residual risk.

Another challenge is responsibility across supply chains. A system integrator may not control the training data, pretrained model, processor firmware or cloud service on which the system depends. Contracts should specify evidence, vulnerability notification, change control, support lifetime and access to relevant documentation.

Finally, governance must remain proportionate. Excessive documentation can obscure critical risks, while insufficient documentation makes decisions unauditable. The appropriate level of assurance depends on severity, exposure, autonomy, reversibility, affected people, uncertainty and regulatory context.

Best-practice checklist

Before deployment, confirm that:

• intended use, limitations and prohibited uses are documented;
• requirements are measurable and traceable to evidence;
• hazards, cyber threats, privacy risks and human factors are assessed;
• independent safety mechanisms do not rely solely on the AI model;
• uncertainty, edge cases and degraded modes are tested;
• model, software, hardware and data versions are controlled;
• access control, secure updates, logging and recovery are operational;
• operators can understand, challenge and override the system where required;
• residual risks and assumptions are communicated;
• post-deployment monitoring, incident response and change review are funded;
• applicable standards and current legal requirements have been checked.

Chapter Summary

Verification and validation are distinct but complementary activities: verification checks conformance to requirements, while validation checks fitness for intended use. Intelligent control systems require layered evidence from analysis, simulation, software-in-the-loop, hardware-in-the-loop, fault injection, physical testing and, where suitable, formal methods. Performance metrics must be interpreted with their assumptions, uncertainty and operating domain.

Functional safety uses hazard analysis, safety functions, independent safeguards, diagnostics, controlled transitions and lifecycle evidence to reduce physical risk. Cybersecurity protects the integrity, availability, authenticity and resilience of cyber-physical functions through defence in depth. Responsible AI governance adds explainability appropriate to stakeholders, meaningful human oversight, privacy and data stewardship, bias assessment, accountability, configuration control and post-deployment monitoring.

Standards such as IEC 61508, ISO 12100, ISO 13849, IEC 62443, ISO/IEC 27001 and AI risk-management frameworks provide useful structures, but they do not replace engineering judgment. The strongest assurance argument is bounded, traceable and honest about assumptions, residual risks and limitations.

Key Terms

Verification: Demonstrating that specified requirements have been satisfied.

Validation: Demonstrating that a system is fit for its intended operational purpose.

Assurance case: A structured claim, argument and evidence showing that a system is acceptably safe or trustworthy.

Traceability: The linkage among requirements, design elements, tests, results and changes.

Hardware-in-the-loop: Testing real hardware against a real-time simulated plant.

Robustness: Acceptable performance despite specified variations and disturbances.

Aleatory uncertainty: Inherent variability in processes or measurements.

Epistemic uncertainty: Uncertainty caused by limited knowledge or incomplete models.

Functional safety: Safety achieved through correct response to hazardous conditions and failures.

Safety function: A function intended to reduce or control risk.

Fail-safe: A design tendency toward a safe state after particular failures.

Threat modelling: Structured identification of assets, threats, vulnerabilities and mitigations.

Defence in depth: Multiple independent or complementary protective layers.

Explainability: Communication of reasons or factors associated with a model output.

Human oversight: Human ability and authority to supervise, intervene or override automation.

Data minimization: Collecting and retaining no more personal data than necessary.

Bias: Systematic distortion that can produce unequal or inaccurate outcomes.

Residual risk: Risk remaining after safeguards are applied.

Configuration control: Managed identification and approval of system versions and changes.

Degraded mode: A defined operating state used when normal functionality is unavailable or unreliable.

Review Questions

Short Answer Questions

1. Distinguish verification from validation and give one example of each.
2. Why is hardware-in-the-loop testing useful for intelligent controllers?
3. Differentiate aleatory and epistemic uncertainty.
4. Why should a safety function not depend solely on a learned perception model?
5. Name four controls that can improve cybersecurity in an industrial control system.

Long Answer Questions

1. Explain how a traceability matrix supports the assurance of an intelligent mechatronic system.
2. Discuss the relationship among hazard analysis, threat modelling and functional safety.
3. Describe a lifecycle verification strategy from model-in-the-loop testing through physical validation.
4. Explain why explainability, human oversight and accountability must be designed together.
5. Compare the contributions and limitations of simulation, statistical testing and formal verification.

Analytical / Application Questions

1. Design a verification and safety strategy for a collaborative robot whose vision model detects human presence. State requirements, degraded modes, tests, independent safeguards and evidence.
2. A controller has a low average tracking error but occasional large excursions when network delay increases. Analyse why RMSE alone is insufficient and propose additional robustness tests and acceptance criteria.
3. A factory connects an intelligent controller to a cloud diagnostic service. Identify at least five cyber-physical risks and develop a layered mitigation and incident-response plan.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes verification from validation?

A. Verification checks whether requirements are satisfied; validation checks whether the system serves its intended purpose.

B. Verification is performed only after deployment; validation is performed only in simulation.

C. Verification concerns cybersecurity; validation concerns privacy.

D. Verification proves zero failures; validation proves zero uncertainty.

Correct Answer: A. Verification checks whether requirements are satisfied; validation checks whether the system serves its intended purpose.

Question 2

In the discrete-time equation x_k+1 = f(x_k,u_k,w_k), what does w_k usually represent?

A. The measured output

B. A process disturbance

C. The control input

D. The reference trajectory

Correct Answer: B. A process disturbance

Question 3

What is a principal limitation of a low average RMSE?

A. It cannot be calculated from sampled data.

B. It always has units of squared error.

C. It can conceal rare but dangerous large deviations.

D. It is valid only for classification models.

Correct Answer: C. It can conceal rare but dangerous large deviations.

Question 4

Which feature most directly supports meaningful human oversight?

A. Removing all operator intervention mechanisms

B. Providing authority, time, information and a feasible intervention method

C. Allowing operators to view only the final actuator command

D. Increasing model complexity without changing the interface

Correct Answer: B. Providing authority, time, information and a feasible intervention method

Question 5

Which standard is primarily associated with functional safety of electrical, electronic and programmable electronic systems?

A. IEC 61508

B. IEC 62443

C. ISO/IEC 27001

D. ISO 9001

Correct Answer: A. IEC 61508

Question 6

Why is secure logging important in an intelligent control system?

A. It guarantees that the model is unbiased.

B. It replaces physical safety testing.

C. It supports accountability, incident reconstruction and detection of unauthorized activity.

D. It eliminates the need for access control.

Correct Answer: C. It supports accountability, incident reconstruction and detection of unauthorized activity.

Question 7

Which statement about epistemic uncertainty is correct?

A. It represents inherent random variability that cannot be reduced by knowledge.

B. It results from limited knowledge and may be reduced through better data or modelling.

C. It is identical to measurement units.

D. It proves that a model is invalid.

Correct Answer: B. It results from limited knowledge and may be reduced through better data or modelling.

Question 8

What is the main purpose of an independent safety layer around an AI planner?

A. To ensure the planner never requires training data

B. To prevent the planner from selecting any efficient route

C. To provide bounded protective behavior even if the learned component fails

D. To make cybersecurity controls unnecessary

Correct Answer: C. To provide bounded protective behavior even if the learned component fails

Question 9

Which practice best supports model accountability?

A. Changing the model without recording the change

B. Recording model version, configuration, inputs and relevant human actions

C. Deleting all operational logs immediately

D. Using one aggregate accuracy value without context

Correct Answer: B. Recording model version, configuration, inputs and relevant human actions

Question 10

What does defence in depth mean in cybersecurity?

A. Using one extremely complex password

B. Relying exclusively on encryption

C. Deploying multiple complementary protective layers

D. Disconnecting every sensor from the controller

Correct Answer: C. Deploying multiple complementary protective layers