12. Project Management, Leadership and Team Practice

Introduction and Context

Cybersecurity work is often described through technical activities—designing controls, testing systems, investigating incidents, or remediating vulnerabilities. Yet technical competence alone does not ensure a successful security outcome. Cybersecurity initiatives are temporary or ongoing organizational projects involving people, budgets, dependencies, competing priorities, regulatory obligations, and operational risk. A technically excellent security solution may fail if it is delivered late, poorly communicated, inadequately tested, rejected by users, or not maintained after implementation.

Project management provides the disciplined means to transform a security objective into an achievable body of work. Leadership gives that work direction, legitimacy, and ethical purpose. Team practice determines whether specialists can coordinate effectively across technical, business, legal, compliance, and operational boundaries. These capabilities are especially important in cybersecurity because the work is characterized by uncertainty, adversarial pressure, urgent incidents, confidential information, and rapid changes in technology and threat conditions.

This chapter examines how cybersecurity professionals plan and govern projects, select agile or hybrid approaches, allocate resources, assure quality, control change, resolve conflict, and lead multidisciplinary teams. The emphasis is not on applying a generic project-management template, but on making informed choices that preserve security, resilience, accountability, and organizational value.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the relationship between cybersecurity strategy, projects, programmes, and operational work.

2. Select and adapt agile, predictive, or hybrid delivery approaches for security initiatives.

3. Develop scope, work breakdown, schedules, resource plans, risk registers, and meaningful measures.

4. Apply quality assurance, security gates, change control, and acceptance practices.

5. Evaluate leadership approaches and build effective multidisciplinary cybersecurity teams.

6. Diagnose and resolve conflict while maintaining psychological safety and professional accountability.

7. Analyse ethical, governance, regulatory, and emerging technology issues in security project delivery.

Cybersecurity Work as a Managed System of Decisions

A cybersecurity project is a temporary undertaking intended to create, improve, or retire a security capability. Examples include implementing identity governance, conducting a cloud migration securely, replacing a security information and event management platform, performing a penetration test, or preparing for an external audit. Operational activities, such as daily alert triage or patch monitoring, are generally continuous, although projects may redesign or automate them.

The distinction matters because projects have defined outcomes, constraints, sponsors, stakeholders, and completion criteria. A project should therefore answer five questions: What security problem is being addressed? What outcome will demonstrate success? Who owns the risk and the decisions? What resources and time are available? How will the organization know that the result is safe and usable?

Cybersecurity projects frequently form part of a programme, such as a zero-trust transformation or regulatory compliance programme. A programme coordinates related projects so that benefits, dependencies, architecture, and risks are managed collectively. A portfolio provides an even broader investment view, allowing leaders to compare projects and allocate scarce resources according to risk reduction, strategic alignment, regulatory need, and organizational capacity.

A useful planning principle is to distinguish outputs from outcomes. A new vulnerability scanner is an output; a sustained reduction in exploitable exposure is an outcome. A security awareness course is an output; improved reporting of suspected phishing is an outcome. Effective governance evaluates both delivery and realized benefit.

Choosing a Delivery Approach

Predictive delivery

A predictive or plan-driven approach defines much of the scope, sequence, and acceptance criteria before execution. It is appropriate when requirements are stable, dependencies are extensive, assurance evidence must be produced in a controlled sequence, or a formal approval process is required. Examples include a data-centre security redesign, a regulated system accreditation, or a major physical-security installation.

The strength of this approach is visibility: sponsors can approve a baseline budget, schedule, architecture, and set of deliverables. Its weakness is that security assumptions may become obsolete while the project is underway. A detailed plan can also create false confidence when threat conditions or business requirements change.

Agile delivery

Agile methods use short iterations, frequent stakeholder feedback, prioritized backlogs, and incremental delivery. In a security context, an iteration might produce an automated control test, a group of prioritized detection rules, a deployable policy-as-code module, or a tested remediation workflow. Agile delivery is valuable where learning is necessary and requirements evolve.

A product backlog should express security value rather than merely list technical tasks. “Configure dashboard” is weaker than “enable the incident team to identify privileged-account anomalies within five minutes.” User stories, acceptance criteria, threat assumptions, and security constraints should be visible in the backlog. Security work must not be relegated indefinitely to a separate queue; it should be integrated into the definition of ready and definition of done.

Agile does not mean uncontrolled change or absence of documentation. Design decisions, risk acceptance, test evidence, and operational runbooks remain necessary. Short cycles increase feedback; they do not remove accountability.

Hybrid delivery

Most substantial cybersecurity initiatives are hybrid. Strategic architecture, funding, privacy review, procurement, and regulatory approvals may require predictive governance, while configuration, testing, and user feedback benefit from iterative delivery. A hybrid model can establish stage gates for business cases and high-risk deployment while using agile teams within each stage.

The choice should be based on uncertainty, criticality, reversibility, stakeholder availability, dependency density, and assurance requirements. Leaders should avoid selecting agile merely because it is fashionable or predictive delivery merely because it appears orderly. The appropriate question is how to learn quickly while keeping risk within approved limits.

From Security Objective to Executable Plan

Planning begins with a concise problem statement and a measurable outcome. For example: “Reduce the risk of unauthorized privileged access by implementing phishing-resistant authentication for administrators, with verified coverage of all in-scope accounts.” The statement identifies the risk, the intervention, and a basis for acceptance.

A project charter normally records the purpose, sponsor, objectives, scope boundaries, assumptions, constraints, major stakeholders, governance arrangements, budget authority, initial risks, and success measures. Scope boundaries are particularly important. A project that begins as an identity-control improvement can expand into an enterprise access redesign unless exclusions and decision rights are explicit.

A work breakdown structure decomposes outcomes into manageable work packages. For an identity project, packages may include discovery, requirements, architecture, supplier assessment, pilot, integration, migration, testing, training, operational handover, and benefits review. Decomposition should be sufficient for estimating and assigning work, but not so detailed that planning becomes administrative work without decision value.

Scheduling requires attention to dependencies. Security testing cannot always begin before a stable build exists; user migration may depend on help-desk readiness; regulatory evidence may depend on control operation over a defined period. Network diagrams, milestone plans, or backlog-based forecasting can reveal the consequences of delay. Critical-path thinking is useful even in agile settings because a short iteration does not eliminate external dependencies.

Resource planning includes more than headcount. It considers scarce expertise, decision authority, environments, licenses, test data, supplier capacity, and time from operational staff. Over-allocation of security architects or incident responders is a frequent hidden constraint. A resource plan should identify primary and backup owners, escalation routes, and periods in which operational duties may conflict with project commitments.

Estimation is uncertain. Teams may use analogous estimates, expert judgment, three-point estimates, story points, throughput data, or capacity-based planning. Estimates should be treated as decision information rather than promises of precision. Confidence ranges, assumptions, and contingency are more honest than a single unexplained date.

Governance, Quality, and Change Control

Governance defines who may decide, who must be consulted, what evidence is required, and how exceptions are recorded. A steering group may approve scope, funding, risk tolerance, and major changes. A project manager coordinates delivery; a product owner prioritizes value; technical and security leads protect architectural integrity; control owners confirm that requirements are met; and the sponsor resolves issues beyond the team’s authority.

A responsibility assignment matrix, such as RACI, can clarify roles, but it should not become a substitute for active collaboration. A person marked accountable must possess authority and capacity to act. Ambiguous accountability is especially dangerous when a project crosses information technology, procurement, legal, privacy, human resources, and business operations.

Quality assurance is broader than final inspection. It includes quality planning, peer review, secure design review, code and configuration review, test strategy, evidence management, defect tracking, and operational readiness. Quality control asks whether a deliverable meets specified criteria; assurance asks whether the delivery process is capable of producing reliable results.

Security gates may be placed at requirements, design, build, pre-production, deployment, and handover. Typical evidence includes threat modelling, architecture approval, vulnerability results, access-control verification, privacy analysis, rollback procedures, backup validation, monitoring coverage, and documented residual risk. Gates should be proportionate: excessive approval can delay urgent risk reduction, while weak approval can create unacceptable exposure.

Change control protects the integrity of approved objectives without preventing learning. A change request should describe the proposed change, reason, urgency, impact on scope, schedule, cost, security risk, architecture, compliance, and operations. The decision may be approve, reject, defer, or approve with conditions. In agile delivery, backlog reprioritization is normal; however, changes that affect risk appetite, regulated commitments, production safety, or contractual obligations still require appropriate governance.

Configuration and version control are essential forms of change control. Infrastructure-as-code, policy-as-code, signed releases, automated testing, and immutable audit trails reduce undocumented variation. Emergency changes require a fast path, not an absence of records. The change should be retrospectively reviewed and linked to the incident or risk that justified it.

Leadership and Team Practice

Cybersecurity leadership is the capacity to establish direction, enable sound decisions, develop people, and protect ethical standards under pressure. It is not synonymous with hierarchy. A security analyst who challenges an unsafe deployment, a developer who identifies an insecure dependency, or an administrator who reports an access-control weakness may exercise important leadership.

Different circumstances call for different leadership behaviours. Directive leadership can be appropriate during an active incident when rapid coordination is essential. Participative leadership is valuable during architecture and risk decisions requiring diverse expertise. Coaching leadership develops capability and autonomy. Adaptive leadership helps an organization address problems for which no single technical solution exists, such as cultural resistance to stronger authentication.

High-performing teams require a shared mission, clear roles, reliable communication, mutual trust, and mechanisms for learning. Multidisciplinary security work benefits from combining security engineering, software development, infrastructure, privacy, legal, compliance, procurement, user experience, risk management, and business operations. Diversity of expertise improves problem framing, but it can also produce conflict if language, priorities, and decision rights are not made explicit.

Useful team practices include a working agreement, regular planning and review sessions, decision logs, concise risk reporting, peer review, blameless retrospectives, and explicit escalation thresholds. Psychological safety does not mean avoiding criticism. It means people can raise concerns, admit uncertainty, and report mistakes without humiliation or retaliation, while still being accountable for professional conduct.

Communication should be adapted to the audience. Executives need risk, decision, cost, and business-impact information. Engineers need interfaces, constraints, test results, and failure conditions. Operations teams need support models, runbooks, maintenance effects, and rollback procedures. Users need understandable explanations of what changes and why. A technically accurate message can still fail if it is delivered in a form that the audience cannot use.

Conflict Resolution and Negotiation

Conflict is not necessarily dysfunctional. Disagreement about risk, architecture, sequencing, or resource allocation can expose assumptions and prevent groupthink. Conflict becomes harmful when it is personalized, concealed, repeatedly unresolved, or decided through inappropriate power rather than evidence.

A practical resolution process is to identify the issue, separate positions from interests, establish shared facts, assess consequences, generate options, decide according to authority and risk, and document the decision. For example, a development team may oppose a proposed security control because it threatens release timing. The underlying interests may be availability, contractual delivery, and manageable implementation effort. Options might include phased enforcement, compensating monitoring, a controlled exception, or a revised release plan.

Leaders should distinguish technical disagreement from misconduct, conflicts of interest, and unacceptable pressure to conceal risk. Escalation is appropriate when a decision exceeds the team’s authority, affects legal or regulatory duties, creates a material safety risk, or cannot be resolved impartially. Negotiation must never be used to trade away mandatory controls without an authorized risk decision.

Measures and Benefits Realization

Project measures should support decisions rather than reward activity. Delivery measures include milestone reliability, backlog completion, defect age, test coverage, unresolved dependencies, and change volume. Security measures may include control coverage, exposure reduction, time to remediate agreed weaknesses, detection quality, privileged-account coverage, or recovery-test results. Human measures may include training completion, adoption, support demand, and user-reported friction.

Metrics require interpretation. A declining vulnerability count might indicate effective remediation—or reduced scanning. Faster incident closure might indicate better capability—or premature closure. Measures should therefore be triangulated, defined consistently, and reviewed for unintended incentives. Leading indicators, such as unresolved design risks, can enable intervention before failure; lagging indicators, such as incidents or audit findings, show realized consequences.

Benefits realization continues after project closure. A handover should identify the operational owner, service-level expectations, maintenance tasks, monitoring, funding, documentation, and review date. Without ownership, a project may deliver a control that gradually becomes ineffective. Post-implementation reviews should examine whether the intended outcome occurred, what assumptions failed, and which lessons should influence the portfolio.

Illustrative Case: Securing a University Research Cloud

Background

A fictional university, Northbridge University, operates research platforms containing intellectual property, personal data, and externally funded project information. Researchers have adopted cloud services independently, creating inconsistent identity controls, unclear data ownership, and limited central visibility. The university launches a nine-month project to improve cloud security without obstructing research collaboration.

Situation and problem

The sponsor initially proposes “centralizing all cloud accounts.” Researchers argue that a rigid central model will delay grants and prevent collaboration with external laboratories. The security team identifies excessive privileges, inactive accounts, and inconsistent logging, but lacks reliable asset and data inventories. The project has a fixed funding period, several suppliers, and limited availability from research staff.

Analysis

The project team maps stakeholders and discovers that the apparent technology problem is also a governance and operating-model problem. A purely predictive implementation would risk designing controls before understanding research workflows. A completely informal agile approach would not provide sufficient privacy, procurement, or risk accountability. The team therefore selects a hybrid model.

The charter defines outcomes: all in-scope cloud accounts must have an accountable owner; privileged access must use stronger authentication and time-limited elevation; critical activity must be logged and reviewed; and exceptions must have documented owners and expiry dates. It explicitly excludes immediate migration of every research workload.

Approach

The steering group establishes stage gates for scope, architecture, privacy review, and production readiness. Within those gates, a cross-functional team works in three-week iterations. A pilot with two research groups tests federated identity, privileged-access workflows, logging, and support procedures. Researchers participate in backlog refinement and evaluate whether controls support legitimate collaboration.

The team uses a risk-based backlog. High-value items include discovery of account ownership, removal of dormant privileged accounts, automated baseline checks, and a self-service exception process. Each item has acceptance criteria, including evidence that the control works, does not expose sensitive data unnecessarily, and can be supported by operations.

A conflict emerges when the research office requests a one-year exception for external collaborators, while security policy permits only ninety days. Rather than treating the matter as a technical dispute, the project team identifies the interest: continuity of long-running research. The approved compromise uses ninety-day renewals, named accountable owners, stronger authentication, activity logging, and review by the research data-governance group.

Outcome

The project delivers a repeatable onboarding process, improved ownership records, stronger privileged access, centralized critical logging, and a governed exception mechanism. Some legacy workloads remain outside the initial scope, but they are visible in a prioritized roadmap. The university avoids claiming that all cloud risk has been eliminated; instead, it records residual risk and assigns operational ownership.

Learning points

The case illustrates that scope should be defined around risk outcomes, not an attractive but unrealistic technical ambition. Hybrid delivery can combine formal assurance with iterative learning. Stakeholder participation improves control usability, while explicit exceptions preserve accountability. Most importantly, project completion is not the same as sustained security capability.

Challenges, Risks, and Common Failure Patterns

Security projects commonly fail through unclear outcomes, optimistic estimates, weak sponsorship, hidden dependencies, inadequate operational participation, and insufficient attention to adoption. A project may also become a “security theatre” exercise in which evidence is produced for an audit without improving real protection.

Other risks include scope creep disguised as urgent work, excessive reliance on a single specialist, supplier lock-in, insecure project tooling, leakage of sensitive information in tickets or collaboration platforms, and inadequate separation of duties. Incident response demands may repeatedly interrupt planned work. Leaders should protect capacity for urgent events while making the impact on the plan visible.

A common mistake is to treat risk registers as static documents. Risks should have owners, triggers, responses, due dates, and escalation thresholds. Another is to report green status because milestones were achieved while unresolved defects and residual risks are hidden. Honest reporting may create short-term discomfort but enables timely intervention.

Ethical, Governance, and Professional Considerations

Cybersecurity leaders exercise power over access, monitoring, privacy, and organizational continuity. Decisions should be necessary, proportionate, transparent to legitimate stakeholders, and consistent with applicable law and policy. Monitoring projects require careful consideration of purpose limitation, data minimization, retention, employee expectations, and access to monitoring records.

Professional integrity requires accurate reporting of test results, limitations, incidents, and residual risk. A project manager or technical lead must not suppress an adverse finding to protect a deadline. Risk acceptance should be made by an authorized person who understands the consequences; it should not be implied by silence.

Procurement and supplier relationships also create ethical duties. Evaluation criteria should be defensible, conflicts of interest disclosed, and security obligations clearly allocated. Teams should avoid discriminatory assumptions in automated security decisions and should provide mechanisms for review when legitimate users are blocked.

Technology, Automation, and Emerging Practice

Digital project tools can connect backlogs, source control, architecture records, test evidence, risk registers, and deployment pipelines. DevSecOps practices embed security checks into development and operations, including dependency analysis, secret detection, infrastructure scanning, policy-as-code, and continuous compliance evidence. Automation improves consistency and speed, but false positives, incomplete coverage, and poorly governed pipelines can scale error as efficiently as success.

Artificial intelligence can assist with backlog classification, dependency analysis, log summarization, control mapping, and drafting project reports. Its outputs require human validation because models may hallucinate evidence, misclassify risk, expose confidential information, or reproduce biased assumptions. Sensitive project data should not be entered into unapproved services. AI-assisted decisions should be traceable, reviewable, and subject to the same accountability as other project decisions.

Emerging practice increasingly emphasizes continuous authorization, automated evidence collection, resilience engineering, platform security, and measurable cyber-risk reduction. These trends reinforce rather than replace leadership fundamentals: clear ownership, appropriate assurance, transparent decisions, and learning from operational experience.

Best Practices for Cybersecurity Project Leaders

Effective practice can be summarized as follows:

• Start with a risk-based outcome and define how success will be demonstrated.
• Select predictive, agile, or hybrid delivery according to uncertainty, criticality, and assurance needs.
• Make scope boundaries, assumptions, dependencies, and decision rights visible.
• Include operations, privacy, legal, users, and business owners early enough to influence design.
• Integrate security into requirements, development, testing, deployment, and handover.
• Use proportionate quality gates and maintain reliable evidence.
• Treat changes and exceptions as governed decisions, not informal promises.
• Report status honestly, including residual risk and confidence in estimates.
• Build psychological safety while preserving accountability.
• Measure outcomes and verify benefits after delivery.

Chapter Summary

Cybersecurity project success depends on the coordinated management of outcomes, people, risk, resources, quality, and change. Projects should be distinguished from continuous operations and positioned within programme and portfolio priorities. Predictive approaches provide control where requirements and assurance needs are stable; agile approaches support learning and incremental value; hybrid approaches often fit complex security initiatives best.

Effective planning converts a security objective into scope, deliverables, dependencies, resources, milestones, measures, and accountable ownership. Governance clarifies decisions, while quality assurance, security gates, configuration control, and documented change processes protect the integrity of delivery. Leadership is distributed across the team and must combine direction, participation, coaching, ethical courage, and communication. Conflict can be constructive when it is handled through shared facts, interests, evidence, and authorized decisions.

The chapter’s central lesson is that a completed technical deliverable is not necessarily a completed security outcome. Sustainable value requires operational ownership, adoption, measurable benefits, transparent residual risk, and continuous learning.

Key Terms

Project: A temporary undertaking created to deliver a defined outcome, capability, or change.

Programme: Coordinated management of related projects to obtain benefits not available from managing them separately.

Portfolio: A collection of projects and programmes governed collectively to achieve strategic objectives.

Project charter: An authorizing document defining purpose, scope, authority, stakeholders, constraints, and initial risks.

Predictive delivery: A plan-driven approach in which scope, sequence, and acceptance are substantially defined in advance.

Agile delivery: An iterative approach using short cycles, prioritized work, feedback, and incremental delivery.

Hybrid delivery: A combination of predictive governance and iterative execution.

Work breakdown structure: A hierarchical decomposition of project outcomes into manageable work packages.

Critical path: The sequence of dependent activities that determines the earliest possible completion date.

Product backlog: A prioritized list of work required to develop or improve a product or security capability.

Security gate: A formal review point requiring specified evidence before work proceeds.

Quality assurance: Planned activities that provide confidence that processes can produce reliable results.

Change control: The governed assessment and authorization of changes to an approved baseline or plan.

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

RACI: A responsibility model identifying who is responsible, accountable, consulted, and informed.

Psychological safety: A team condition in which people can raise concerns and admit uncertainty without fear of humiliation or retaliation.

Benefits realization: The process of verifying that intended organizational value is achieved after delivery.

DevSecOps: The integration of security practices and automation throughout development and operations.

Risk acceptance: An authorized decision to retain a known risk under defined conditions.

Review Questions

Short Answer Questions

1. How does a cybersecurity project differ from a cybersecurity operational activity?

2. What is the distinction between a project output and a project outcome?

3. Identify two circumstances in which predictive delivery may be appropriate.

4. Why should security gates be proportionate to project risk?

5. What is psychological safety, and why does it matter in security teams?

Long Answer Questions

1. Compare predictive, agile, and hybrid approaches for a cybersecurity identity-management initiative.

2. Explain how a project charter, work breakdown structure, schedule, and resource plan contribute to delivery control.

3. Discuss the role of quality assurance, security testing, change control, and operational handover in cybersecurity projects.

4. Analyse how leadership style and multidisciplinary collaboration affect cybersecurity project performance.

5. Explain how ethical conduct and governance should influence monitoring, risk acceptance, supplier management, and reporting.

Analytical / Application Questions

1. A security project is on schedule, but unresolved design risks, incomplete operational training, and weak monitoring remain. How should the project manager report and govern its status?

2. A development team rejects mandatory authentication controls because they may delay a product release. Analyse the conflict and propose a resolution that preserves both delivery objectives and security accountability.

3. Design a hybrid delivery approach for a cloud-security project involving privacy review, supplier procurement, iterative configuration, user adoption, and regulatory evidence. Justify the stage gates and agile activities you select.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a cybersecurity project outcome from an output?

A. An outcome is always delivered before an output.

B. An output is a tangible deliverable, while an outcome is the security or organizational value achieved.

C. An output is strategic, while an outcome is purely technical.

D. An outcome is limited to project documentation.

Correct Answer: B. An output is a tangible deliverable, while an outcome is the security or organizational value achieved.

Question 2

Which delivery approach is generally most suitable when requirements are uncertain and frequent stakeholder feedback is needed?

A. Agile delivery

B. Fully predictive delivery

C. Fixed-scope procurement delivery

D. Unmanaged operational delivery

Correct Answer: A. Agile delivery

Question 3

Why might a cybersecurity initiative use a hybrid approach?

A. To eliminate the need for governance evidence

B. To avoid involving operational stakeholders

C. To combine formal assurance gates with iterative learning and delivery

D. To ensure that scope cannot ever change

Correct Answer: C. To combine formal assurance gates with iterative learning and delivery

Question 4

Which item is most appropriate for a project charter?

A. Every individual command used during testing

B. The project purpose, scope, authority, stakeholders, constraints, and initial risks

C. Only the final list of unresolved defects

D. A daily operational alert queue

Correct Answer: B. The project purpose, scope, authority, stakeholders, constraints, and initial risks

Question 5

A proposed change affects regulatory commitments and production safety. What is the most appropriate response?

A. Allow the technical team to implement it without documentation

B. Ignore it if the change improves user convenience

C. Apply appropriate change governance and assess risk, compliance, schedule, and operations

D. Defer all changes until project closure

Correct Answer: C. Apply appropriate change governance and assess risk, compliance, schedule, and operations

Question 6

Which practice best demonstrates quality assurance rather than merely final inspection?

A. Reviewing process capability, test strategy, peer review, and evidence throughout delivery

B. Checking only whether the final presentation is attractive

C. Counting completed meetings

D. Accepting all deliverables because the deadline was met

Correct Answer: A. Reviewing process capability, test strategy, peer review, and evidence throughout delivery

Question 7

In a conflict over a security control, what should leaders do first?

A. Assign blame to the team opposing the control

B. Separate positions from interests and establish shared facts

C. Escalate immediately without analysing the issue

D. Remove the control from the project scope

Correct Answer: B. Separate positions from interests and establish shared facts

Question 8

Which measure is most directly an outcome-oriented security measure?

A. Number of project meetings held

B. Number of dashboard screens created

C. Reduction in exploitable privileged-access exposure

D. Number of pages in the project plan

Correct Answer: C. Reduction in exploitable privileged-access exposure

Question 9

What is a key requirement for an authorized risk acceptance decision?

A. It should be implied when nobody objects

B. It should be made by an authorized person who understands the consequences

C. It should never have an expiry or review condition

D. It should replace all security testing

Correct Answer: B. It should be made by an authorized person who understands the consequences

Question 10

Why should AI-generated project or security analysis be reviewed by a human?

A. AI cannot process any project information

B. AI outputs may contain errors, unsupported conclusions, bias, or confidentiality risks

C. Human review makes governance unnecessary

D. AI is useful only for writing advertisements

Correct Answer: B. AI outputs may contain errors, unsupported conclusions, bias, or confidentiality risks