Governance, Risk, and Compliance practice questions

Data masking for all patient data

Why it fails: Data masking is not specifically mandated by HIPAA; encryption is the primary control.

Annual penetration testing

Why it fails: Penetration testing is not specifically mandated by HIPAA.

Public key infrastructure for all users

Why it fails: PKI is not explicitly required; alternative controls may be acceptable.

Average time to patch critical vulnerabilities

Why it fails: This is a KPI for patch management efficiency.

Mean time to detect (MTTD)

Why it fails: This is a KPI for detection capability.

Number of security awareness training completions

Why it fails: This is a KPI, not a KRI; it measures activity, not risk.

Total number of security incidents this quarter

Why it fails: This is a lagging indicator, not a leading KRI.

Mean time to detect (MTTD)

Why it fails: MTTD is a KPI measuring performance, not a risk indicator.

$150,000

Why it fails: Incorrect calculation.

$50,000

Why it fails: This is SLE, not ALE.

$200,000

Why it fails: This would be multiplying AV by ARO without EF.

Conducting annual risk assessments

Why it fails: Risk assessments are required but not specifically for cardholder data protection.

Using a dedicated network segment for card processing

Why it fails: Network segmentation is recommended but not mandatory if compensating controls exist.

Implementing multi-factor authentication for all users

Why it fails: MFA is required for remote access and non-console admin access, but not all users.

Unclassified

Why it fails: Unclassified is a government term.

For Official Use Only

Why it fails: This is a U.S. government marking, not a typical corporate classification.

Top Secret

Why it fails: Top Secret is a government classification, not typically used in corporate.

Standard, Policy, Procedure, Guideline

Why it fails: Policy should be highest.

Policy, Guideline, Standard, Procedure

Why it fails: Standards are above guidelines.

Procedure, Guideline, Standard, Policy

Why it fails: This is reversed order.

Mean time to detect (MTTD) for security incidents

Why it fails: This is a lagging indicator.

Number of security incidents reported last month

Why it fails: This is a lagging indicator.

Percentage of systems with antivirus installed

Why it fails: This is a security control metric, not a KRI.

Categorize

Why it fails: Categorize assigns an impact level to the system and its information, producing the starting point for control selection rather than performing it. It is tempting because categorisation drives which control baseline applies, so it shapes selection indirectly; it would be the right step when first determining system criticality under FIPS 199.

Assess

Why it fails: Assess determines whether implemented controls are effective, occurring after selection and implementation, so it cannot choose controls from the risk assessment. It is tempting because assessment also uses risk information; it would be correct when evaluating an existing control set against a baseline during authorisation preparation.

Implement

Why it fails: Implement executes the approved controls and documents their deployment; selection happens earlier, in the Select step, where controls are chosen from the assessment. Implement suits organisations that have already completed selection and are now applying controls within their systems.

Employee satisfaction score

Why it fails: This is an HR metric, not a security KPI.

Number of critical vulnerabilities identified

Why it fails: This is a KRI (risk indicator), not a KPI of program effectiveness.

Total budget spent on security

Why it fails: Budget is a resource metric, not a performance indicator.

Guideline, Policy, Procedure, Standard

Why it fails: Incorrect. Policy is highest, guideline is lower.

Standard, Policy, Procedure, Guideline

Why it fails: Incorrect. Policy should be highest.

Procedure, Guideline, Standard, Policy

Why it fails: Incorrect. This is reversed.

Confidential

Why it fails: Incorrect. Confidential may cause moderate harm, but 'restricted' is higher.

Public

Why it fails: Incorrect. Public data is intended for release.

Internal

Why it fails: Internal data classification assumes disclosure would cause only minor or moderate harm, not the serious reputational or financial damage specified in the stem. This option is tempting because many organisations use "Internal" as a default label for non-public business data, and it would be correct for data whose exposure causes limited inconvenience rather than severe impact. The concrete failure is that the stem demands a tier that explicitly addresses critical harm, which "Internal" does not cover.

Requiring the vendor to purchase cyber insurance

Why it fails: Incorrect. Insurance is a risk transfer, not a direct assessment of security.

Reviewing the vendor's financial statements

Why it fails: Incorrect. Financial health is important but not a direct security control assessment.

Percentage of employees who completed security awareness training

Why it fails: Incorrect. This is a KPI (performance indicator), not a risk indicator.

Time to patch critical systems

Why it fails: Incorrect. This is a performance metric.

Budget spent on security tools

Why it fails: Incorrect. This is a financial metric, not a risk indicator.

Right to transfer

Why it fails: Not a standard GDPR right; the correct term is data portability.

Right to be informed

Why it fails: This is a GDPR right, but it is not listed as one of the two correct options in this question.

Right to be forgotten

Why it fails: Incorrect. Although the right to be forgotten (erasure) is a GDPR right, it is not one of the two selected correct options in this question.

Supply chain bill of materials

Why it fails: Relevant for supply chain risk but not primary evidence for security controls.

Security questionnaire completed by the vendor

Why it fails: Self-reported and may not be independently verified.

Right-to-audit clause in the contract

Why it fails: A contractual right, not evidence of control effectiveness.

Policy, Procedure, Guideline, Standard

Why it fails: Standard should come before guideline and procedure.

Guideline, Policy, Standard, Procedure

Why it fails: Guideline is lower than policy and standard.

Standard, Policy, Procedure, Guideline

Why it fails: Policy should be above standard.

Guideline

Why it fails: A guideline offers recommendations and best practices but is not mandatory. The scenario requires mandatory use of MFA, so a guideline would be too permissive. Guidelines help guide decisions when no standard exists, but they lack the enforceability needed for administrative access controls. Thus, a guideline is not appropriate here.

Policy

Why it fails: A policy is a high-level statement of management intent, but it does not typically include specific technical requirements like MFA for administrative access. Policies are broad and enduring, while standards provide the detailed mandatory controls. The scenario asks for a document that specifies mandatory use of MFA, which is more granular than a policy.

Procedure

Why it fails: A procedure provides step-by-step instructions for performing a task. While MFA implementation may involve procedures, the document that mandates its use is a standard. Procedures are operational and focus on how to execute a process, not on setting mandatory requirements. The scenario asks for a document that specifies mandatory use, which is a standard's role.

PCI DSS Report on Compliance

Why it fails: A PCI DSS Report on Compliance is produced by a Qualified Security Assessor, but it applies only to entities that store, process, or transmit cardholder data and confirms payment-card controls. It is not a general, internationally recognized certification of an organization's security management system, so it would not satisfy a broad regulator and partner assurance requirement.

SOC 2 Type II

Why it fails: SOC 2 Type II does report on operating effectiveness of controls over a period, but it is an AICPA attestation aimed primarily at service organizations serving customers, not an internationally recognized framework designed for broad regulator and partner assurance. It also centers on the trust services criteria rather than a general control framework the retailer itself can be certified against.

NIST Cybersecurity Framework profile

Why it fails: The NIST Cybersecurity Framework is a voluntary risk-management framework that helps organizations describe current and target security postures through profiles and tiers. It provides no certification, no accredited assessor, and no formal opinion on control operating effectiveness, so it cannot deliver the independent assurance the retailer needs to present to regulators and partners.

Include a right-to-audit clause in all vendor contracts and exercise it annually.

Why it fails: A right-to-audit clause is valuable, but exercising it annually is resource-intensive and may not be feasible for all vendors. It provides periodic, not continuous, monitoring. Moreover, many cloud vendors refuse such clauses or offer alternative assurances like SOC 2 reports, making it less effective than continuous monitoring services.

Conduct a one-time penetration test of each vendor before onboarding.

Why it fails: A one-time penetration test provides only a point-in-time snapshot and does not support continuous monitoring. Vendors' environments change, so a single test becomes outdated quickly. While useful for initial due diligence, it fails to meet the requirement for ongoing visibility and contractual protections.

Require vendors to self-attest compliance with industry best practices via a questionnaire.

Why it fails: Self-attestation is subjective and lacks independent verification. It can be easily falsified or based on incomplete information. While questionnaires are useful for initial screening, they do not provide the reliable, ongoing assurance needed for critical SaaS providers. They are not an effective continuous monitoring control.