ISC2 Governance, Risk and Compliance (CGRC) Practice Test

Risk acceptance decisions must honor mandatory regulatory requirements. The Payment Card Industry Data Security Standard (PCI DSS) Requirement 3 demands that primary account numbers be rendered unreadable (for example, by strong encryption) whenever stored. Because PCI DSS compliance is compulsory for any system that processes or stores cardholder data, the Authorizing Official cannot override this obligation simply by agreeing to accept the risk. The other statements are incorrect: FIPS 199 categorization would already have been completed in earlier RMF steps, NIST SP 800-37 does not forbid accepting moderate confidentiality risk, and OMB Circular A-123 addresses internal controls but does not require financial risks to be transferred.

Senior officials need a concise view of outstanding weaknesses and the progress of corrective actions. The Plan of Action and Milestones (POA&M) is the RMF document designed for that purpose; it is kept current and distributed so executives can track mitigation status and residual risk. The original Security Assessment Report is a historical snapshot, not a living report. A Configuration Management Plan describes baseline processes but does not convey current compliance status. A boundary diagram is useful for architecture reviews, yet it does not communicate risk remediation progress.

A System Security Plan (SSP) is the foundational document in the Risk Management Framework that details the system's boundaries, operational environment, and every security control selected or implemented. Assessors rely on the SSP to understand how the organization intends to meet each control requirement before they decide what additional evidence, interviews, or technical tests are necessary. A Plan of Action and Milestones focuses only on outstanding deficiencies and does not provide a complete control picture. An Authorization to Operate letter merely records the authorizing official's decision and gives no detail about control implementation. A configuration baseline snapshot is useful for technical verification but lacks the broader context of all administrative, technical, and managerial controls. Therefore, reviewing the SSP first gives the assessor the most comprehensive starting point for evaluating compliance.

Untracked control deficiencies present a direct gap in the risk picture the authorizing official needs to see. If weaknesses documented in the SAR do not appear in the POA&M with planned remediation steps and milestones, the organization cannot demonstrate that it is managing those risks, which often results in the authorization decision being postponed. Editorial issues such as inventory currency, document titles, or formatting rarely cause a delay as long as the underlying control status is transparent and properly managed.

The system owner has primary responsibility for the overall procurement, development, integration, modification, operation, maintenance, and eventual disposal of an information system. Because this role is accountable for day-to-day management and life-cycle decisions, the system owner must be involved from the outset of any assessment or audit.

The information owner focuses on data-specific policies, not system operation. An independent auditor/assessor conducts the review but is not responsible for system decisions. The CISO sets enterprise security strategy and oversight but does not manage individual system life cycles. Therefore, including the system owner is essential when establishing stakeholder participation for the assessment.

ISO/IEC 27001 clause 6.1.3 d mandates creation of a Statement of Applicability (SoA). The SoA maps each Annex A control to the organization's risk treatment results, shows its implementation status, and records a rationale for inclusion or justified exclusion. A Risk Treatment Plan schedules actions but does not track implementation status control-by-control. A generic control implementation matrix is not a prescribed ISO/IEC 27001 artifact, and a Security Test and Evaluation Report is associated with other frameworks, not the ISMS certification process.

AC-16 establishes the requirement to associate security and privacy attributes-such as CUI designations-with information in a system. Enhancement (1), Automated Marking, specifically requires the system to automatically generate and apply those markings when the information is created, processed, stored, or transmitted. MP-3 focuses on labeling physical or removable media but does not mandate automated tagging of individual electronic files. SC-12 addresses cryptographic key management rather than data marking. PL-4 defines user behavior rules and likewise does not create or enforce automated CUI banners. Therefore, AC-16(1) is the control enhancement that directly meets the automated CUI marking requirement.

Scope is defined by whether a component processes, stores, or transmits organizational information that is subject to the assessment objectives. Because the CRM SaaS handles regulated customer data and ties directly into core business workflows, it must be considered part of the system boundary. Physical location and ownership of hardware do not remove compliance obligations, and the difficulty or cost of evidence collection does not determine scope.

The Plan of Action and Milestones (POA&M) is the authoritative artifact for tracking security-control weaknesses that remain unresolved or have been formally accepted. For every deficiency it captures the planned corrective actions, required resources, responsible parties, and target or milestone dates, ensuring the issue stays visible until it is remediated or permanently accepted. A communication matrix merely specifies who will exchange risk information, the testing methodology annex describes assessment procedures, and an executive summary offers only a high-level overview-none of these provide the detailed, line-item tracking required for open control deficiencies.

Strengthening existing safeguards to lower the likelihood or impact of a vulnerability is an example of risk mitigation. You are not eliminating the appliance altogether (avoidance), living with the unaltered risk (acceptance), or shifting liability to another party (transfer/share). Instead, you are adding compensating controls to reduce the risk level until the vendor patch is available, which aligns with a mitigation strategy.

Because the identity-and-access management service is implemented, assessed, and authorized at the organizational level, its safeguards are considered common controls that multiple information systems can inherit. System-specific controls are tailored only to the payroll system itself, while hybrid controls split responsibility between system and provider. Discretionary controls describe a type of access control decision method, not a category of inheritability.

NIST SP 800-53B instructs organizations to begin with the entire high-impact baseline-this includes every control and enhancement identified for high systems. Tailoring is permitted, but any control removed or downgraded must be justified and documented in the System Security Plan. Simply implementing common controls, selecting only P1 items, or starting from the low baseline contradicts the guidance because those methods omit protections that the high-impact baseline presumes necessary to prevent severe or catastrophic harm.

NIST SP 800-64 Rev. 2 (Table 3-15) lists the initial activity in the Disposal phase as identifying and inventorying all hardware, software, and data that will be removed from service. This inventory establishes exactly what assets and information must be addressed. Only after completing this accounting does the organization develop and approve a disposal or transition plan that details how the inventoried components will be sanitized, archived, transferred, or destroyed. Revoking the ATO, exporting audit logs, and performing media sanitization are later tasks executed in accordance with that approved plan.

NIST SP 800-115 and SP 800-53A both state that an assessment or testing plan is not considered final until it receives formal approval from senior management-typically the authorizing official and the system owner. Their sign-off confirms that the defined scope, methods, resources, and schedule meet organizational and regulatory expectations and that management accepts any residual risks associated with the planned activities.

The other options describe useful preparation tasks but they do not constitute formal plan finalization. A kickoff briefing (option B) is normally scheduled after the plan is approved. Procuring tools and test accounts (option C) supports execution but can proceed only once the plan is authorized. Adding preliminary findings from earlier audits (option D) may enhance context, yet it is not a prerequisite for plan approval. Therefore, obtaining documented management approval is the required step to complete the assessment plan.

Because privileged users may connect from unmanaged, potentially insecure devices and networks, the threat of credential theft or session hijacking increases. Requiring multifactor authentication (MFA) for all privileged remote sessions is a widely adopted safeguard that aligns with NIST SP 800-53 Revision 5 control IA-2(11), which mandates MFA for remote access by both privileged and non-privileged users. Implementing MFA makes it far harder for attackers to compromise accounts with stolen passwords alone. By contrast, reducing log retention, allowing obsolete SSH v1, or disabling session timeouts would decrease security and fail to mitigate the identified risk.

The primary purpose of an authorization boundary is to identify every component that stores, processes, or transmits the system's information so that assessors and authorizing officials know precisely what must be protected and evaluated. Listing all hardware, software, and network interfaces establishes the scope of the security assessment and control implementation. Although data-retention schedules, privileged-user lists, and overarching privacy policies are important artifacts within a complete System Security Plan, they do not by themselves establish where the system begins and ends or what resources are subject to control selection. Therefore, specifying all system components and interconnections is the most critical detail for the authorization boundary.

Risk acceptance must be formally approved by those who have the authority to bear that risk. Under the NIST RMF, the authorizing official documents an Authorization Decision in which the residual risk is either accepted, mitigated, or the system is denied operation. A written risk-acceptance memorandum or Authorization Decision signed by the authorizing official (and usually acknowledged by the system/business owner) satisfies the requirement for stakeholder concurrence. Simply adding items to a POA&M, re-classifying risk levels, or transferring risk without formal agreements does not constitute documented concurrence and would violate RMF process expectations.

The standard that enumerates detailed information security controls and provides implementation guidance is ISO/IEC 27002 (Code of practice for information security controls). It complements ISO/IEC 27001 by describing the objectives and recommended controls organizations may adopt to meet confidentiality, integrity, and availability requirements. ISO/IEC 27000 supplies only terminology and an overview, ISO/IEC 27001 specifies high-level management system requirements, and ISO/IEC 27005 focuses on risk management rather than listing specific security controls.

The purpose of the risk mitigation summary in an initial assessment report is to give management a concise, high-level view of how each identified risk could be reduced. At this early point the assessor is not expected to deliver a full project plan or evidence of completed fixes. Instead, the report should briefly describe potential control enhancements or procedural changes that would lower the likelihood or impact of the vulnerability. Detailed budgets, residual-risk decisions, and verification of completed remediation occur later in the remediation and follow-up phases, so those items are inappropriate for the initial report.

The request to correct inaccurate personal information and to complete missing details invokes the GDPR right to rectification. This right, set out in Article 16, allows individuals to have inaccurate personal data corrected without undue delay and, where incomplete, to have it completed. By contrast, the right to erasure (the 'right to be forgotten') concerns deleting data entirely, the right to data portability concerns receiving data in a structured, machine-readable format for transfer elsewhere, and the right to object allows individuals to oppose certain processing activities. None of those directly address the need to amend inaccurate or incomplete records, making rectification the correct choice.