Hard Difficulty Questions

It guarantees the system will never be breached

Why it fails: No system is ever immune to breaches.

It eliminates the need for any internal security oversight

Why it fails: FedRAMP authorisation shifts baseline control assessment onto the CSP but leaves the organisation accountable for inherited-control verification, configuration, and its own usage of the service. It is tempting because authorisation removes duplicate auditing effort, which is the genuine benefit, yet oversight obligations under the shared responsibility model remain.

It allows the organization to bypass the RMF

Why it fails: FedRAMP authorisation is itself an output of the RMF process, so it cannot let an organisation bypass RMF; agencies must still authorise the system and document inherited controls. It is tempting because the CSP's package supplies much of the evidence, and it would apply when leveraging an existing authorisation to accelerate, not skip, the customer's own RMF steps.

Require the CSP to obtain a new FedRAMP authorization at the High impact level before proceeding.

Why it fails: While a High baseline may be necessary, requiring the CSP to reauthorize is not the immediate action. The CSP's authorization is independent; your system can inherit the Moderate controls and you can add controls via an overlay. The CSP may not offer High services, and waiting for reauthorization could delay the project unnecessarily.

Document the gap as a risk and accept it without additional controls, since the CSP is already authorized.

Why it fails: Accepting the risk without additional controls is inappropriate for a high-impact system with sensitive data. The CSP's Moderate authorization does not cover High impact requirements. You must implement additional controls or justify acceptance through a formal risk acceptance process, but that is not the first step; addressing the gap is.

Select a different CSP that already has a FedRAMP High authorization and migrate the system.

Why it fails: Migrating to another CSP is a drastic step and not the first action. It may be considered if the current CSP cannot meet requirements, but the overlay approach allows you to address gaps without migration. The question asks for the first action to address the gap, and an overlay is a more direct and less disruptive solution.

The boundary must include all cloud components regardless of the provider's authorization status to ensure end-to-end security.

Why it fails: Including all cloud components regardless of authorization status would duplicate efforts and potentially exceed the agency's authority. Cloud components managed by providers with existing authorizations should be leveraged through inheritance. The agency's responsibility is to ensure that the provider's controls meet its needs and to document the inheritance, not to reassess the provider's infrastructure.

The boundary should be defined based on the physical location of the servers to ensure data sovereignty requirements are met.

Why it fails: While data sovereignty may influence where data is stored, the authorization boundary is based on management control, not physical location. Defining the boundary by physical location could incorrectly include or exclude components that are under the agency's control or managed by a provider. The boundary should reflect the components for which the agency is responsible for security controls.

The PaaS provider's underlying infrastructure is included in the boundary because the agency's applications run on it.

Why it fails: The PaaS provider's underlying infrastructure is managed by the provider and is typically covered by the provider's own authorization, such as a FedRAMP package. The agency does not have direct control over that infrastructure, so it should not be included in the agency's boundary. Instead, the agency should inherit controls from the provider's authorization and document the dependency.

FedRAMP Authority to Operate (ATO) letter

Why it fails: The FedRAMP ATO letter indicates that the CSP has received an authorization, but it does not provide the granular control inheritance information. It is a high-level document that confirms the authorization status, not the specific responsibilities of the agency.

FedRAMP Security Assessment Report (SAR)

Why it fails: The FedRAMP SAR contains the assessment results for the CSP's system, but it does not clearly delineate which controls are inherited by the agency versus those the agency must assess. The SAR is a detailed technical report, but the customer responsibility matrix is the primary document for inheritance details.

FedRAMP Continuous Monitoring (ConMon) plan

Why it fails: The ConMon plan describes how the CSP will maintain ongoing monitoring, but it does not specify which controls the agency inherits or must assess. The CRM is the authoritative source for control inheritance and responsibility allocation between the CSP and the agency.

Re-assess the common control independently because the system's high-impact level requires a full assessment of all controls.

Why it fails: NIST SP 800-37 and SP 800-53A allow leveraging assessment results from common controls. Re-assessing independently duplicates effort and may not be necessary if the common control's assessment is current and applicable. The Assessor should evaluate the shared assessment report for sufficiency and relevance to the system's environment, not automatically repeat the assessment. This approach wastes resources and may delay authorization without adding value.

Perform a penetration test of the common control to validate the shared assessment report before accepting it.

Why it fails: Penetration testing is not a substitute for assessing a common control's implementation against NIST SP 800-53A. While testing can provide evidence, it does not cover all assessment objectives and may not be scoped to the control. The Assessor should rely on the shared assessment report if it is valid, rather than conducting an unplanned penetration test, which could be disruptive and unnecessary.

Exclude the common control from the system's assessment because it is outside the system's authorization boundary.

Why it fails: Common controls are within the system's boundary in the sense that they are relied upon for security. Excluding them would leave a gap in the assessment and misrepresent the system's security posture. The Assessor must ensure that the common control's assessment is valid and that the control is implemented correctly for the system. Excluding it would violate the requirement to assess all controls that are part of the system's authorization package.

Email all vendors every January to ask if they are ready.

Why it fails: Emails gather self-declared readiness, not evidence of due diligence, and cannot enforce the annual cadence or record assessment outcomes against Critical vendors. It is tempting because vendor communication is part of TPRM, but a questionnaire or automated assessment workflow tied to vendor risk tiering would be the correct configuration.

Hire a full-time employee to manage vendor emails.

Why it fails: A full-time employee managing vendor emails is a manual staffing measure, not a platform configuration enforcing annual due diligence. The requirement needs tier-based scheduling that automatically initiates reassessment for Critical vendors each year. Manual email handling is tempting because vendor communication is labour-intensive, but it cannot guarantee recurring, auditable review cycles.

Require vendors to login to the GRC platform daily.

Why it fails: Daily vendor logins impose an authentication frequency unrelated to due diligence scheduling. Annual reassessment of Critical vendors requires the GRC platform to trigger reviews based on vendor tier and elapsed time since the last assessment. Daily logins are tempting as a visibility measure, but they generate activity, not periodic risk evaluation.

A manual email notification from the risk owner to the CISO.

Why it fails: A manual email relies on human action, so the treatment workflow is not triggered automatically when a score exceeds appetite. It is tempting because notifying the CISO is a genuine governance step, and it would be correct where the requirement is escalation awareness rather than automated workflow initiation.

A change in the risk rating calculation formula.

Why it fails: Altering the scoring formula changes how risk values are calculated, not what happens once a score breaches the appetite threshold. It is tempting because appetite thresholds are often expressed in score terms, so tuning the formula feels related, and it would be correct if the requirement were to recalibrate risk ratings themselves.

A daily report showing all risks over the appetite.

Why it fails: A daily report only surfaces breaches after the fact; it initiates no treatment workflow at the moment the score exceeds appetite. It is tempting because reporting is a real risk-management control, and it would be correct where the requirement is monitoring and visibility rather than automatic workflow triggering.

Allowing all users to edit any data at any time.

Why it fails: Unrestricted editing destroys the audit trail and data integrity a System of Record depends on, since any user could silently alter or overwrite records. It is tempting because open collaboration suits shared working documents, but a System of Record requires role-based write restrictions and versioned, tamper-evident change logging instead.

Disabling the backup of the GRC database.

Why it fails: Disabling backups removes the ability to restore the system of record after corruption, deletion or ransomware, so integrity cannot be assured. It tempts as a way to cut storage cost or speed maintenance, and would suit a disposable test instance holding no authoritative data.

The boundary diagram will be rejected by the Authorizing Official for formatting errors.

Why it fails: While accuracy is important, the primary risk is not formatting but the security gap created by omitting a critical component. Authorizing Officials focus on whether all necessary controls are assessed, not on diagram aesthetics. The omission of the identity provider means a key security function is unaccounted for, which is a substantive issue.

The system will be automatically categorized as low-impact due to the missing component.

Why it fails: Security categorization is based on the potential impact of a loss of confidentiality, integrity, or availability, not on the completeness of the boundary diagram. Omitting a component does not change the categorization; it only creates a gap in the assessment. The system remains high-impact if the data and mission so dictate.

The external identity provider will be required to undergo a separate full authorization, delaying the project.

Why it fails: The identity provider may already have its own authorization or be treated as a common control provider. The risk is not necessarily a separate full authorization, but rather that its controls are not assessed or inherited. The omission could lead to a false sense of security and unassessed risks, which is more significant than a schedule delay.

Accept the risk because the CSP is responsible for the cryptographic module and the system owner has no control over it.

Why it fails: The system owner cannot simply accept risk based on CSP responsibility; the AO is the only one who can formally accept risk. The ISSO must document the finding and seek resolution. Assuming the CSP's responsibility absolves the system owner is incorrect under the shared responsibility model.

Immediately remove the system from the authorization boundary because the cryptographic module is non-compliant.

Why it fails: Removing the system from the boundary is a drastic step not warranted by a single control finding. The ISSO should first attempt to resolve the issue through the CSP and document it in the POA&M. The system may still operate with mitigating controls while remediation is pursued, depending on the AO's risk decision.

Escalate the finding directly to the Authorizing Official (AO) without taking any preliminary action.

Why it fails: While the AO may ultimately need to be informed, the ISSO should first gather facts, document the finding, and coordinate with the CSP. Escalating without preliminary analysis and documentation is premature and does not follow the standard RMF process for handling assessment findings.

Change the global password policy for GRC users.

Why it fails: Password policy governs authentication strength for GRC users and has no bearing on when or how control assessments are triggered. Tightening password rules is the right control when credential compromise or weak authentication is the identified risk.

Require the GRC admin to manually assign tasks to users.

Why it fails: Manual task assignment cannot trigger from control criticality, so the automatic CSA workflow never fires; a human must initiate every assessment. It is tempting because manual assignment suits ad hoc, judgement-heavy reviews where an administrator deliberately routes work. Here the stem demands criticality-driven automation, which only a rule or workflow condition evaluating that attribute can satisfy.

Disable the self-assessment feature to force all audits to be external.

Why it fails: Disabling self-assessment removes the very workflow the CSA requirement depends on, so no criticality-based trigger can fire. It is tempting when independence is the goal, since external audits avoid self-review bias; that suits mandated third-party attestation, not an automated, criticality-driven CSA process.

The system's latest vulnerability scan report.

Why it fails: A vulnerability scan enumerates software flaws on hosts, not communication paths between systems, so it cannot evidence interconnection inventory. It is tempting because scans do discover live hosts and open ports, and would suit validating exposure of known interconnections rather than identifying them.

The organization's enterprise risk register.

Why it fails: A risk register records identified risks and treatments, not the authoritative inventory of system interconnections required by the SAP. It is tempting because it catalogues organisational exposures, but interconnection inventory belongs in the system inventory and boundary documentation instead.

A listing of all installed software patches.

Why it fails: Patch listings evidence software maintenance status, not the interconnections between systems that the SAP inventory must demonstrate. It is tempting because patch data supports other assessment objectives, but it cannot show which systems connect to which external or internal counterparts.

Conduct a full independent assessment of all controls, ignoring the CSP's FedRAMP authorization to ensure completeness.

Why it fails: Ignoring the CSP's FedRAMP authorization would duplicate effort and increase costs unnecessarily. FedRAMP encourages leveraging existing authorizations to promote reuse and efficiency. A full independent assessment is not required when controls are inherited from an authorized CSP.

Rely entirely on the CSP's FedRAMP authorization and forego any additional assessment of the new system.

Why it fails: While the CSP's FedRAMP authorization can reduce the assessment burden, the organization must still assess controls that are not inherited from the CSP. The system may have additional controls or specific configurations that require assessment. Relying entirely on the CSP's authorization without assessing the remaining controls is not compliant with FedRAMP guidance.

Request the CSP to modify its FedRAMP authorization to include the new system's specific controls before proceeding.

Why it fails: The CSP's FedRAMP authorization covers its own service, not the customer's system. The customer cannot request the CSP to modify its authorization to include customer-specific controls. Instead, the customer must assess those controls themselves or implement compensating measures.

Mark the control as 'Implemented' and leave the field blank.

Why it fails: Recording 'Implemented' with a blank field misrepresents the control's status and leaves no audit trail. 'Not Applicable' demands a written justification explaining why the control falls outside the system boundary. Marking implemented suits controls that are genuinely in place and evidenced.

Request a waiver from the CISO.

Why it fails: A waiver is a formal risk-acceptance instrument for controls that cannot be met, not for controls genuinely outside the system boundary. Marking 'Not Applicable' requires documented justification in the SSP, not CISO sign-off. Waivers would be correct where a control applies but cannot be implemented.

Just delete the control from the system security plan (SSP).

Why it fails: Deleting the control removes it from the SSP entirely, destroying the tailoring audit trail and traceability to the baseline. The control must remain listed with a documented 'Not Applicable' justification. Deletion would suit controls never selected into the baseline during initial scoping.

Storing all exception requests in a shared spreadsheet that is accessible to the entire IT department.

Why it fails: A shared spreadsheet lacks access controls, audit trails, and workflow automation. It does not ensure that approvals are properly documented or that exceptions expire. It also exposes sensitive risk information to unauthorized personnel. This method is not auditable and does not support a systematic exception management process, making it unsuitable for GRC.

Allowing exceptions to remain active indefinitely as long as the requester provides a verbal justification.

Why it fails: Indefinite exceptions with only verbal justification lack documentation and review. They can lead to unmanaged risk, as the original justification may become invalid over time. This approach does not enforce regular review or expiration, and it fails to provide an audit trail. It undermines the purpose of exception management, which is to temporarily accept risk with oversight.

A requirement that all exception requests be approved by the Chief Information Security Officer (CISO) regardless of risk level.

Why it fails: Requiring CISO approval for all exceptions, regardless of risk, creates a bottleneck and is not scalable. It also violates the principle of delegated authority; lower-risk exceptions should be approved by appropriate risk owners. This approach can delay business operations and may not be necessary for effective risk management, as it ignores risk-based decision-making.

The cost of the hardware

Why it fails: Hardware cost has no bearing on which systems, people, and data flows fall inside the boundary. Cost accounting matters for budget approval, but the boundary follows data flow and operational control, so this fails to capture the external partner's shared processing.

The physical location of the server racks

Why it fails: Rack location describes physical siting, not logical authorisation scope. Data-centre placement matters for physical security and resilience planning, yet the boundary is defined by interconnected systems and data flows, so co-location or cloud hosting does not settle it.

The number of users accessing the system

Why it fails: User count does not determine which components process or store the shared data. Licensing and capacity planning use user numbers, but the boundary is drawn from data flows and system interconnections, so a partner sharing data remains outside this reasoning.

On a local USB drive

Why it fails: A local USB drive is not a secure escrow location; it can be lost, stolen or left attached to the machine, defeating recovery-key confidentiality. It is tempting because removable media are convenient for offline recovery, and would be correct only as a temporary export when the key is also escrowed in Microsoft Entra ID or Active Directory.

Printed on the side of the PC

Why it fails: Printing the recovery key on the PC casing exposes it to anyone with physical access, defeating the purpose of BitLocker. It is tempting because a printed copy survives disk failure and needs no infrastructure, and would be correct only as a sealed offline record stored separately from the encrypted device.

In a text file on the desktop

Why it fails: A plaintext file on the desktop is readable by anyone who boots or logs into the machine, so it cannot protect the recovery key. It is tempting because it is quick and requires no directory infrastructure, and would be correct only if the file were encrypted and stored off-device.

Documenting the continuous monitoring strategy in the system security plan and obtaining approval from the authorizing official.

Why it fails: Documenting the strategy is necessary but does not demonstrate that monitoring is actually occurring. The authorizing official needs evidence of operational monitoring, not just plans. Approval of the strategy is a one-time action. Effective ongoing authorization requires continuous data feeds and analysis, which this option does not provide.

Conducting an annual security control assessment and providing the results to the authorizing official.

Why it fails: An annual assessment is a point-in-time activity and does not demonstrate continuous visibility. Ongoing authorization relies on near real-time monitoring data to inform risk decisions. While annual assessments are required, they alone do not show that the program is continuously monitoring controls. The authorizing official needs more frequent and automated data to maintain ongoing authorization.

Submitting a quarterly report that summarizes all security incidents and their resolutions.

Why it fails: Quarterly incident reports are reactive and do not provide continuous visibility into control effectiveness. They are useful for trend analysis but do not demonstrate real-time monitoring. Ongoing authorization requires proactive, continuous data to detect and respond to changes in risk. Incident reports alone are insufficient to show that the program is effectively supporting ongoing authorization.

Total number of security awareness training completions in the last quarter.

Why it fails: Training completions are an output metric but not necessarily predictive of breach risk. High completion rates do not guarantee reduced risk if the training is ineffective or if other vulnerabilities exist. It is more of a compliance metric than a leading risk indicator, and it does not directly measure exposure to patient data breaches.

Number of past data breach incidents involving patient records.

Why it fails: This is a lagging indicator because it measures incidents that have already occurred. While useful for trend analysis, it does not provide early warning of future breaches. The CISO specifically requested predictive KRIs, so historical incident counts are not suitable for proactive risk management.

Average time to detect a security incident after it occurs.

Why it fails: This is a lagging indicator as it measures performance after an incident has happened. While important for response effectiveness, it does not predict future breaches. The CISO wants predictive metrics, so detection time is not appropriate for this purpose.

Mark the control as 'Not Applicable' because the encryption is not required for this system.

Why it fails: The control is applicable because the system uses encryption. Marking it as Not Applicable is incorrect. The encryption must meet the requirement, or an exception must be granted. Misclassifying the control would undermine the integrity of the assessment and could lead to unauthorized operation with non-compliant controls.

Immediately disconnect the system from the network until the encryption is replaced.

Why it fails: Immediate disconnection is an extreme measure that may not be warranted if the risk is low or the system is isolated. The standard process is to document the finding and plan remediation. The AO may impose restrictions, but the ISSO should not unilaterally disconnect the system. This action could disrupt critical operations.

Accept the encryption as an equivalent control and document the rationale in the SSP.

Why it fails: NIST SP 800-53 requires the use of FIPS 140-2 validated cryptography for federal systems. While equivalent controls can be proposed, they must be approved through a formal waiver process. Simply documenting the rationale in the SSP is insufficient. The system owner must either replace the encryption with validated modules or seek an approved exception from the AO.