Security and Risk Management practice questions

Right to rectification

Why it fails: The right to rectification is a valid GDPR right (Article 16), but it is not one of the three rights that answer this question. The question requires exactly three correct options, and A, B, C are the intended correct answers.

Right to remuneration

Why it fails: The 'Right to Remuneration' is not a recognized data subject right under the General Data Protection Regulation (GDPR). GDPR focuses on granting individuals control over their personal data, ensuring privacy, and providing mechanisms for data access, correction, and deletion. It does not establish a right for individuals to receive financial compensation or payment for an organization's legitimate processing of their personal data.

Data can be recovered from any point within the past 2 hours

Why it fails: This statement describes a flexible recovery capability, suggesting the ability to restore to *any* specific moment within a 2-hour window. However, the Recovery Point Objective (RPO) defines the *maximum acceptable age* of data that can be lost from an IT service due to an incident. It specifies the *single point in time* to which data must be recovered, not a continuous range of recovery points.

The maximum tolerable downtime is 2 hours

Why it fails: This statement accurately defines the Maximum Tolerable Downtime (MTD) or the Recovery Time Objective (RTO). The RTO specifies the maximum acceptable duration for a business process or system to be unavailable following a disruption, focusing on the time required to restore operations. In contrast, the Recovery Point Objective (RPO) specifically addresses the maximum amount of data loss an organization can endure, measured in time.

The database must be fully recovered within 2 hours of a disaster

Why it fails: This statement describes the Recovery Time Objective (RTO), which is the maximum acceptable time allowed for the recovery of a business function or IT system after a disaster or disruption. The RTO focuses on the *duration of service unavailability* and the speed of restoration. The Recovery Point Objective (RPO), however, is concerned with the *amount of data loss* that is acceptable, not the time it takes to bring systems back online.

Ensure encryption keys for backups are available

Why it fails: While important, this is a prerequisite rather than a restoration consideration; but it's not one of the three if the question expects other answers? Actually, it is important, but the answer set likely wants B, C, D. However, E is also a consideration. Let me adjust: The question says 'key considerations' and E is valid but perhaps the intended correct are B, C, D. I'll keep B, C, D as correct.

Restore data directly to production servers to save time

Why it fails: Restoring data directly to production servers immediately after a ransomware attack is a high-risk strategy that prioritizes speed over security and reliability. This approach bypasses critical verification steps, such as malware scanning and integrity checks, potentially reintroducing the ransomware or other dormant threats to the production environment. Furthermore, it prevents the validation of the restored data's functionality and completeness in a safe sandbox, risking further operational disruption and a failed recovery.

Medium

Why it fails: While some less stringent risk matrices might categorize a high likelihood and medium impact scenario as medium, standard practice in robust qualitative risk assessments often elevates this. The high probability of an event occurring, even if its individual impact is not extreme, typically warrants a higher classification. This ensures that frequently occurring issues with noticeable consequences receive appropriate attention and resource allocation.

Critical

Why it fails: Critical risk is generally reserved for scenarios where both the likelihood and the impact are assessed as 'High' or 'Very High,' indicating a near-certain catastrophic event. In this case, while the likelihood is high, the impact is only medium, which does not meet the threshold for a critical designation. A critical risk implies an existential threat or severe operational failure that would fundamentally compromise the organization's mission or survival.

Low

Why it fails: Classifying a risk with high likelihood and medium impact as 'Low' would fundamentally misrepresent the potential threat and is inconsistent with standard risk management principles. A high probability of occurrence, regardless of the impact level, inherently means the event is likely to happen, precluding a low-risk rating. Low risk typically applies to events with very low likelihood and minimal impact, requiring minimal mitigation effort.

NIST Cybersecurity Framework

Why it fails: The NIST Cybersecurity Framework (CSF) is a voluntary framework designed to help organizations, particularly critical infrastructure, manage and reduce cybersecurity risks. It provides a flexible, risk-based approach to improving cybersecurity posture through five core functions: Identify, Protect, Detect, Respond, and Recover. While excellent for cybersecurity risk management, it does not prescribe a formal, auditable management system for all information assets in the comprehensive manner of ISO 27001.

COBIT 2019

Why it fails: COBIT 2019 (Control Objectives for Information and Related Technologies) is a comprehensive framework for enterprise governance of information and technology (EGIT). It provides principles, processes, and organizational structures to help organizations govern and manage their IT assets and information holistically, aligning IT with business objectives and managing IT-related risks. While information is central, COBIT's scope is broader, encompassing overall IT governance rather than a specific information security management system.

ITIL

Why it fails: ITIL (Information Technology Infrastructure Library) is a widely adopted framework providing detailed practices for IT service management (ITSM). It focuses on aligning IT services with business needs, covering the entire service lifecycle from strategy and design to operation and continual improvement. ITIL is primarily concerned with the efficient and effective delivery and support of IT services, rather than the overarching governance and security management of information assets themselves.

Avoid

Why it fails: Avoid is a valid strategy, but it is not included as a correct answer here because the question focuses on Transfer and Accept as the two correct choices.

Ignore

Why it fails: Ignore is not a standard risk response strategy; risks must be addressed properly.

Eliminate

Why it fails: Eliminate is not standard terminology; the proper term is Avoid.

Auditing

Why it fails: Auditing, while a critical security function, is not considered a distinct, standalone element within the AAA framework itself. Instead, the data collection necessary for auditing, such as user actions, system events, and resource consumption, is primarily handled by the Accounting component. Accounting provides the raw logs and records that security teams later analyze during an audit to detect anomalies, investigate incidents, or ensure compliance.

Availability

Why it fails: Availability is a fundamental principle of information security, representing one-third of the well-known CIA triad (Confidentiality, Integrity, Availability). It ensures that authorized users can reliably access information and resources when needed. However, availability is a broader security goal and system characteristic, distinct from the operational functions of identity verification, access control, and activity logging provided by the AAA framework.

Act honorably

Why it fails: This is the second canon of the ISC2 Code of Ethics, which mandates that professionals "Act honorably, honestly, justly, responsibly, and legally." It requires practitioners to maintain the highest standards of personal and professional conduct, ensuring that all actions are beyond reproach and comply with applicable laws.

Provide diligent service

Why it fails: While "Provide diligent and competent service to principals" is indeed an official ISC2 canon, it is the third canon in the hierarchy, not the first or second. In the event of a conflict, this duty to employers and clients is legally and ethically subordinate to protecting society and acting honorably.

Act honestly

Why it fails: Although acting honestly is a core behavioral expectation embedded within the text of the second canon, "Act honestly" is not a standalone canon itself. Candidates must distinguish between the high-level titles of the four official canons and the specific descriptive adjectives used within their supporting text.

Advance the profession

Why it fails: This option represents the fourth and final canon of the ISC2 Code of Ethics: "Advance and protect the profession." While vital for the long-term growth and integrity of the cybersecurity community, it occupies the lowest priority in the ethical hierarchy and is incorrect for questions targeting the first two canons.

Binding Corporate Rules (BCRs)

Why it fails: Binding Corporate Rules are internal policies approved by supervisory authorities for intra-group transfers within a corporate group. While they are a valid GDPR transfer mechanism, they are not suitable for transfers to external parties and require lengthy approval. The scenario does not specify intra-group transfers, so SCCs are more appropriate.

Privacy Shield Framework

Why it fails: The EU-US Privacy Shield Framework was invalidated by the Court of Justice of the European Union in 2020 (Schrems II). It is no longer a valid mechanism for data transfers from the EU to the US. Therefore, it cannot be used to meet GDPR requirements, making it incorrect.

Adequacy decision by the European Commission

Why it fails: An adequacy decision is a determination by the European Commission that a non-EU country provides an adequate level of data protection, allowing free data flows. However, the US does not currently have a general adequacy decision. While the EU-US Data Privacy Framework was adopted in 2023, it is not an adequacy decision in the traditional sense and is subject to legal challenges. SCCs remain the most reliable mechanism.

Authorization, Authentication, Accounting

Why it fails: This order is fundamentally flawed because authorization, which grants access permissions, cannot logically occur before authentication. An access control system must first verify the identity of a user or entity ('who you are') through authentication mechanisms. Without a confirmed identity, the system has no basis to determine what specific privileges ('what you can do') should be assigned or denied.

Authentication, Accounting, Authorization

Why it fails: Placing accounting before authorization is incorrect as it attempts to log activities before access rights are even established. The system must first authenticate the user and then authorize their specific permissions to resources. Only after authorization has determined what actions are permissible can accounting accurately record those actions in the context of granted access, ensuring proper audit trails.

Accounting, Authentication, Authorization

Why it fails: Initiating the access control process with accounting is illogical, as there are no actions to log prior to identity verification and permission assignment. Accounting's role is to record events and resource usage, which presupposes that a user has been identified and granted some level of access. Therefore, both authentication and authorization must precede any meaningful accounting activities within the system.

$100,000

Why it fails: This figure represents the Asset Value (AV), which is the total worth of the asset being protected, such as the data itself or the system housing it. While a critical component in risk assessment, the AV alone does not account for the probability or impact of a specific threat event. It is merely the starting point for calculating potential losses, not the Annualized Loss Expectancy (ALE).

$50,000

Why it fails: This amount represents the Single Loss Expectancy (SLE), which quantifies the financial impact of a single occurrence of a specific threat. The SLE is calculated by multiplying the Asset Value (AV) by the Exposure Factor (EF), representing the percentage of asset loss due to the threat. However, SLE does not incorporate the frequency of the event, making it an incomplete measure for the Annualized Loss Expectancy (ALE).

$20,000

Why it fails: This value would be obtained if an incorrect Annualized Rate of Occurrence (ARO) of 0.4 (or 40%) was used in the calculation. If the Single Loss Expectancy (SLE) is $50,000, multiplying it by an ARO of 0.4 yields $20,000. However, for this specific scenario, the correct ARO is 0.2, indicating a lower annual probability of the data breach occurring than assumed in this incorrect calculation.

Provide diligent and competent service to principals

Why it fails: This canon, while crucial for professional conduct, is the third in the (ISC)² Code of Ethics hierarchy, meaning it does not take precedence over the first two. It mandates that CISSPs perform their duties with the highest level of professional care and skill for their employers, clients, or other stakeholders. However, this obligation is subordinate to protecting society and acting honorably, especially when conflicts of interest or duty arise.

Act honorably, honestly, justly, responsibly, and legally

Why it fails: This canon represents the second-highest priority within the (ISC)² Code of Ethics, establishing the foundational ethical conduct expected of all certified professionals. It requires adherence to legal statutes and ethical principles in all professional activities, ensuring integrity and trustworthiness. While fundamental to a CISSP's professional life, this canon is superseded by the paramount duty to protect society, the common good, and the infrastructure.

Advance and protect the profession

Why it fails: This canon is the fourth and lowest in the hierarchical structure of the (ISC)² Code of Ethics, meaning it does not take precedence over the other three. It obligates CISSPs to uphold the reputation of the information security profession, contribute to its knowledge base, and mentor future professionals. While important for the long-term viability and respect of the field, this duty is subordinate to all other canons, particularly the direct protection of society.

Warm site

Why it fails: A warm site provides a facility with pre-installed hardware and network infrastructure, but it typically lacks current data and may require significant configuration and data restoration efforts. While offering a faster recovery than a cold site, its near-real-time or batched data synchronization means it cannot achieve the extremely low Recovery Time Objective (RTO) and Recovery Point Objective (RPO) required for critical applications demanding immediate availability.

Cold site

Why it fails: A cold site is an empty facility equipped only with basic utilities like power and cooling, requiring the organization to procure, transport, install, and configure all necessary hardware, software, and data. This extensive setup process results in the longest Recovery Time Objective (RTO) and Recovery Point Objective (RPO) among all disaster recovery site types. Consequently, a cold site is entirely unsuitable for critical applications that necessitate rapid restoration and minimal downtime.

Reciprocal agreement

Why it fails: A reciprocal agreement involves two organizations agreeing to provide backup facilities to each other in a disaster scenario. However, this approach carries substantial risks, as the host organization's resources may be insufficient, incompatible, or unavailable when needed, especially if both parties are affected simultaneously. Such agreements often lack guaranteed service levels and typically cannot meet the stringent Recovery Time Objective (RTO) and Recovery Point Objective (RPO) demands of critical applications due to potential resource contention or configuration discrepancies.

ISO/IEC 27001

Why it fails: ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). While it ensures secure handling of information assets, its primary focus is on managing information security risks and controls across an organization, not on the lifecycle management of IT services themselves.

NIST Cybersecurity Framework

Why it fails: The NIST Cybersecurity Framework provides a policy framework of computer security guidelines to help organizations manage and reduce cybersecurity risks. It outlines five core functions—Identify, Protect, Detect, Respond, and Recover—to improve an organization's ability to prevent, detect, and respond to cyber incidents, but it does not detail a service delivery lifecycle.

COBIT 2019

Why it fails: COBIT 2019 is a comprehensive framework for enterprise IT governance and management, providing principles, processes, and organizational structures to align IT with business objectives. It focuses on value creation from IT, risk optimization, and resource optimization across the entire enterprise, rather than specifically detailing the lifecycle stages of individual IT services.

Medium risk

Why it fails: "Medium risk" is typically assigned in a qualitative risk assessment when either the likelihood or the impact is moderate, or when one factor is high while the other is low, resulting in an intermediate overall risk level. It represents a situation where the potential harm is not catastrophic, and the event is not highly probable, suggesting that mitigation efforts can be prioritized after higher risks are addressed.

Low risk

Why it fails: "Low risk" is characterized by both a low likelihood of a threat event occurring and a minimal impact if it were to materialize, according to the qualitative assessment criteria. This combination indicates that the potential for adverse effects on organizational assets or operations is negligible, allowing for less urgent or less resource-intensive mitigation strategies, or even risk acceptance.

De minimis risk

Why it fails: "De minimis risk" refers to a level of risk that is so insignificant or trivial that it can be practically ignored, often falling below the threshold for any formal risk management action or resource expenditure. It implies an extremely low likelihood and an almost imperceptible impact, making it economically impractical or unnecessary to expend resources on further analysis or mitigation efforts.

Step 1: Log in, Step 2: Enter code, Step 3: Access system

Why it fails: A procedure provides detailed, step-by-step instructions for performing a specific task or process. This example clearly outlines the sequential actions required to gain system access, making it an operational guide rather than a high-level organizational mandate. Policies state *what* must be done, while procedures explain *how* to do it.

It is recommended to change passwords every 90 days

Why it fails: A guideline offers advice or best practices that are strongly suggested but not strictly mandatory. The use of "recommended" indicates a flexible suggestion rather than a compulsory rule, allowing for discretion based on specific circumstances. Policies, in contrast, establish binding requirements that must be followed without exception.

Use passwords of at least 12 characters with mixed case and numbers

Why it fails: A standard specifies mandatory requirements for hardware, software, or configurations to ensure consistency and interoperability within an organization. This example details specific technical parameters for password construction, providing a precise, enforceable rule for password complexity. While derived from policy, it outlines the *specific technical criteria* that must be met, rather than the overarching security objective.

Corporate policy

Why it fails: Corporate policy, while crucial for internal governance and operational consistency, does not independently serve as a lawful basis for processing personal data under GDPR Article 6. GDPR explicitly requires a specific legal ground, such as consent, contract, legal obligation, vital interests, public task, or legitimate interests, to justify data processing activities. An internal policy merely dictates how an organization operates, not the legal permissibility of its data handling, meaning reliance solely on such a policy would result in non-compliance.

Profit motive

Why it fails: Profit motive, while a primary driver for commercial enterprises, is not recognized as a standalone lawful basis for processing personal data under the GDPR. The desire for financial gain may underpin activities that could potentially be justified under the 'legitimate interests' basis, but only if a strict balancing test is performed. This test must demonstrate that the organization's interests are not overridden by the fundamental rights and freedoms of the data subject, making mere profit a insufficient justification.

Marketing preference

Why it fails: Marketing preference refers to an individual's expressed choice regarding the receipt of marketing communications, or their opt-in/opt-out status. This preference itself is not a lawful basis for processing personal data under GDPR. Instead, the processing of data for marketing purposes must be justified by a specific lawful basis, typically either the data subject's explicit consent or the organization's legitimate interests, provided a robust impact assessment and balancing test are conducted. The preference merely dictates the scope or permissibility of marketing activities under an established basis.

Annual audit report

Why it fails: While HIPAA-covered entities are required to conduct risk analyses and implement security measures, an "annual audit report" is not a specific document mandated by HIPAA that must be shared with a Business Associate (like a billing company) as a prerequisite for data sharing. The primary requirement for establishing a compliant data-sharing relationship with a Business Associate is the execution of a Business Associate Agreement, which outlines responsibilities rather than requiring the sharing of internal audit findings.

Patient consent

Why it fails: HIPAA generally permits the use and disclosure of Protected Health Information (PHI) for treatment, payment, and healthcare operations (TPO) without requiring explicit patient consent or authorization. Sharing PHI with a billing company falls squarely under "payment" operations, which is a permissible disclosure under HIPAA. While patients have the right to receive a Notice of Privacy Practices, this informs them of how their PHI may be used, but does not necessitate their specific consent for TPO activities.

Data Protection Impact Assessment

Why it fails: A Data Protection Impact Assessment (DPIA) is a specific requirement under the European Union's General Data Protection Regulation (GDPR) for processing activities likely to result in a high risk to individuals' rights and freedoms. While a hospital subject to HIPAA must conduct a risk analysis as part of its Security Rule compliance, a DPIA is a distinct regulatory instrument not mandated by HIPAA for sharing PHI with a billing company in the United States.

$30,000

Why it fails: This value is incorrect for the Annualized Loss Expectancy (ALE) and indicates a miscalculation. It appears to be derived by multiplying the Single Loss Expectancy (SLE) of $15,000 by an incorrect Annualized Rate of Occurrence (ARO) of 2, or by simply doubling the SLE. Such an error would imply the threat event occurs twice a year, which contradicts the scenario where $7,500 is the correct ALE, suggesting an ARO of 0.5. This miscalculation significantly overestimates the annual financial impact of the risk, leading to potentially misguided resource allocation.

$15,000

Why it fails: This figure represents the Single Loss Expectancy (SLE), which is the monetary loss expected each time a specific threat event occurs. SLE is calculated as the Asset Value (AV) multiplied by the Exposure Factor (EF), quantifying the impact of a single incident. However, the question asks for a value that is likely the Annualized Loss Expectancy (ALE), which incorporates the frequency of occurrence over a year. Therefore, while $15,000 is a crucial component in the ALE calculation, it is not the final annualized figure that accounts for recurrence.

$75,000

Why it fails: This value is significantly higher than the correct Annualized Loss Expectancy (ALE) and strongly suggests a calculation error, most likely a misplaced decimal point or an incorrect multiplier. If the Single Loss Expectancy (SLE) is $15,000 and the Annualized Rate of Occurrence (ARO) is 0.5, then multiplying $15,000 by 5 instead of 0.5, or by 0.05 and then by 10, would lead to this erroneous result. Such a substantial overestimation would lead to misinformed risk management decisions, potentially causing an organization to overspend on controls for a less impactful risk.

Implement security controls

Why it fails: Implementing security controls is a risk-treatment activity performed after the BIA identifies impact; the BIA itself quantifies disruption and recovery priorities, not control deployment. Control selection suits the risk response stage, where identified critical processes are matched to safeguards.

Identify vulnerabilities in the network

Why it fails: A BIA quantifies the operational and financial impact of disrupting business processes, establishing recovery priorities and tolerances; it does not enumerate network weaknesses. Vulnerability identification belongs to risk assessment or scanning. The option tempts because BIA feeds risk analysis, but its axis is impact over time, not flaw discovery.

Test the disaster recovery plan

Why it fails: Testing the disaster recovery plan validates recovery capability and occurs after the BIA has set recovery time and point objectives. The BIA determines impact and criticality; it does not execute tests. DR testing suits the later validation phase, once continuity strategies are built from BIA findings.