SQA Governance, Leadership and Strategic Management

Introduction

Software quality assurance (SQA) is often introduced as a collection of testing, review, measurement and process-improvement practices. At enterprise scale, however, quality is not sustained by technical practices alone. It depends on governance: the structures, decision rights, policies, controls, assurance mechanisms and leadership behaviours through which an organization directs and controls quality-related work.

Governance becomes particularly important when software is developed across multiple business units, suppliers, geographic locations, cloud platforms and regulatory environments. In such settings, quality failures may arise not because engineers lack technical competence, but because accountability is unclear, risks are accepted without authority, audit evidence is incomplete, suppliers are inadequately controlled, or executives receive information that is late, distorted or too optimistic.

SQA governance connects organizational strategy with software delivery. It establishes what “good quality” means, who is responsible for achieving it, how evidence is collected, how exceptions are approved, and how risks are escalated. Strategic quality management extends this perspective from individual projects to products, programs and portfolios.

This chapter examines governance frameworks, leadership responsibilities, accountability models, audit and compliance systems, vendor assurance, quality policies, capability development and risk-informed executive decision making. It also considers ethical issues, artificial intelligence, contemporary delivery models and the limitations of governance systems.

Learning Objectives

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

1. Explain the relationship between SQA governance, management and operational quality practices.

2. Design a governance structure with appropriate decision rights and accountability.

3. Develop quality policies, gates, controls and assurance mechanisms for software portfolios.

4. Evaluate audit, compliance and vendor-assurance arrangements.

5. Use quality metrics and risk information to support executive decisions.

6. Assess leadership practices that create a sustainable quality culture.

7. Critically evaluate the limitations and unintended consequences of quality governance.

1. Quality as an Organizational Governance Concern

Quality is a multidimensional property. It may include functional suitability, reliability, usability, performance efficiency, security, maintainability, portability, accessibility and compliance. Different stakeholders value these characteristics differently. A product owner may emphasize time to market, a regulator may emphasize traceability, a security officer may emphasize confidentiality, and an operations team may emphasize recoverability.

Governance provides a mechanism for reconciling these interests. It answers five fundamental questions:

• What quality outcomes are strategically important?
• Who has authority to define, approve and change quality expectations?
• What evidence demonstrates that expectations have been met?
• How are deviations, risks and exceptions handled?
• How does the organization learn and improve?

Governance should be distinguished from management and assurance. Governance is concerned with direction, accountability and oversight. Management plans and coordinates work to achieve objectives. Assurance provides independent or semi-independent confidence that controls and outcomes are appropriate. Quality control consists of operational activities such as reviews, testing and inspection. These functions interact but should not be treated as interchangeable.

A useful relationship is:

Strategy → Governance → Management systems → Engineering practices → Evidence and outcomes

For example, an organizational strategy may require trustworthy digital services. Governance may establish security and availability policies, mandatory architecture review and executive risk acceptance. Management may allocate staff and schedule assurance activities. Engineering teams may implement threat modelling, automated testing and resilient deployment. Evidence may include test results, audit trails, incident records and service-level measurements.

2. Principles of SQA Governance

2.1 Accountability is explicit

A governance system should identify the person or role accountable for each significant quality outcome. Shared participation is valuable, but “everyone is responsible” often means that no one is answerable when a decision is required. Accountability should exist for product quality, process compliance, security, supplier performance, release approval and risk acceptance.

2.2 Decision rights match risk

Low-risk decisions should remain close to delivery teams. High-impact decisions require broader review and, in some cases, executive approval. Governance becomes inefficient when every decision is escalated, and unsafe when major decisions are left to informal local judgement.

2.3 Evidence supports claims

Quality assertions should be supported by credible evidence. A statement such as “the system is secure” is weak unless the organization can identify the threat model, security requirements, test results, vulnerability status and residual risk. Evidence should be proportionate to risk rather than generated merely for administrative completeness.

2.4 Independence is balanced with collaboration

Independent assurance reduces conflicts of interest and confirmation bias. Nevertheless, assurance functions that operate entirely apart from engineering may become adversarial or disconnected from practical constraints. Effective organizations combine independent challenge with early collaboration.

2.5 Quality is designed, not inspected into a product

Testing can reveal defects, but it cannot compensate for ambiguous requirements, poor architecture, weak supplier controls or unrealistic schedules. Governance should therefore address the whole life cycle, from investment and requirements through operation and retirement.

2.6 Transparency includes uncertainty

Executives need to know not only what is known, but also what is uncertain. Reports should distinguish verified facts, estimates, assumptions, unresolved risks and management judgements. Suppressing uncertainty creates false confidence and weakens decision quality.

2.7 Proportionality prevents bureaucracy

Controls should be scaled according to factors such as safety impact, financial exposure, data sensitivity, regulatory obligations, complexity, novelty and recoverability. A small internal tool and a national payment platform should not be governed identically.

3. Governance Architecture and Accountability

3.1 Levels of governance

SQA governance commonly operates at four levels:

Enterprise level. Establishes quality principles, corporate policies, risk appetite, common standards and major assurance expectations.

Portfolio or program level. Prioritizes investments, resolves cross-project dependencies, compares risks and allocates quality capability across initiatives.

Product or project level. Defines quality objectives, release criteria, quality plans, roles, controls and evidence for a particular product.

Team and operational level. Executes engineering practices, records evidence, monitors production quality and responds to incidents.

These levels should be connected without imposing unnecessary duplication. Enterprise policies should define minimum expectations, while product teams should be able to select suitable methods within those boundaries.

3.2 Common governance bodies and roles

A quality governance structure may include the following:

• Board or executive committee: approves risk appetite, oversees material quality risks and ensures that quality supports organizational strategy.
• Chief information or technology officer: integrates technology quality with business priorities and investment decisions.
• Chief information security officer or security authority: governs security risk, controls and incident readiness.
• Quality council: maintains quality policies, standards, metrics and cross-portfolio improvement priorities.
• Architecture review board: evaluates design integrity, interoperability, resilience and technical debt.
• Product owner or business sponsor: owns business value and accepts product-level trade-offs.
• Project or delivery manager: coordinates scope, schedule, resources, risks and dependencies.
• SQA or quality manager: defines assurance activities, monitors evidence and reports quality status.
• Engineering team: creates and verifies the product, maintains technical quality and addresses defects.
• Internal audit: independently evaluates governance, risk management and control effectiveness.
• Supplier manager: monitors third-party obligations, performance and remediation.

The exact titles vary, but the functions should be present where relevant.

3.3 RACI and decision accountability

A RACI model identifies who is Responsible, Accountable, Consulted and Informed for an activity. It is useful for revealing gaps and overlaps, but it is not a substitute for judgement. Each major decision should normally have one clearly accountable role, even if several groups are responsible for contributing work.

For example, in a release decision:

• Engineering may be responsible for completing verification.
• SQA may be responsible for assessing evidence.
• Security may be consulted on vulnerabilities.
• The product owner may be accountable for business acceptance.
• Executives may be informed when residual risk exceeds a defined threshold.

A governance charter should specify the scope of each authority, quorum requirements, escalation routes, decision records and review frequency.

4. Strategic Quality Management

Strategic quality management translates organizational objectives into quality capabilities and measurable outcomes. It requires more than selecting a quality standard. It asks how quality contributes to competitiveness, trust, resilience, legal compliance and sustainable cost.

4.1 Quality policy and quality objectives

A quality policy should express organizational commitments, such as:

• protecting users and sensitive information;
• meeting applicable legal and contractual obligations;
• using risk-based assurance;
• encouraging early defect prevention;
• making quality information visible to decision makers;
• continuously improving processes and capabilities.

The policy must be converted into objectives. A weak objective is “improve quality.” A stronger objective may be “reduce escaped high-severity defects in customer-facing releases while maintaining agreed delivery frequency.” Objectives should identify scope, ownership, measurement method, target or decision rule, and review period.

4.2 Portfolio quality management

At portfolio level, quality management addresses trade-offs among initiatives. A portfolio may contain a modernization program, a regulatory project, a legacy system stabilization effort and several experimental products. Each has different risk characteristics and assurance needs.

Portfolio governance should examine:

• concentration of technical and supplier risk;
• shared platforms and single points of failure;
• cumulative technical debt;
• capability bottlenecks in testing, security or architecture;
• duplicated controls and tooling;
• quality trends across products;
• risks created by simultaneous releases or migrations.

A portfolio dashboard should not simply rank teams by defect counts. It should provide context: product criticality, exposure duration, severity, operational impact, trend direction, confidence in the data and management response.

4.3 Quality gates and stage governance

A quality gate is a decision point at which defined evidence is reviewed before work proceeds. Gates may occur at investment approval, requirements baseline, architecture approval, test readiness, release readiness and post-implementation review.

A gate should specify:

1. entry and exit criteria;

2. required evidence;

3. decision authority;

4. treatment of incomplete evidence;

5. escalation and exception procedures;

6. conditions for re-review.

Gates should not become ceremonial approvals. If every project passes regardless of evidence, the gate has no control value. Conversely, if criteria are rigid and disconnected from risk, teams may optimize paperwork rather than quality.

5. Risk-Informed Executive Decision Making

Software decisions are made under uncertainty. Executives may need to choose whether to release with known defects, delay a launch, replace a supplier, fund remediation or accept technical debt. SQA governance should make these decisions explicit rather than allowing them to occur informally.

A risk statement normally identifies a cause, uncertain event and consequence. For example: “Because the recovery process has not been tested at the expected transaction volume, a regional outage may cause prolonged service unavailability and contractual penalties.”

Risk assessment may use qualitative scales such as low, moderate and high, or quantitative estimates where reliable data exist. A simple expected-loss estimate can be expressed as:

Expected loss = Probability of adverse event × Impact if the event occurs

This relationship is useful only when probability and impact are defined consistently and the assumptions are understood. It should not be treated as a precise prediction when evidence is weak. Impacts may include financial loss, safety consequences, legal exposure, reputation damage and operational disruption.

Risk responses include avoidance, reduction, transfer and acceptance. Acceptance is a valid response only when the accountable authority understands the residual risk and has authority under the organization’s risk appetite. A project manager should not silently accept an enterprise-level regulatory risk merely because the schedule is under pressure.

Executive quality reporting should include:

• the decision required;
• the relevant evidence and its confidence;
• the principal risks and dependencies;
• options and trade-offs;
• recommended action;
• owner and due date;
• residual risk after the proposed action.

Metrics should support decisions, not create an illusion of control. For example, a high test-case execution rate does not prove that test design covers the most important risks.

6. Audit, Compliance and Control Systems

6.1 Assurance and audit

An audit evaluates whether governance, processes or controls meet defined criteria. Internal audit generally provides independent assurance to management and governing bodies. External audits may support certification, contractual assurance or regulatory oversight.

An effective audit system includes:

• a defined audit universe;
• risk-based planning;
• clear criteria and scope;
• competent auditors;
• documented evidence;
• objective findings;
• root-cause analysis;
• corrective-action ownership;
• follow-up and closure verification.

Audits should distinguish nonconformity from opportunity for improvement. A control may be absent, inadequately designed, inconsistently operated or poorly evidenced. These conditions have different implications and require different remedies.

6.2 Compliance as a control design problem

Compliance is not equivalent to collecting documents. The organization must identify obligations, translate them into controls, assign control owners, gather evidence and monitor effectiveness. Examples include privacy obligations, accessibility requirements, financial controls, software licensing, records retention, cybersecurity regulations and contractual service levels.

A compliance control should answer:

• What obligation does it address?
• What risk does it reduce?
• Who owns it?
• How frequently does it operate?
• What evidence is retained?
• What happens when it fails?

Control libraries and traceability matrices can connect obligations to requirements, tests, approvals and operational evidence. However, traceability does not prove that a control is effective. A requirement may be linked to a test that is poorly designed or never exercised under realistic conditions.

6.3 Corrective and preventive action

Corrective action addresses the cause of an identified problem; preventive action addresses a potential problem or systemic weakness. Effective action focuses on root causes rather than blaming individuals. Root-cause methods may include causal analysis, fault trees, five-whys questioning and analysis of organizational conditions such as incentives, workload and communication.

Closure should require evidence that the action was implemented and that it reduced recurrence risk. Merely changing a procedure document is rarely sufficient.

7. Vendor and Third-Party Quality Assurance

Organizations increasingly depend on cloud providers, systems integrators, software vendors, open-source components, testing firms and managed service providers. Third-party dependence transfers some work but not necessarily accountability. The organization remains responsible for understanding risks affecting its customers and obligations.

7.1 Vendor lifecycle controls

Vendor assurance should begin before contract signature. A lifecycle approach includes:

1. Due diligence: assess capability, financial stability, security posture, references, delivery history and subcontractors.

2. Contract definition: specify quality attributes, service levels, evidence rights, audit rights, incident notification, data handling, intellectual property, continuity and exit provisions.

3. Onboarding: establish interfaces, environments, access controls, reporting and acceptance procedures.

4. Performance monitoring: review defects, incidents, service levels, responsiveness, change control and corrective actions.

5. Reassessment: increase scrutiny when risk, scope, technology or supplier conditions change.

6. Exit and transition: preserve data, documentation, continuity and knowledge required to change suppliers or bring work in-house.

Contracts should avoid vague language such as “industry-standard quality” unless the standard and evidence are defined. Acceptance criteria should address observable outcomes and responsibilities for defects discovered after delivery.

7.2 Fourth-party and supply-chain risk

A vendor may rely on further suppliers, cloud infrastructure or open-source packages. Governance should identify material fourth-party dependencies, software provenance, vulnerability notification processes and concentration risk. A supplier certificate can provide useful evidence, but it should not replace risk-based verification.

8. Leadership and Quality Culture

Quality culture is the pattern of behaviours that an organization rewards, tolerates and models. Posters and policy statements have limited influence if leaders reward speed while ignoring unsafe shortcuts.

Leaders shape quality culture by:

• making quality part of business performance rather than a specialist concern;
• allocating time and budget for prevention and technical debt reduction;
• asking evidence-based questions without encouraging concealment;
• responding to incidents with learning-oriented accountability;
• protecting staff who raise credible concerns;
• recognizing collaboration and prevention, not only heroic recovery;
• aligning incentives with sustainable outcomes.

A “blame-free” culture should not mean an absence of accountability. It means distinguishing human error, system weaknesses, risky choices and wilful misconduct. Fair accountability encourages reporting while preserving professional responsibility.

8.1 Capability development

Strategic quality requires capability planning. Organizations should assess current and target maturity in areas such as requirements engineering, test automation, security engineering, reliability, data quality, architecture, audit and supplier management.

Capability development may include communities of practice, mentoring, certification, internal training, rotations, coaching and recruitment. Training alone is insufficient if tools, processes, staffing and leadership incentives prevent people from applying what they learn.

Maturity models can structure discussion, but maturity levels should not become goals in themselves. A higher documented maturity level does not automatically produce better customer outcomes. Outcome evidence remains essential.

9. Technology, Automation and Artificial Intelligence

Governance increasingly depends on digital evidence: pipeline records, test results, configuration histories, vulnerability scans, observability data and deployment approvals. Automation can improve consistency and reduce manual effort, but automated evidence is only as reliable as its design and data.

Artificial intelligence may support test generation, defect classification, code review, anomaly detection, risk summarization and audit preparation. It also introduces governance concerns, including:

• inaccurate or fabricated recommendations;
• biased prioritization;
• unclear provenance of training data;
• leakage of confidential information;
• insecure generated code;
• overreliance by reviewers;
• difficulty explaining decisions;
• intellectual-property and licensing risks.

AI-assisted quality activities should therefore include human accountability, controlled data use, validation against representative cases, logging, model or prompt change management and defined limits on autonomous decisions. For high-impact systems, AI-generated evidence should be treated as an input to professional judgement, not as independent assurance.

10. An Illustrative Case: National Benefits Platform

The following is a fictional illustrative case.

Background

A government agency commissioned a national benefits platform to replace several regional systems. The platform processed sensitive personal data and calculated payments. A consortium of suppliers developed the application, hosted infrastructure and provided operational support.

Problem

The program was six months from its mandated launch date. Executive reports showed that 96 percent of planned test cases had been executed and that most major milestones were green. However, independent reviewers identified incomplete performance testing, inconsistent identity verification across environments, unresolved high-severity vulnerabilities and unclear responsibility for disaster recovery. Suppliers disagreed about who owned defects spanning application and infrastructure boundaries.

Analysis

The problem was not simply insufficient testing. Governance analysis found:

• no single accountable owner for end-to-end service quality;
• quality metrics focused on activity completion rather than risk exposure;
• contractual acceptance criteria that emphasized deliverables, not operational outcomes;
• exceptions approved in working meetings without recorded authority;
• supplier reports that used different severity definitions;
• no integrated evidence repository;
• schedule incentives that discouraged escalation.

The apparent green status was therefore unreliable. The program had generated substantial evidence, but the evidence did not answer the most important risk questions.

Approach

The steering committee established an end-to-end service owner and a risk-based release board. It introduced common severity definitions, a shared risk register and a mandatory decision log. Release criteria were revised to require:

• successful end-to-end identity and payment scenarios;
• performance evidence at projected peak load plus agreed resilience conditions;
• closure or formally authorized acceptance of critical vulnerabilities;
• tested backup restoration and disaster recovery;
• traceability for high-impact business rules;
• clear operational ownership and incident procedures.

The committee did not require every low-risk defect to be closed. Instead, it required explicit analysis of residual risk and authorization by the appropriate authority. Supplier contracts were amended to include cross-boundary incident responsibilities and evidence access.

Outcome

The launch was delayed by eight weeks. During the additional period, a recovery test revealed that a supposedly redundant dependency could not be restored within the required time. The issue was corrected before public release. Although the delay created political and financial pressure, the platform subsequently achieved stable operation and avoided a major payment disruption.

Learning points

1. Activity metrics can conceal important quality risks.

2. End-to-end accountability is essential in multi-supplier systems.

3. Release decisions should be based on evidence and residual risk, not status colour alone.

4. Delaying a release can be a quality success when it prevents unacceptable harm.

5. Governance must include operational resilience, not only development completion.

11. Challenges and Limitations

Governance systems have predictable failure modes. Excessive controls can slow delivery, encourage workarounds and shift attention from outcomes to documentation. Poorly chosen metrics can produce gaming: teams may reduce reported defect counts by redefining severity or postponing discovery. Independent assurance can become ceremonial if auditors lack access, competence or authority. Centralized governance can suppress local innovation, while decentralized governance can produce inconsistent controls and duplicated effort.

There are also epistemic limitations. Some software risks cannot be measured precisely before deployment. Novel attacks, emergent system interactions and organizational behaviour are difficult to predict. Quantitative risk models may give a misleading appearance of precision when probability estimates are subjective. Governance should therefore combine metrics with expert judgement, scenario analysis, operational feedback and humility about uncertainty.

Ethically, quality governance must consider people affected by software who are not represented in project meetings. Accessibility, privacy, fairness, safety and the consequences of service failure should be included in decision making. Organizations should not treat legal compliance as the complete definition of responsible quality.

12. Best-Practice Implementation Roadmap

An organization seeking to strengthen SQA governance can proceed incrementally:

1. Diagnose: map current decision rights, quality risks, controls, metrics and accountability gaps.

2. Define principles: establish risk appetite, quality commitments and proportionality rules.

3. Create governance charters: document authorities, escalation routes, evidence requirements and meeting purposes.

4. Standardize essential controls: define minimum requirements for security, testing, release, supplier management and operational readiness.

5. Build integrated evidence: connect requirements, risks, tests, approvals, defects, incidents and changes where practical.

6. Improve reporting: provide concise, decision-oriented information with uncertainty and residual risk visible.

7. Develop capability: invest in people, tools, coaching and communities of practice.

8. Assure and learn: conduct independent reviews, examine incidents, verify corrective actions and refine controls.

9. Review proportionality: remove controls that do not reduce meaningful risk and strengthen controls where evidence shows weakness.

The aim is not maximum governance. It is dependable decision making and sustainable quality at an acceptable level of risk.

Chapter Summary

SQA governance establishes the direction, accountability, decision rights and evidence mechanisms through which software quality is managed across an organization. It differs from operational quality control, management and independent assurance, although these functions must work together.

Effective governance is based on explicit accountability, risk-proportionate controls, evidence-based decisions, appropriate independence, transparency and continuous learning. Governance should operate at enterprise, portfolio, product and team levels. Quality policies must be translated into measurable objectives, quality gates and decision rules.

Audit and compliance systems should link obligations to effective controls, owners, evidence and corrective action. Vendor assurance must cover the entire supplier lifecycle, including subcontractors, cloud dependencies and exit arrangements. Leadership influences quality culture through incentives, resource allocation, psychological safety and the treatment of incidents and dissent.

Executive decisions should make residual risk, uncertainty, alternatives and accountability visible. Metrics are useful only when interpreted in context and connected to decisions. Automation and AI can strengthen assurance, but they introduce risks involving data, bias, explainability, security and overreliance. Ultimately, strategic SQA governance seeks not paperwork or perfect prediction, but trustworthy products, responsible decisions and organizational capacity to learn.

Key Terms

Governance: The structures, authorities and processes used to direct and control quality-related activity.

SQA: Software quality assurance; planned activities that provide confidence that software processes and products meet defined expectations.

Quality policy: An organizational statement of commitments and principles concerning quality.

Quality objective: A defined, measurable or assessable quality outcome linked to organizational priorities.

Accountability: The obligation of a role or person to answer for a decision or outcome.

Quality gate: A formal decision point requiring specified evidence before work proceeds.

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

Residual risk: Risk remaining after controls or treatment actions have been applied.

Assurance: Independent or semi-independent confidence that governance, controls or outcomes are appropriate.

Audit: A systematic evaluation against defined criteria, supported by evidence.

Compliance control: A defined activity intended to meet an obligation or reduce a related risk.

RACI: A responsibility model identifying Responsible, Accountable, Consulted and Informed roles.

Vendor assurance: Evaluation and monitoring of the quality, risk and control performance of suppliers.

Technical debt: The future cost created by expedient technical decisions or deferred remediation.

Quality culture: Shared behaviours and assumptions concerning quality, responsibility and improvement.

Corrective action: Action taken to address the cause of an identified problem.

Control owner: The role accountable for designing, operating or maintaining a control.

Traceability: The ability to relate requirements, risks, tests, approvals and outcomes.

Residual uncertainty: The limits of knowledge remaining after available analysis and evidence.

Portfolio governance: Oversight of quality, risk and investment across multiple products or initiatives.

Review Questions

Short Answer Questions

1. Distinguish governance, management, assurance and quality control in SQA.

2. Why should accountability be explicit in a quality governance structure?

3. What information should a quality gate define?

4. Identify four areas that should be considered in vendor assurance.

5. Why can a high test-execution percentage be a misleading quality metric?

Long Answer Questions

1. Explain how SQA governance connects organizational strategy with engineering practices and evidence.

2. Discuss the design of a risk-proportionate quality governance framework for a large software portfolio.

3. Analyze the roles of internal audit, compliance controls and corrective action in sustaining software quality.

4. Explain how leadership behaviour and organizational incentives influence quality culture.

5. Critically evaluate the benefits and limitations of using AI in software quality assurance governance.

Analytical / Application Questions

1. A critical service has passed all planned functional tests but has not completed disaster-recovery testing. As the release board, what evidence and decision options would you require, and who should authorize residual risk?

2. A supplier reports zero high-severity defects, while the customer organization records repeated major incidents. Analyze possible causes of the discrepancy and design a common assurance approach.

3. Design a portfolio quality dashboard for three products with different levels of business criticality. Explain which metrics you would include, how you would provide context and how executives should use the information.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes governance from operational quality control?

A. Governance defines direction, authority and oversight, while quality control performs operational checking activities.

B. Governance consists only of software testing, while quality control concerns budgets.

C. Governance is performed only by suppliers, while quality control is performed only by executives.

D. Governance replaces the need for engineering practices.

Correct Answer: A. Governance defines direction, authority and oversight, while quality control performs operational checking activities.

Question 2

What is the primary purpose of a quality gate?

A. To ensure that every defect is removed before any project continues.

B. To provide a formal evidence-based decision point before work proceeds.

C. To transfer accountability from the product owner to the testing team.

D. To measure team productivity without considering risk.

Correct Answer: B. To provide a formal evidence-based decision point before work proceeds.

Question 3

Which role is normally accountable for accepting a product-level business trade-off?

A. A build automation tool

B. The product owner or business sponsor

C. An individual test case

D. A subcontractor with no customer authority

Correct Answer: B. The product owner or business sponsor

Question 4

Which is the best example of a residual risk?

A. A risk identified before any controls are designed

B. A risk remaining after mitigation controls have been applied

C. A risk that has been deleted from a risk register

D. A risk that cannot affect software operation

Correct Answer: B. A risk remaining after mitigation controls have been applied

Question 5

Why should vendor assurance include exit and transition planning?

A. To guarantee that suppliers never change their prices

B. To preserve continuity and knowledge if the supplier must be replaced

C. To eliminate the need for contract monitoring

D. To ensure that all vendor decisions are made by auditors

Correct Answer: B. To preserve continuity and knowledge if the supplier must be replaced

Question 6

Which practice most directly supports a healthy quality culture?

A. Rewarding schedule achievement even when serious risks are concealed

B. Discouraging staff from reporting defects near a release date

C. Encouraging evidence-based escalation and learning from incidents

D. Measuring quality only by the number of documents produced

Correct Answer: C. Encouraging evidence-based escalation and learning from incidents

Question 7

What is a major limitation of relying only on test-case execution percentage?

A. It cannot show whether important risks are adequately covered.

B. It always decreases when automation is introduced.

C. It measures supplier financial stability directly.

D. It proves that operational resilience has been tested.

Correct Answer: A. It cannot show whether important risks are adequately covered.

Question 8

Which statement about compliance is most accurate?

A. Compliance is achieved by storing policies, regardless of whether controls operate.

B. Compliance requires translating obligations into owned controls and evidence of effectiveness.

C. Compliance is solely the responsibility of external auditors.

D. Compliance eliminates the need for risk assessment.

Correct Answer: B. Compliance requires translating obligations into owned controls and evidence of effectiveness.

Question 9

What additional governance concern is especially relevant when AI is used for quality decisions?

A. AI removes the need for human accountability.

B. AI-generated recommendations may be inaccurate, biased or difficult to explain.

C. AI guarantees complete test coverage.

D. AI prevents confidential data from being exposed.

Correct Answer: B. AI-generated recommendations may be inaccurate, biased or difficult to explain.

Question 10

Which action is most consistent with risk-proportionate governance?

A. Applying identical controls to every software product regardless of impact

B. Removing all review activities to maximize delivery speed

C. Scaling assurance according to criticality, exposure, complexity and regulatory obligations

D. Requiring executive approval for every minor code change

Correct Answer: C. Scaling assurance according to criticality, exposure, complexity and regulatory obligations