Professional Ethics, Governance and Compliance

Introduction

Software is not ethically neutral. A system can distribute opportunities, restrict access, expose personal information, consume energy, or influence decisions about employment, healthcare, education and public services. Professional software engineering therefore involves more than producing working code. It requires responsible judgement about users, organisations, society and the environment.

Professional ethics concerns the values and duties that guide conduct. Governance establishes who makes decisions, who is accountable, and how risks are controlled. Compliance means meeting applicable laws, regulations, contracts, standards and organisational policies. These ideas overlap but are not identical: legal compliance is a minimum requirement, whereas ethical responsibility may require action beyond what the law explicitly demands.

This chapter examines accessibility, inclusion, intellectual property, licensing, data protection, sustainability, algorithmic bias and accountability. It also introduces practical governance controls that help software teams make defensible decisions throughout the software development life cycle.

Learning Objectives

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

1. Explain the relationship between professional ethics, governance and compliance.
2. Evaluate software responsibilities concerning accessibility, inclusion and human impact.
3. Distinguish intellectual property rights and select suitable software licences.
4. Apply basic data-protection principles to software projects.
5. Identify sustainability risks and algorithmic bias.
6. Design practical accountability, assurance and governance controls.
7. Analyse an ethical and compliance problem and recommend an appropriate response.

1. Professional Responsibility in Software Engineering

A professional is expected to exercise competence, honesty, care and judgement. Software engineers have duties to several groups:

• Users and affected persons: Systems should be safe, usable, accessible and respectful of rights.
• Clients and employers: Engineers should protect confidential information, communicate risks and deliver work competently.
• Colleagues: Teams should support respectful workplaces, peer review and responsible escalation.
• Society: Software should not knowingly facilitate serious harm, discrimination, deception or unlawful surveillance.
• The environment: Technical choices should consider energy use, hardware consumption and electronic waste.

These duties can conflict. A manager may request rapid release, while testing reveals a serious privacy or safety risk. Professional conduct requires the engineer to document the concern, communicate it clearly, propose proportionate mitigation and escalate it when necessary. “The client requested it” is not a sufficient defence for knowingly harmful or unlawful conduct.

Codes such as the ACM Code of Ethics and the Software Engineering Code of Ethics and Professional Practice provide useful principles, including avoiding harm, being fair, respecting privacy, maintaining competence and accepting responsibility. A code is not a substitute for law or judgement; it is a framework for interpreting difficult situations.

Ethical decision-making

A practical ethical process is:

1. Identify the decision and the people affected.
2. Establish facts, uncertainties and relevant requirements.
3. Identify duties, rights, risks and competing interests.
4. Generate alternatives, including postponement or refusal.
5. Assess foreseeable benefits, harms, likelihood and reversibility.
6. Consult appropriate technical, legal, security and user representatives.
7. Choose, document and communicate the decision.
8. Monitor outcomes and revise the decision if evidence changes.

This process reduces “ethical fading”, in which commercial deadlines cause people to overlook ethical consequences.

2. Accessibility and Inclusion

Accessibility is the extent to which people with disabilities can use a product, service or environment. Inclusion is broader: it concerns whether people with different identities, abilities, languages, cultures, economic circumstances and experiences can participate fairly and feel respected.

A system may be technically accessible yet socially exclusionary. For example, a website might support screen readers but require an expensive smartphone and continuous high-speed internet. Inclusive design considers the whole service, not merely the interface.

Important accessibility practices include:

• providing text alternatives for meaningful images;
• ensuring keyboard navigation and visible focus indicators;
• using sufficient colour contrast and not relying on colour alone;
• providing captions and transcripts for audio or video;
• labelling form controls and explaining errors clearly;
• supporting text enlargement, responsive layouts and assistive technologies;
• avoiding time limits where possible, or allowing users to extend them;
• testing with disabled users and accessibility tools.

The Web Content Accessibility Guidelines (WCAG) organise accessibility around four principles: content should be perceivable, operable, understandable and robust. WCAG conformance levels are commonly described as A, AA and AAA. Organisations should identify the level required by applicable law, procurement rules or risk assessment rather than claiming conformance without evidence.

Inclusive practice begins before implementation. Personas, user research and requirements should represent diverse users. Accessibility acceptance criteria belong in the product backlog, design reviews, test plans and release gates. Automated tools can detect some problems, but they cannot replace manual testing and participation by people with relevant lived experience.

3. Intellectual Property and Software Licensing

Intellectual property (IP) protects creations and business interests. Common categories include:

Copyright usually arises automatically in original software, but ownership depends on jurisdiction, employment arrangements and contracts. A developer may write code but not own it if it was created within employment duties or assigned by agreement. Open-source code is not “free of all conditions”. Its licence determines permitted use, modification and redistribution.

Licence families

• Permissive licences such as MIT, BSD and Apache 2.0 generally allow reuse, modification and distribution, subject to conditions such as preserving notices. Apache 2.0 also includes an express patent licence with conditions.
• Weak copyleft licences such as LGPL permit broader combination with other software while imposing specific obligations on modifications to the covered component.
• Strong copyleft licences such as GPL generally require distribution of covered derivative works under the same licence when distributed, subject to the licence’s terms.
• Proprietary licences grant defined permissions while retaining ownership and restricting copying, modification or redistribution.

The exact legal effect depends on the licence text and jurisdiction. Teams should maintain a software bill of materials (SBOM), record component versions and licences, review compatibility, preserve notices and obtain approval for exceptions. Copying code from a public repository without reading its licence is poor professional practice.

4. Data Protection and Privacy

Privacy concerns people’s ability to control information about themselves. Data protection laws differ by jurisdiction, but many frameworks share principles such as lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, security and accountability.

Important terms include:

• Personal data: Information relating to an identified or identifiable person.
• Sensitive or special-category data: Data receiving additional legal protection, such as health or biometric information in many regimes.
• Controller: The party deciding why and how personal data is processed.
• Processor: A party processing data on behalf of a controller.
• Data subject: The person to whom the data relates.
• Processing: Operations such as collection, storage, analysis, sharing or deletion.

Privacy by design means considering privacy from requirements through retirement. A team should define the purpose, collect only necessary data, provide an understandable notice, restrict access, encrypt data where appropriate, establish retention periods and support lawful rights requests. Test data should be synthetic or properly de-identified; production personal data should not be copied casually into development environments.

Security is necessary but not sufficient. Encryption, authentication, authorisation, logging, patching, backups and incident response protect data, but a perfectly secure system can still be unlawful if it collects excessive information for an unjustified purpose.

A privacy impact or data protection impact assessment is appropriate where processing is likely to create significant risks, such as large-scale monitoring, sensitive data processing or automated decisions. It should describe the processing, assess necessity and proportionality, identify risks and document mitigations.

5. Sustainability and Responsible Computing

Software affects sustainability through the energy and materials used by devices, networks and data centres, and through the replacement and disposal of hardware. Software can also reduce environmental impact—for example, by optimising transport or supporting remote collaboration—but such claims require evidence.

Practical measures include:

• efficient algorithms and data structures;
• reducing unnecessary network transfers and storage;
• caching and appropriate data retention;
• efficient queries and batch processing;
• right-sizing cloud resources and shutting down unused environments;
• designing for repair, longevity and lower hardware requirements;
• measuring rather than assuming that a “cloud” service is environmentally harmless.

A useful conceptual model is life-cycle thinking: identify impacts during development, deployment, operation, maintenance and disposal. Sustainability must be balanced with safety, security, accessibility and reliability. For example, reducing logging may save storage but weaken incident investigation. The correct response is to classify logs, retain essential records and remove unnecessary data—not to eliminate accountability controls.

6. Algorithmic Bias, Fairness and Human Oversight

An algorithm may produce unequal outcomes because of biased training data, historical discrimination, unrepresentative samples, proxy variables, measurement errors or deployment conditions. Bias can enter during problem definition as well as model development.

Relevant distinctions include:

• Equality: Applying the same rule or resource to everyone.
• Equity: Addressing unequal starting conditions to achieve fair opportunity.
• Disparate impact: A seemingly neutral practice producing substantially worse outcomes for a protected group.
• Fairness metric: A defined way of assessing group or individual treatment.

There is no single fairness measure that is appropriate for every context. For binary classification, a team may compare the selection rate for a group:

The variable g denotes a defined group. This measure is descriptive, not proof of fairness. Other measures include false-positive and false-negative rates, calibration and equal opportunity. Some measures cannot generally be satisfied simultaneously when groups have different base rates, so the relevant harm, legal requirement and decision context must guide the choice.

Responsible practice includes documenting the intended use, data provenance, excluded uses, performance by relevant groups, uncertainty and known limitations. Teams should test before deployment and monitor after deployment. High-impact decisions should provide meaningful human review, a way to challenge outcomes and a route to correction. Human involvement is not meaningful if the reviewer has no time, information or authority to disagree with the system.

7. Governance, Standards and Compliance Controls

Governance is the system by which an organisation directs and controls technology. It allocates authority, defines objectives, manages risk and provides assurance. Management establishes policy, but governance must be implemented through operational controls.

A useful distinction is:

• Policy: What the organisation requires.
• Standard: A mandatory or recommended specification of practice.
• Procedure: The steps for carrying out a task.
• Control: A mechanism that prevents, detects or corrects risk.
• Evidence: Records showing that a control operated.
• Assurance: Independent or structured evaluation of whether controls are effective.

Examples of controls include peer review, separation of duties, access approval, change management, vulnerability scanning, privacy reviews, licence checks, accessibility testing, model documentation and incident exercises.

Governance across the life cycle

Standards such as ISO/IEC 27001 for information-security management and ISO/IEC 27701 for privacy information management can structure organisational controls. ISO/IEC 42001 addresses artificial-intelligence management systems. NIST frameworks and the OWASP Software Assurance Maturity Model are also useful sources of practice. Standards support governance but do not automatically prove that a particular system is safe or lawful.

Compliance should be risk-based and evidence-led. A compliance matrix can map each obligation to an owner, control, evidence source, review frequency and status. Audits should test operating effectiveness, not merely whether a policy exists.

8. Accountability and Incident Response

Accountability means that responsibility is assigned and decisions can be explained. It is supported by:

• named system and data owners;
• a decision log recording assumptions and approvals;
• traceable requirements and change history;
• clear escalation routes;
• access and activity logs protected against inappropriate alteration;
• incident reporting and corrective-action tracking;
• independent review for high-risk systems.

A useful incident sequence is: detect, contain, assess, notify where required, remediate, recover and learn. Notification duties and deadlines vary by jurisdiction and incident type; therefore, teams should not improvise legal advice during an incident. They should activate the approved response plan and involve the designated legal, privacy and security functions.

Whistleblowing and escalation mechanisms should protect people who raise good-faith concerns. Retaliation discourages reporting and increases organisational risk.

9. Illustrative Case: Automated Scholarship Screening

Background

A college introduces an automated system to rank scholarship applications. It uses examination results, household information, attendance and a historical record of previous awards.

Problem

After deployment, applicants from one neighbourhood receive awards at a much lower rate. The college argues that the model uses no protected characteristic such as ethnicity. A review finds that neighbourhood and school attended act as proxies for socioeconomic and demographic differences. Historical awards also reflect earlier unequal access to guidance.

Analysis

The system presents several risks. First, the training outcome may reproduce historical discrimination. Second, applicants were not clearly told how automation affected their application. Third, the model’s errors may be difficult to challenge. Fourth, collecting household information creates privacy and security obligations. Finally, the college has not defined who is accountable for decisions.

A simple selection-rate comparison could identify an outcome difference, but it would not by itself establish the cause or determine the legally correct remedy. The college should examine data quality, legitimate eligibility criteria, error rates, accessibility of the application process and the consequences of false rejection.

Approach and solution

The college pauses fully automated rejection, informs applicants about the system, appoints a responsible owner and conducts an impact assessment. It removes unnecessary variables, reviews data provenance, tests performance across relevant groups and establishes human review for borderline or adverse decisions. Applicants receive reasons, correction procedures and an appeal route. The model card records intended use, limitations, evaluation results and prohibited uses. An independent committee reviews the system before each annual cycle.

Outcome

The revised process produces a smaller but more defensible role for automation. Some applications require additional human review, increasing processing time, but applicants gain transparency and a meaningful opportunity to correct errors. The college also discovers that improving outreach and application accessibility addresses part of the inequality more effectively than changing the model alone.

Learning points

1. Removing protected attributes does not remove bias.
2. Historical data can encode institutional disadvantage.
3. Human oversight must have genuine authority.
4. Transparency, appeal and correction are governance controls.
5. Fairness requires examining the wider process, not only model accuracy.

10. Challenges and Limitations

Ethical governance cannot eliminate all disagreement or risk. Legal requirements differ across countries, and standards may be interpreted differently. Fairness measures can conflict; privacy protection can limit data needed for bias evaluation; accessibility improvements may require redesign rather than a quick technical patch. Small organisations may lack specialist staff, while large organisations may have policies that are disconnected from daily practice.

There is also a danger of “ethics washing”: publishing principles without changing incentives, testing or accountability. Governance becomes credible when it affects budgets, release decisions, performance evaluation and executive responsibility. Documentation is valuable only when it is accurate, maintained and used.

11. Best-Practice Checklist

Before release, a software team should be able to answer “yes” to most of the following:

• Have affected users and communities been identified and consulted?
• Are accessibility and inclusion requirements tested with representative users?
• Are ownership, third-party components and licence obligations recorded?
• Is personal data necessary, protected, retained only as long as justified and covered by an appropriate notice?
• Have security, environmental and operational risks been assessed?
• Has algorithmic performance been evaluated for relevant groups and failure modes?
• Are decisions, owners, approvals and exceptions documented?
• Can users obtain explanations, corrections, human review or appeal where appropriate?
• Are incidents reportable through a tested response process?
• Is there evidence that controls operated, rather than merely a policy statement?

Chapter Summary

Professional software engineering includes duties to users, clients, colleagues, society and the environment. Ethics guides judgement where rules are incomplete; governance assigns authority and accountability; compliance translates legal, contractual and standards-based obligations into controls and evidence. Accessibility and inclusion require participation by diverse users and testing beyond automated checks. Intellectual property and licences determine how software may be used and distributed. Data protection requires justified purposes, minimisation, security, transparency and accountability. Sustainability demands life-cycle thinking. Algorithmic systems require attention to biased data, unequal outcomes, transparency, human oversight and appeal. Effective governance operates across the entire life cycle through owners, reviews, risk assessments, documentation, monitoring and incident response.

Key Terms

Professional ethics: Principles guiding responsible professional conduct.

Governance: Direction and control of organisational activity.

Compliance: Meeting applicable laws, regulations, contracts, standards and policies.

Accessibility: Ability of people, including disabled people, to use a system.

Inclusion: Fair participation and respect for diverse people and circumstances.

Intellectual property: Legal rights protecting creations, inventions, identifiers and confidential knowledge.

Copyright: Protection for original expressive works, including software code.

Open-source licence: Licence granting defined rights to use, modify or distribute software.

Software bill of materials: Inventory of software components and their metadata.

Personal data: Information relating to an identified or identifiable person.

Data controller: Party deciding why and how personal data is processed.

Data processor: Party processing data on behalf of a controller.

Data minimisation: Collecting and using no more personal data than necessary.

Privacy by design: Integrating privacy considerations into system design and operation.

Algorithmic bias: Systematic unfairness associated with data, design or deployment.

Human oversight: Competent human ability to review, challenge and intervene in system decisions.

Control: Mechanism that prevents, detects or corrects a risk.

Assurance: Evaluation of whether governance and controls are suitable and effective.

Accountability: Ability to assign responsibility and explain decisions and actions.

Impact assessment: Structured analysis of risks, consequences and mitigations.

Review Questions

Short Answer Questions

1. Distinguish professional ethics from legal compliance.
2. State the four principles of WCAG.
3. Why is an open-source component not automatically free of obligations?
4. Explain data minimisation.
5. Give two reasons why removing a protected attribute may not eliminate algorithmic bias.

Long Answer Questions

1. Explain how accessibility and inclusion should be addressed throughout the software development life cycle.
2. Compare permissive, weak copyleft and strong copyleft software licences.
3. Describe the main data-protection principles relevant to a mobile application collecting user information.
4. Explain how governance converts organisational policy into operational assurance.
5. Discuss the roles of documentation, human oversight and appeal in high-impact automated decisions.

Analytical / Application Questions

1. A company wants to copy production customer data into a shared test environment to accelerate development. Analyse the ethical, privacy and security risks and recommend controls.
2. An online recruitment model selects candidates at equal rates across two groups but produces many more false negatives for one group. What further analysis and governance actions are required?
3. A release manager wants to ship a system that fails keyboard navigation tests because the deadline is commercially important. Prepare a professionally justified response, including escalation and possible alternatives.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes governance from compliance?

A. Governance assigns direction, authority and accountability, while compliance concerns meeting applicable obligations.

B. Governance is limited to writing source code, while compliance is limited to testing.

C. Governance applies only to public organisations, while compliance applies only to private organisations.

D. Governance replaces all legal and regulatory requirements.

Correct Answer: A. Governance assigns direction, authority and accountability, while compliance concerns meeting applicable obligations.

Question 2

Which WCAG principle requires content to work with current and future user agents, including assistive technologies?

A. Perceivable

B. Operable

C. Understandable

D. Robust

Correct Answer: D. Robust

Question 3

What is the primary purpose of an SBOM?

A. To record the visual design of an application

B. To inventory software components and their metadata

C. To replace all software testing

D. To calculate a project budget

Correct Answer: B. To inventory software components and their metadata

Question 4

Which practice best supports data minimisation?

A. Collecting every available field in case it becomes useful later

B. Keeping personal data indefinitely

C. Collecting only data necessary for a defined and justified purpose

D. Copying production data into all development environments

Correct Answer: C. Collecting only data necessary for a defined and justified purpose

Question 5

Why can an algorithm remain biased even when it does not use ethnicity as an input?

A. Algorithms cannot process numerical data

B. Other variables may act as proxies for ethnicity or reflect historical inequality

C. Removing a variable always makes predictions random

D. Bias exists only when programmers intentionally discriminate

Correct Answer: B. Other variables may act as proxies for ethnicity or reflect historical inequality

Question 6

Which item is an example of a preventive control?

A. A post-incident report

B. A public complaint after release

C. Approval and peer review before a production change

D. A retrospective after a system failure

Correct Answer: C. Approval and peer review before a production change

Question 7

What is the most appropriate response when an accessibility defect creates a serious barrier immediately before release?

A. Ignore it because accessibility is optional

B. Document the risk, escalate it and evaluate remediation or a justified release decision

C. Remove all accessibility tests permanently

D. Ask users to purchase different devices

Correct Answer: B. Document the risk, escalate it and evaluate remediation or a justified release decision

Question 8

Which statement about human oversight is most accurate?

A. Any human presence automatically makes an automated decision fair

B. Oversight is meaningful only when the reviewer has information, time and authority to intervene

C. Human reviewers should never question model output

D. Human oversight eliminates the need for system testing

Correct Answer: B. Oversight is meaningful only when the reviewer has information, time and authority to intervene

Question 9

Which activity most directly supports software sustainability?

A. Retaining all logs forever

B. Deploying unused cloud resources continuously

C. Reducing unnecessary data transfer and right-sizing computing resources

D. Replacing efficient code with more hardware regardless of need

Correct Answer: C. Reducing unnecessary data transfer and right-sizing computing resources

Question 10

Which sequence best represents a typical incident-response process?

A. Detect, contain, assess, notify where required, remediate and learn

B. Delete, deny, conceal, relaunch and forget

C. Design, advertise, sell, archive and outsource

D. Test, patent, trademark, license and invoice

Correct Answer: A. Detect, contain, assess, notify where required, remediate and learn