ISC2 Governance, Risk and Compliance (CGRC) Practice Test

FISMA extends an agency's information-security responsibilities to any information system that is "used or operated by a contractor of an agency or other organization on behalf of an agency". The agency head must therefore ensure that the contractor's system receives security protections commensurate with the risk and comparable to those applied to government-operated systems. Merely publishing notices, shifting liability through contracts, or seeking external approval are not mandated by the statute. FISMA keeps accountability within the agency and requires equivalent protections, not procedural formalities that delegate or transfer responsibility.

NIST RMF expects organizations to begin with an appropriate baseline and then tailor it to fit the system's specific mission, business, and operational context. Tailoring includes scoping out controls that are not applicable, adjusting control parameters, or substituting compensating controls that achieve the same objectives with less impact. These decisions and their justifications must be documented in the system security plan so that assessors and authorizing officials understand how risk is being managed. Simply applying all controls without evaluating relevance ignores the governance principle of aligning security with business objectives. Deferring the decision to a later RMF step or waiting for a waiver after deployment fails to follow the structured risk management process and can lead to unmanaged risk or project delays.

Both the NIST Risk Management Framework and the FedRAMP Security Assessment Framework require an independent evaluation of implemented safeguards before any authorization decision is made. Once controls are put in place, an assessor examines evidence and performs testing to confirm that the controls are correctly implemented, operating as intended, and meeting the desired security outcomes. Only after this assessment is complete can the package move to the Authorizing Official for an authorization decision, and continuous monitoring will follow authorization. Revisiting control selection is not normally required unless significant changes or analysis results dictate it.

The design phase focuses on translating security requirements into an overall architecture. Creating detailed security architecture diagrams that map trust boundaries, expected data flows, and the controls that must be built into each component is a design-phase task. Code-level static analysis, penetration testing, and formal authorization decisions occur in the development, test, and deployment/operations stages, respectively, after the design has been completed and implemented.

Non-repudiation requires technical evidence that definitively binds a specific individual to a specific action and protects that evidence from undetected alteration. A digital signature created with the executive's private key meets this requirement because:

• The private key is uniquely associated with the signer, so the origin of the message can be proven.
• The cryptographic hash included in the signature detects any later modification of the signed content.
• Anyone with the signer's public certificate can verify both origin and integrity, making it difficult for the signer to credibly deny the action.

TLS encryption only protects data in transit; once the session ends it provides no enduring proof of origin. Web-server logs that record IP addresses can be forged, shared, or spoofed and therefore do not offer strong assurance. Multi-factor authentication confirms the user's identity when logging in but does not bind that identity to the specific purchase-order message in a verifiable way after the fact.

During the Development (coding) phase, the emphasis is on writing secure code and detecting vulnerabilities as early as possible. Static Application Security Testing (SAST) examines source code or byte-code without running it, allowing security flaws such as injection, insecure API use, or buffer overflows to be found and corrected while the code is still being written. Activities such as post-implementation log reviews occur in the operations phase, retirement planning belongs to the disposal phase, and obtaining an Authorization to Operate is part of the authorization step that follows assessment. Therefore, running SAST (or comparable static code analysis) is the most appropriate security activity to integrate in the development phase.

NIST RMF tasks require that the authorization boundary begin with basic system identification: the system's official name or unique identifier together with a concise statement of its mission, purpose, and scope. This high-level description comes before listing hardware, software, information types, data flows, assessments, or training needs, and anchors all subsequent scoping and categorization work.

During the disposal/decommissioning phase, the organization must ensure that any media containing federal information is properly sanitized, purged, or destroyed in accordance with NIST SP 800-88 guidelines. NIST SP 800-37 Rev. 2 identifies media sanitization as a mandatory disposal task that must be completed before the Authorizing Official can formally terminate the system's authorization to operate. Simply transferring risk, reallocating budgets, or removing the system from the FISMA inventory can occur only after the assurance has been obtained that no sensitive data remains accessible. Therefore, validating that all information system media have been sanitized or destroyed is the correct and most critical step.

NIST SP 800-88 identifies three sanitization levels: Clear, Purge, and Destroy. For SSD-based media, cryptographic erase-destroying the media's encryption key so that remaining ciphertext is indecipherable-is specifically listed as a Purge method. It removes data to the same assurance level as physical block erasure but preserves the drive for future use. A single overwrite pass is only a Clear operation and is unreliable on SSDs because wear-leveling may leave residual data. Mechanical shredding renders the drive unrecoverable, meeting the Destroy level, but does not permit reuse. Degaussing is ineffective on flash technology because SSDs do not store data magnetically and therefore cannot be sanitized by a magnetic field. Consequently, invoking the drive's built-in cryptographic erase function is the best choice.

The described committee is carrying out governance. Governance establishes direction and oversight, aligns information-security efforts with business objectives, and holds leaders accountable for outcomes. By reviewing metrics against strategic goals and directing corrective actions, the committee exercises that oversight function. Risk management would focus on identifying and treating specific risks, compliance would emphasize adherence to external requirements, and incident response coordination concerns reacting to security events-none of which are the primary purpose of this meeting.

A geographically distributed, load-balanced failover cluster directly addresses availability because it provides redundant capacity and automatic traffic distribution; if one site or node fails, service continues with minimal interruption, supporting the 99.95 percent uptime objective. The other options primarily protect different security objectives: input sanitization safeguards data integrity, client-side certificate authentication strengthens confidentiality (and to some extent integrity), and HMAC-based digital signatures provide non-repudiation and integrity assurance for logs, but none of these measures keeps the service accessible when hardware or site outages occur.

When different jurisdictions impose conflicting retention requirements, the organization must satisfy the most stringent (longest) mandate so that it does not violate any applicable law or regulation. Selecting the shorter three-year period would breach the seven-year mandate, while averaging or retaining data indefinitely would either still break the stricter law or conflict with storage-limitation principles that require data not be kept longer than necessary.

Under the HIPAA Security Rule, the security standards are grouped into three safeguard categories: administrative (§164.308), physical (§164.310), and technical (§164.312). Conducting a risk analysis (§164.308(a)(1)(ii)(A)) and designating a security official (§164.308(a)(2)) are both listed within the Administrative Safeguards section. Physical safeguards address facility and device protections, while technical safeguards focus on electronic measures such as access control and encryption. Separate from these safeguards, §164.314 establishes organizational requirements (for example, business associate contracts). Because both cited requirements appear in §164.308, they are Administrative Safeguards.

During Step 4 (Implement) of the NIST Risk Management Framework, the system owner not only puts the selected controls in place but also documents how each control was implemented and integrated within the system and its operating environment. This information is recorded in the System Security Plan (SSP) so that assessors can evaluate the controls against documented evidence. Creating a POA&M, requesting an authorization decision, or finalizing a continuous monitoring strategy occur in later RMF steps (Assess, Authorize, and Monitor, respectively), not during implementation.

The priority is to stop the unauthorized cross-border transfer immediately and launch a formal investigation and risk assessment. Halting the flow contains any further potential exposure and allows the organization to determine legality, security impact, and necessary notifications. Once the incident is contained and assessed, the data-flow diagram, GDPR Article 30 records, and other documentation can be updated, and additional controls (such as tokenization) or remediation (such as purging data) can be planned. Not every undocumented international transfer is automatically a notifiable breach, so notifications should follow the investigation if required.

Encrypting the communications channel with a current version of Transport Layer Security protects the salary information from disclosure to unauthorized parties as it traverses untrusted networks, directly addressing confidentiality. Multi-factor authentication strengthens user identity proofing but does not prevent interception of the data stream itself. File integrity monitoring verifies that stored data has not been altered, serving integrity rather than confidentiality. Redundant network links improve availability but leave the information readable if captured in transit.

The General Data Protection Regulation (GDPR) sets a strict 72-hour deadline for data controllers to report personal data breaches to the relevant supervisory authority (Art. 33 (1)), unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. HIPAA allows up to 60 days to notify affected individuals, FISMA/OMB guidance generally requires federal agencies to report certain incidents to US-CERT within one hour, and PCI-DSS does not define a universal regulatory timeline-making GDPR the only framework in the list that mandates a 72-hour authority notification.

The Authorizing Official is a senior management role that has the statutory authority to assume responsibility for operating an information system at an acceptable level of risk. After reviewing the Security Assessment Report and other authorization package artifacts, the Authorizing Official issues the formal Authorization to Operate (ATO). The System Owner is responsible for the system throughout its life-cycle but cannot grant authorization. The Information System Security Officer supports security operations and reporting but does not make risk acceptance decisions. The Security Control Assessor conducts the assessment and provides findings but likewise lacks the authority to authorize operation.

During the Prepare step, organizations establish the foundational activities that will streamline later RMF tasks. One of those activities is identifying common controls and their providers so the system owner can inherit them instead of duplicating effort. Categorizing the system is performed in the separate Categorize step, tailoring baselines happens in the Select step, and executing the security assessment plan occurs in the Assess step. Therefore, documenting shared control providers during Prepare is the correct choice.

During the requirements-gathering (requirements analysis) phase, the project team must determine and document the system's security and privacy requirements that stem from business objectives, data sensitivity, and applicable laws or regulations. Capturing these requirements early allows security controls to be designed into the system from the outset, guiding architecture, development, and later testing activities. Configuring servers, performing penetration tests, or deploying production monitoring are important security tasks but occur in later SDLC phases-implementation, testing, and operations, respectively-after requirements have been set.