Chapter 9. Risk, Security, Governance and Regulation — Part 2 of 3
9.14 Fault Tree Analysis
Fault Tree Analysis begins with an undesirable event and works backward to identify combinations of conditions that could cause it. It is a deductive risk-analysis technique because the analysis begins with a defined top event and progressively asks what conditions, failures, or combinations of events could lead to that event. Whereas Failure Mode and Effects Analysis generally begins with individual components or processes and examines how they might fail, Fault Tree Analysis begins with a significant undesirable outcome and works backward toward its possible causes. The two approaches can therefore complement one another within a multidimensional technology evaluation framework.
CONCEPTUAL FRAMEWORK
System Compromise: Contributing Factors
| SYSTEM COMPROMISE ↓ Unauthorized Access ↓ Credential Theft ↓ Weak Authentication | SYSTEM COMPROMISE ↓ Software Vulnerability ↓ Delayed Patching ↓ Inadequate Maintenance |
|---|
Figure: Conceptual pathways leading to system compromise
These simplified examples illustrate an important characteristic of Fault Tree Analysis: a major event may have more than one pathway. A system compromise may occur because unauthorized access is obtained through stolen credentials, but it may also occur because an unpatched vulnerability is exploited. In a more complex analysis, several pathways may operate simultaneously or interact with one another.
Fault Tree Analysis uses logical relationships to show how different events combine to produce the top event. The logical relationship may be represented through an OR relationship, in which any one of several conditions can produce the undesirable event, or through an AND relationship, in which several conditions must occur together before the event can take place. This distinction is important because it changes the nature of the risk. If a critical system can be compromised through any one of several independent weaknesses, the organization may need to address each pathway. If an event requires several conditions to occur simultaneously, the risk-management strategy may focus on maintaining controls that interrupt one or more of those conditions.
For example, suppose an automated industrial system experiences an unauthorized command. The top event may be “unauthorized system command.” The possible pathways could include compromised credentials, exploitation of a software vulnerability, malicious insider activity, or compromise of a connected third-party system. Each of these pathways can then be decomposed further. Compromised credentials could result from phishing, password reuse, credential theft, or inadequate authentication. A software vulnerability could result from an unpatched application, insecure configuration, unsupported software, or inadequate vulnerability testing.
The analysis can continue until the evaluator reaches events that are sufficiently specific to be assessed or controlled. The purpose is not to produce the largest possible diagram but to create a logical representation of the pathways that could lead to the defined top event. Excessive complexity can make an analysis difficult to understand and maintain, while excessive simplification can conceal important dependencies.
Fault Tree Analysis is particularly useful when evaluators need to understand how multiple failures can combine to produce a major event. This is important because serious technology incidents are not always caused by one isolated failure. A major incident may result from the interaction of several individually manageable weaknesses. For example, inadequate authentication may not produce a serious incident on its own if network segmentation is strong. A vulnerable application may not produce a serious incident if patching is timely. A stolen credential may not produce significant damage if privileged access is tightly controlled. However, when several weaknesses coexist, the combined risk may become considerably greater.
This characteristic makes Fault Tree Analysis useful for cybersecurity, safety-critical systems, financial infrastructure, healthcare technology, industrial automation, transportation systems, energy systems, telecommunications, and other environments in which failures can have significant consequences. It can also be applied to artificial intelligence systems where undesirable outcomes may arise from combinations of poor data quality, model limitations, inappropriate configuration, inadequate human oversight, and system integration problems.
In an AI-enabled decision-support system, for example, the top event could be “materially incorrect automated recommendation.” The pathways might include inappropriate training data, model degradation, data drift, incorrect system configuration, an integration error, or inappropriate use outside the validated operating context. These pathways can themselves be decomposed. Data drift could result from changes in the population, market conditions, operating environment, or data-generation process. Configuration errors could arise from software updates, incorrect parameter settings, or insufficient testing after system modification.
Fault Tree Analysis can also help distinguish between initiating events and enabling conditions. An initiating event may directly begin a chain of events, whereas an enabling condition may allow the initiating event to produce a more serious consequence. For example, a stolen password may be an initiating event, while excessive user privileges may be an enabling condition that allows the attacker to access critical systems. Similarly, a component failure may initiate a disruption, while the absence of redundancy may allow that disruption to become a major operational event.
This distinction is important for technology evaluation because risk controls can operate at different points in the causal chain. Controls may prevent the initiating event, reduce the likelihood of an enabling condition, interrupt the sequence after an initiating event, or reduce the consequences of the final event. Consequently, Fault Tree Analysis provides a useful bridge between causal analysis and control design.
Where reliable quantitative information is available, Fault Tree Analysis can also support probability analysis. Probabilities can potentially be assigned to basic events and then combined according to the logical structure of the fault tree. However, quantitative results should be treated cautiously when data are limited. Emerging technologies frequently lack sufficient historical information to estimate failure probabilities with precision. In such circumstances, qualitative analysis may be more appropriate than assigning artificial numerical precision to uncertain estimates.
The analysis should also identify assumptions. If the evaluator assumes that two failures are independent, that assumption may materially affect the result. In real technology systems, failures may not be independent. A common software supplier, shared cloud provider, common power source, common network, or common maintenance team may create dependencies between events. A cybersecurity incident may simultaneously affect multiple systems. A natural disaster may disrupt electricity, communications, transportation, and supply chains at the same time. Therefore, independence assumptions should be examined rather than accepted automatically.
Fault Tree Analysis can also identify common-cause failures. A common-cause failure occurs when several apparently independent components or controls are affected by the same underlying cause. For example, two backup systems may appear to provide redundancy, but if both depend on the same power supply, network, software library, or physical location, a single event may disable both. The presence of multiple components does not necessarily guarantee resilience. FTA can help reveal such hidden dependencies.
Another important application is the evaluation of control effectiveness. A fault tree may show that several preventive controls exist, but it may also reveal that those controls depend upon the same underlying assumption or resource. If all controls depend upon one monitoring system, failure of that monitoring system may remove several layers of protection simultaneously. Consequently, technology evaluation should consider not only the number of controls but also their independence, reliability, coverage, and ability to function under adverse conditions.
Fault Tree Analysis can therefore contribute to a deeper understanding of systemic technology risk. It moves the evaluation beyond the question of whether a component can fail and toward the question of how multiple conditions may combine to produce a major event. This is especially important in interconnected technologies in which local failures can propagate across organizational and technological boundaries.
The general logic of Fault Tree Analysis can be represented as:
Top undesirable event → intermediate events → initiating events → basic causes.
The evaluator can then examine:
Cause → control → residual pathway → consequence.
This approach helps identify where additional controls may interrupt the causal chain. It also provides a useful foundation for scenario testing, resilience planning, incident response, and risk communication.
9.15 Bow-Tie Analysis
Bow-Tie Analysis integrates causes, preventive controls, the central adverse event and consequences. It combines elements of cause-based and consequence-based risk analysis and provides a visual representation of how threats can lead to a critical event and how mitigation measures can limit the consequences after that event occurs.
Its structure can be represented as:
Threats → Preventive Controls → Critical Event → Mitigation Controls → Consequences
The central event represents the point at which control over the hazardous or undesirable situation is lost. The left side of the bow-tie focuses primarily on prevention, while the right side focuses primarily on mitigation. This makes the method particularly useful for understanding the relationship between causes, barriers, consequences, and recovery.
For example, in a technology-dependent industrial process, a critical event might be the loss of control over an automated process. Threats could include sensor malfunction, incorrect software configuration, unauthorized access, operator error, communication failure, or power instability. Preventive controls could include system validation, access controls, redundancy, automated diagnostics, operator training, configuration management, and preventive maintenance. Once the critical event occurs, mitigation controls might include emergency shutdown mechanisms, alarms, manual override, backup systems, isolation procedures, and incident-response processes. The consequences could include production interruption, equipment damage, financial loss, environmental harm, or safety consequences.
Bow-Tie Analysis is valuable because it makes the concept of barriers explicit. A technology may contain several preventive barriers intended to stop a threat from reaching the critical event. It may also contain several mitigation barriers intended to reduce the consequences if prevention fails. This reflects an important principle of risk management: no single control should necessarily be assumed to be completely reliable.
The left side of the bow-tie asks why the critical event might occur. The right side asks what could happen if it does occur and what can be done to limit the consequences. Consequently, Bow-Tie Analysis can connect risk identification with control design and emergency preparedness.
Preventive controls may be technical, organizational, procedural, human, contractual, or governance-related. A technical control might involve encryption, redundancy, automated validation, or a safety interlock. An organizational control might involve segregation of duties or approval procedures. A procedural control might require periodic testing or maintenance. A human control might involve independent review. A contractual control might establish security requirements for a supplier. A governance control might require senior authorization for high-risk technology deployment.
Mitigation controls operate after the central event or during the development of its consequences. They may include containment, isolation, backup systems, emergency procedures, manual intervention, fail-safe mechanisms, communication procedures, disaster recovery, business continuity, and stakeholder notification. The objective is not necessarily to prevent the central event once it has occurred, but to prevent the event from developing into more serious consequences.
This distinction is particularly important in safety-critical and high-consequence technologies. It may not be realistic to assume that every failure can be prevented. Therefore, a robust system should also be designed to limit harm when preventive barriers fail. This is closely connected to resilience because resilience requires the capacity to absorb disruption and recover from it.
Bow-Tie Analysis can also identify barrier weaknesses. A barrier may exist formally but be ineffective in practice. For example, an organization may have a cybersecurity policy but lack effective monitoring. It may have backup procedures but never test whether restoration actually works. It may have an emergency shutdown function but fail to maintain the relevant equipment. It may have human review requirements but provide insufficient staffing for meaningful review. The existence of a control should therefore not automatically be interpreted as evidence that the risk is adequately controlled.
The analysis should consider barrier effectiveness, independence, reliability, availability, testability, and maintainability. A control that depends on the same infrastructure as the system it is intended to protect may fail simultaneously with that system. Similarly, a control that requires a human response within a few seconds may not be effective if personnel are unavailable or insufficiently trained.
Bow-Tie Analysis is also useful for communicating risk to decision-makers who may not be specialists in technical risk analysis. A complex risk can be represented through a relatively understandable causal structure: threats on one side, controls around the critical event, and consequences on the other side. This can help managers understand why particular controls are necessary and what could happen if those controls are absent or ineffective.
Within a multidimensional technology evaluation framework, Bow-Tie Analysis can connect technical risk with legal, environmental, financial, human, social, reputational, cybersecurity, and systemic consequences. A single technical event may produce consequences across several dimensions. For example, failure of an automated industrial control system could result not only in equipment damage but also in environmental releases, employee safety concerns, regulatory consequences, production losses, customer disruption, and reputational effects.
The method therefore reinforces the principle that technology risk should be evaluated according to both the probability of failure and the consequences that may follow. It also highlights the importance of multiple layers of protection rather than reliance upon a single safeguard.
9.16 Scenario Analysis
Scenario analysis is especially valuable when historical data are limited.
A technology evaluation can construct:
best-case scenarios;
expected-case scenarios;
adverse scenarios;
extreme scenarios; and
deliberately challenging "stress test" scenarios.
Scenario analysis does not predict the future with certainty. Instead, it helps decision-makers understand how a technology might behave under different conditions.
The value of scenario analysis becomes particularly significant when evaluating emerging technologies because historical evidence may be incomplete or unavailable. A technology may be new, deployed at a scale that has not previously been experienced, integrated into an unfamiliar environment, or dependent upon rapidly changing infrastructure. In such circumstances, relying exclusively on historical averages may provide an incomplete picture of future risk.
A scenario is a structured description of a plausible set of future conditions. It should not be confused with a forecast. A forecast attempts to estimate what is likely to occur, whereas scenario analysis explores what could occur under specified assumptions. Several scenarios can therefore be examined without claiming that one of them will necessarily happen.
The best-case scenario can be used to examine conditions under which the technology performs successfully and produces the intended benefits. The expected-case scenario can represent conditions considered reasonably plausible based on available evidence and assumptions. The adverse scenario can introduce disruptions, underperformance, resource constraints, unexpected user behaviour, or other difficulties. The extreme scenario can explore conditions in which several adverse factors occur simultaneously. Stress-test scenarios deliberately place the technology under demanding conditions to examine its limits.
For example, an organization introducing an AI-supported decision system might develop scenarios involving stable data quality, moderate growth in usage, normal infrastructure availability, and effective human oversight. An adverse scenario might involve rapid growth in users, declining data quality, increased system complexity, and staff shortages. An extreme scenario might combine a cybersecurity incident, network disruption, unreliable data, supplier interruption, and a sudden increase in demand. The purpose is to understand how the technology and organization respond under each condition.
Scenario analysis should consider both internal and external variables. Internal variables may include system capacity, staffing, maintenance quality, data quality, software configuration, training, and organizational processes. External variables may include energy prices, regulatory changes, supply-chain disruption, environmental conditions, geopolitical events, technological developments, market changes, user behaviour, and infrastructure availability.
The method is especially valuable for evaluating interdependencies. A technology may perform effectively when its supporting systems are functioning normally but become vulnerable when several external systems are simultaneously disrupted. For example, a digital service may depend upon electricity, telecommunications, cloud infrastructure, payment systems, identity services, and third-party software. A scenario involving the simultaneous disruption of several dependencies can reveal vulnerabilities that would not become visible when each dependency is assessed independently.
Scenario analysis can also be used to examine scale. A technology that performs well in a pilot project may experience different risks when deployed to thousands or millions of users. Increased scale may create higher data volumes, increased infrastructure requirements, more complex maintenance, greater cybersecurity exposure, larger environmental demands, and more significant consequences from failure. Therefore, scenario analysis should distinguish between pilot-scale, organizational-scale, national-scale, and potentially global-scale deployment where relevant.
Time should also be incorporated into scenario development. Some technologies create risks that become visible only after prolonged use. Software systems may accumulate technical debt. Components may become obsolete. Data distributions may change. Maintenance requirements may increase. Users may develop new patterns of reliance. Suppliers may discontinue products. Environmental conditions may change. Regulatory requirements may evolve. Scenario analysis can therefore examine short-term, medium-term, and long-term conditions.
Scenario analysis can also be connected to lifecycle thinking. A technology may have different risk characteristics during design, testing, deployment, operation, maintenance, upgrading, replacement, and disposal. For example, supply-chain risks may be particularly important during manufacturing, cybersecurity risks may become particularly significant during operation, and data migration risks may become important during replacement. A lifecycle scenario approach can therefore provide a more complete assessment than a single point-in-time evaluation.
Another important use is stress testing. A stress test deliberately applies severe but plausible conditions to determine whether the technology and its supporting organization can continue to perform essential functions. Stress testing does not necessarily require the actual occurrence of the adverse condition. Simulated or tabletop exercises can be used to examine response capacity. The results can reveal gaps in staffing, communication, backup systems, decision authority, recovery procedures, and technical resilience.
Scenario analysis should clearly distinguish between assumptions and evidence. For example, an evaluator may assume that demand increases by a certain amount, that a supplier becomes unavailable, or that energy availability decreases. Such assumptions should be documented rather than presented as established facts. Different assumptions can then be tested to determine whether the evaluation is sensitive to particular conditions.
Sensitivity analysis can complement scenario analysis by examining which variables have the greatest influence on outcomes. If small changes in one variable produce substantial changes in risk, that variable may require closer monitoring. If a technology remains relatively stable across a wide range of assumptions, the risk assessment may be more robust to uncertainty.
Scenario analysis can also support decision thresholds. An organization may define conditions under which deployment can proceed, conditions requiring additional controls, and conditions requiring temporary suspension or redesign. These thresholds should be established according to the technology's intended function, potential consequences, regulatory requirements, organizational risk appetite, and stakeholder considerations.
Importantly, scenario analysis should not become a mechanism for creating unrealistic worst-case narratives. Scenarios should be plausible enough to provide meaningful decision information. At the same time, they should be sufficiently challenging to reveal vulnerabilities. The objective is structured exploration of uncertainty rather than either excessive optimism or unsupported alarm.
Scenario analysis therefore strengthens technology evaluation by asking not only whether the technology works under normal conditions, but also how it behaves when conditions change. It encourages evaluators to examine uncertainty, dependencies, scale, disruption, adaptation, recovery, and long-term consequences.
A useful scenario-analysis sequence is:
Define technology and objective → identify critical assumptions → identify uncertain variables → construct plausible scenarios → assess performance and risk under each scenario → identify vulnerabilities → evaluate controls → examine resilience and recovery → identify monitoring indicators → revise scenarios as evidence changes.
The results can then be incorporated into technology governance and continuous monitoring. As real-world evidence becomes available, assumptions can be compared with observed conditions. Scenarios can be updated, new scenarios can be introduced, and controls can be modified. In this way, scenario analysis becomes part of an adaptive technology evaluation process rather than a one-time planning exercise.
9.17 Cybersecurity Evaluation
Cybersecurity evaluation should examine:
identity management;
authentication;
authorization;
encryption;
network security;
vulnerability management;
logging;
incident detection;
incident response;
backup and recovery;
third-party risk;
supply-chain security; and
organizational governance.
NIST CSF 2.0 provides a useful structure for organizing cybersecurity outcomes, while ISO/IEC 27001 provides a management-system approach to information security (International Organization for Standardization & International Electrotechnical Commission [ISO/IEC], 2022; Pascoe et al., 2024).
Cybersecurity evaluation should be understood as a multidimensional assessment of the ability of a technology and its supporting organization to protect information, systems, users, services, and critical operations against unauthorized access, disruption, alteration, destruction, or misuse. Cybersecurity is therefore not simply a technical issue concerning firewalls or passwords. It involves technology architecture, data governance, human behaviour, organizational processes, supplier relationships, incident management, business continuity, legal obligations, and leadership responsibility.
Identity management establishes who or what is permitted to interact with the technology environment. Modern systems may involve employees, customers, administrators, contractors, applications, devices, automated services, and machine-to-machine communications. Each identity should have an appropriate level of access and should be managed throughout its lifecycle. This includes creation, verification, modification, suspension, and removal of identities. Weak identity lifecycle management can leave former employees, inactive accounts, service accounts, or unnecessary privileges available after they are no longer required.
Authentication concerns the process of establishing that an identity is genuine. Different technologies may employ passwords, multifactor authentication, cryptographic credentials, biometrics, hardware security devices, certificates, or combinations of these methods. The appropriate level of authentication depends upon the sensitivity of the system and the potential consequences of unauthorized access. Strong authentication is particularly important where systems contain sensitive information or control critical processes.
Authorization determines what an authenticated identity is permitted to do. Authentication alone does not guarantee security. A legitimate user may still be given excessive privileges. The principle of least privilege therefore seeks to ensure that users and system processes receive only the permissions necessary to perform their authorized functions. Role-based access controls, privilege reviews, segregation of duties, and privileged-access management can contribute to reducing unauthorized activity.
Encryption protects information by transforming it into a form that is not readily usable by unauthorized parties without the appropriate cryptographic means. Evaluation should consider information both when it is being transmitted and when it is stored. The effectiveness of encryption also depends on key management, implementation quality, configuration, and lifecycle practices. Encryption should therefore not be evaluated simply as a yes-or-no feature.
Network security concerns the protection of communications and network-connected systems. Modern technologies frequently depend on distributed networks, cloud services, wireless connections, application programming interfaces, remote access, and interconnected devices. Network segmentation, secure configuration, monitoring, access control, and appropriate architectural design can reduce the possibility that compromise of one system will automatically expose the wider environment.
Vulnerability management involves identifying, evaluating, prioritizing, remediating, and monitoring weaknesses in hardware, software, configurations, applications, and infrastructure. Vulnerabilities can emerge throughout the technology lifecycle. New weaknesses may be discovered after deployment, while software updates may introduce new dependencies or configuration requirements. Vulnerability management should therefore be treated as a continuous process rather than a one-time technical inspection.
Patch management is an important part of vulnerability management. Delayed patching may leave known vulnerabilities available for exploitation. However, immediate patching is not always straightforward in critical environments because changes may affect system availability or compatibility. Effective evaluation should therefore consider patching procedures, testing, prioritization, emergency patch processes, unsupported software, compensating controls, and documented exceptions.
Logging provides records of relevant system activity. Logs can support security monitoring, investigation, accountability, troubleshooting, and compliance. However, simply generating logs does not guarantee that incidents will be detected. Organizations should consider whether logs are sufficiently detailed, protected against unauthorized modification, retained for an appropriate period, centralized where necessary, and actively reviewed or analyzed.
Incident detection concerns the organization's ability to recognize suspicious activity or actual security incidents. Detection mechanisms may include automated monitoring, anomaly detection, endpoint protection, network monitoring, security information and event management systems, user reporting, and threat intelligence. The evaluation should consider detection speed as well as detection accuracy. A system that produces large numbers of false alerts may overwhelm security personnel and reduce the effectiveness of the overall monitoring process.
Incident response addresses what happens after a cybersecurity event has been identified. An effective response capability should define responsibilities, escalation procedures, containment actions, investigation processes, communication requirements, recovery activities, and lessons-learned procedures. Incident response should be tested periodically because procedures that exist only in documentation may not function effectively under pressure.
Backup and recovery are essential because cybersecurity incidents may involve data destruction, ransomware, system corruption, hardware failure, or service interruption. Evaluation should consider whether backups exist, whether they are protected from compromise, whether restoration has been tested, how quickly systems can be restored, and whether critical data can be recovered with acceptable levels of loss. Backup existence alone should not be treated as evidence of effective recovery capability.
Third-party risk is increasingly important because organizations often depend on external providers for cloud computing, software, data, payment processing, telecommunications, cybersecurity services, artificial intelligence models, hosting, analytics, and maintenance. A technology can therefore inherit vulnerabilities from suppliers even when its internal security controls are strong. Vendor evaluation should consider security requirements, contractual obligations, access arrangements, incident notification, data handling, subcontractors, audit rights, business continuity, and termination procedures.
Supply-chain security extends this analysis beyond direct suppliers. Modern technology may involve numerous layers of hardware, software, open-source components, cloud services, libraries, development environments, logistics providers, and manufacturing partners. A weakness introduced at an earlier stage may become part of a downstream technology. Software supply-chain attacks, compromised dependencies, counterfeit components, malicious modifications, and insecure development practices illustrate why security should be considered throughout the technology lifecycle.
Organizational governance provides the broader structure within which cybersecurity controls operate. Governance includes leadership responsibility, policies, accountability, risk management, resource allocation, staff competence, training, assurance, audit, regulatory compliance, and continuous improvement. Cybersecurity cannot be separated entirely from organizational decision-making because security controls require investment, prioritization, maintenance, and oversight.
NIST CSF 2.0 provides a useful structure for organizing cybersecurity outcomes, while ISO/IEC 27001 provides a management-system approach to information security (International Organization for Standardization & International Electrotechnical Commission [ISO/IEC], 2022; Pascoe et al., 2024). These frameworks can support evaluation by providing structured ways of considering cybersecurity capabilities and information-security management. However, a framework should not be treated as proof that a particular technology is secure. The evaluator still needs to determine whether the relevant controls are implemented, appropriate to the technology, functioning effectively, and proportionate to the risks involved.
Cybersecurity evaluation should also distinguish between compliance and effectiveness. An organization may have policies, procedures, certifications, or documented controls but still experience security weaknesses. Conversely, a particular technical safeguard may be highly effective even if it is not described through a specific certification. Therefore, evaluation should examine actual implementation, testing, evidence, monitoring, and continuous improvement rather than relying exclusively on documentation.
Human behaviour is a major component of cybersecurity. Phishing, social engineering, password reuse, accidental disclosure, inappropriate data sharing, insecure device use, and poor handling of credentials can introduce vulnerabilities. However, human behaviour should be considered within the design of the overall system. If security procedures are unnecessarily complicated, users may develop workarounds. If security training is infrequent or disconnected from actual work practices, its effectiveness may be limited. Technology evaluation should therefore consider whether secure behaviour is realistically supported by system design and organizational processes.
Cybersecurity evaluation should also consider the relationship between confidentiality, integrity, and availability. Confidentiality concerns preventing unauthorized disclosure of information. Integrity concerns preventing unauthorized or inappropriate alteration of information and systems. Availability concerns ensuring that authorized users can access systems and information when required. Different technologies may place different emphasis on these objectives. For example, a public information website may have different confidentiality requirements from a medical database, while an emergency communication system may place particularly strong emphasis on availability.
For artificial intelligence systems, cybersecurity evaluation can require additional consideration. AI systems may depend upon large datasets, model repositories, external APIs, training pipelines, cloud infrastructure, and automated deployment processes. Risks may involve unauthorized modification of training data, compromised model files, malicious inputs, prompt manipulation, unauthorized model access, leakage of sensitive information, compromised dependencies, or attacks against connected systems. The precise risks depend upon the architecture and intended use of the AI system, so cybersecurity assessment should be tailored to the specific technology rather than assuming that all AI systems present identical risks.
Cybersecurity also intersects with privacy and data governance. A system may have strong perimeter security but still collect excessive information, retain data unnecessarily, or provide inappropriate access to sensitive records. Technology evaluation should therefore consider what information is collected, why it is collected, how it is processed, where it is stored, who can access it, how long it is retained, and how it is securely disposed of. The legal and regulatory environment relevant to the particular jurisdiction and technology should also be considered.
Resilience is another important dimension. Cybersecurity should not be evaluated solely according to whether an attack can be prevented. Organizations should also consider whether critical functions can continue during an incident, how quickly systems can recover, whether alternative processes exist, and whether lessons from incidents are incorporated into future controls. This creates a broader security sequence:
Prevent → protect → detect → respond → recover → learn → adapt.
The evaluation should also consider the possibility of cascading cybersecurity consequences. A compromised identity system, for example, could affect multiple applications. A compromised cloud provider could affect numerous services. A compromised software dependency could expose many organizations simultaneously. These situations demonstrate why cybersecurity risk can become systemic rather than remaining within a single application.
Cybersecurity risk should therefore be evaluated at several levels:
Technology → application → organization → supply chain → infrastructure → ecosystem.
This layered approach recognizes that a secure individual technology may still be exposed through weaknesses in its surrounding environment. Similarly, an organization's cybersecurity posture may depend upon national infrastructure, telecommunications, cloud providers, electricity availability, and other external services.
Continuous monitoring is essential because cybersecurity conditions change rapidly. New vulnerabilities are discovered, threat methods evolve, software changes, employees join and leave organizations, suppliers change, systems are upgraded, and new technologies are integrated. Consequently, a cybersecurity evaluation conducted at one point in time represents a particular state of the system rather than a permanent guarantee of security.
A comprehensive cybersecurity evaluation should therefore ask whether the organization knows what assets it has, who can access them, what vulnerabilities exist, what controls are operating, whether those controls are tested, how incidents are detected, how incidents are contained, how systems are recovered, how suppliers are managed, and how lessons are incorporated into future improvements.
Within the broader technology evaluation framework, cybersecurity should not be treated as an isolated technical dimension. It intersects with operational continuity, legal and regulatory obligations, privacy, financial risk, reputation, safety, human behaviour, supply-chain resilience, governance, and systemic risk. A cybersecurity weakness can therefore affect several other dimensions simultaneously.
The central principle is that cybersecurity evaluation should move beyond the question of whether a technology has security features and instead examine whether the entire socio-technical system can prevent, withstand, detect, respond to, recover from, and learn from cybersecurity events. The resulting assessment should consider both current controls and future conditions, because emerging technologies may introduce new forms of connectivity, automation, data dependence, and interdependence that alter the cybersecurity risk profile over time.
9.18 Security by Design
Security should not be added after development. Security-by-design principles require security considerations to be incorporated from the earliest stages of system architecture. This principle changes the position of security from a final inspection activity into an integral component of technology development, evaluation, deployment, operation, maintenance, and eventual retirement.
This includes:
threat modelling;
secure coding;
least-privilege access;
secure defaults;
authentication;
encryption;
monitoring;
recovery planning; and
continuous testing.
Security by design begins with the recognition that many vulnerabilities are influenced by architectural and design decisions made before a system becomes operational. If security is considered only after development has been completed, weaknesses may already be embedded in software architecture, data structures, interfaces, authentication mechanisms, communication protocols, supplier dependencies, and operational processes. Correcting such weaknesses later may require substantial redesign, additional expenditure, service interruption, migration, or replacement of components.
The principle is particularly important for connected technologies because vulnerabilities may become difficult or expensive to correct after deployment. Modern technologies rarely operate as completely isolated systems. Applications may communicate with cloud platforms, databases, payment systems, mobile devices, sensors, artificial intelligence services, third-party applications, identity-management systems, and external APIs. A vulnerability in one component may therefore create exposure elsewhere in the system.
Threat modelling provides an important foundation for security by design. It requires developers and evaluators to identify valuable assets, potential threats, possible attack pathways, trust boundaries, vulnerable components, and potential consequences. The purpose is not to predict every possible attack but to understand the security assumptions built into the system and identify where those assumptions could fail.
Secure coding is another important component. Software should be developed using practices that reduce the likelihood of common vulnerabilities, including inappropriate input handling, insecure authentication, inadequate authorization, unsafe data processing, insecure configuration, and weaknesses in dependency management. Secure development should also include code review, testing, vulnerability scanning, dependency analysis, and controlled release processes.
Least-privilege access requires that users, applications, devices, and services receive only the permissions necessary for their legitimate functions. Excessive privileges increase the potential consequences of compromised credentials or malicious activity. Least privilege should therefore apply not only to human users but also to automated processes, service accounts, APIs, and interconnected systems.
Secure defaults are particularly important because many users do not modify technical settings after deployment. If a technology is initially configured with unnecessarily broad access, weak security controls, excessive data collection, or insecure communication settings, insecure behaviour may become the normal operating condition. Secure-by-default design attempts to establish safer conditions without requiring users to possess specialist cybersecurity knowledge.
Authentication and authorization should be designed according to the sensitivity and consequence profile of the system. A low-risk public information service may have different requirements from a system controlling financial transactions, medical records, industrial processes, or critical infrastructure. Security evaluation should therefore be proportionate to the consequences of unauthorized access.
Encryption should similarly be incorporated into the architecture rather than treated as an optional feature added later. The evaluation should consider data at rest, data in transit, key management, access to cryptographic keys, implementation quality, and the lifecycle of encrypted information.
Monitoring should also be considered during design. A system that cannot generate meaningful evidence about important activities may become difficult to secure, troubleshoot, audit, and investigate. Monitoring should therefore be designed to provide appropriate visibility into authentication events, access attempts, configuration changes, system abnormalities, security alerts, and other relevant activities.
Recovery planning is equally important. Security by design does not imply that failure or compromise can always be prevented. Instead, systems should be designed so that they can be isolated, restored, recovered, and operated safely after disruption. Backup architecture, redundancy, recovery procedures, alternative operating modes, and tested restoration processes can therefore form part of security architecture.
Continuous testing is necessary because security conditions change. Software is updated, new vulnerabilities are discovered, system configurations change, suppliers introduce new components, and new connections are established. Penetration testing, vulnerability assessment, code review, configuration review, security testing, and controlled exercises can provide evidence about whether the security architecture continues to operate as intended.
Security by design also applies beyond software. Physical infrastructure, hardware components, telecommunications, data centres, sensors, Internet of Things devices, industrial equipment, and embedded systems can all contain security dependencies. A technology evaluation should therefore examine the complete system rather than assuming that cybersecurity is limited to application software.
The principle also has an organizational dimension. Developers, system architects, information-security specialists, data managers, procurement teams, legal advisers, risk managers, and operational personnel may all influence security outcomes. Security by design is therefore most effective when responsibility is distributed across the development and governance process while remaining subject to clearly identified accountability.
Procurement is another important stage. Security requirements should be established before technology is acquired rather than after a supplier has already been selected. Organizations may need to examine supplier security practices, vulnerability disclosure procedures, update mechanisms, data-handling arrangements, access requirements, support arrangements, incident notification obligations, and end-of-contract procedures.
Security by design should also consider future change. A technology may initially be secure but become vulnerable when new features, integrations, users, devices, or data sources are added. Change management should therefore include security assessment. Major architectural changes should trigger reassessment of threats, controls, dependencies, and residual risks.
The principle can be represented as:
Requirement definition → threat identification → secure architecture → secure development → security testing → controlled deployment → monitoring → incident learning → continuous improvement.
Security by design therefore establishes security as a lifecycle responsibility. It reduces dependence on late-stage inspection and encourages organizations to consider security before vulnerabilities become embedded in the technology and its surrounding processes.
9.19 Data Governance
Data governance establishes responsibilities and rules for data. It provides the organizational structure through which data are collected, classified, stored, accessed, processed, shared, retained, corrected, protected, and ultimately disposed of. In contemporary technology systems, data are often one of the most important organizational assets and one of the most significant sources of risk.
A technology evaluation should ask:
Who owns the data?
Who controls access?
Who validates data quality?
How are data classified?
How are data retained?
How are errors corrected?
What happens when data are transferred?
How are personal data protected?
These questions are important because technology performance is frequently dependent upon data quality. A sophisticated system cannot necessarily compensate for inaccurate, incomplete, outdated, inconsistent, or inappropriate data. The evaluation of technology should therefore consider the relationship between the technology, its data environment, and the processes through which those data are governed.
Data ownership should be clearly understood, although ownership may have different legal, contractual, operational, and organizational meanings depending upon the context. An organization may control data operationally while another party may have contractual or legal rights concerning those data. These relationships should be documented so that responsibilities are not assumed incorrectly.
Access control is another central element. Not every individual who can use a technology should necessarily have access to all associated data. Access should be based upon legitimate purpose, role, authorization, and necessity. Access should also be reviewed periodically because responsibilities change and users may leave an organization.
Data quality should be evaluated systematically. Relevant dimensions may include accuracy, completeness, consistency, timeliness, validity, uniqueness, relevance, and traceability. Poor data quality can affect not only technical performance but also financial reporting, operational decisions, research findings, public services, healthcare decisions, and AI outputs.
Data classification provides a mechanism for distinguishing information according to sensitivity and importance. Public information, internal information, confidential business information, personal information, sensitive information, and highly restricted information may require different controls. Classification should influence storage, access, transmission, retention, monitoring, and disposal requirements.
Data retention is also important. Organizations should not necessarily retain information indefinitely merely because storage has become inexpensive. Retention should be connected to legitimate operational, legal, regulatory, research, or contractual requirements. Excessive retention may increase privacy, cybersecurity, storage, and governance risks.
Error correction procedures should be established because data inevitably contain errors. The organization should know how incorrect information is identified, who has authority to correct it, whether changes are recorded, and whether affected systems are updated consistently. For critical applications, the ability to trace data corrections can be particularly important.
Data transfer creates additional governance considerations. Data may move between departments, organizations, countries, cloud platforms, suppliers, applications, or analytical environments. Each transfer may introduce security, privacy, legal, contractual, and integrity risks. Data governance should therefore establish rules for authorized transfer, secure transmission, recipient responsibilities, and appropriate documentation.
Data governance is particularly important for AI because model performance is strongly influenced by training and operational data.
Gebru et al. (2021) and Mitchell et al. (2019) illustrate the importance of documentation practices for datasets and models.
Documentation can improve transparency by helping evaluators understand where data came from, how they were created or collected, what limitations exist, how they should be used, and what assumptions apply. Dataset documentation can provide information about provenance, composition, intended use, limitations, and potential risks. Model documentation can similarly describe intended use, performance characteristics, limitations, evaluation conditions, and relevant considerations.
For AI systems, data governance should extend across the model lifecycle. Training data, validation data, testing data, operational data, feedback data, and monitoring data may have different purposes and risks. The organization should understand how data enter the system and how changes in those data may affect model performance.
Data drift is an important consideration. The statistical characteristics of operational data may change over time. A model that performed adequately when first developed may produce different results when the population, market, environment, user behaviour, or operating conditions change. Data governance should therefore include mechanisms for monitoring relevant changes and determining when reassessment or retraining is necessary.
Data provenance is another important consideration. Evaluators should be able to understand where important data originated and, where feasible, how they were transformed. This becomes particularly important when data are combined from multiple sources. Without adequate provenance, it may become difficult to identify errors, reproduce results, investigate incidents, or determine responsibility.
Data governance also intersects with ethics. Questions about who controls data, who benefits from data use, who bears risks, and whose interests are represented cannot always be answered through technical controls alone. Data practices can affect privacy, autonomy, fairness, inclusion, organizational power, and access to services. Therefore, data governance should be considered within the broader social and ethical evaluation of technology.
Data governance should also support accountability. If an important decision is based on data, the organization should be able to identify the relevant data source, responsible process, applicable rules, and decision authority. This becomes increasingly important when automated or AI-supported decisions affect individuals or organizations.
A useful data-governance lifecycle can be represented as:
Data creation → collection → classification → validation → storage → access → processing → sharing → monitoring → retention → correction → archival or secure disposal.
This lifecycle perspective reinforces the principle that data governance is not limited to storage and cybersecurity. It encompasses the entire life of information.