Governance, Ethics and Sustainable Engineering

Introduction

Full-stack development is often described as a technical activity involving interfaces, application services, databases, infrastructure, and deployment pipelines. In practice, however, a full-stack system is also a social and institutional system. It determines who can access information, how decisions are automated, where data is stored, whose intellectual property is used, how environmental resources are consumed, and who is accountable when something goes wrong.

Governance provides the structures through which technology is directed, controlled, monitored, and improved. Ethics concerns the values and duties that should guide technical choices, especially where legal compliance alone is insufficient. Sustainable engineering extends responsibility across the system’s social, economic, and environmental effects. These concerns are strategic rather than optional: they influence user trust, market access, operational resilience, regulatory exposure, recruitment, procurement, and the long-term viability of software products.

This chapter examines accessibility, algorithmic fairness, intellectual property, open-source licensing, data sovereignty, regulatory compliance, responsible innovation, green software, and organizational technology governance as connected dimensions of professional full-stack practice.

Learning Objectives

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

1. Explain why governance, ethics, and sustainability are engineering concerns.
2. Evaluate accessibility and inclusive design in full-stack systems.
3. Identify sources of algorithmic bias and propose fairness controls.
4. Distinguish major forms of intellectual property and open-source licensing obligations.
5. Analyse data sovereignty, privacy, security, and regulatory compliance.
6. Apply responsible-innovation and technology-governance frameworks.
7. Explain principles and metrics for green software engineering.
8. Recommend governance practices for a software organization.

1. Governance as an Engineering Responsibility

Technology governance is the system of decision rights, policies, controls, roles, and evidence used to ensure that technology supports organizational objectives while managing risk. It is different from day-to-day management. Management delivers current work; governance determines direction, accountability, acceptable risk, and oversight.

A useful governance cycle is:

direct → design → implement → measure → review → improve

For a full-stack product, governance questions include:

• Who is permitted to approve collection of a new category of personal data?
• Which risks must be assessed before release?
• Who owns a security vulnerability after deployment?
• What evidence demonstrates that an automated decision is fair?
• Which software dependencies may legally be distributed?
• What happens when a vendor, cloud region, or open-source project becomes unavailable?

Good governance does not mean that every decision requires a committee. Effective governance places decisions at the lowest competent level while establishing escalation rules for high-impact risks. It combines technical controls, documented processes, independent review, and organizational accountability.

Governance, ethics, and law

These concepts overlap but are not identical.

Legal compliance is a minimum threshold. A practice may be lawful but still ethically questionable—for example, using a confusing consent interface that technically presents a privacy notice. Conversely, an organization may voluntarily adopt stronger controls than legislation requires because trust and social legitimacy are strategic assets.

2. Accessibility and Inclusive Full-Stack Design

Accessibility is the design and implementation of products that can be used by people with diverse physical, sensory, cognitive, and technological abilities. It is not limited to visual design. It includes content, interaction, authentication, error recovery, performance, device compatibility, and support processes.

The Web Content Accessibility Guidelines commonly organize accessibility around four principles:

• Perceivable: Information and interface components must be available through more than one sensory channel where necessary.
• Operable: Users must be able to navigate and operate controls, including without a mouse.
• Understandable: Content, interaction patterns, and errors should be predictable and comprehensible.
• Robust: Content should work with current and future user agents, including assistive technologies.

Accessibility must be considered across the stack:

A common mistake is to treat accessibility as a final audit. Retrofitting may be expensive because inaccessible assumptions can be embedded in component libraries, database fields, workflows, and identity systems. Inclusive design begins with user research involving disabled users and continues through requirements, prototyping, implementation, testing, and maintenance.

Accessibility as a quality attribute

Accessibility is related to, but not identical with, usability. A highly usable system for a mouse user may be unusable for a keyboard user. Accessibility requirements should therefore be stated as testable acceptance criteria, such as:

• Every interactive control can be reached and operated using a keyboard.
• Form fields have programmatically associated labels.
• Validation errors identify the affected field and explain correction.
• Videos provide captions and, where appropriate, audio description.
• Text remains usable when enlarged and when display orientation changes.

Automated tools can identify missing labels, invalid markup, and some contrast failures. They cannot reliably determine whether instructions are understandable, whether focus movement is logical, or whether a workflow is usable with a screen reader. Human evaluation remains essential.

3. Algorithmic Fairness and Accountable Automation

Full-stack applications increasingly use ranking, recommendation, fraud detection, identity verification, pricing, hiring, lending, and generative artificial intelligence. Once software influences opportunities or treatment, fairness becomes a governance issue rather than merely a model-accuracy issue.

Sources of unfairness

Unfair outcomes may arise from:

1. Historical bias: Training data reflects earlier discrimination.
2. Representation bias: Some populations are underrepresented.
3. Measurement bias: A proxy does not accurately represent the intended concept for all groups.
4. Label bias: Human judgments used as labels are inconsistent or prejudiced.
5. Aggregation bias: One model assumes that relationships are identical across groups.
6. Deployment bias: A model is used outside the context for which it was designed.
7. Feedback loops: Automated decisions change future data, reinforcing earlier patterns.

Removing protected attributes does not guarantee fairness. Other variables may act as proxies, and unequal historical conditions may already be encoded in the data.

Fairness measures

Let a binary outcome be represented by Ŷ, the predicted decision, and Y, the actual outcome. Let A represent a protected or monitored group attribute. Several measures are useful, but they express different ethical commitments.

Demographic parity compares positive decision rates:

This requires equal positive prediction rates between groups a and b. It may be inappropriate when groups have different base rates or when the decision objective requires calibrated probabilities.

Equal opportunity requires equal true-positive rates:

It focuses on people who truly qualify for the positive outcome. Equalized odds additionally requires equal false-positive rates:

These measures assume that outcomes and group membership are defined meaningfully, that the data is sufficiently representative, and that the selected metric corresponds to the harm being addressed. In many realistic settings, different fairness criteria cannot all be satisfied simultaneously, particularly when groups have different base rates. Fairness therefore requires contextual judgment, stakeholder participation, and explicit trade-off decisions.

A responsible model lifecycle

A practical fairness lifecycle includes:

1. Define the decision, affected stakeholders, and potential harms.
2. Document data sources, consent conditions, missingness, and known limitations.
3. Test performance and error rates across relevant groups.
4. Conduct qualitative review with domain experts and affected communities.
5. Provide human review and a meaningful appeal mechanism for high-impact decisions.
6. Monitor drift, complaints, and disparate outcomes after deployment.
7. Record model version, training data, decision threshold, and responsible owner.

A model card or system card can communicate intended use, limitations, evaluation data, and known risks. For high-impact applications, governance should also define when automation must not be used.

4. Intellectual Property and Open-Source Licensing

Software projects combine original code, third-party libraries, data, documentation, images, fonts, models, and infrastructure configurations. Each may carry different rights and obligations.

Main forms of intellectual property

• Copyright: Protects original expression, including source code, documentation, graphics, and some database content. It generally protects expression rather than an abstract idea.
• Patents: May protect qualifying technical inventions, subject to jurisdictional rules and exclusions. Patent risk can exist even when code was independently written.
• Trademarks: Protect names, logos, and signs that distinguish goods or services.
• Trade secrets: Protect valuable confidential information when reasonable secrecy measures are maintained.
• Moral rights: In some jurisdictions, protect attribution or integrity interests of authors.

Ownership depends on jurisdiction, employment contracts, commissioned-work rules, contributor agreements, and the terms under which materials were obtained. A developer should not assume that code found online is free to copy merely because it is publicly visible.

Open-source licenses

Open source grants permissions through a license. It does not mean “without conditions.” Common license families include:

The exact legal effect depends on the license text, the way components are combined, distribution circumstances, and applicable law. Organizations should maintain a software bill of materials, record license metadata, preserve required notices, review compatibility, and obtain legal advice for material distribution decisions. A dependency scanner is useful but cannot replace legal and architectural analysis.

Ethical dimensions of open source

Open-source use creates responsibilities beyond formal compliance. Projects may be maintained by unpaid contributors, depend on fragile infrastructure, or carry security vulnerabilities. Organizations should contribute fixes, funding, documentation, or support when their commercial systems depend heavily on community projects. They should also avoid extracting value while ignoring maintainer safety and sustainability.

5. Data Sovereignty, Privacy, and Compliance

Data sovereignty refers to the authority of the jurisdiction in which data is collected, stored, processed, or accessed. It differs from data residency, which concerns physical or contractual location. A company may store data in one country while administrators in another country can access it; sovereignty and cross-border legal exposure may therefore remain relevant.

Important data-governance questions include:

• What data is collected, and is each field necessary?
• Who determines the purpose and means of processing?
• Where is data stored, backed up, and processed?
• Which vendors and subprocessors can access it?
• How long is it retained?
• Can individuals access, correct, export, or delete it where applicable?
• What happens when a legal authority requests disclosure?

Privacy engineering practices include data minimization, purpose limitation, access control, encryption in transit and at rest, pseudonymization, retention schedules, secure deletion, audit logging, and privacy impact assessments. Pseudonymization reduces direct identification but does not automatically make data anonymous; re-identification may remain possible when datasets are combined.

Compliance as a system property

Compliance should be designed into architecture rather than left to policy documents. For example, a retention policy is ineffective if backups cannot be deleted or if logs contain unrestricted personal information. A deletion request requires coordinated behavior across the user interface, API, databases, caches, analytics systems, backups, and vendor services.

A compliance control should specify:

• the obligation or risk addressed;
• the responsible owner;
• the technical and procedural control;
• the evidence produced;
• the review frequency;
• the escalation path when the control fails.

Relevant obligations vary by jurisdiction and sector and may include privacy, cybersecurity, accessibility, consumer protection, financial services, health, employment, records management, and breach notification requirements. Developers must not treat a general framework as a substitute for jurisdiction-specific legal advice.

6. Responsible Innovation

Responsible innovation asks not only whether a product can be built, but whether it should be built, for whom, under what conditions, and with what safeguards. It is especially important for artificial intelligence, biometric systems, surveillance technologies, autonomous decisions, and products affecting vulnerable populations.

A practical framework has four activities:

1. Anticipation: Examine plausible benefits, harms, misuse, second-order effects, and affected groups.
2. Reflection: Question assumptions, objectives, data choices, incentives, and power relationships.
3. Inclusion: Involve diverse stakeholders, including people likely to experience the system’s harms.
4. Responsiveness: Modify, pause, restrict, or withdraw the system when evidence indicates unacceptable risk.

These activities should be supported by a documented impact assessment. A useful assessment records intended use, foreseeable misuse, affected populations, reversibility of harm, human oversight, security threats, environmental effects, and exit criteria.

Responsible innovation does not require eliminating all risk. It requires proportionate safeguards, transparency, contestability, and accountability. A low-risk recommendation tool may require explanation and opt-out controls. A system that determines access to essential services may require independent review, human intervention, rigorous testing, and a prohibition on fully automated rejection.

7. Green Software and Sustainable Engineering

Green software engineering seeks to reduce the environmental impact of software across its lifecycle. Software consumes resources indirectly through hardware, networks, data centres, cooling systems, manufacturing, and disposal. Software design influences how much computation, storage, network traffic, and device replacement are required.

Sustainability has at least three dimensions:

• Environmental: Energy use, carbon emissions, water consumption, material use, and electronic waste.
• Social: Accessibility, worker welfare, digital inclusion, and long-term community effects.
• Economic: Affordability, maintainability, resilience, and viable operating cost.

Practical engineering strategies

• Reduce unnecessary data transfer through compression, caching, pagination, and efficient media formats.
• Avoid excessive polling; use event-driven communication when appropriate.
• Select efficient algorithms and data structures, while measuring real workloads.
• Retain only necessary data and remove obsolete replicas.
• Right-size compute resources and shut down idle environments.
• Use autoscaling carefully; uncontrolled scaling can increase both cost and emissions.
• Extend device life through lightweight interfaces and backward compatibility.
• Choose hosting regions and architectures using credible energy and carbon information.
• Include sustainability requirements in procurement and architecture reviews.

A simple energy estimate can be expressed as:

where E is energy, P is average power, and t is operating time. If P is measured in watts and t in hours, E is measured in watt-hours. This relationship assumes that average power is a suitable approximation over the interval. For a service with variable power, energy is more accurately represented by:

where P(t) is power at time t. Engineers should distinguish measured energy from estimated energy and should document system boundaries, hardware assumptions, workload, and measurement period.

Carbon impact can be approximated as:

where C is carbon dioxide equivalent, E is energy, and I is the carbon-intensity factor, usually expressed in grams of CO₂e per kilowatt-hour. This estimate is only meaningful when the energy boundary and carbon-intensity source are known. It should not be presented as an exact universal value.

Sustainable performance trade-offs

An optimization that reduces server energy may increase client energy, or a cache may reduce network traffic while increasing storage. Accessibility and sustainability may also interact: a lightweight interface can support low-bandwidth users, but reducing information too aggressively can harm comprehension. Sustainable engineering therefore requires lifecycle analysis rather than a single “green” metric.

Useful measures include energy per transaction, carbon per user journey, data transferred per task, infrastructure utilization, hardware lifetime, and percentage of workloads using renewable or lower-carbon energy. Metrics must be tied to user outcomes; minimizing energy by making a service unreliable or inaccessible is not responsible engineering.

8. Organizational Technology Governance

Governance becomes effective when it is embedded in organizational structures. A mature technology governance model commonly includes:

• Board or executive oversight: Sets risk appetite and strategic priorities.
• Product and engineering leadership: Allocates resources and owns delivery decisions.
• Security and privacy functions: Define controls, assess threats, and coordinate response.
• Architecture review: Examines resilience, interoperability, data flows, and technical debt.
• Legal and compliance specialists: Interpret obligations and review high-risk arrangements.
• Data and model governance: Manages data quality, lineage, access, model approval, and monitoring.
• Internal audit or independent assurance: Tests whether controls operate effectively.
• Development teams: Implement controls and maintain evidence as part of normal delivery.

A responsibility-assignment matrix can clarify who is responsible for performing a task, accountable for its outcome, consulted before action, and informed afterward. Governance should also define exception handling. If a team cannot meet a control, it should document the reason, compensating measures, owner, expiry date, and approval authority.

Governance integrated with delivery

A practical delivery pipeline may include:

1. Intake: Classify the product and identify affected people and data.
2. Design review: Assess accessibility, privacy, security, fairness, licensing, and sustainability.
3. Implementation: Use approved patterns, dependency controls, and secure coding practices.
4. Verification: Run automated tests, manual accessibility tests, threat modelling, license checks, and impact evaluation.
5. Release decision: Approve residual risk and record evidence.
6. Operation: Monitor reliability, incidents, complaints, fairness indicators, and environmental metrics.
7. Retirement: Migrate or delete data, revoke access, archive evidence, and communicate closure.

This approach is often called “governance by design.” It reduces the cost of compliance because controls and evidence are produced during ordinary engineering work rather than reconstructed before an audit.

Applied Case: A Public Benefits Eligibility Platform

The following is an illustrative case, not a description of a particular real organization.

Background

A government agency commissions a full-stack platform through which citizens apply for housing assistance. The platform includes a mobile interface, an identity service, a rules engine, document storage, analytics, and an automated prioritization model. A cloud provider operates the infrastructure in several regions.

Problem

Pilot testing reveals that screen-reader users cannot complete the document-upload step. Applicants with non-standard names experience identity-verification failures. Historical data shows lower approval rates for some minority communities, and the model’s training data contains inconsistent records. The agency also discovers that a third-party document-processing library has a license incompatible with its intended distribution model. Finally, the platform stores more personal information than the eligibility decision requires.

Analysis

The problems are interconnected. Accessibility failures create unequal access before the algorithm operates. Identity data may act as a proxy for protected characteristics. Excessive data increases privacy and breach risk. The licensing issue creates legal and operational exposure. Cloud-region selection affects sovereignty and contractual controls. Because housing assistance is a high-impact service, applicants need understandable reasons, human review, and an appeal route.

Approach and solution

The organization establishes a cross-functional governance group and assigns accountable owners. It redesigns the upload workflow using semantic controls, keyboard testing, captions for instructional media, and testing with disabled applicants. Identity verification is changed so that name matching tolerates legitimate variation and sends uncertain cases to trained human reviewers.

The model is paused for prioritization decisions until data quality and fairness evaluation are completed. The team compares group-specific error rates, documents the selected fairness criterion, and creates an appeal process. It also separates eligibility rules from the predictive model so that policy decisions remain auditable.

A data inventory removes fields not necessary for eligibility, defines retention periods, restricts staff access, and records cloud locations and subprocessors. The license issue is resolved by replacing the component after legal review. The pipeline generates a software bill of materials and checks dependency licenses at each release. Performance budgets reduce unnecessary document transfer, and dormant test environments are automatically stopped.

Outcome

The revised platform improves task completion for assistive-technology users, reduces false identity rejections, and gives applicants clearer explanations. The agency obtains evidence for its compliance review and can trace each release to its approvals, dependencies, and test results. The predictive model remains restricted to a lower-risk support function until monitoring demonstrates acceptable performance. Energy and storage use decline because of smaller uploads, shorter retention, and controlled environments.

Learning points

1. Accessibility is an access-rights issue, not merely a visual-design feature.
2. Fairness must be evaluated in context and across the complete decision process.
3. Data minimization reduces privacy, security, storage, and environmental burdens simultaneously.
4. Open-source compliance belongs in architecture and continuous integration.
5. High-impact automation requires explainability, human review, contestability, and accountable ownership.
6. Governance is strongest when evidence is generated during development and operation.

Challenges and Limitations

Governance frameworks have limitations. Standards can become checkbox exercises if organizations reward documentation rather than improved outcomes. Fairness metrics may conflict or conceal harms affecting small groups. Accessibility testing can miss real experiences when disabled users are excluded from research. Carbon estimates may be uncertain because cloud providers use different measurement boundaries. Open-source compliance tools may misidentify licenses or miss obligations embedded in documentation and transitive dependencies. Privacy controls can also conflict with legitimate research, safety monitoring, or public-interest reporting.

These limitations require professional judgment and continuous review. Teams should disclose uncertainty, avoid unsupported precision, document assumptions, and invite challenge from people affected by system decisions. Independent review is particularly important when commercial incentives make an organization reluctant to pause a profitable system.

Contemporary Developments and Professional Practice

Several trends are reshaping full-stack governance:

• Generative AI is increasing the need for provenance, privacy controls, copyright analysis, prompt and output testing, and human oversight.
• Software bills of materials are becoming central to supply-chain transparency and vulnerability response.
• Policy-as-code and automated compliance checks are integrating governance into delivery pipelines.
• Digital product passports and sustainability reporting are increasing interest in lifecycle and supply-chain data.
• Privacy-enhancing technologies, including selective disclosure and confidential processing, are being explored where data minimization alone is insufficient.
• Platform engineering is standardizing secure, accessible, and compliant deployment patterns for development teams.

Professionals should maintain a governance portfolio: architecture decisions, threat models, accessibility results, dependency inventories, data maps, model documentation, incident records, sustainability measurements, and approval evidence. This portfolio demonstrates not only that a system was built, but that it was built responsibly.

Best-Practice Checklist

Before release, a full-stack team should be able to answer “yes” to the following questions:

• Have affected users, including disabled users, participated in design or testing?
• Can the principal workflows be completed with keyboard and assistive technologies?
• Are automated decisions tested for relevant group disparities and error patterns?
• Is there human review and appeal for high-impact decisions?
• Are data purposes, locations, retention periods, and access permissions documented?
• Have all third-party components, licenses, and notices been reviewed?
• Is the software bill of materials current?
• Are security, privacy, and regulatory controls mapped to owners and evidence?
• Have energy, data-transfer, storage, and hardware-lifecycle effects been considered?
• Are monitoring, incident response, exception handling, and retirement plans defined?

Chapter Summary

Governance, ethics, and sustainable engineering are strategic dimensions of full-stack development. Accessibility ensures that systems can be used by people with diverse abilities and must be addressed across interfaces, services, data, operations, and testing. Algorithmic fairness requires analysis of data, model behavior, context, and human consequences; no single fairness metric is universally correct.

Intellectual property law governs code, content, inventions, brands, and confidential information. Open-source software grants valuable permissions but imposes license obligations that must be managed through inventories, notices, compatibility review, and responsible participation. Data sovereignty and privacy require control over collection, location, access, retention, transfer, and deletion. Regulatory compliance should be implemented as an architectural and operational property supported by accountable owners and evidence.

Responsible innovation adds anticipation, reflection, inclusion, and responsiveness to technical decision-making. Green software engineering reduces resource use across the lifecycle while recognizing trade-offs among energy, performance, accessibility, reliability, and cost. Organizational governance connects these practices through decision rights, risk ownership, assurance, monitoring, and retirement. The professional full-stack developer is therefore not only a builder of features but also a steward of rights, resources, trust, and long-term social value.

Key Terms

Accessibility: The ability of people with diverse abilities to use a system effectively.

Algorithmic fairness: The evaluation and management of unequal effects produced by automated systems.

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

Data residency: The physical or contractual location where data is stored or processed.

Data sovereignty: The authority of a jurisdiction over data and its processing.

Demographic parity: A fairness criterion requiring equal positive prediction rates between groups.

Equal opportunity: A fairness criterion requiring equal true-positive rates between groups.

Governance: Structures and processes for directing, controlling, and accounting for technology.

Green software engineering: Designing and operating software to reduce lifecycle environmental impact.

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

Open-source license: Legal terms granting rights to use, modify, and redistribute software.

Pseudonymization: Transforming identifiers to reduce direct identification while retaining possible re-identification risk.

Responsible innovation: Innovation that anticipates impacts, reflects on assumptions, includes stakeholders, and responds to evidence.

Software bill of materials: An inventory of software components and their relevant metadata.

Sustainability: The capacity to maintain beneficial environmental, social, and economic outcomes over time.

Technology governance: Organizational decision rights, policies, controls, and assurance for technology.

Trade secret: Confidential commercially valuable information protected through secrecy measures.

Transparency: Making relevant system purposes, processes, limitations, and decisions understandable.

Review Questions

Short Answer Questions

1. Distinguish governance, ethics, and legal compliance in software development.
2. State the four broad principles commonly associated with accessible web content.
3. Why does removing a protected attribute not necessarily eliminate algorithmic bias?
4. What is the difference between data residency and data sovereignty?
5. State two ways in which software design can reduce environmental impact.

Long Answer Questions

1. Explain how accessibility requirements should be integrated across the full technology stack.
2. Compare demographic parity, equal opportunity, and equalized odds, including situations in which they may conflict.
3. Discuss the main intellectual-property and open-source licensing risks in a commercial full-stack project.
4. Explain how privacy and data sovereignty can be implemented through architecture and operational controls.
5. Evaluate the role of organizational governance in responsible innovation and sustainable engineering.

Analytical / Application Questions

1. A university uses an automated system to prioritize scholarship applications. Design a fairness and accountability assessment, including data review, performance measures, human oversight, and appeals.
2. A startup plans to release a web application containing several open-source libraries and processing personal data in multiple cloud regions. Recommend a governance plan addressing licensing, data location, retention, security, and evidence.
3. A media platform wants to reduce emissions by lowering video quality and shortening content retention. Analyse the environmental, accessibility, user-experience, and business trade-offs, and propose appropriate metrics and safeguards.

Multiple Choice Questions with Answers

Question 1

Which statement best describes technology governance?

A. The process of writing application code without managerial involvement

B. The structures and controls used to direct, oversee, and account for technology

C. A method for increasing software execution speed

D. A legal license that permits software redistribution

Correct Answer: B. The structures and controls used to direct, oversee, and account for technology

Question 2

Which accessibility principle requires that an interface can be operated without a mouse?

A. Perceivable

B. Operable

C. Understandable

D. Robust

Correct Answer: B. Operable

Question 3

Which fairness criterion compares positive prediction rates between groups?

A. Demographic parity

B. Equal opportunity

C. Equalized odds

D. Calibration only

Correct Answer: A. Demographic parity

Question 4

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

A. Protected attributes are never stored in databases

B. Other variables may act as proxies or encode historical inequalities

C. Models cannot process numerical variables

D. Removing variables always increases accuracy

Correct Answer: B. Other variables may act as proxies or encode historical inequalities

Question 5

Which intellectual-property right most directly protects original source-code expression?

A. Trademark

B. Patent in every case

C. Copyright

D. Trade secret only

Correct Answer: C. Copyright

Question 6

What is a software bill of materials primarily used for?

A. Recording employee salaries

B. Listing software components and their metadata

C. Measuring screen contrast

D. Replacing all security testing

Correct Answer: B. Listing software components and their metadata

Question 7

Which practice best supports data minimization?

A. Collecting every potentially useful field indefinitely

B. Retaining only data necessary for a defined purpose and period

C. Copying personal data into all development environments

D. Allowing unrestricted vendor access

Correct Answer: B. Retaining only data necessary for a defined purpose and period

Question 8

If a system uses 200 watts continuously for 5 hours, what energy does it consume?

A. 40 Wh

B. 205 Wh

C. 1,000 Wh

D. 10,000 Wh

Correct Answer: C. 1,000 Wh

Question 9

Which activity is part of responsible innovation?

A. Avoiding all stakeholder involvement to preserve speed

B. Anticipating impacts and responding when evidence indicates unacceptable risk

C. Treating legal compliance as the only ethical requirement

D. Deploying first and documenting risks only after complaints

Correct Answer: B. Anticipating impacts and responding when evidence indicates unacceptable risk

Question 10

Which statement about open-source software is most accurate?

A. Publicly visible code has no licensing conditions

B. All open-source licenses impose identical obligations

C. Open-source software can be reused subject to the applicable license terms

D. Open-source software cannot be used commercially

Correct Answer: C. Open-source software can be reused subject to the applicable license terms