Governance, Ethics and Digital Transformation

Introduction

Digital transformation is not simply the replacement of paper processes with software. It is the deliberate redesign of how an organisation creates value, makes decisions, manages risk, serves stakeholders and fulfils legal and social obligations through digital technologies. Cloud platforms, application programming interfaces, artificial intelligence, data analytics, mobile applications and automated decision systems can improve productivity and access to services. They can also create new forms of exclusion, surveillance, environmental cost, intellectual-property conflict, privacy harm and operational dependency.

Software engineers therefore participate in governance whether or not their job title includes the word “governance”. A developer who selects a third-party library makes a licensing decision. A product team that omits keyboard navigation makes an accessibility decision. A data engineer who retains personal data indefinitely makes a privacy and risk decision. A machine-learning team that deploys a model without monitoring its outcomes makes an accountability decision.

Governance provides the structures through which authority, responsibility, controls and evidence are established. Ethics helps professionals reason about what ought to be done, including situations where the law is incomplete or compliance alone would still cause harm. Digital transformation combines these concerns with strategy, portfolio management and organisational change.

Learning Objectives

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

1. Explain the relationship among governance, ethics, compliance and accountability.
2. Apply professional codes of conduct to software-engineering decisions.
3. Evaluate accessibility, sustainability, privacy, intellectual property and software licensing risks.
4. Identify sources and consequences of algorithmic bias and propose mitigation controls.
5. Design audit trails, control processes and accountability arrangements for digital systems.
6. Analyse digital-transformation initiatives using portfolio and benefits-realisation principles.
7. Critically assess a transformation proposal from technical, legal, social and strategic perspectives.

1. Governance as a Software-Engineering Responsibility

Governance is the system by which an organisation is directed and controlled. It allocates decision rights, defines acceptable risk, establishes oversight and requires evidence that commitments are being met. Governance differs from management: management plans and executes work, whereas governance determines direction, authorises decisions and evaluates whether the organisation is acting responsibly.

Four governance questions apply to almost every digital initiative:

• Who has authority? For example, who may approve a production release or a new use of personal data?
• Who is accountable? A team may perform a task, but a named role must remain answerable for the outcome.
• What controls are required? Controls may include testing, approval gates, segregation of duties, encryption, retention limits and incident response.
• What evidence will demonstrate responsible practice? Examples include requirements records, accessibility tests, risk assessments, decision logs and audit reports.

A useful distinction is between responsibility and accountability. Responsibility concerns carrying out an activity; accountability concerns answerability for its result. A developer may be responsible for implementing an authentication feature, while the product owner and security authority may be accountable for accepting the residual risk of that feature.

Governance should be proportionate. A low-risk internal prototype does not require the same approval structure as a clinical decision system or a public benefits platform. However, speed is not a justification for eliminating controls. Instead, organisations should use risk-based controls: stronger review, testing and monitoring where potential harm, scale, sensitivity or irreversibility is greater.

Governance layers

Digital transformation commonly requires governance at three connected levels:

A governance failure can occur at any level. A technically excellent system may still fail if it addresses the wrong strategic problem. Conversely, a well-chosen strategy may fail through weak operational controls.

2. Professional Codes and Ethical Reasoning

Professional codes translate broad values into expectations for conduct. Relevant examples include codes published by computing and engineering professional bodies, such as the ACM Code of Ethics and Professional Conduct and the Software Engineering Code of Ethics and Professional Practice. These codes commonly emphasise public welfare, honesty, competence, privacy, fairness, confidentiality, professional responsibility and respect for intellectual property.

A code is not a substitute for judgement. Real situations often involve competing duties. For example, an engineer may have a duty to maintain confidentiality but also a duty to report a serious and foreseeable safety risk. Ethical reasoning requires identifying stakeholders, harms, rights, duties, alternatives and evidence rather than merely asking whether an action is technically possible.

A practical ethical decision process is:

1. Describe the decision clearly. Avoid vague statements such as “the algorithm has an issue.” State who is affected and what action is proposed.
2. Identify stakeholders and power differences. Include direct users, non-users, employees, communities, suppliers and people indirectly affected.
3. Identify duties and constraints. Consider law, professional codes, contracts, organisational policies and fundamental rights.
4. Assess consequences. Examine benefits, harms, likelihood, severity, reversibility and distribution across groups.
5. Generate alternatives. An ethical choice is often not a choice between deployment and cancellation; redesign, staged release or human review may be alternatives.
6. Document the rationale. Record assumptions, dissenting views, evidence and the person authorised to accept residual risk.
7. Monitor after deployment. Ethical risk may emerge only when a system interacts with real populations.

Three ethical perspectives are especially useful. A consequentialist analysis evaluates likely outcomes and aggregate harms. A duty-based analysis asks whether rights and obligations are respected even when doing so reduces efficiency. A justice-oriented analysis asks how benefits and burdens are distributed, particularly among vulnerable groups. These perspectives can produce different conclusions; responsible governance makes the disagreement visible rather than pretending that a single metric resolves it.

3. Accessibility and Inclusive Design

Accessibility means that people with diverse physical, sensory, cognitive and technological conditions can perceive, understand, navigate and interact with a product or service. It includes permanent disabilities, temporary impairments and situational limitations. A person with a broken arm, poor network connection or noisy environment may experience accessibility barriers even without a long-term disability.

The Web Content Accessibility Guidelines (WCAG) provide widely used guidance organised around four principles: content should be perceivable, operable, understandable and robust. Common engineering practices include:

• providing text alternatives for meaningful images;
• ensuring keyboard operation and visible focus indicators;
• maintaining sufficient colour contrast and not relying on colour alone;
• associating labels and error messages with form controls;
• using semantic HTML and correctly structured headings;
• supporting screen readers and assistive technologies;
• providing captions and transcripts for multimedia;
• avoiding time limits that users cannot extend;
• testing responsive behaviour, zoom and reduced-motion preferences.

Accessibility is a governance concern because legal obligations, procurement requirements and public trust may depend on it. It is also a quality concern: semantic structure, clear error handling and simple navigation benefit many users. Retrofitting accessibility after implementation is generally more expensive and less effective than incorporating it into requirements, design systems, automated tests and acceptance criteria.

Automated accessibility tools are valuable but incomplete. They can identify some missing labels, contrast issues and structural errors, but they cannot reliably judge whether instructions are understandable or whether a workflow is usable with assistive technology. Manual keyboard testing, screen-reader testing and participation by users with disabilities remain important.

4. Sustainability and Responsible Technology

Sustainable software seeks to reduce environmental and social harm throughout a system’s lifecycle. Environmental impacts include energy consumption in data centres and devices, embodied carbon in hardware manufacture, electronic waste and network traffic. Social sustainability includes decent working conditions, maintainability, digital inclusion and avoiding technology that shifts hidden costs onto communities.

Engineering choices affect sustainability. Excessive polling, inefficient queries, unnecessary data retention, oversized media, poorly chosen machine-learning models and premature hardware replacement can increase resource use. Practical controls include:

• measuring energy and infrastructure usage where feasible;
• choosing efficient algorithms and data formats;
• caching and batching requests appropriately;
• reducing transfer size and unnecessary computation;
• extending hardware life through maintainable software;
• selecting suppliers with credible environmental and labour practices;
• designing for repair, portability and exit from a supplier;
• deleting data that has no legitimate retention purpose.

There is no universal rule that a smaller or newer model is always more sustainable. A less accurate system may cause additional manual work or harm, while a larger model may be justified for a high-value task. Sustainability decisions should therefore consider the complete lifecycle and the system’s purpose. Claims such as “green software” should be supported by measurable evidence rather than marketing language.

5. Intellectual Property and Software Licensing

Intellectual property (IP) law protects different kinds of subject matter. Copyright commonly protects original software code, documentation, graphics and other expressive works. Patents may protect eligible technical inventions in jurisdictions where the requirements are met. Trademarks protect indicators of commercial origin. Trade secrets protect confidential information when reasonable measures are taken to preserve secrecy.

Ownership and permission are distinct. An organisation may own code created by an employee under applicable employment arrangements, but a contractor’s work may require an explicit assignment. A team may possess a copy of an open-source package without owning the copyright. The right to use, modify, distribute or sublicense depends on the applicable licence and surrounding obligations.

Open-source software is not “free of obligations”. Permissive licences commonly require preservation of copyright and licence notices. Copyleft licences may require modifications or combined distributions to be made available under specified terms. Licence interpretation depends on the exact licence text, distribution model, linking or combination method and jurisdiction. Organisations should obtain legal advice for material uncertainty rather than relying on informal assumptions.

A software bill of materials (SBOM) records components and versions included in a product. It supports vulnerability response, licence review and supplier transparency. A practical IP-control process includes:

1. approving sources and repositories;
2. recording component names, versions and licences;
3. checking compatibility with the intended distribution model;
4. preserving required notices and attribution;
5. controlling proprietary material and confidential information;
6. reviewing employee and contractor ownership terms;
7. monitoring dependencies for licence and security changes.

Developers should never copy code from an online source into a commercial system without understanding its licence and provenance. Likewise, training or prompting generative AI systems with confidential code may create disclosure, ownership and policy risks. Organisations need rules for acceptable AI tools, code review, attribution, data handling and human responsibility for generated output.

6. Privacy, Data Governance and Security

Privacy concerns the appropriate collection, use, disclosure, retention and deletion of information about identifiable or identifiable individuals. Security protects confidentiality, integrity and availability; privacy asks whether processing is justified, proportionate and respectful. A secure system can still violate privacy if it collects excessive data or uses it for an unexpected purpose.

A privacy-by-design approach integrates privacy into architecture and delivery rather than treating it as a final legal check. Core practices include data minimisation, purpose limitation, transparency, access controls, encryption, pseudonymisation where appropriate, retention schedules, deletion mechanisms and rights-management processes. A privacy impact assessment can identify affected people, data flows, risks, controls and residual risk before deployment.

Data governance assigns ownership and rules for data quality, classification, access, retention and sharing. Important roles may include a data owner who approves use, a data steward who manages quality and a processor or service provider that handles data on behalf of an organisation. Records should document the source of data, permitted purposes, transformations, access history and retention rationale.

Privacy regulation varies by jurisdiction and sector. Requirements may concern lawful basis, notice, consent, individual access, correction, deletion, breach notification, cross-border transfers and special categories of sensitive data. A software engineer should not assume that a generic privacy notice or a checkbox automatically satisfies these requirements. Legal and privacy specialists should be involved where the processing is high risk or involves sensitive populations.

7. Algorithmic Bias, Explainability and Accountability

Algorithmic bias occurs when a computational system produces systematically unfair outcomes or distributes errors unequally. Bias can enter through historical data, under-representation, proxy variables, labelling decisions, measurement choices, model objectives, deployment context and feedback loops. Removing a protected attribute does not necessarily remove bias because other variables may act as proxies.

Consider a hiring model trained on historical recruitment decisions. If past decisions reflected unequal opportunity, the model may reproduce those patterns while appearing statistically accurate. A risk-scoring system may perform differently across groups because of unequal data quality or because the target variable is an imperfect proxy for the outcome of interest.

Bias assessment should examine several stages:

• Problem formulation: Is the prediction target appropriate, and should automation be used at all?
• Data: Who is represented, excluded or mislabelled? Are historical labels themselves biased?
• Model: Are features, thresholds and error trade-offs justified?
• Deployment: Does the context differ from the training environment?
• Impact: Are errors concentrated among particular groups, and can people challenge decisions?

Fairness metrics can conflict. For example, equal false-positive rates and equal positive predictive values are generally difficult to achieve simultaneously when groups have different base rates, except under special conditions. Therefore, a fairness assessment must state the chosen definition, population, threshold and purpose. No single numerical metric proves that a system is fair.

Accountable AI requires more than explainability. A technically interpretable model may still be unfair, and a complex model may be governed responsibly through impact assessment, human review, documentation and monitoring. Useful artefacts include model cards, data sheets, decision logs, risk assessments, test results, incident records and an appeal process. Human oversight must be meaningful: a reviewer needs authority, time, competence and access to relevant evidence, not merely a button that approves an automated recommendation.

8. Audit, Compliance and Control Design

Compliance means meeting applicable laws, regulations, contracts, standards and internal policies. It is narrower than ethics, because legal compliance establishes minimum obligations rather than the complete range of responsible conduct. Audit is a systematic, independent evaluation of evidence against defined criteria. An audit does not guarantee that a system is safe; it provides assurance about the adequacy and operation of specified controls.

A control may be preventive, detective or corrective. Multi-factor authentication is preventive. An alert for unusual access is detective. Restoring from a tested backup is corrective. Controls may also be manual, automated or hybrid. Effective control design answers five questions:

1. What risk is being addressed?
2. What control reduces that risk?
3. Who owns and operates the control?
4. What evidence demonstrates operation?
5. What happens when the control fails?

A control matrix can connect obligations to implementation and evidence.

Audit trails should be trustworthy. They need appropriate timestamps, user or service identity, event detail, protection against unauthorised alteration and retention consistent with legal and operational needs. Logging everything is not automatically good governance: excessive logs can increase privacy risk, cost and noise. Logs should be designed around investigative and accountability requirements.

9. Digital-Transformation Strategy and Portfolio Governance

A transformation portfolio is the collection of programmes, projects, products and operational changes managed together to achieve strategic objectives. Portfolio governance differs from project management. Project management asks how to deliver a defined result; portfolio governance asks which initiatives should be funded, sequenced, stopped or redesigned in relation to the organisation’s overall capacity and strategy.

A sound portfolio process includes:

• a clearly stated strategic problem and measurable desired outcomes;
• assessment of value, feasibility, risk, dependencies and compliance;
• consideration of organisational capacity and change fatigue;
• prioritisation using transparent criteria;
• stage gates or review points at discovery, pilot, scale and operation;
• benefits ownership after implementation;
• explicit criteria for stopping an initiative.

Benefits should not be confused with deliverables. A new customer portal is an output; reduced service time or improved accessibility is a benefit. Benefits realisation requires a baseline, an accountable owner, a measurement method and a time horizon. Where benefits are difficult to quantify, qualitative evidence may be used, but the assumptions should be explicit.

Digital transformation often fails when technology is treated as the solution before the problem is understood. A portfolio board should ask whether process simplification, training, policy change or service redesign could achieve the outcome with less risk. It should also consider interoperability, vendor lock-in, cybersecurity, skills, data quality and the ability to retire legacy systems.

10. An Integrated Governance Lifecycle

Governance should operate throughout the lifecycle rather than at a final approval meeting.

Discovery

Define the public, customer or organisational problem. Identify affected stakeholders, legal constraints, accessibility needs, data sources, sustainability considerations and possible harms.

Design

Translate obligations into requirements and architecture. Define data flows, threat models, retention rules, accessibility criteria, licence controls, decision rights and escalation paths.

Build and test

Use secure development practices, peer review, automated and manual testing, dependency checks, accessibility testing, bias evaluation and documented change control. Test with representative users and realistic operating conditions.

Release and operate

Use staged deployment, rollback capability, incident response, monitoring, support and clear communication. Confirm that operational staff understand their responsibilities and that users can seek help or challenge outcomes.

Review and retire

Evaluate outcomes against objectives, audit controls, investigate incidents, reassess risks and retire systems safely. Retirement includes data deletion or migration, contract closure, credential revocation and preservation of evidence required for legitimate accountability.

This lifecycle can be represented as a continuous loop: purpose and risk inform design; design produces controls; operation produces evidence; evidence informs review and redesign. Governance is therefore adaptive rather than a one-time approval.

11. Illustrative Case: A Digital Benefits Eligibility Platform

Background

A regional public agency proposes an online platform to process applications for housing support. The platform will integrate existing records, use a rules engine to identify likely eligibility and provide a mobile interface. The agency expects shorter processing times and lower administrative cost.

Problem

During a pilot, applications from people with limited digital literacy and unstable internet access are abandoned more often. Historical records contain inconsistent addresses and incomplete information for some communities. The rules engine recommends rejection in a substantial number of cases, but applicants cannot understand the reason or easily request review. A vendor also proposes retaining detailed interaction data indefinitely to improve its analytics product.

Analysis

The strategic objective is legitimate, but the proposed design creates several risks:

• accessibility barriers may exclude people with disabilities or limited connectivity;
• historical data quality may create unequal error rates;
• a rules engine may be treated as authoritative despite incomplete data;
• indefinite retention conflicts with data minimisation and increases breach impact;
• vendor analytics may exceed the purpose for which applicants supplied information;
• unclear responsibility may leave staff unable to correct errors.

Approach and solution

The agency establishes a named accountable executive, a product owner, a data owner, a privacy lead and an independent review panel. It conducts a privacy impact assessment, an accessibility assessment and a data-quality analysis before expansion.

The service is redesigned to provide assisted in-person and telephone routes alongside the digital channel. The interface supports keyboard operation, screen readers, clear language, error recovery and low-bandwidth use. The rules engine produces a recommendation and reason codes rather than an irreversible decision. Trained staff review adverse decisions, can override the recommendation with justification and provide an appeal route.

The agency limits data collection to information necessary for eligibility assessment, defines retention periods and prohibits secondary vendor use without a separately justified basis. Access is role-based, sensitive fields are protected, and audit records capture rule versions, input changes, reviewer actions and applicant appeals. A component inventory records third-party libraries and their licences.

Before scaling, the agency sets measurable conditions: accessibility defects must be resolved to an agreed threshold; error rates must be monitored across relevant groups; appeal outcomes must be reviewed; security controls must pass independent testing; and the expected processing benefit must be demonstrated without unacceptable exclusion.

Outcome

The revised pilot takes longer to design but produces a more resilient service. Digital completion improves, assisted channels remain available, staff can explain recommendations, and the agency discovers data-quality problems that would otherwise have been hidden. Some projected savings are reduced because human review is retained, but the service has stronger legitimacy, lower legal exposure and a clearer route for correcting errors.

Learning points

1. A transformation benefit is not valid if it depends on excluding difficult users.
2. Human review is meaningful only when reviewers have authority and information.
3. Data quality is a governance issue, not merely a database issue.
4. Privacy, accessibility, licensing and fairness should be designed together.
5. A pilot should test assumptions and harms, not merely demonstrate technical operation.

12. Challenges, Trade-offs and Contemporary Developments

Governance frequently involves trade-offs. Stronger logging may improve accountability but increase privacy risk. More human review may improve fairness but reduce speed and increase cost. A highly portable architecture may reduce vendor lock-in but require greater internal capability. A model may be more accurate overall while producing unacceptable outcomes for a minority group.

These trade-offs should be explicit, evidence-based and reviewed by people with relevant expertise. “Business need” should not be used as a vague reason to override rights or safety. Nor should ethics be delegated exclusively to a specialist team; engineers, managers, legal professionals, users and affected communities each hold relevant knowledge.

Generative AI intensifies existing governance questions. Organisations should control confidential inputs, verify generated code and content, assess training-data and IP risks, document human review, test for insecure output and establish responsibility for errors. AI systems also create supply-chain questions because models, datasets, hosted services and plugins may be third-party dependencies. Procurement should require transparency about data use, service changes, incident notification, audit rights, deletion and exit.

Contemporary governance is moving toward continuous assurance: automated policy checks, infrastructure-as-code controls, software supply-chain security, model monitoring and evidence generated during delivery. Automation can improve consistency but cannot determine whether an organisation’s purpose is legitimate or whether a community considers a service harmful. Technical controls must remain connected to human judgement and institutional accountability.

Best-Practice Checklist

Before approving a significant digital initiative, ask:

• Is the problem and intended public or organisational value clearly defined?
• Are affected and vulnerable stakeholders represented in design and testing?
• Are accessibility requirements measurable and tested with disabled users?
• Are data collection, use, retention and deletion justified?
• Are IP ownership, third-party components and licence obligations recorded?
• Have sustainability impacts and supplier practices been considered?
• Are algorithmic errors, subgroup impacts and appeal routes evaluated?
• Are decision rights, accountable owners and escalation paths named?
• Do controls produce reliable evidence for audit?
• Are benefits, risks, dependencies and stop criteria defined?
• Can the organisation operate, secure, modify and eventually retire the system?

Chapter Summary

Governance directs and controls digital transformation by assigning authority, accountability, risk ownership and evidence requirements. Professional ethics extends beyond legal compliance by requiring attention to public welfare, fairness, privacy, competence and professional integrity. Accessibility and sustainability should be built into requirements and architecture rather than added after implementation. Intellectual-property ownership and open-source licensing require deliberate component management, attribution and licence review. Privacy depends on appropriate purpose, minimisation, transparency, security and retention. Algorithmic bias can arise from problem formulation, data, models and deployment; no single fairness metric is sufficient, so accountable systems require monitoring, human review and appeal. Audit and compliance depend on well-designed controls whose operation can be demonstrated. Finally, portfolio governance connects individual projects to strategy, benefits, capacity and responsible stopping decisions. Effective digital transformation is therefore a socio-technical discipline: technology, people, institutions and values must be designed together.

Key Terms

Governance: The system for directing, controlling and overseeing an organisation or digital initiative.

Accountability: The obligation of a person or role to answer for decisions and outcomes.

Responsibility: The duty to perform or manage a particular activity.

Professional code: A formal statement of ethical duties and expected conduct for members of a profession.

Accessibility: The capability of people with diverse abilities and circumstances to use a product or service.

Sustainability: The management of environmental, social and economic impacts across a system’s lifecycle.

Intellectual property: Legal rights relating to creations, inventions, brands and confidential knowledge.

Open-source licence: Legal terms governing the use, modification and distribution of software whose source is made available.

Software bill of materials (SBOM): An inventory of software components and their versions in a product.

Privacy: Appropriate control over the collection, use, disclosure and retention of personal information.

Data minimisation: Collecting and retaining only the data necessary for a defined legitimate purpose.

Data governance: Roles, rules and processes for managing data quality, access, protection and use.

Algorithmic bias: Systematic and unfair differences in computational outcomes or error rates.

Explainability: The extent to which a system’s operation or output can be meaningfully understood.

Audit trail: A protected record of events and actions that supports investigation and accountability.

Compliance: Conformance with applicable laws, regulations, contracts, standards and policies.

Control: A preventive, detective or corrective measure used to reduce risk.

Portfolio governance: Oversight of a collection of initiatives to align investment with strategy and capacity.

Benefits realisation: The process of defining, measuring and achieving intended outcomes from an initiative.

Residual risk: The risk remaining after controls have been implemented.

Review Questions

Short Answer Questions

1. Distinguish governance from management and give one example of each.
2. Why is accessibility a software-engineering and governance concern?
3. Explain the difference between privacy and security.
4. What information does an SBOM provide, and why is it useful?
5. Why is human review not automatically meaningful in an automated decision system?

Long Answer Questions

1. Explain how professional codes support ethical software engineering, and discuss a situation in which two professional duties might conflict.
2. Describe a privacy-by-design process for a digital public service, including data collection, access, retention and user rights.
3. Analyse how algorithmic bias can enter at the problem, data, model and deployment stages.
4. Compare project governance with portfolio governance in a digital-transformation programme.
5. Explain how audit controls, evidence and accountability should operate across the digital-system lifecycle.

Analytical / Application Questions

1. A university plans to use an AI tool to rank scholarship applications. Develop a governance plan addressing fairness, privacy, accessibility, intellectual property, human review and appeals.
2. A start-up wants to combine several open-source libraries in a commercial application but has not recorded their licences. Identify the risks and propose a component-management process.
3. An organisation claims that moving all workloads to a larger cloud platform is automatically sustainable. Critically evaluate the claim and identify the evidence needed before approving the portfolio investment.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes accountability from responsibility?

A. Accountability concerns technical skill, while responsibility concerns legal compliance.

B. Accountability is answerability for an outcome, while responsibility concerns carrying out an activity.

C. Accountability applies only to managers, while responsibility applies only to developers.

D. Accountability is optional when a control is automated, while responsibility is mandatory.

Correct Answer: B. Accountability is answerability for an outcome, while responsibility concerns carrying out an activity.

Question 2

Which practice most directly supports accessibility?

A. Using colour alone to indicate validation errors

B. Removing visible focus indicators to simplify the interface

C. Providing semantic structure, keyboard operation and meaningful labels

D. Requiring users to complete forms within an unextendable time limit

Correct Answer: C. Providing semantic structure, keyboard operation and meaningful labels

Question 3

What is the primary purpose of a software bill of materials?

A. To replace all software testing

B. To list software components and versions for security and licence management

C. To prove that software is free of copyright

D. To calculate the financial return of a project

Correct Answer: B. To list software components and versions for security and licence management

Question 4

Which statement about privacy and security is most accurate?

A. Privacy and security are identical concepts.

B. Privacy concerns appropriate data processing, while security protects confidentiality, integrity and availability.

C. Security is relevant only to financial data, while privacy concerns only public data.

D. A secure system automatically satisfies all privacy obligations.

Correct Answer: B. Privacy concerns appropriate data processing, while security protects confidentiality, integrity and availability.

Question 5

Why can removing a protected attribute fail to eliminate algorithmic bias?

A. Models cannot process numerical variables.

B. Other variables may act as proxies for the protected attribute.

C. Protected attributes are always required for prediction.

D. Bias exists only when a model uses no human review.

Correct Answer: B. Other variables may act as proxies for the protected attribute.

Question 6

Which is an example of a detective control?

A. Encrypting stored data

B. Requiring multi-factor authentication

C. Alerting on unusual access patterns

D. Restoring a system from a tested backup after failure

Correct Answer: C. Alerting on unusual access patterns

Question 7

What is the main concern of portfolio governance?

A. Writing individual functions efficiently

B. Choosing and coordinating investments in relation to strategy, risk and capacity

C. Replacing all project managers with an automated tool

D. Ensuring that every proposed project is completed regardless of benefit

Correct Answer: B. Choosing and coordinating investments in relation to strategy, risk and capacity

Question 8

Which statement best describes meaningful human oversight?

A. A person clicks approval without seeing the system’s evidence.

B. A reviewer has authority, competence and information to question or change an automated outcome.

C. A human is named in a policy, even though the system cannot be overridden.

D. A reviewer accepts every recommendation to preserve consistency.

Correct Answer: B. A reviewer has authority, competence and information to question or change an automated outcome.

Question 9

Which practice best reflects data minimisation?

A. Retaining all collected data indefinitely in case it becomes useful

B. Collecting and retaining only data necessary for a defined legitimate purpose

C. Sharing data with vendors for unrelated analytics by default

D. Collecting additional sensitive data to improve the appearance of personalisation

Correct Answer: B. Collecting and retaining only data necessary for a defined legitimate purpose

Question 10

Why should benefits not be confused with deliverables in transformation governance?

A. Deliverables are always financial, while benefits are always technical.

B. A deliverable is an output, whereas a benefit is the intended improvement or outcome produced by using it.

C. Benefits cannot be measured, while deliverables can always be measured precisely.

D. Portfolio boards are responsible only for deliverables and never for outcomes.

Correct Answer: B. A deliverable is an output, whereas a benefit is the intended improvement or outcome produced by using it.