CCNA Governance, Risk, and Compliance Questions

Accountability for risk that exceeds the approved appetite rests with the board or a committee it empowers, since governance ultimately owns organizational risk. Executives and security staff implement and monitor controls, but accepting risk beyond the tolerance level requires the governing body's authority and oversight.

The organizational security policy sits at the top of the hierarchy, establishing management's mandatory intent and direction. Standards, guidelines and procedures all derive from and must align with it, so it satisfies the stem's requirement for the highest-level document.

Privacy by design requires that privacy be considered proactively and embedded into the design rather than added after deployment. Conducting a privacy impact assessment early identifies risks and informs decisions about what data to collect, how long to keep it, and how to protect it. Designing data minimization controls at the start directly implements the principle of limiting collection to what is necessary and demonstrates privacy by design in this scenario.

A policy is a high-level, management-approved statement of intent that defines the organization's security objectives and assigns responsibility without prescribing technical detail. The board's document matches this exactly: it sets overall direction, delegates accountability to executives, and intentionally avoids product-specific or configuration-level content. That places it at the top of the governance hierarchy, above standards and procedures.

The recovery time objective (RTO) is the maximum acceptable time that an application or system can be unavailable after a disruption. It defines how quickly the business needs the service restored. In this scenario, an RTO of 4 hours means the e-commerce application must be back online within 4 hours to avoid unacceptable business impact. This is the correct definition.

Mitigation applies controls to reduce risk.

Mean Time to Detect measures the average elapsed time between an incident occurring and its detection, exactly matching the metric described. It isolates detection speed from response or resolution timing, which are covered by separate metrics.

A SOC 2 Type II report covers controls over a period, but it is six months old and may not address your specific data flows. A risk assessment using a security questionnaire gathers current, scenario-specific evidence about how the vendor protects your customer database.

Automated daily file integrity monitoring directly satisfies PCI DSS continuous monitoring by detecting unauthorised changes to critical system files between point-in-time assessments. Unlike periodic manual reviews, it provides the ongoing, evidence-generating oversight the stem demands, flagging tampering or drift promptly so remediation occurs before the next audit cycle.

Transfer shifts the financial consequences of a risk to a third party, typically an insurer, while the risk itself remains. Insurance is the classic example, matching the stem's requirement to move financial impact rather than avoid, reduce or accept the risk.

The GDPR mandates appointing a Data Protection Officer for large-scale monitoring or special-category processing, and requires data protection impact assessments for high-risk processing. These obligations are explicit GDPR articles, matching the stem's EU personal-data scenario rather than CCPA, HIPAA or SOX.

A right-to-audit clause contractually grants the company permission to examine the vendor's security controls, evidence and records. It directly satisfies the requirement to perform an audit, giving enforceable access rather than relying on the vendor's voluntary cooperation.

Restricted data demands the highest protection level, typically limited to a very small number of authorised individuals with strict need-to-know. It sits above confidential, internal and public classifications, matching the scenario's requirement for the most tightly controlled category.

A SOC 2 Type II report tests controls across a defined audit period rather than a single point in time, so the auditor's opinion addresses whether controls operated effectively throughout those 12 months. This satisfies the vendor risk assessment's need for evidence of sustained control performance.

Regulatory breach-notification regimes impose fixed deadlines measured from awareness, and contracts with partners often impose separate, sometimes tighter deadlines. Notifying regulators, affected individuals, and contractually entitled parties within each applicable window satisfies the full set of obligations. This parallel approach respects that different recipients have different triggers and timelines, which is exactly what the incident lead must coordinate.

A right-to-audit clause contractually grants the organisation the ability to inspect the vendor's controls, records and security practises on an ongoing basis. This directly satisfies the requirement for continuing visibility into the vendor's security posture, unlike one-off certifications or SLAs, which only report point-in-time or service-level assurances.

Restricted data demands the strictest controls because it covers information whose exposure causes severe harm, such as trade secrets or regulated personal data. It sits above Confidential, Internal and Public in the classification hierarchy, satisfying the stem's requirement for the highest sensitivity tier needing the most stringent protection.

GDPR Article 35 requires a DPIA when processing is likely to result in a high risk to data subjects, especially when using new technologies and processing special categories of data on a large scale. Clinical trials involving genetic and health data on a large scale clearly meet this threshold. Genetic data and health data are special categories under Article 9, and large-scale processing triggers the DPIA requirement.

Automated discovery that assigns classification labels at the point of creation enforces the labeling objective at the earliest possible moment and removes reliance on users to remember the scheme. It directly operationalizes the classification standard by ensuring every artifact carries its sensitivity marking, which downstream controls such as encryption and access rules can then act upon consistently.

MTTR directly quantifies how quickly the team contains and resolves incidents, making it the clearest indicator of response-process effectiveness. It captures elapsed time from detection to resolution, exposing bottlenecks in triage, escalation and containment that other metrics, such as incident counts, cannot reveal.

Embedding privacy controls at the initial system architecture stage satisfies privacy by design, which requires data protection to be built into systems from the outset rather than bolted on after deployment. Retrofitting later cannot match this preventative, architecture-level alignment.

Multiplying asset value by exposure factor gives the single-loss expectancy: $50,000 × 0.2 = $10,000. Annualising by the ARO of 4 yields $40,000, satisfying the stem's requirement to compute ALE from AV, EF and ARO. The $40,000 figure therefore matches the correct calculation.

The GDPR right to data portability requires that data subjects can receive their personal data in a structured, commonly used, and machine-readable format. An API endpoint that returns data in JSON or CSV satisfies this requirement and provides a scalable, automated way to fulfill data subject requests. This is the most direct technical control for the requirement.

GDPR is generally the most stringent regime the retailer faces, so using it as the baseline and layering stricter state-specific duties (for example, opt-out of sale or targeted advertising) onto that control set produces one harmonized framework that satisfies every jurisdiction without duplicating effort.

BCRs are approved by the competent supervisory authority and serve as a documented, enforceable framework for intra-group transfers and accountability. They demonstrate GDPR compliance without needing case-by-case authorization for each transfer, making them suitable for a multinational expanding into the EU. They are specifically designed for corporate groups with multiple entities, providing a transparent and legally binding mechanism.

A DPIA is a GDPR requirement for processing that likely results in high risk to data subjects. It identifies and mitigates privacy risks early in the design phase, directly implementing privacy by design. By conducting it before development, the architect ensures controls are built in, not bolted on, and addresses multiple regulatory requirements proactively.

The right to erasure, also called the right to be forgotten, lets a data subject require an organisation to delete personal data without undue delay. It is one of the GDPR's enumerated data subject rights, satisfying the stem's question.

When remediation is not feasible, applying compensating controls can reduce residual risk to an acceptable level. Network segmentation limits lateral movement, and enhanced monitoring improves detection. This approach aligns with the organization's risk appetite by addressing the risk without incurring the full cost of replacing the legacy application, and it demonstrates due diligence in managing accepted risks.

A publicly available exploit raises the likelihood of active attacks, since attackers can readily obtain working code. This directly increases the vulnerability's risk level when prioritising remediation, alongside impact factors such as asset criticality and exposure.

Fourth-party risk arises when a subcontractor, contracted by your direct vendor, handles your data without privity of contract with you. The stem's defining constraint — no contract exists between the organisation and the subcontractor — matches this exactly, since the exposure flows through the third party rather than directly.

COSO ERM emphasizes that risk management must be integrated with strategy-setting and performance, not treated as a separate compliance exercise. Embedding risk into strategic planning ensures objectives are pursued within the organization's risk appetite. This integration is a defining core component of ERM.

When a risk owner fails to act, the security team's role is to escalate through governance channels so that accountable leadership can make a decision. Providing the risk committee with the current status, potential impact, and lack of progress ensures the risk remains visible and that a timely treatment decision is made. This preserves accountability and aligns with risk management practices that require escalation when treatment deadlines are missed.

SAQ A is designed for merchants that fully outsource all cardholder data functions to PCI DSS validated third parties and do not store, process, or transmit cardholder data electronically. The retailer's use of a validated third-party payment page matches this profile exactly. Completing SAQ A is the correct and least burdensome validation path here.

Because the dominant residual exposure is time-to-recover against a hard 15-minute threshold, additional mitigation through automated failover and validated recovery exercises directly reduces the likelihood and impact of missing that objective. This aligns treatment with the actual risk driver, complements the existing backup controls, and gives the board measurable evidence that the residual risk now sits within appetite.

The encryption mandate exists as a stated policy, but no implementing procedures exist for mobile devices. The gap therefore lies between policy and procedures, since the documented requirement lacks the operational steps needed to enact it on that platform.

Contracting a validated service provider to handle card processing moves operational responsibility and much of the associated risk to that vendor. This is transference or sharing, since the provider assumes defined obligations and liabilities through the agreement, though the organization retains oversight and compliance accountability.

The RoPA is the Article 30 accountability artifact that catalogues each processing activity, its purposes, data categories, recipients, retention periods, and security measures. It directly answers the regulator's need for a living register documenting what is processed and for how long. Because the retailer processes data at scale, maintaining this register is mandatory and serves as the documentary backbone for demonstrating GDPR accountability.

Policies gain authority only when senior leadership formally approves them, which signals organizational commitment and provides the mandate for enforcement. Approval by executive management and the relevant governance body also ensures the policy aligns with business objectives and legal obligations, and it establishes accountability if disciplinary action is later required for violations, making this the essential step before publication.

Privacy as the default setting requires that systems automatically apply the strictest privacy protections without user intervention, so personal data is protected unless the individual opts otherwise. This directly satisfies the requirement that controls be integrated into default settings.

Risk transference shifts the financial impact of a risk to a third party, typically through insurance or contracts. By purchasing cyber insurance, the organization transfers the potential financial losses from a breach to the insurer. This is a classic example of risk transference. The risk itself remains, but the financial burden is shared or shifted. This aligns with the scenario.

Expiration dates enforce time-bound risk acceptance, ensuring exceptions are reviewed and renewed rather than persisting indefinitely. This directly satisfies the process requirement for periodic reassessment, preventing stale waivers from silently accumulating. Without expiry, exceptions become permanent policy bypasses, undermining governance and auditability across Microsoft Entra ID and other controlled environments.

Privacy by design embeds data minimisation and access controls into the CRM architecture from inception, rather than retrofitting them later. This satisfies GDPR's requirement that protection be built into processing systems and default settings before personal data is collected.

Public denotes information approved for unrestricted disclosure, carrying no confidentiality requirement. It satisfies the stem's requirement for a common classification level, forming the lowest tier of enterprise schemes and letting architects label marketing material, published policies and open datasets without unnecessary controls.

A retention and residency matrix ties each data category to the specific retention period and storage location mandated by every applicable jurisdiction, making conflicts explicit and resolvable. This is exactly the governance artifact needed when a single global schedule cannot satisfy GDPR and local residency law, because it allows differentiated handling per jurisdiction while preserving an auditable rationale.

Patch compliance percentage directly measures the proportion of assets carrying current security updates, giving the board a quantifiable view of vulnerability exposure reduction. It is a standard operational KPI because it tracks remediation effectiveness over time against a defined baseline, satisfying the stem's requirement for board-level security programme metrics.

Within the NIST RMF, Step 2 (Select) chooses controls from the risk assessment, and Step 3 (Implement) deploys them into the system. This mapping satisfies the stem's requirement to tie control selection and implementation to the organisation's governance structure.

SOC 2 Type II evaluates control design and operating effectiveness across a defined audit period, unlike Type I which reports design at a single point in time. This satisfies the vendor assessment requirement for sustained control performance evidence.

The right to erasure, or right to be forgotten, lets a data subject demand deletion of personal data where no overriding legal ground for retention applies. This directly satisfies the GDPR requirement for an individual to request erasure of their data.

PCI DSS Requirement 3 requires that stored cardholder data be rendered unreadable through encryption, truncation, tokenization, or hashing. This addresses data at rest and is essential for protecting stored PAN. The architect must ensure that any storage of cardholder data complies with this requirement to reduce the risk of compromise.

MTTR measures elapsed time from incident detection to containment or resolution, directly reflecting how quickly the response process actually works. It satisfies the stem's requirement for a KPI gauging incident response effectiveness, unlike volume or cost metrics.

Loss event frequency and loss magnitude form FAIR's two top-level factors, splitting risk into how often a threat event occurs and how much it costs. This taxonomy directly satisfies the stem's quantification requirement, letting analysts model frequency and magnitude separately rather than relying on qualitative ratings.

SOX mandates accurate, reliable financial reporting and internal controls over financial disclosure, directly satisfying the stem's regulatory constraint for a financial institution. Unlike frameworks centred on data privacy or payment card handling, SOX specifically governs the integrity of financial statements and the controls assuring their accuracy.

Quarterly scanning satisfies PCI DSS Requirement 11.3.2 by identifying exploitable weaknesses in external and internal networks before attackers do, enabling remediation within the mandated timeframe. Continuous detection keeps the cardholder data environment compliant between annual penetration tests, directly addressing the standard's timely-remediation constraint.

Loss Magnitude quantifies the financial impact of a single loss event across primary and secondary forms. It is a primary FAIR factor, paired with Loss Event Frequency to derive annualised risk exposure in the model.

Access control mechanisms are a core control area verified under right-to-audit clauses, confirming that only authorised identities reach vendor systems and data. Auditors examine authentication, authorisation and privileged access management to validate the vendor's safeguards against unauthorised entry.

ALE is calculated by multiplying single loss expectancy by annualised rate of occurrence: $50,000 × 0.2 = $10,000. This quantifies the expected annual loss from the risk, matching the stem's supplied SLE and ARO values.

The Authorize step is where a senior official reviews the security assessment results, the plan of action and milestones, and the continuous monitoring strategy, then formally accepts the residual risk and grants an authorization to operate. This directly satisfies the Chief Risk Officer's requirement that risk decisions be authorized before production changes are made, because the authorization decision is documented and tied to explicit risk acceptance.

The HIPAA Security Rule requires covered entities to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information. Documented system inventories and periodic risk analysis results are core administrative safeguards and provide direct audit evidence. This activity demonstrates that the hospital has identified where ePHI resides and has evaluated risks, which is exactly what an auditor expects to see.

Accepting the risk means the risk owner acknowledges the legacy application's exposure and proceeds without encryption, absorbing potential loss. This matches risk acceptance rather than mitigation, transfer or avoidance, satisfying the stem's decision to tolerate the identified risk.

Retention schedules per classification level directly satisfy PCI DSS's requirement to define and enforce how long cardholder data is kept. Mapping each classification to a defined retention period ensures data is disposed of once its purpose expires, preventing the indefinite storage the audit identified.

Mean time to patch measures the average elapsed duration between patch release and deployment across systems, directly quantifying remediation speed. It isolates the time dimension of the patching programme, unlike coverage or count metrics, which describe breadth rather than how quickly critical patches are applied.

A SOC 2 Type II report covers the design and operating effectiveness of controls over a review period, giving evidence that the provider's control environment actually functioned. Type I only assesses design at a point in time, so it cannot demonstrate sustained SOC 2 compliance during due diligence.

A right-to-audit clause contractually grants the organisation the ability to inspect a critical vendor's security controls and evidence on demand, satisfying the requirement for ongoing visibility into their security posture rather than relying on one-off assurances.

SLE equals asset value multiplied by exposure factor: $100,000 × 0.4 = $40,000. ALE equals SLE multiplied by annualised rate of occurrence: $40,000 × 2 = $80,000. This matches the calculated annualised loss expectancy for the credit card server.

System categorisation, assigning impact levels (low, moderate, high) based on confidentiality, integrity and availability, is a distinctive early step in the NIST RMF. ISO 27005 addresses risk assessment and treatment without mandating this formal categorisation phase, making it the unique element.

The provider has blocked access to internal audit reports but explicitly permits the firm to send assessors on-site. A direct on-site assessment lets the firm independently inspect the provider's controls, interview staff, and review evidence first-hand, generating the assurance the questionnaire or report-based approaches could not deliver under these constraints.

Multiplying the single loss expectancy of $50,000 by the annualised rate of occurrence of 0.2 yields $10,000, satisfying the stem's quantitative risk calculation. This figure represents the expected yearly financial loss from the asset, enabling cost-benefit comparison against proposed security controls.

Residual risk is what remains after existing controls are applied to an inherent risk. The firewall, tokenization, and recurring penetration tests reduce the likelihood and impact of exploitation, so the lower rating reflects residual risk. The scenario explicitly describes inherent risk dropping once current controls are considered, which is the definition of residual risk.

A KRI signals exposure against a defined risk appetite, not operational throughput. Critical vulnerabilities breaching that threshold indicate the security posture has moved beyond acceptable tolerance, prompting escalation. KPIs, by contrast, measure performance such as patch coverage or mean time to remediate, so this metric is the risk indicator.

Impact measures the severity of consequences if a risk materializes, including financial loss, reputational damage, and regulatory penalties. For an online banking platform, impact directly ties to customer trust and compliance. Prioritizing risks with high impact ensures that treatment addresses threats that could severely disrupt operations or violate regulations, aligning security efforts with business resilience.

Acceptance fits because the legacy system cannot be patched, remains operationally critical, and the mitigation cost exceeds the potential loss. Retaining the residual risk formally, with documented sign-off and monitoring, is the proportionate treatment rather than transfer, avoidance or further mitigation.

The Govern function, new in CSF 2.0, focuses on establishing and monitoring cybersecurity strategy, policies, and risk management. It ensures that governance structures are in place to support the other functions. This directly addresses the development and implementation of policies and procedures for managing risk.

NIST RMF is the U.S. federal framework built on the six-step lifecycle: Categorize, Select, Implement, Assess, Authorize and Monitor. It satisfies the stem's requirement for a federal-specific process, unlike ISO 31000 or COSO ERM, which lack this mandated authorisation step and U.S. federal alignment.

Requiring current SOC 2 Type II reports gives the firm an independent auditor's opinion on the design and operating effectiveness of the provider's controls over a period of time. Delivering them annually ensures the assurance stays valid rather than relying on a one-time snapshot. This directly supports ongoing, third-party-verified visibility into the provider's security posture and complements other contractual safeguards.

Continuous compliance monitoring continuously assesses controls against frameworks, so drift and misconfigurations surface immediately rather than at periodic audits. This satisfies the stem's requirement for a primary benefit: real-time visibility into compliance posture, enabling prompt remediation before gaps escalate into reportable findings.