10. Secure Technology Governance and Digital Transformation

Introduction and Context

Digital transformation changes not only the technologies used by an organisation but also its operating model, decision rights, information flows, dependencies, and exposure to risk. Cloud platforms, application programming interfaces, mobile services, artificial intelligence, Internet of Things devices, operational technology, and automated delivery pipelines allow organisations to create value at unprecedented speed. They also make security failures more systemic. A vulnerable identity provider, poorly governed cloud configuration, compromised software dependency, or unsafe industrial controller may affect several business services simultaneously.

Secure technology governance provides the organisational means to ensure that technology decisions support business objectives while remaining within acceptable risk, legal, ethical, and operational boundaries. It translates enterprise risk appetite into architecture principles, engineering requirements, approval processes, accountability structures, and measurable controls. The purpose is not to prevent innovation. Rather, it is to make secure innovation repeatable and defensible.

Traditional governance often treated security as a review performed near the end of a project. Digital transformation requires a different approach. Security, privacy, resilience, and compliance must be considered while a business capability is being designed, before major technical commitments are made, and continuously after deployment. This chapter examines how risk governance can be embedded in enterprise architecture, software development, DevSecOps, cloud, zero trust, identity, data, operational technology, and IoT programmes.

Learning Objectives

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

1. Explain the relationship between technology governance, enterprise architecture, and cybersecurity risk management.

2. Apply security-by-design and privacy-by-design principles to digital transformation initiatives.

3. Describe how architecture review, configuration governance, and change control reduce technology risk.

4. Analyse the security implications of DevSecOps, cloud computing, zero trust, identity, data, OT, and IoT.

5. Design governance mechanisms that balance delivery speed, innovation, resilience, compliance, and risk appetite.

6. Evaluate an organisational case involving insecure digital transformation and recommend improvements.

From Technology Projects to Governed Digital Capabilities

Technology governance is the system of structures, authorities, processes, and measures through which an organisation directs and controls its use of technology. It answers several practical questions: Who may approve a new technology? Which risks are acceptable? What evidence is required before deployment? Who owns an identity, dataset, interface, or cloud account? How are exceptions recorded and retired?

Governance differs from management, although the two are closely related. Governance establishes direction, accountability, policy, and oversight. Management plans and executes work within that direction. For example, a risk committee may approve the principle that production systems must use strong administrative authentication. Engineering management then selects and implements the relevant identity controls.

Enterprise architecture connects business strategy with information, applications, technology platforms, and security capabilities. A useful architecture practice maintains several related views:

• The business view describes capabilities, processes, stakeholders, and critical services.
• The information view identifies data domains, ownership, sensitivity, flows, retention, and use.
• The application view shows systems, interfaces, dependencies, and trust relationships.
• The technology view records platforms, networks, endpoints, cloud services, and operating environments.
• The security view describes controls, threat assumptions, regulatory obligations, resilience requirements, and residual risks.

Architecture governance is effective when these views are used to make decisions rather than merely documented. A proposed customer platform, for example, should be assessed in relation to business criticality, data classification, identity architecture, supplier dependence, recovery objectives, logging, and exit options. This prevents a narrow focus on features or acquisition cost.

A practical governance model usually assigns three levels of accountability. The board or executive committee establishes risk appetite and receives assurance. A technology or security architecture authority interprets that appetite through standards and design decisions. Delivery teams implement controls and provide evidence. Independent risk, audit, privacy, and compliance functions challenge the process without taking ownership away from the delivery team.

Security-by-Design and Privacy-by-Design

Security-by-design means that protection against misuse, compromise, disruption, and unauthorised access is built into a system from its conception. It is stronger than adding controls after implementation because architectural decisions determine the system's attack surface, trust boundaries, data exposure, and recoverability.

A security-by-design review should consider at least the following questions:

1. What business service is being enabled, and what would be the consequences of failure?

2. What assets, identities, data, interfaces, and operational processes are involved?

3. Which actors may be trusted, and under what conditions?

4. What abuse cases and realistic attack paths exist?

5. What preventive, detective, responsive, and recovery controls are required?

6. What evidence will demonstrate that the controls work?

Threat modelling gives these questions structure. Teams can identify assets and trust boundaries, model likely adversaries, examine misuse cases, and prioritise mitigations. The method may be formal or lightweight, but it should be proportionate to risk. A low-risk internal information page does not require the same analysis as an identity service connected to payment processing.

Privacy-by-design extends this reasoning to personal information. It requires purpose limitation, data minimisation, appropriate transparency, lawful processing, access and correction mechanisms, retention controls, and protection throughout the information lifecycle. Privacy is not achieved merely by encrypting a database. A system that collects unnecessary personal data, retains it indefinitely, or uses it for an undisclosed purpose may remain poorly governed even when technically secure.

Security and privacy decisions can conflict. Detailed monitoring may improve fraud detection while increasing privacy exposure. Strong data minimisation may reduce future analytical value. Governance therefore requires explicit choices, documented necessity and proportionality, access restrictions, retention periods, and independent review where appropriate.

Architecture Review as a Risk Decision

Architecture review should be an evidence-based decision process, not a ceremonial approval meeting. The review authority examines whether a proposed design conforms to principles, standards, and risk appetite. It may approve the design, approve it with conditions, request redesign, or accept a time-bound exception.

A proportionate review normally examines:

• business and service criticality;
• data classification and jurisdictional requirements;
• authentication, authorisation, and privileged access;
• network trust zones and external exposure;
• secure interfaces and dependency management;
• logging, monitoring, incident response, and forensic needs;
• resilience, backup, recovery, and failure modes;
• supplier, cloud, and concentration risk;
• secure development and testing evidence; and
• decommissioning, portability, and exit arrangements.

Architecture principles should be concise enough to guide decisions. Examples include: authenticate every privileged action; encrypt sensitive data in transit and at rest; minimise implicit trust; separate development and production; use approved cryptographic services; maintain recoverable configurations; and assign an accountable owner to every critical service.

Exceptions are inevitable, particularly in legacy environments. A sound exception process records the requirement, affected assets, risk assessment, compensating controls, accountable owner, expiry date, and remediation plan. An exception without an expiry date becomes an undocumented architecture standard. Risk acceptance must be performed by an authority with sufficient seniority and must not be confused with the technical team's acknowledgement of a problem.

Secure Development and DevSecOps

The software development life cycle provides a natural structure for integrating governance. During initiation, security objectives, regulatory constraints, data requirements, and risk ownership should be identified. During design, threat modelling and abuse-case analysis should influence architecture. During coding, developers use secure coding practices, approved libraries, secrets management, and peer review. During testing, automated and manual testing examine vulnerabilities, misuse, resilience, and access control. Before release, the organisation verifies that high-risk findings are addressed or formally accepted. After release, monitoring, patching, vulnerability management, and incident response continue.

DevSecOps extends DevOps by making security activities continuous and shared. Security controls are integrated into source control, build pipelines, infrastructure-as-code, artifact repositories, deployment tools, and runtime monitoring. Examples include software composition analysis for third-party components, static and dynamic application testing, secret detection, infrastructure configuration scanning, container image assessment, and policy checks that prevent unsafe deployments.

Automation improves consistency but does not remove judgement. A scanner may report a vulnerability that is unreachable in the deployed context, or it may fail to recognise a business-logic flaw. Conversely, a pipeline that allows every critical finding to be overridden offers the appearance of control without meaningful protection. Governance should define severity thresholds, evidence requirements, override authority, expiry periods, and escalation paths.

Software supply-chain governance is increasingly important. Organisations should maintain an inventory of components, assess supplier provenance, control build environments, protect signing keys, verify artifacts, monitor vulnerabilities, and plan for dependency replacement. The software bill of materials can support visibility, but it is useful only when connected to ownership, vulnerability intelligence, and remediation processes.

Cloud, Configuration, and Change Governance

Cloud security follows a shared-responsibility model. The provider secures aspects of the underlying service, while the customer remains responsible for choices such as identity permissions, data protection, network exposure, workload configuration, and often operating-system or application security. Responsibility varies by service model and must be established contractually and technically rather than assumed.

Cloud governance should address account or subscription structure, approved regions, identity federation, privileged access, logging, key management, network segmentation, backup, workload deployment, service limits, supplier resilience, and exit planning. A cloud centre of excellence may provide reusable patterns, guardrails, reference architectures, and expert support, while business teams retain accountability for their services.

Configuration governance is the disciplined management of secure settings across systems and environments. Baselines define approved configurations for operating systems, databases, containers, cloud resources, network devices, and identity platforms. Configuration drift occurs when actual settings diverge from the approved state. Drift may arise from emergency changes, manual administration, undocumented experimentation, or malicious activity.

Infrastructure-as-code and policy-as-code allow configurations and controls to be versioned, reviewed, tested, and automatically enforced. Continuous compliance tools can identify public storage, excessive permissions, disabled logging, unsupported software, or unencrypted resources. These tools must be integrated with remediation ownership; an alert that is never acted upon is not an effective control.

Change control should be risk-based. A routine, pre-approved change may follow an automated path, whereas a change to an identity provider, industrial controller, encryption service, or disaster-recovery configuration deserves deeper assessment. Every significant change should have an identified owner, implementation plan, testing evidence, rollback method, communication plan, and post-change verification. Emergency change procedures are necessary, but emergency status should not eliminate later review.

Zero Trust and Identity-Centred Governance

Zero trust is an architectural and governance approach based on the principle that access should not be granted merely because a user, device, or workload is inside a network boundary. Access decisions should consider identity, device condition, resource sensitivity, request context, and risk, and should be continuously evaluated where appropriate.

Identity is therefore a central control plane. Governance must address the full identity lifecycle: joining, role change, temporary access, delegation, suspension, and departure. Role-based or attribute-based access should implement least privilege while remaining manageable. Privileged access management can require stronger authentication, just-in-time elevation, session recording, approval, and separation of duties.

A mature identity programme maintains authoritative sources for workforce and non-human identities, removes dormant accounts, controls service credentials, rotates secrets, and reconciles entitlements with business responsibilities. Machine identities are often overlooked even though applications, APIs, containers, and automated jobs may hold significant privileges.

Zero trust is not achieved by purchasing a product or replacing a network firewall. It requires segmentation, strong authentication, device and workload visibility, policy enforcement, telemetry, and a culture of explicit access decisions. Poorly designed policies can create operational disruption, encourage workarounds, or concentrate excessive authority in a central platform. Governance must therefore include usability, resilience, break-glass access, and recovery procedures.

Data Governance, Analytics, and Artificial Intelligence

Data governance establishes ownership, quality expectations, classification, access rules, lifecycle controls, and accountability for data. Security governance should connect data classifications to practical controls. Confidential data may require encryption, restricted access, monitoring, tokenisation, and approved processing locations. Critical records may require immutability, reconciliation, retention, and recoverability.

Data lineage helps an organisation understand where data originates, how it is transformed, where it is stored, and with whom it is shared. It supports incident investigation, regulatory response, impact analysis, and responsible analytics. Data governance should also address copies in development environments, test datasets, backups, logs, spreadsheets, and personal devices.

Artificial intelligence introduces additional concerns, including sensitive training data, model theft, prompt injection, data poisoning, insecure plugins, hallucinated outputs, bias, and insufficient human oversight. Governance should identify approved uses, prohibited uses, data handling rules, testing requirements, model ownership, monitoring, explainability needs, and escalation procedures. High-impact decisions require particular attention to fairness, accountability, contestability, and human review. An AI system should not be treated as outside the organisation's normal risk and change controls.

Operational Technology and IoT

Operational technology controls physical processes such as manufacturing, energy, transport, building management, and healthcare equipment. Internet of Things environments connect sensors, actuators, gateways, applications, and cloud services. Their security objectives may differ from those of conventional information technology. Safety, availability, process integrity, and human welfare can take precedence over rapid patching or confidentiality.

OT governance must respect engineering constraints, long equipment lifecycles, specialised protocols, maintenance windows, and the need for safe operation. Segmentation, controlled remote access, asset inventories, secure engineering workstations, monitoring, tested backups, and incident response plans are essential. Patching should be risk-assessed and tested; where patching is impossible, compensating controls and replacement plans are required.

IoT governance should address device identity, secure onboarding, unique credentials, firmware integrity, update mechanisms, exposed services, physical tampering, supplier support, and end-of-life disposal. A device inventory that records only serial numbers is insufficient. The organisation needs to know what the device does, what data it handles, what it can control, how it communicates, and who is accountable for it.

Convergence between IT, OT, and IoT increases efficiency but also creates pathways for attack. Architecture reviews should examine indirect dependencies, shared identity services, remote maintenance, common cloud platforms, and consequences of loss of control. Safety and cybersecurity teams should collaborate rather than operate through disconnected risk registers.

Illustrative Case: The Rapid Retail Platform Programme

Background

Northstar Retail, a fictional national retailer, launched a digital transformation programme to create a cloud-based customer platform. The programme included mobile shopping, personalised recommendations, warehouse automation, and integration with payment and loyalty systems. Executive sponsors promised a rapid launch before the peak sales period.

Situation and Problem

Delivery teams created separate cloud accounts and selected services independently. Developers stored test data copied from production in a shared environment. Administrative access was granted through long-lived credentials, and several service accounts had broad permissions. The architecture board reviewed the programme only after the first release candidate was complete. It discovered that logging was inconsistent, the mobile application depended on an unsupported library, warehouse devices shared default passwords, and the payment integration had no tested recovery procedure.

Management initially proposed accepting the risks until after launch. The security leader argued that the risks were interconnected: a compromised developer account could reach cloud resources, exposed customer data could trigger regulatory consequences, and disruption of warehouse systems could affect physical operations and revenue.

Analysis

The programme's primary failure was governance timing. Security was treated as a final quality gate rather than a design responsibility. There was no common architecture baseline, no accountable owner for cross-platform identity, and no process for distinguishing temporary development shortcuts from permanent production decisions. The absence of configuration governance allowed insecure settings to spread. The programme also underestimated non-human identities and the relationship between IT services and warehouse OT.

Approach and Strategy

The executive committee paused high-risk production changes for a limited period and appointed service owners. An architecture review established a target design with central identity federation, multifactor authentication, separate environments, segmented warehouse connectivity, approved cloud patterns, and mandatory logging. Production data was removed from development and replaced with masked datasets. The delivery pipeline added dependency scanning, secret detection, infrastructure policy checks, and release evidence.

A risk register recorded residual risks, owners, compensating controls, and expiry dates. Warehouse devices were inventoried, default credentials were replaced, remote access was restricted, and a safe maintenance procedure was agreed with operations engineers. The payment integration received a recovery test before launch. A limited release proceeded only after critical controls were verified; lower-risk improvements remained in the roadmap under formally accepted exceptions.

Outcome

The programme launched later than originally planned but with clearer accountability, stronger access control, improved monitoring, and a tested recovery capability. The organisation retained delivery speed by using reusable cloud patterns and automated pipeline checks. It also adopted quarterly architecture health reviews and required every new digital product to nominate security, privacy, data, and operational owners.

Learning Points

The case demonstrates that governance is most valuable before technology choices become expensive to reverse. It also shows that secure transformation is not equivalent to security department approval. Business owners, architects, developers, operations personnel, privacy specialists, suppliers, and executives must share responsibility. Automated controls are valuable, but they require ownership, exception discipline, and business-context analysis.

Challenges, Limitations, and Common Governance Failures

One challenge is the tension between central control and delivery autonomy. Excessive centralisation creates queues and encourages teams to bypass governance. Excessive autonomy creates inconsistent controls and unmanaged dependencies. Federated governance, reusable patterns, risk-based review, and clear escalation paths provide a workable balance.

Legacy technology presents another difficulty. It may be impossible to implement modern authentication, segmentation, or patching without affecting safety or availability. Governance should avoid pretending that compliance equals security. It should document residual risk, introduce compensating controls, establish monitoring, and create a funded migration or retirement plan.

Metrics can also mislead. Counting architecture reviews or vulnerabilities closed says little about actual risk reduction. More useful measures may include the proportion of critical services with named owners, the percentage of privileged access reviewed, the age of unresolved high-risk exceptions, configuration compliance, recovery-test performance, and the time required to revoke access. Metrics should support decisions rather than reward cosmetic activity.

Common mistakes include approving designs without operational owners, treating cloud responsibility as the provider's problem, ignoring service accounts, using production data in test environments, allowing permanent emergency access, failing to test rollback, and accepting exceptions without expiry. Another frequent error is separating cybersecurity, privacy, safety, and resilience into independent processes when the system's risks are interconnected.

Ethical, Regulatory, and Professional Considerations

Secure technology governance affects individuals, employees, customers, suppliers, and communities. Surveillance-heavy monitoring may improve security but can undermine privacy and trust. Automated decisions may reproduce bias or deny meaningful appeal. Security controls should therefore be necessary, proportionate, transparent to the extent possible, and subject to accountable oversight.

Organisations must comply with applicable data-protection, critical-infrastructure, sectoral, contractual, and cybersecurity obligations. Legal compliance is a baseline, not a complete risk strategy. Professional practice also requires accurate reporting of residual risk, responsible disclosure, protection of sensitive evidence, avoidance of conflicts of interest, and respect for safety in OT environments.

Boards and executives cannot delegate accountability merely because implementation is technical. They must ensure that risk appetite is explicit, resources are adequate, incentives do not reward unsafe shortcuts, and assurance is independent enough to be credible.

Emerging Developments and Best Practices

Secure digital transformation is increasingly supported by policy-as-code, continuous control monitoring, software supply-chain transparency, confidential computing, passwordless authentication, secure-by-default cloud services, and automated identity governance. AI-assisted security operations may improve detection and investigation, but generated recommendations require validation and must not obscure accountability.

Best practice is characterised by a small number of consistent behaviours:

• establish accountable owners for services, data, identities, and risks;
• apply proportionate architecture and threat reviews early;
• use approved patterns and automate preventive checks;
• maintain accurate inventories of assets, dependencies, configurations, and software components;
• integrate privacy, resilience, safety, and security decisions;
• make exceptions explicit, time-bound, and reviewable;
• test recovery, access revocation, monitoring, and incident response;
• measure control effectiveness and business outcomes; and
• treat decommissioning and supplier exit as part of design.

The central governance question is not whether a system is perfectly secure. Perfect security is unattainable. The question is whether the organisation understands its exposure, has reduced avoidable risk, can detect and respond to failure, and has assigned authority to make informed residual-risk decisions.

Chapter Summary

Secure technology governance embeds cybersecurity risk management in the decisions that shape digital capabilities. Enterprise architecture provides the connection between strategy, information, applications, technology, and security. Security-by-design and privacy-by-design move protection earlier in the lifecycle, while architecture review makes risk and accountability explicit.

DevSecOps integrates security into development and deployment, but automation must be governed through thresholds, evidence, and controlled exceptions. Cloud governance depends on understanding shared responsibility, configuration baselines, identity, logging, resilience, and exit planning. Zero trust places identity and contextual access decisions at the centre of protection. Data governance addresses classification, lineage, lifecycle, and responsible analytics. OT and IoT require special attention to safety, availability, device identity, long lifecycles, and physical consequences.

Effective governance balances central standards with delivery autonomy. It relies on accountable owners, risk-based reviews, configuration and change control, measurable assurance, tested recovery, and ethical oversight. Digital transformation is secure when security is treated as an operating capability rather than a final approval activity.

Key Terms

Security governance: Structures and processes used to direct, control, and oversee cybersecurity risk.

Enterprise architecture: A structured view linking business strategy with information, applications, technology, and security.

Security-by-design: Integrating security requirements and controls into system conception and development.

Privacy-by-design: Embedding privacy protection, minimisation, transparency, and lifecycle controls into system design.

Architecture review: A formal assessment of a proposed design against principles, standards, risks, and requirements.

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

DevSecOps: A development and operations approach that integrates security throughout delivery and runtime activities.

Infrastructure-as-code: Defining and managing infrastructure through version-controlled, executable specifications.

Configuration drift: Divergence between approved system settings and actual deployed settings.

Change control: Governance of modifications to technology, configurations, applications, or processes.

Zero trust: An approach that avoids implicit trust and evaluates access using identity, context, resource, and risk.

Privileged access management: Controls for restricting, monitoring, approving, and reviewing elevated access.

Data lineage: Documentation of data origin, movement, transformation, storage, and use.

Software supply chain: The people, processes, tools, libraries, and components involved in producing software.

Operational technology: Technology that monitors or controls physical processes and equipment.

Internet of Things: Connected physical devices that sense, communicate, process, or act on information.

Compensating control: An alternative safeguard used when a preferred control cannot be implemented.

Residual risk: Risk remaining after controls and treatments have been applied.

Policy-as-code: Expressing governance rules as machine-readable policies that can be tested or enforced automatically.

Review Questions

Short Answer Questions

1. Distinguish between technology governance and technology management.

2. What is the purpose of an architecture review?

3. Explain configuration drift and identify one way to control it.

4. Why are service accounts important in identity governance?

5. State two reasons why OT security cannot simply copy conventional IT security practices.

Long Answer Questions

1. Explain how security-by-design and privacy-by-design influence the digital system lifecycle.

2. Discuss the governance implications of the shared-responsibility model in cloud computing.

3. Describe how DevSecOps can integrate security controls without making automation a substitute for professional judgement.

4. Analyse the role of identity, least privilege, and privileged access management in a zero-trust architecture.

5. Explain how data governance, software supply-chain governance, and configuration governance contribute to enterprise resilience.

Analytical / Application Questions

1. A business unit wants to deploy a customer analytics platform using copied production data in a public cloud account. Identify the governance issues, recommend an architecture-review process, and specify appropriate controls.

2. An industrial organisation cannot patch several legacy controllers without risking production safety. Develop a risk-based treatment plan using segmentation, monitoring, compensating controls, access governance, and a retirement strategy.

3. A DevSecOps pipeline reports hundreds of vulnerabilities, while developers routinely override the findings to meet release dates. Design a governance model for severity thresholds, exception approval, evidence, metrics, and remediation accountability.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the relationship between governance and management in secure technology programmes?

A. Governance performs all technical implementation activities.

B. Governance establishes direction, accountability, and oversight, while management executes within that direction.

C. Management determines organisational risk appetite and the board implements controls.

D. Governance is required only when a security incident occurs.

Correct Answer: B. Governance establishes direction, accountability, and oversight, while management executes within that direction.

Question 2

A cloud team discovers that a storage resource has become publicly accessible after a manual change. Which governance issue is most directly illustrated?

A. Data lineage

B. Configuration drift

C. Threat intelligence

D. Software licensing

Correct Answer: B. Configuration drift

Question 3

Which action most closely reflects security-by-design?

A. Adding multifactor authentication after a breach

B. Performing threat modelling while the system architecture is being created

C. Purchasing cyber insurance before development begins

D. Reviewing audit logs only at the end of the financial year

Correct Answer: B. Performing threat modelling while the system architecture is being created

Question 4

A sound technology risk exception should normally include which combination?

A. Only the name of the system and the developer's approval

B. The risk, compensating controls, accountable owner, expiry date, and remediation plan

C. A permanent waiver and no further monitoring

D. A statement that the supplier accepts all responsibility

Correct Answer: B. The risk, compensating controls, accountable owner, expiry date, and remediation plan

Question 5

Which practice is most consistent with zero trust?

A. Granting broad access because a user is connected to the corporate network

B. Allowing permanent administrator rights to reduce support delays

C. Evaluating identity, device condition, resource sensitivity, and request context before access

D. Replacing all application controls with a perimeter firewall

Correct Answer: C. Evaluating identity, device condition, resource sensitivity, and request context before access

Question 6

Why does a software bill of materials provide limited value when used alone?

A. It cannot identify any software components.

B. It is useful only for hardware inventories.

C. It provides visibility but must be connected to ownership, vulnerability information, and remediation.

D. It eliminates the need for secure coding and testing.

Correct Answer: C. It provides visibility but must be connected to ownership, vulnerability information, and remediation.

Question 7

Which approach is most appropriate when an OT controller cannot be patched safely?

A. Ignore the vulnerability because OT systems are never connected.

B. Immediately shut down all production without a safety assessment.

C. Use risk-assessed compensating controls, such as segmentation and restricted access, while planning replacement.

D. Expose the controller directly to the internet so that vendors can maintain it.

Correct Answer: C. Use risk-assessed compensating controls, such as segmentation and restricted access, while planning replacement.

Question 8

In the illustrative Northstar Retail case, what was the primary governance failure?

A. The organisation used cloud technology.

B. Security was treated as a final review rather than an integrated design responsibility.

C. The organisation used automated testing.

D. The programme had too many service owners.

Correct Answer: B. Security was treated as a final review rather than an integrated design responsibility.

Question 9

Which metric is most likely to provide meaningful evidence of identity-governance effectiveness?

A. Number of security policy documents published

B. Number of meetings held by the architecture board

C. Percentage of privileged access reviewed and inappropriate access revoked

D. Total number of software developers employed

Correct Answer: C. Percentage of privileged access reviewed and inappropriate access revoked

Question 10

Why should privacy and security governance be considered together in digital transformation?

A. Encryption automatically satisfies every privacy obligation.

B. Privacy concerns only data stored outside the organisation.

C. Security controls can affect collection, monitoring, access, retention, and use of personal information.

D. Privacy requirements eliminate the need for cybersecurity controls.

Correct Answer: C. Security controls can affect collection, monitoring, access, retention, and use of personal information.