Information Security Risk, Governance and Compliance

Introduction and Context

Information security is no longer only a technical function concerned with firewalls, malware protection, or access control. It is a strategic discipline involving the protection of information assets, the achievement of organizational objectives, the management of uncertainty, and the demonstration of accountability to stakeholders. Digital transformation, cloud computing, artificial intelligence, interconnected supply chains, remote work, and increasingly strict privacy regulation have expanded both the value of information and the consequences of its compromise.

Information security risk, governance, and compliance are closely related but distinct. Risk management concerns the identification, analysis, evaluation, and treatment of uncertainty affecting information assets and business objectives. Governance concerns direction, oversight, decision rights, accountability, and alignment with organizational strategy. Compliance concerns fulfilling applicable legal, regulatory, contractual, and internal requirements. An organization may be compliant with a regulation yet poorly governed, or it may have strong technical controls without a systematic risk-management process.

A postgraduate security professional must therefore be able to connect technical safeguards with business consequences, evaluate competing frameworks, interpret assurance evidence, and make ethically defensible decisions under uncertainty.

Learning Objectives

After completing this chapter, the reader should be able to:

1. Explain the relationships among information security risk, governance, and compliance.

2. Perform a structured qualitative and quantitative risk assessment.

3. Select and justify risk-treatment options and controls.

4. Compare ISO/IEC 27001, the NIST Cybersecurity Framework, and COBIT.

5. Design governance structures, accountability mechanisms, and assurance processes.

6. Evaluate audit evidence, regulatory obligations, and third-party risk.

7. Analyze ethical issues involving security, privacy, artificial intelligence, and organizational responsibility.

8. Apply these ideas to a realistic organizational case.

1. Information Security Risk as an Organizational Concern

1.1 Key terminology

An asset is something of value to an organization, such as data, software, infrastructure, services, reputation, intellectual property, or human capability. A threat is a potential cause of an unwanted incident. Threats may be malicious, accidental, environmental, or operational. A vulnerability is a weakness that can be exploited or triggered. An information security event is an observable occurrence relevant to security, whereas an incident is an event that compromises, or threatens to compromise, confidentiality, integrity, or availability.

The traditional security objectives are:

• Confidentiality: information is accessible only to authorized entities.
• Integrity: information and systems remain accurate, complete, and protected from unauthorized alteration.
• Availability: authorized users can access information and services when required.

Modern risk analysis often adds authenticity, accountability, safety, privacy, and resilience. For example, an industrial control system may remain confidential and available while producing unsafe physical outcomes. Similarly, a privacy breach may occur even when information has not been modified.

Inherent risk is the level of risk before controls are considered. Residual risk is the risk remaining after controls and treatments are applied. Risk appetite is the broad amount and type of risk an organization is willing to pursue or retain. Risk tolerance is the acceptable variation around an objective or risk boundary. A risk appetite statement is strategic; a tolerance threshold is usually more operational and measurable.

1.2 Risk components and measurement

A useful conceptual model represents risk as a function of likelihood and impact:

Risk = f(likelihood, impact)

This is not a universal law or a single mandatory formula. It is a decision model. Likelihood may reflect threat capability, exposure, vulnerability, and control effectiveness. Impact may include financial loss, legal liability, safety consequences, service interruption, loss of trust, and strategic damage.

For a simple quantitative estimate, organizations sometimes use:

Annualized Loss Expectancy (ALE) = Single Loss Expectancy (SLE) × Annual Rate of Occurrence (ARO)

SLE is the estimated loss from one occurrence, and ARO is the expected number of occurrences per year. This model assumes that the loss estimate is reasonably stable and that annual frequency is meaningful. It is less reliable for rare, systemic, correlated, or rapidly changing events. It should not be presented as a precise prediction when the underlying data are weak.

For example, suppose a business estimates that a major compromise would cost $400,000 and that comparable events could occur 0.25 times per year. The estimated ALE is:

ALE = $400,000 × 0.25 = $100,000 per year.

If a proposed control costs $60,000 annually and reduces the expected loss to $30,000, the estimated annual benefit is $70,000. Under this simplified model, the control produces a net expected benefit of $10,000 per year, before implementation friction, residual uncertainty, and secondary effects are considered. This does not automatically justify implementation: strategic, legal, ethical, and safety factors may outweigh a financial calculation.

1.3 Risk scenarios

Scenario-based analysis is often more useful than lists of isolated threats. A scenario connects an actor or source, an event, a vulnerability, an asset, and a consequence. For example:

“A compromised supplier credential is used to access the organization’s software repository, allowing malicious code to be inserted into a production release and causing customer-service disruption.”

This scenario identifies supply-chain dependence, identity weakness, software integrity, and availability consequences. It also helps identify owners and controls. A risk register should record, at minimum, the scenario, asset or objective affected, causes, consequences, existing controls, inherent risk, residual risk, treatment decision, owner, due date, and review status.

2. The Risk-Management Lifecycle

Risk management is a continuous process rather than an annual documentation exercise. A practical lifecycle contains the following activities.

Establish context

The organization defines objectives, scope, stakeholders, risk criteria, assumptions, legal obligations, dependencies, and decision authority. Context may be an entire enterprise, a business process, an application, a cloud service, or a specific project. Poorly defined scope produces misleading assessments.

Identify risks

Assets, processes, information flows, threats, vulnerabilities, dependencies, and potential consequences are identified. Workshops, interviews, architecture reviews, incident data, threat intelligence, vulnerability assessments, and supplier questionnaires may be used. Identification should include intentional and accidental causes, not just cyberattack scenarios.

Analyze risks

The analyst estimates likelihood and impact, considers existing controls, and documents confidence in the assessment. Qualitative scales such as low, medium, and high are practical but must have explicit definitions. For example, “high impact” could mean regulatory reporting, more than a specified duration of service interruption, or a material safety consequence. Without definitions, a color-coded matrix creates an appearance of rigor without reliable comparability.

Quantitative methods may use historical frequencies, loss distributions, Monte Carlo simulation, or expert elicitation. Their value depends on data quality and model assumptions. Analysts should distinguish observed evidence from judgment and should record uncertainty ranges when precision is not justified.

Evaluate and prioritize

Risk is compared with criteria, appetite, legal requirements, and resource constraints. Prioritization should consider concentration risk and dependencies. Several individually moderate risks may create a severe combined risk, such as weak identity governance across many suppliers.

Treat risks

The main treatment choices are:

• Avoid: discontinue the activity creating unacceptable risk.
• Reduce or modify: implement controls that lower likelihood or impact.
• Share or transfer: use insurance, contracts, outsourcing, or other arrangements, recognizing that accountability generally cannot be completely transferred.
• Retain: accept the risk knowingly within approved authority.

Risk acceptance should identify the decision maker, rationale, duration, assumptions, and trigger for reassessment. “No action” is not the same as informed acceptance.

Monitor and communicate

Risks change as systems, threats, regulations, suppliers, and business processes change. Monitoring should include control performance, incidents, near misses, threat intelligence, audit findings, and key risk indicators. Communication should be tailored: boards need exposure, trends, and decisions; engineers need actionable weaknesses; regulators need evidence and truthful reporting.

3. Governance of Information Security

3.1 Governance versus management

Governance determines direction and evaluates whether objectives are achieved. Management plans, builds, operates, and monitors activities within that direction. This distinction is important because security governance cannot be delegated entirely to the chief information security officer. The board and executive leadership retain responsibility for oversight, resource allocation, and organizational accountability.

Effective governance links security decisions to enterprise objectives. A hospital may prioritize patient safety and clinical availability; a financial institution may emphasize transaction integrity, resilience, and regulatory trust; a research organization may emphasize intellectual-property protection and openness. The same control may have different priority and design in each context.

3.2 Governance structures

A mature structure usually includes:

• Board or governing body: approves direction, oversees material risks, and challenges management.
• Executive leadership: allocates resources, establishes accountability, and resolves risk conflicts.
• Chief information security officer: coordinates security strategy, risk reporting, and security capability.
• Risk, legal, privacy, and compliance functions: interpret obligations and provide independent challenge.
• System and data owners: decide classification, access, retention, and acceptable use.
• Control operators: implement and maintain safeguards.
• Internal audit: provides independent assurance, not operational ownership.
• External auditors and regulators: provide additional assurance or enforcement.

A responsibility assignment matrix can clarify who is Responsible, Accountable, Consulted, and Informed. Accountability should be explicit: a committee that discusses risk but cannot make decisions is not an effective governance mechanism.

3.3 Governance principles

Important principles include:

1. Alignment: security supports business and societal objectives.

2. Risk-based proportionality: controls match the value and consequences of assets.

3. Accountability: decisions have identifiable owners.

4. Transparency: material assumptions, limitations, and conflicts are disclosed.

5. Independence: assurance functions can challenge operational management.

6. Resilience: governance addresses preparation, response, recovery, and adaptation.

7. Continuous improvement: lessons from incidents and audits change practice.

4. Major Frameworks and Standards

Frameworks are not interchangeable checklists. Each has a purpose, structure, scope, and level of prescription.

4.1 ISO/IEC 27001

ISO/IEC 27001:2022 specifies requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). It requires an organization to define scope, understand its context, establish leadership and policy, perform risk assessment and treatment, set objectives, manage documented information, conduct internal audits and management reviews, and improve the ISMS.

The standard uses a risk-based management-system approach. Annex A provides a reference set of controls organized in the 2022 edition into four themes: organizational, people, physical, and technological controls. Organizations are not required to implement every Annex A control automatically. They select controls based on risk and justify inclusion or exclusion in the Statement of Applicability. The standard’s requirements and the control reference are related but not identical.

Certification is performed by an independent certification body and provides evidence that the ISMS conforms to the audited requirements within scope. It is not a guarantee that no breach will occur, nor does it certify every system or supplier connected to an organization.

4.2 NIST Cybersecurity Framework 2.0

The NIST Cybersecurity Framework (CSF) 2.0 is a voluntary framework for managing cybersecurity risk. Its six high-level Functions are:

• Govern: establish and monitor cybersecurity risk strategy, expectations, and policy.
• Identify: understand assets, suppliers, risks, and organizational context.
• Protect: use safeguards to prevent or contain adverse events.
• Detect: discover and analyze possible attacks or compromises.
• Respond: take action regarding detected incidents.
• Recover: restore assets and operations and communicate recovery activities.

The CSF includes a Core, Organizational Profiles, and Tiers. Profiles describe current and target outcomes; Tiers characterize the sophistication and integration of risk governance and management. The CSF is outcome-oriented and can be mapped to other standards. It does not itself create legal compliance or prescribe one implementation design.

4.3 COBIT 2019

COBIT, published by ISACA, is a framework for the governance and management of enterprise information and technology. It distinguishes governance activities—evaluate, direct, and monitor—from management activities—plan, build, run, and monitor. COBIT’s governance system and design factors help organizations tailor objectives to enterprise goals, risk profile, compliance requirements, sourcing model, and technology context.

COBIT is particularly useful for connecting enterprise objectives, information and technology processes, capability, performance measurement, and assurance. It is broader than cybersecurity alone. It can therefore help boards and executives understand how security fits within enterprise governance, while specialized standards provide deeper technical or management detail.

4.4 Framework comparison

ISO/IEC 27001 is strongest when an organization requires a certifiable ISMS and disciplined management-system processes. NIST CSF is strong for communication, profiling, and flexible cybersecurity improvement. COBIT is strong for enterprise governance, decision rights, performance, and alignment between business and technology.

They can be integrated rather than competitively selected. For example, COBIT may define governance and performance relationships, ISO/IEC 27001 may establish the ISMS, and NIST CSF may express cybersecurity outcomes and target profiles. Mapping documents are useful, but a mapped control is not automatically effective; evidence and context remain necessary.

5. Compliance, Audit, and Assurance

5.1 The compliance landscape

Security obligations may arise from legislation, sector regulation, contractual commitments, licensing conditions, court orders, standards adopted by policy, and internal rules. Privacy laws commonly impose duties concerning lawful processing, purpose limitation, data minimization, security safeguards, retention, individual rights, breach notification, and international transfers. Sector-specific regimes may address payment data, health information, financial resilience, critical infrastructure, or government systems.

A compliance program should maintain an obligation register identifying the requirement, jurisdiction, applicability, control owner, evidence, reporting deadline, and review frequency. Legal interpretation must be performed with qualified legal and privacy professionals; security teams should not assume that a technical control alone resolves a legal obligation.

5.2 Audit and assurance

An audit is a systematic, independent evaluation against defined criteria. Assurance is broader: it is confidence that governance, risk management, and controls are designed and operating effectively. A control can be well designed but poorly operated, or consistently operated yet inadequate for the risk.

Useful evidence includes approved policies, access reviews, configuration records, change tickets, training records, incident exercises, vulnerability remediation data, supplier assessments, system logs, and management decisions. Evidence should demonstrate scope, timing, ownership, completeness, and authenticity. Screenshots without context are weak evidence.

Internal audit should preserve independence from activities it evaluates. Management owns remediation, while auditors assess and report. A finding should identify the condition, criterion, cause, consequence or risk, and agreed corrective action. Repeated findings often indicate governance or accountability weaknesses rather than isolated technical defects.

5.3 Metrics and reporting

Metrics should support decisions rather than reward superficial activity. Examples include the proportion of critical assets with tested recovery procedures, time to revoke access after termination, age and business criticality of unresolved vulnerabilities, percentage of high-risk suppliers with current assessments, and successful completion of incident exercises.

A metric must have a defined population, calculation method, owner, reporting period, and interpretation. For example, “95% of vulnerabilities closed on time” is meaningless unless severity, due date, exceptions, and asset criticality are known. Boards should receive trend information, material exceptions, residual risk, and decisions required—not an excessive list of technical indicators.

6. Third-Party, Cloud, and Supply-Chain Risk

Organizations increasingly depend on cloud providers, managed-service providers, software libraries, payment processors, and data-sharing partners. Outsourcing an activity does not outsource the organization’s legal or ethical responsibility to protect customers and stakeholders.

Third-party risk management should be lifecycle-based:

1. Classify suppliers according to information access, criticality, concentration, and substitutability.

2. Perform due diligence before contracting.

3. Define security, privacy, resilience, audit, breach notification, subcontracting, and exit requirements.

4. Monitor performance and material changes.

5. Test continuity and termination arrangements.

6. Remove access and securely return or delete data at exit.

Cloud responsibility is shared. The provider may secure underlying infrastructure while the customer remains responsible for identity configuration, data classification, application security, logging choices, and appropriate use. Exact responsibilities must be established for each service model and contract.

Software supply-chain controls may include signed artifacts, provenance records, dependency inventories such as software bills of materials, protected build systems, code review, reproducible or controlled builds, vulnerability monitoring, and rapid revocation mechanisms. These controls reduce but do not eliminate systemic dependency risk.

7. Ethics, Privacy, and Accountability

Security decisions affect people, not only systems. Ethical analysis is required when monitoring employees, using intrusive detection, collecting personal data, conducting penetration tests, retaining logs, or deploying artificial intelligence.

Important principles include necessity, proportionality, purpose limitation, data minimization, fairness, transparency, due process, and respect for human dignity. A technically possible surveillance practice may still be unjustified if it collects excessive information or lacks meaningful safeguards. Security exceptions should be documented and reviewed rather than normalized.

AI introduces additional governance questions. AI systems may expose confidential prompts or training data, generate insecure code, amplify bias, produce inaccurate classifications, or obscure accountability through opaque decisions. Governance should address approved use cases, data handling, model evaluation, human oversight, logging, vendor terms, prompt and output security, incident reporting, and reassessment when models or data change. AI should support professional judgment, not replace accountable decision makers in high-impact contexts.

Responsible disclosure requires balancing public safety, vendor remediation, transparency, and protection of researchers. Penetration testing requires written authorization, defined scope, safe handling of evidence, and procedures to stop testing if harmful effects occur. Professionals should not exploit a discovered weakness beyond what is necessary to establish and report it.

8. Detailed Illustrative Case: Meridian Health Services

Background

Meridian Health Services, a fictional regional healthcare provider, operates hospitals, outpatient clinics, an electronic health-record platform, diagnostic devices, and a patient portal. It uses cloud hosting for analytics and relies on several suppliers for laboratory services and appointment management.

Problem

A phishing campaign compromises a billing employee’s credentials. Multifactor authentication is not enforced for a legacy supplier portal. The attacker accesses patient and insurance information, then attempts to move toward the clinical network. Meridian discovers that access reviews are inconsistent, supplier contracts have different breach-notification terms, and the board receives only counts of blocked emails rather than risk exposure.

Analysis

The incident affects confidentiality and may affect integrity if records are altered. The clinical-network dependency creates availability and patient-safety concerns. Initial analysis identifies risks involving weak identity governance, excessive privileges, supplier access, incomplete logging, and uncertain regulatory notification obligations.

A qualitative assessment rates the supplier-portal scenario as high because the information is sensitive, the account is externally reachable, controls are inconsistent, and consequences include legal, clinical, and reputational harm. Confidence is moderate because asset and access inventories are incomplete. The risk is not treated as a purely technical problem: ownership is assigned jointly to the clinical system owner, procurement, privacy officer, and security leadership.

Approach and solution

Meridian first contains the incident, resets credentials, preserves evidence, and engages legal and privacy specialists. It determines affected data and notification obligations based on verified facts rather than speculation. It then adopts a target profile using NIST CSF outcomes, incorporates the risk process into its ISO/IEC 27001-aligned ISMS, and uses COBIT governance practices to clarify executive oversight and performance reporting.

Controls include phishing-resistant multifactor authentication for privileged and external access, formal joiner-mover-leaver procedures, quarterly access reviews for high-risk systems, network segmentation between clinical and administrative environments, centralized logging, tested recovery procedures, and supplier criticality classification. Contracts are standardized to include security baselines, notification time frames, subcontractor transparency, evidence rights, and exit provisions.

The board receives a dashboard showing material risks, overdue remediation, critical supplier coverage, recovery-test results, and decisions requiring acceptance. Internal audit independently tests whether controls operate as described.

Outcome

Meridian reduces exposed legacy access, improves detection coverage, and completes a clinical-service recovery exercise. It does not claim that risk has been eliminated. Instead, residual risks are documented, accepted by authorized executives where appropriate, and reviewed when systems or suppliers change.

Learning points

The case demonstrates that incidents often reveal governance weaknesses rather than a single failed control. Risk assessment must include dependencies and safety consequences. Compliance analysis must be fact-based and coordinated with legal specialists. Frameworks are most useful when translated into ownership, evidence, decisions, and measurable improvement.

9. Challenges and Limitations

Risk matrices can create false precision, especially when categories are poorly defined or when low-probability catastrophic events are averaged away. Quantitative models may be distorted by incomplete incident data, changing threat behavior, and correlated failures. Framework proliferation can lead to duplicated documentation and control fatigue. Certification can encourage boundary management—excluding difficult systems from scope—rather than genuine improvement.

Governance may fail through unclear authority, conflicts of interest, insufficient board expertise, or incentives that favor short-term delivery over resilience. Compliance may become a checkbox exercise if organizations optimize for audit evidence rather than actual outcomes. Metrics can be gamed, and third-party attestations may provide limited visibility into subcontractors or operational reality.

These limitations require professional skepticism. Analysts should document assumptions, use multiple evidence sources, conduct scenario exercises, test controls in operation, and revisit decisions after incidents or major change.

10. Contemporary Developments and Best Practices

Contemporary programs increasingly emphasize cyber resilience, identity-centric security, zero-trust principles, software supply-chain assurance, privacy engineering, operational technology safety, and continuous control monitoring. Regulatory expectations are also moving toward demonstrable governance, timely incident reporting, executive accountability, and resilience testing.

Best practices include:

• Begin with business objectives, critical services, and stakeholder harm.
• Maintain accurate asset, data, identity, supplier, and obligation inventories.
• Use a common risk language across technical and executive communities.
• Combine preventive, detective, responsive, and recovery controls.
• Design security and privacy into systems rather than adding them at the end.
• Assign accountable owners and record risk acceptance explicitly.
• Test controls and recovery capabilities under realistic conditions.
• Integrate security requirements into procurement and architecture review.
• Preserve audit independence and protect the integrity of evidence.
• Report uncertainty and material limitations honestly.
• Use automation and AI with human oversight, secure data handling, and clear accountability.
• Treat incidents and near misses as inputs to continual improvement.

Chapter Summary

Information security risk, governance, and compliance form an integrated strategic discipline. Risk management identifies uncertainty affecting assets and objectives, analyzes likelihood and impact, selects treatment, and monitors residual exposure. Governance establishes direction, decision rights, accountability, and oversight; it cannot be delegated entirely to technical staff. Compliance translates legal, regulatory, contractual, and internal obligations into accountable processes and evidence, but compliance alone does not guarantee security.

ISO/IEC 27001:2022 provides a certifiable risk-based ISMS model; NIST CSF 2.0 offers flexible cybersecurity outcomes organized around Govern, Identify, Protect, Detect, Respond, and Recover; and COBIT 2019 connects enterprise governance and management of information and technology. These frameworks can be integrated when their purposes and limitations are understood.

Effective practice requires sound risk scenarios, explicit assumptions, proportionate controls, independent assurance, supplier oversight, tested resilience, ethical judgment, and transparent reporting. The central professional responsibility is to make defensible decisions that protect information, services, people, and society while acknowledging uncertainty.

Key Terms

Asset: Something of value requiring protection.

Confidentiality: Protection against unauthorized information disclosure.

Integrity: Protection of accuracy, completeness, and authorized modification.

Availability: Accessibility of information and services when required.

Threat: A potential cause of an unwanted security event.

Vulnerability: A weakness that may be exploited or triggered.

Inherent risk: Risk before considering controls.

Residual risk: Risk remaining after controls or treatment.

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

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

Risk treatment: Action taken to avoid, reduce, share, or retain risk.

ISMS: Information Security Management System.

Statement of Applicability: Documented justification for selected or excluded ISO/IEC 27001 controls.

Governance: Direction, oversight, accountability, and evaluation of organizational activity.

Compliance: Fulfillment of applicable legal, regulatory, contractual, or internal requirements.

Audit: Independent, systematic evaluation against defined criteria.

Assurance: Confidence that governance, risk management, and controls are effective.

Residual exposure: Remaining potential harm after treatment.

Supply-chain risk: Risk arising from dependencies on providers, products, services, or software components.

Risk owner: Person accountable for managing or accepting a specified risk.

Review Questions

Short Answer Questions

1. Distinguish inherent risk from residual risk.

2. What are the six Functions of NIST CSF 2.0?

3. Why is a Statement of Applicability important in ISO/IEC 27001?

4. Explain the difference between governance and management.

5. Identify two limitations of qualitative risk matrices.

Long Answer Questions

1. Explain the complete information security risk-management lifecycle and the role of risk acceptance.

2. Compare ISO/IEC 27001, NIST CSF 2.0, and COBIT 2019 in terms of purpose, structure, and organizational use.

3. Discuss how audit, assurance, and compliance evidence should be designed to support accountability.

4. Analyze the governance challenges created by cloud computing and third-party suppliers.

5. Explain the ethical principles that should guide employee monitoring and the use of artificial intelligence in security operations.

Analytical / Application Questions

1. An organization estimates a single loss of $250,000 and an annual occurrence rate of 0.2. Calculate the ALE. If a proposed control costs $35,000 annually and reduces the ALE to $20,000, evaluate the simplified financial case and identify at least two non-financial factors that should also be considered.

2. Design a target cybersecurity profile for a hospital using the six NIST CSF 2.0 Functions. Identify one measurable outcome and one accountable role for each Function.

3. Using the Meridian Health Services case, prioritize three treatments, assign suitable owners, and explain how ISO/IEC 27001, NIST CSF, and COBIT could jointly support implementation and oversight.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes governance from management in information security?

A. Governance operates technical controls, while management sets laws.

B. Governance provides direction and oversight, while management plans and operates activities.

C. Governance is performed only by auditors, while management is performed only by regulators.

D. Governance concerns confidentiality only, while management concerns availability only.

Correct Answer: B. Governance provides direction and oversight, while management plans and operates activities.

Question 2

An organization estimates a single loss expectancy of $200,000 and an annual rate of occurrence of 0.25. What is the estimated ALE?

A. $50,000

B. $200,000

C. $800,000

D. $250,000

Correct Answer: A. $50,000

Question 3

Which ISO/IEC 27001 document records the justification for including or excluding reference controls?

A. Risk appetite statement

B. Statement of Applicability

C. Incident response ticket

D. Supplier invoice register

Correct Answer: B. Statement of Applicability

Question 4

Which NIST CSF 2.0 Function focuses on establishing and monitoring cybersecurity risk strategy and expectations?

A. Protect

B. Detect

C. Govern

D. Recover

Correct Answer: C. Govern

Question 5

Which of the following is a risk-treatment option?

A. Encrypt every asset regardless of value

B. Avoid the activity creating unacceptable risk

C. Ignore risks below a color threshold

D. Transfer all accountability to a supplier

Correct Answer: B. Avoid the activity creating unacceptable risk

Question 6

What is a principal limitation of a certification to ISO/IEC 27001?

A. It proves that no security incident can occur.

B. It applies automatically to every supplier and system.

C. It demonstrates conformity of the audited ISMS scope, not perfect security.

D. It eliminates the need for risk assessment.

Correct Answer: C. It demonstrates conformity of the audited ISMS scope, not perfect security.

Question 7

Which COBIT emphasis is most relevant to linking information and technology with enterprise objectives and accountability?

A. Enterprise governance and management of information and technology

B. Password hashing algorithms only

C. Physical destruction of all records

D. Malware signature development only

Correct Answer: A. Enterprise governance and management of information and technology

Question 8

Why should an organization classify suppliers by criticality?

A. To ensure every supplier receives identical controls

B. To align due diligence and monitoring with potential impact and dependency

C. To avoid including suppliers in contracts

D. To eliminate the need for exit planning

Correct Answer: B. To align due diligence and monitoring with potential impact and dependency

Question 9

Which principle is most relevant when evaluating employee monitoring?

A. Collect all possible data indefinitely

B. Necessity and proportionality

C. Avoid documenting monitoring practices

D. Give monitoring decisions to software vendors

Correct Answer: B. Necessity and proportionality

Question 10

A control reduces expected annual loss from $90,000 to $30,000 and costs $40,000 annually. Under a simplified expected-loss model, what is the net annual expected benefit?

A. $20,000

B. $40,000

C. $60,000

D. $100,000

Correct Answer: A. $20,000