Enterprise Security Strategy and Leadership

Introduction

Enterprise information security is no longer confined to technical protection of networks and systems. It is a strategic capability that enables an organisation to pursue digital transformation while controlling operational, legal, financial, safety, privacy and reputational risk. Cloud computing, application programming interfaces, remote work, artificial intelligence, connected devices and extensive supply chains have expanded the enterprise attack surface. At the same time, boards and executives increasingly expect security leaders to explain risk in business terms, allocate scarce resources rationally and demonstrate measurable improvement.

An enterprise security strategy translates organisational purpose and risk appetite into decisions about governance, operating models, policies, people, technology, investment and assurance. It should not be a catalogue of security products. A sound strategy explains which outcomes matter, what could prevent them, how the organisation will respond, who is accountable and how performance will be evaluated.

This chapter examines the design and leadership of enterprise security programmes. It integrates risk management, governance, operating models, budgeting, workforce planning, metrics, executive reporting and third-party risk management.

Learning Objectives

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

1. Explain the relationship among business strategy, digital transformation, risk appetite and security strategy.

2. Compare major security governance and operating-model choices.

3. Develop policy, investment, workforce and capability plans.

4. Design useful security metrics and executive reports.

5. Establish a proportionate third-party risk-management programme.

6. Critically evaluate ethical, regulatory and organisational issues in security leadership.

1. Security as an Enterprise Capability

1.1 From technical function to strategic capability

A traditional security function often focused on perimeter controls, antivirus software, access administration and incident response. These remain important, but they are insufficient for modern enterprises. Security is now distributed across product design, procurement, human resources, legal practice, physical operations, data governance and business continuity.

The strategic question is not “How do we eliminate all cyber risk?” Such elimination is impossible and would be economically irrational. The question is: “Which risks are material to organisational objectives, what level of risk is acceptable, and what combination of controls provides justified assurance?”

Security contributes value in at least five ways:

• protecting critical services and information;
• supporting regulatory and contractual obligations;
• enabling trustworthy digital products and transactions;
• reducing the frequency and impact of adverse events; and
• improving organisational resilience and informed decision-making.

Security investment is therefore both defensive and enabling. Excessive restrictions can obstruct innovation, whereas inadequate controls can cause unacceptable loss. Leadership consists partly in managing this tension.

1.2 Alignment with business and digital transformation

A security strategy should begin with the enterprise strategy. Relevant questions include:

• Which products, services and processes generate strategic value?
• Which information assets and operational capabilities are mission-critical?
• What transformation initiatives depend on cloud, automation, data sharing or AI?
• What interruptions or disclosures would threaten customers, safety, revenue or legitimacy?
• Which obligations arise from law, regulation, contracts and professional standards?

For each major business objective, the security strategy should identify enabling conditions and material risks. For example, a digital-health programme may require secure identity, privacy-by-design, resilient clinical systems, supplier assurance and evidence of compliance. Security is then integrated into programme architecture and funding rather than added as a late approval gate.

2. Strategic Foundations and Risk Governance

2.1 Mission, scope and principles

A strategy normally contains a security mission, strategic outcomes, guiding principles, a target state, initiatives, ownership and measures. Useful principles include:

• risk-based prioritisation rather than equal treatment of every asset;
• accountability at the level where decisions and resources reside;
• security and privacy by design;
• least privilege and explicit verification of access;
• resilience through preparation, response and recovery;
• evidence-based assurance; and
• proportionality, usability and respect for human rights.

The scope should include information, technology, people, facilities, suppliers and processes. It should also state exclusions and dependencies, since ambiguity creates accountability gaps.

2.2 Risk appetite and tolerance

Risk appetite is the amount and type of risk an organisation is willing to pursue or retain in achieving its objectives. Risk tolerance specifies acceptable variation for a particular objective, service or risk category. A board might express very low tolerance for compromise of safety-critical systems, but a higher tolerance for brief disruption to a non-critical internal service.

Risk appetite is not a target number for all cyber risks. It is a governance statement that guides decisions. It should be translated into operational thresholds, such as maximum tolerable downtime, recovery-point expectations, privileged-access conditions or supplier requirements. Thresholds must be reviewed when business conditions change.

2.3 Enterprise risk management integration

Security risk should use the organisation’s established risk language and escalation mechanisms. A practical risk statement has the form:

“Because of [threat or condition], [vulnerability or exposure] could affect [asset or objective], causing [business consequence].”

This structure separates causes from consequences and avoids vague statements such as “cyber risk is high.” Risk assessment commonly considers likelihood, impact, control effectiveness and uncertainty. Numerical scoring can support prioritisation, but scores are not objective measurements of reality. They depend on definitions, evidence, assessor judgement and aggregation rules.

Risk treatment options are generally to avoid, reduce, transfer or accept risk. Transfer, such as insurance or contractual allocation, does not remove the underlying operational or societal consequences. Acceptance should be explicit, time-bounded where appropriate and approved by an accountable risk owner—not merely by the security department.

2.4 Governance roles

A mature governance arrangement distinguishes authority, execution and independent challenge. Typical responsibilities include:

• Board or governing body: approves direction, oversees material risk and tests management accountability.
• Executive committee: resolves cross-functional priorities and allocates resources.
• Chief information security officer (CISO): develops and leads the security programme, advises executives and reports material risk.
• Business and technology owners: own risks in their processes and systems.
• Legal, privacy, compliance and audit functions: provide specialist interpretation and independent assurance.
• Employees and contractors: follow requirements and report suspected events.

The CISO’s reporting line matters. Independence from operational technology management can strengthen challenge, while close operational integration can improve execution. The appropriate model depends on organisational size, regulatory expectations, complexity and the need to avoid conflicts of interest.

3. Frameworks, Maturity and the Target Operating Model

3.1 Frameworks as common languages

Frameworks provide structures for organising activities and communicating capability. The NIST Cybersecurity Framework 2.0 uses the functions Govern, Identify, Protect, Detect, Respond and Recover. ISO/IEC 27001 specifies requirements for an information security management system, including risk treatment, leadership, continual improvement and documented evidence. COBIT is frequently used for governance and management of enterprise information and technology. CIS Controls provide a prioritised set of technical and organisational safeguards.

These frameworks are complementary, not interchangeable certifications or automatic security guarantees. A framework should be selected according to the decision it must support. An organisation may use one framework for executive structure, another for an auditable management system and detailed controls for implementation.

3.2 Capability maturity

Maturity models describe the consistency and institutionalisation of capability. A simple progression is:

1. Ad hoc: activities depend on individuals and are inconsistent.

2. Repeatable: basic processes exist but vary across units.

3. Defined: processes and standards are documented and broadly adopted.

4. Measured: performance and risk outcomes are monitored.

5. Optimised: learning, automation and adaptation are systematic.

Maturity is not identical to security. A highly mature process may consistently implement an inappropriate control, while a low-maturity team may temporarily achieve strong protection through expert effort. Maturity assessments should therefore be combined with threat exposure, control effectiveness, business criticality and independent evidence.

3.3 The security operating model

An operating model specifies where capabilities reside and how they work together. Common patterns include:

• Centralised: security authority, services and standards are concentrated in one function. This supports consistency and economies of scale but may reduce business responsiveness.
• Federated: a central security function sets policy and provides specialist services while business units retain embedded security personnel. This improves contextual understanding but can create duplication.
• Distributed: responsibility is extensively delegated to business units. This may support autonomy but requires strong enterprise architecture, minimum standards and assurance.
• Platform or shared-service model: common capabilities such as identity, security monitoring and vulnerability management are delivered as enterprise services.

A hybrid model is common. Decisions should be centralised when consistency, independence or scale is important, and delegated when domain expertise, speed or local regulation is decisive. The model should explicitly define decision rights, service levels, funding, escalation and accountability.

4. Policy Architecture and Control Design

A policy is an authoritative statement of required behaviour or decision principles. It is not the same as a procedure, standard or guideline. A useful hierarchy is:

• Policy: mandatory organisational intent and obligations.
• Standard: specific mandatory requirements, such as encryption or logging conditions.
• Procedure: repeatable steps for performing an activity.
• Guideline: recommended practice where context may justify variation.
• Record or evidence: proof that requirements were implemented or tested.

Policies should have an owner, approval authority, scope, definitions, requirements, exceptions process, enforcement expectations, review date and mapping to obligations. Excessive policy detail can make documents unreadable and difficult to maintain. Conversely, vague statements cannot guide implementation or assurance.

Exceptions are an essential governance mechanism, not a failure of governance. A valid exception records the requirement, business justification, risk, compensating controls, owner, expiry date and approval level. Permanent informal exceptions indicate that the policy or architecture may be unrealistic.

Control design should consider preventive, detective, responsive and corrective measures. It should also address people and process controls, not only technology. For example, strong authentication without joiner-mover-leaver discipline may leave dormant accounts active.

5. Investment, Budgeting and Economic Decision-Making

5.1 Building a security budget

A security budget should connect spending to risk reduction, required capability and business enablement. Typical categories include personnel, managed services, software and hardware, training, assessments, architecture, incident response, resilience, legal support and contingency.

A useful planning sequence is:

1. identify business-critical services and obligations;

2. assess current exposure and capability gaps;

3. define target capabilities and minimum control requirements;

4. estimate one-time and recurring costs;

5. identify dependencies and implementation capacity;

6. compare options using risk, benefit, cost and uncertainty; and

7. obtain accountable approval with review points.

One-time implementation expenditure and recurring operating expenditure should be separated. A cloud security service, for example, may reduce capital expenditure but create continuing consumption charges, integration work and supplier dependency.

5.2 Cost-effectiveness and uncertainty

Security decisions should not rely on return-on-investment calculations alone. Benefits may include avoided loss, regulatory compliance, customer trust, safety and strategic enablement, many of which are difficult to monetise. Scenario analysis is often more honest than a single precise estimate.

If quantitative analysis is justified, expected loss can be represented as:

Expected annual loss = annual rate of occurrence × loss magnitude

The annual rate of occurrence is the estimated frequency of events in one year, and loss magnitude is the financial consequence per event. The calculation assumes that event frequency and consequences can be estimated on a comparable basis and that the scenarios are defined consistently. It is an estimate, not a prediction. For multiple scenarios, expected losses may be summed only when the scenarios are sufficiently distinct or dependence is explicitly considered.

For example, if a defined incident scenario is estimated to occur 0.2 times per year and each occurrence would cause £300,000 of loss, its expected annual loss is £60,000. A proposed control costing £40,000 annually may be economically attractive if it materially reduces that scenario and does not introduce disproportionate new risks. The analysis must also consider implementation uncertainty, residual risk, benefits across other scenarios and non-financial obligations.

6. Workforce and Leadership

6.1 Workforce planning

Workforce planning begins with capability demand rather than job titles. Required capabilities may include security architecture, governance and risk, identity, cloud security, application security, digital forensics, threat intelligence, privacy engineering, third-party assurance, awareness and communication.

A capability matrix can classify each capability by required proficiency, current capacity, strategic importance, sourcing option and development pathway. Sourcing choices include permanent staff, internal rotation, managed services, contractors, partnerships and automation. Outsourcing accountability is not acceptable: the organisation retains responsibility for decisions, oversight and outcomes.

Shortages should be addressed through a portfolio of recruitment, reskilling, communities of practice, apprenticeships, succession planning and carefully governed external support. Burnout is a strategic risk, especially in incident response and security operations. Sustainable on-call arrangements, role clarity and psychological safety improve retention and decision quality.

6.2 Leadership behaviours

Effective security leaders translate technical uncertainty into decision-relevant choices without exaggeration. They build coalitions with product, finance, legal, privacy, operations and human resources. They distinguish a control weakness from an actual incident, communicate uncertainty, admit limitations and create conditions in which employees report mistakes early.

Security culture is shaped by incentives. If delivery teams are rewarded only for speed, controls will be bypassed. If security blocks every change, teams may develop shadow systems. Balanced objectives, usable controls and proportional accountability are more effective than fear-based compliance.

7. Metrics, Measurement and Executive Reporting

7.1 Principles of useful metrics

A metric should have a defined purpose, population, method, owner, frequency, target or threshold and action associated with an adverse result. Metrics should be reliable enough for their decision context and should distinguish activity from outcome.

Examples of activity metrics include the percentage of systems assessed or the number of awareness sessions delivered. Outcome-oriented measures may include reduction in exploitable critical weaknesses, restoration performance during exercises, containment time for defined incident classes or the proportion of critical suppliers with tested recovery arrangements.

No single metric captures security. A balanced dashboard may include:

• exposure: externally reachable assets, unsupported systems and critical vulnerabilities;
• control health: privileged-access review completion, logging coverage and backup restoration results;
• resilience: recovery exercise performance and service dependency readiness;
• response: detection, escalation and containment performance;
• assurance: overdue high-risk findings and supplier assessment status; and
• people: staffing capacity, training effectiveness and workload indicators.

Terms such as mean time to detect or mean time to respond require precise definitions. Averages can hide severe outliers; medians, percentiles and distributions may provide better insight. Metrics can also create gaming—for example, closing tickets without reducing exposure. Leaders should ask what behaviour a metric incentivises.

7.2 Executive reporting

An executive report should be concise but decision-useful. It should explain changes since the previous period, material risks, business consequences, trends, assumptions, top actions, accountable owners, funding decisions and matters requiring escalation. Traffic-light colours alone are inadequate because they conceal uncertainty and interdependencies.

A strong report distinguishes:

• inherent exposure before controls;
• current residual risk after controls;
• accepted risk and its owner;
• emerging risks and assumptions; and
• management actions with due dates.

Reporting should be adapted to the audience. Boards need strategic exposure, resilience, legal and reputational implications, while operational leaders need actionable control and service information.

8. Third-Party and Supply-Chain Risk

8.1 Why third parties matter

An enterprise’s security posture depends partly on cloud providers, software vendors, outsourcers, contractors, logistics partners, open-source components and fourth parties. A supplier may process sensitive data, administer infrastructure, provide a critical service or create a pathway into internal systems.

Third-party risk management should be risk-based rather than a questionnaire exercise. The organisation should understand service criticality, data handled, connectivity, geographic and legal exposure, concentration risk, substitutability and recovery dependencies.

8.2 Lifecycle model

A practical lifecycle includes:

1. Planning: classify the service and define inherent risk.

2. Due diligence: evaluate governance, architecture, security practices, resilience, privacy and relevant independent evidence.

3. Contracting: establish requirements for access, notification, audit, subcontracting, data use, vulnerability handling, continuity, deletion and termination.

4. Onboarding: limit access, verify controls and document dependencies.

5. Monitoring: review changes, incidents, assurance reports, performance and threat information.

6. Response: coordinate investigation, communication and containment.

7. Exit: revoke access, retrieve or delete data, transfer services and test continuity.

Evidence should be proportionate. A critical provider may require architecture review, independent assurance, penetration-test summaries, recovery exercises and concentration analysis. A low-risk office supplier may need only basic contractual and access controls. Certifications provide evidence of a defined management system or assessment scope; they do not prove that every relevant risk is controlled.

9. Ethics, Regulation and Accountability

Security leadership involves power over information, access, monitoring and disruption. Ethical practice requires necessity, proportionality, transparency and respect for privacy and due process. Employee monitoring should have a legitimate purpose, limited collection, controlled access and retention rules. Security testing must be authorised and carefully scoped.

Regulatory obligations vary by jurisdiction and sector, but commonly concern privacy, breach notification, resilience, records, critical infrastructure, financial controls and accountability. A strategy should maintain an obligations register and map requirements to owners and evidence. Legal compliance is a baseline, not a complete definition of responsible security.

Incident disclosure creates difficult trade-offs. Delayed disclosure can increase harm and breach obligations, while premature or inaccurate statements can obstruct investigation and damage trust. Legal, communications, privacy, technical and executive roles should be rehearsed before an incident.

Board oversight should be informed and active without converting directors into operational security managers. Management must provide understandable evidence, disclose material uncertainty and avoid presenting compliance as proof of safety.

10. Technology, Automation and Artificial Intelligence

Automation can improve consistency in identity provisioning, vulnerability prioritisation, configuration assessment, detection and reporting. However, automation may amplify errors, create excessive alerts or make decisions without sufficient context. Every automated control requires ownership, testing, logging, fallback procedures and periodic review.

AI introduces additional security and governance questions. Generative AI systems may expose confidential prompts, produce inaccurate advice, leak training data or enable fraud and social engineering. AI used in security operations may misclassify events, conceal uncertainty or embed bias in prioritisation. Governance should address approved use cases, data handling, model access, human review, testing, monitoring, provenance and incident response.

AI is best treated as a capability within the existing risk framework rather than as a replacement for governance. The organisation should identify both risks from AI and opportunities to use AI for defensive improvement.

Illustrative Case: Meridian Transit Digital Transformation

Background

Meridian Transit, a fictional regional transport operator, planned a five-year programme involving cloud-based ticketing, mobile applications, connected station equipment and outsourced payment processing. Its security function was small and mainly focused on corporate IT. Operational technology, suppliers and privacy responsibilities were dispersed across departments.

Problem

A readiness review found inconsistent identity management, unsupported station devices, unclear supplier obligations, untested recovery arrangements and no agreed risk appetite for service disruption. The board received counts of blocked malware events but no view of whether passenger services could be restored after a major incident.

Analysis

The CISO and chief operating officer mapped critical services rather than beginning with products. They identified ticket issuance, fare collection, passenger information and station safety as priority services. Dependencies included cloud identity, communications networks, payment providers, station controllers and a managed service provider. The analysis showed that a low-frequency cyber event could have high operational and public consequences.

Approach and solution

Meridian adopted a federated operating model. A central team established policy, identity, monitoring, incident coordination and assurance, while operational units appointed security leads. The strategy used the NIST functions as an executive organising structure and mapped detailed requirements to an ISO/IEC 27001-aligned management system.

The board approved principles for service resilience and very low tolerance for unauthorised changes affecting safety functions. Investment was prioritised for privileged-access management, asset discovery, segmentation, tested backups, supplier controls and recovery exercises. Contracts were revised to require incident notification, subcontractor transparency, evidence of recovery testing and controlled access. Executive reporting changed from activity counts to service-level measures, including restoration-test results and unresolved critical dependencies.

An AI-based monitoring pilot was permitted only for triage assistance. Analysts retained decision authority, and the pilot required logging, quality review and restrictions on sensitive data.

Outcome

After eighteen months, Meridian had not eliminated cyber risk, but it had clarified ownership, reduced unmanaged privileged accounts, discovered previously unknown assets and demonstrated recovery of priority services in an exercise. The board could see residual risks and approve exceptions explicitly. The programme also revealed that supplier concentration remained a significant unresolved issue, leading to a separate continuity investment.

Learning points

The case illustrates that strategy begins with business services and consequences, not security tools. It also shows the importance of federated accountability, measurable resilience, supplier governance, explicit risk acceptance and controlled experimentation with AI. Improved reporting did not merely describe security; it changed executive decisions.

Challenges and Limitations

Enterprise strategy is difficult because threat information is incomplete, business priorities conflict, dependencies are opaque and benefits are often preventive. Maturity scores may create false precision, risk registers may become administrative inventories and dashboards may reward activity rather than outcomes. Frameworks can be adopted ceremonially without changing decisions. Outsourcing can obscure accountability, while centralisation can distance security from operational reality.

Strategies also decay. Acquisitions, new regulations, geopolitical change, cloud migration and novel technologies can invalidate assumptions. Review should therefore be triggered by significant business or threat changes, not only by an annual calendar. Independent assurance, scenario exercises and candid reporting are essential to counter overconfidence.

Best-Practice Design Principles

1. Start with critical business services and outcomes.

2. Make risk ownership explicit outside the security department.

3. Use frameworks as adaptable communication and assurance tools.

4. Separate policy, standards, procedures and evidence.

5. Fund capabilities across people, process and technology.

6. Measure outcomes and resilience, not only activity.

7. Treat suppliers and fourth parties as part of the enterprise risk system.

8. Design exceptions, escalation and incident communication in advance.

9. Preserve human oversight over high-impact automated decisions.

10. Reassess strategy when business assumptions or dependencies change.

Chapter Summary

Enterprise security strategy aligns protection, resilience and trust with organisational objectives. It begins with business services, risk appetite and accountable governance, then translates these into an operating model, policy architecture, capabilities, investment and workforce plans. Frameworks such as NIST CSF, ISO/IEC 27001, COBIT and CIS Controls provide useful structures, but they do not replace judgement or evidence.

Effective leaders distinguish risk ownership from security advice, communicate uncertainty and report outcomes in business terms. Budgets should consider recurring costs, residual risk, uncertainty and non-financial obligations. Metrics should support decisions and avoid rewarding superficial activity. Third-party risk requires lifecycle governance from planning through exit. Ethical monitoring, regulatory accountability, responsible automation and human oversight are essential. Ultimately, security maturity is valuable only when it improves the organisation’s ability to achieve its mission safely and resiliently.

Key Terms

Risk appetite: The amount and type of risk an organisation is willing to pursue or retain.

Risk tolerance: Acceptable variation around an objective or risk condition.

Residual risk: Risk remaining after controls and treatments are applied.

Risk owner: Person accountable for managing and accepting a defined risk.

Security strategy: A coordinated plan aligning security capabilities with organisational objectives.

Security governance: Direction, oversight and accountability for security decisions.

Operating model: The arrangement of roles, services, decision rights and processes.

Federated model: A model combining central standards or services with embedded business responsibility.

Policy: An authoritative statement of organisational requirements or intent.

Standard: A mandatory, specific requirement supporting a policy.

Control: A measure intended to modify risk.

Maturity: The degree to which capability is defined, repeatable, measured and improved.

Security metric: A defined measure used to evaluate security activity, condition or outcome.

Expected annual loss: Estimated annual event frequency multiplied by loss per event.

Third-party risk: Risk arising from suppliers, service providers or other external dependencies.

Concentration risk: Exposure created by dependence on one provider, technology or location.

Security culture: Shared behaviours and expectations concerning security.

Exception: Authorised departure from a requirement with documented justification and controls.

Residual risk acceptance: Explicit approval to retain a known remaining risk.

Security by design: Integrating security and privacy considerations throughout solution design.

Review Questions

Short Answer Questions

1. Why should enterprise security strategy begin with business services rather than security products?

2. Distinguish risk appetite from risk tolerance.

3. What is the difference between a policy, a standard and a procedure?

4. Why can maturity scores not be treated as direct measures of security?

5. Identify four stages in the third-party risk-management lifecycle.

Long Answer Questions

1. Explain how a CISO can align security strategy with digital transformation while preserving business agility.

2. Compare centralised, federated and distributed security operating models, including their strengths and limitations.

3. Discuss how security budgets should incorporate risk reduction, recurring costs, uncertainty and non-financial benefits.

4. Design an executive security dashboard and explain why each category of measure is useful.

5. Evaluate the ethical and governance challenges of using AI in security operations.

Analytical / Application Questions

1. A critical supplier processes sensitive data and administers a key production platform. Develop a proportionate due-diligence, contracting, monitoring and exit plan.

2. A business unit requests a permanent exception to privileged-access requirements because implementation is inconvenient. Analyse the governance response, evidence required and possible compensating controls.

3. A defined incident scenario has an estimated annual occurrence rate of 0.15 and a loss magnitude of $400,000. Calculate its expected annual loss, then explain why the result alone cannot determine whether a proposed control should be funded.

Multiple Choice Questions with Answers

Question 1

Which statement best describes enterprise security strategy?

A. A catalogue of security products owned by the IT department

B. A plan aligning security capabilities, risk decisions and investment with organisational objectives

C. A technical procedure for detecting malware

D. A legal document used only during audits

Correct Answer: B. A plan aligning security capabilities, risk decisions and investment with organisational objectives

Question 2

Who should normally accept a business risk?

A. The risk owner accountable for the affected objective

B. The newest security analyst

C. The external software supplier in every case

D. The internal audit team

Correct Answer: A. The risk owner accountable for the affected objective

Question 3

Which NIST Cybersecurity Framework function is primarily concerned with restoring capabilities after an incident?

A. Identify

B. Protect

C. Recover

D. Govern

Correct Answer: C. Recover

Question 4

What is a defining characteristic of a federated security operating model?

A. All security decisions are outsourced

B. Business units have no security responsibilities

C. A central function provides direction while business units retain embedded responsibility

D. Every unit independently selects incompatible standards

Correct Answer: C. A central function provides direction while business units retain embedded responsibility

Question 5

An incident is estimated to occur 0.2 times per year and cause $300,000 per occurrence. What is its expected annual loss?

A. $6,000

B. $60,000

C. $150,000

D. $500,000

Correct Answer: B. $60,000

Question 6

Which is an outcome-oriented security measure?

A. Number of awareness slides published

B. Number of policy documents stored

C. Percentage of priority services successfully restored in an exercise

D. Number of security meetings held

Correct Answer: C. Percentage of priority services successfully restored in an exercise

Question 7

Which action belongs to the contracting stage of third-party risk management?

A. Defining incident notification and audit requirements

B. Deleting all supplier records before selection

C. Ignoring subcontractors

D. Removing access before the service begins

Correct Answer: A. Defining incident notification and audit requirements

Question 8

What should a documented security exception include?

A. Only the requesting employee’s name

B. Business justification, risk, compensating controls, owner and review or expiry information

C. A guarantee that no incident can occur

D. An automatic permanent exemption

Correct Answer: B. Business justification, risk, compensating controls, owner and review or expiry information

Question 9

Why is a security certification not proof that all supplier risks are controlled?

A. Certifications never assess any controls

B. Certification evidence has scope, assumptions and assessment limitations

C. Suppliers cannot be audited

D. Certifications apply only to physical security

Correct Answer: B. Certification evidence has scope, assumptions and assessment limitations

Question 10

Which principle is most appropriate for high-impact AI use in security operations?

A. Remove all human review to increase speed

B. Permit use without logging if accuracy is expected

C. Require defined ownership, testing, monitoring and human oversight

D. Allow unrestricted use of confidential data

Correct Answer: C. Require defined ownership, testing, monitoring and human oversight