Select Two (Multi-Select) Questions

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.

The hardware manufacturer.

Why it fails: Hardware manufacturers supply physical components to the cloud provider; they hold no compliance obligations in the shared responsibility model. It is tempting because hardware underpins cloud infrastructure, but the provider secures that layer itself, so manufacturers never carry customer or provider compliance duties.

The local internet service provider.

Why it fails: ISPs merely carry network traffic; they bear no responsibility for cloud compliance controls, which rest with the provider and customer. It is tempting because connectivity is essential to cloud access, but transport provision is unrelated to the security and compliance obligations allocated under the shared responsibility model.

The end-user of the application.

Why it fails: End-users consume the application; they hold no responsibility for compliance controls, which sit with the cloud provider and the customer organisation. It is tempting because users must follow acceptable-use policies, but policy adherence differs from maintaining compliance obligations under the shared responsibility model.

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.

Conducting annual security awareness training for all users

Why it fails: Security awareness training is a required control (AT-2) but is not a core continuous monitoring activity as defined in NIST SP 800-137. Continuous monitoring focuses on ongoing assessment of security control effectiveness and risk. While training supports overall security, it is not one of the primary activities like ongoing assessment or status reporting. It is typically assessed periodically, but not continuously.

Conducting a full Security Assessment Report (SAR) only at the end of the authorization cycle

Why it fails: A full SAR is typically produced during the initial assessment and authorization process. Continuous monitoring requires ongoing assessment and reporting, not just at the end of the cycle. Waiting until the end would defeat the purpose of continuous monitoring, which is to provide real-time or near-real-time awareness of security posture and enable timely risk response. The SAR is updated as needed, but not solely at the end.

Documenting the system's security categorization

Why it fails: Security categorization is a one-time activity performed during the RMF Initiate phase (Step 1). While it informs continuous monitoring, it is not an ongoing activity within the program itself. Continuous monitoring assumes categorization is already complete and focuses on maintaining awareness of the system's security state through assessments, monitoring, and reporting.

External stock prices

Why it fails: Stock prices are financial-market data unrelated to information security audit boundaries. Scope is defined by which systems, assets, processes and controls the audit covers. External share performance would matter to financial reporting or investor analysis, not to determining what an IS audit examines.

Competitor market analysis

Why it fails: Competitor market analysis concerns business strategy, not the systems, processes or controls an IS audit examines. Scope is set by the organisational and technical boundaries under review. Competitor data would be relevant to market positioning work, not to defining audit coverage.

Employee home addresses

Why it fails: Home addresses are personal data, not an audit scope determinant; scope derives from systems, processes and controls under review. It would be relevant to a privacy or HR data-handling assessment. Including it here confuses employee records with the boundaries of an information security audit.

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.

Storing all patch files on a public FTP site

Why it fails: A public FTP site exposes patch binaries to unauthenticated download and tampering, so integrity cannot be assured. Centralised, access-controlled repositories with checksum or signature verification are required. Public hosting would only be defensible for deliberately published, non-sensitive artefacts where authenticity is verified independently.

Manual approval for every single update

Why it fails: Requiring manual approval for every update does not scale and delays critical security fixes beyond acceptable exposure windows. Risk-based prioritisation with automated deployment for routine patches is required. Manual gating suits only a small estate of high-impact systems where each change demands formal review.

Disabling all automatic updates

Why it fails: Disabling automatic updates removes timely deployment of vendor fixes, leaving known vulnerabilities unpatched between manual cycles. An effective programme schedules and enforces update installation. Disabling automation is only reasonable for isolated systems where a validated patch could break a certified, change-controlled configuration.

Conducting a full reauthorization every six months

Why it fails: Full reauthorization every six months is not required. Continuous monitoring aims to avoid costly full reauthorizations by providing ongoing assurance. Reauthorization is typically triggered by significant changes or as determined by the AO, but not on a fixed six-month cycle. NIST SP 800-137 promotes ongoing authorization instead.

Documenting all security incidents in the System Security Plan (SSP)

Why it fails: Security incidents are documented in incident reports and the continuous monitoring dashboard, not in the SSP. The SSP is a static document describing controls. While it may be updated, incident documentation belongs in other records. NIST SP 800-137 does not require incident logging in the SSP as a core continuous monitoring activity.

Performing annual penetration testing on all systems

Why it fails: While penetration testing can be part of continuous monitoring, it is not an essential component for all systems. NIST SP 800-137 does not mandate annual penetration testing; it focuses on continuous assessment and monitoring. The frequency and type of testing should be risk-based, and not all systems require annual pen tests.

Use automated tools exclusively for all controls to eliminate human error and ensure consistency.

Why it fails: Automated tools are valuable for specific technical controls but cannot assess all controls, especially management and operational controls that require judgment or documentation review. An assessment that relies only on automated tools will miss important evidence and may produce incomplete results. A balanced approach combining automated and manual methods is necessary for a comprehensive assessment.

Rely solely on interviews with system administrators to verify technical controls because they are the most knowledgeable.

Why it fails: Interviews alone are insufficient for verifying technical controls. They provide context but do not independently confirm that a control is implemented correctly. A reliable assessment uses multiple methods such as examine, interview, and test. Over-reliance on interviews introduces bias and may miss configuration errors or operational gaps that only testing can reveal.

Conduct the assessment only after the system has been in operation for at least one year to gather sufficient operational data.

Why it fails: Waiting a year is not a requirement and may delay authorization unnecessarily. Assessments are typically conducted during the assessment phase before authorization and then periodically thereafter. The timing should align with the RMF phase and organizational policy, not an arbitrary one-year waiting period. Delaying assessment could leave the system operating with unaddressed risks.

The home address of the CISO.

Why it fails: A GRC policy states governance requirements such as scope, roles, and compliance obligations; a CISO's home address is personal data with no governance function. It tempts because identifying the accountable executive is legitimate, yet the policy names the role, never private contact details.

A list of all employees' social media handles.

Why it fails: Governance documentation specifies control ownership and compliance requirements, not employees' personal social media accounts, which are irrelevant and a privacy risk. It tempts because identifying personnel responsible for controls is valid, but that means role titles, not personal handles.

The exact color scheme of the company website.

Why it fails: GRC policies define control objectives, responsibilities, and enforcement mechanisms; website colour schemes carry no governance meaning. It tempts because brand and style standards are documented artefacts, but they belong in marketing guidelines, not in a governance policy.

Annual risk assessment

Why it fails: An annual risk assessment is a managerial control, relying on human judgement, process and governance rather than automated technical enforcement. It is tempting because it underpins security decisions, but assessments sit in the management category; technical controls are mechanisms such as encryption, firewalls or intrusion detection systems that enforce policy through technology.

Security policies

Why it fails: Security policies are administrative controls, expressed as documented rules and management direction rather than technical enforcement mechanisms. They are tempting because they govern security posture, but policy documents belong to the administrative category; technical controls are implemented in hardware or software, such as firewalls, antivirus or access control lists.

Fencing around the data center

Why it fails: Fencing is a physical security control, implemented through barriers and deterrence rather than technology processing access or data. It is tempting because fencing protects the data centre, but physical safeguards belong to the physical control category; technical controls are enforced by hardware or software, such as firewalls, encryption or access control lists.

Authentication.

Why it fails: Authentication establishes identity before access; FIPS 199 instead categorises potential impact against confidentiality, integrity and availability. It is tempting because authentication is a core security service and a common control selection, but the standard's impact evaluation is performed only against the C-I-A triad.

Accountability.

Why it fails: FIPS 199 evaluates confidentiality, integrity and availability; accountability is not one of those three objectives. It is tempting because accountability underpins audit and access governance, and it appears in broader control frameworks, but impact categorisation under FIPS 199 is performed solely against the C-I-A triad.

Non-repudiation.

Why it fails: FIPS 199 categorises impact against confidentiality, integrity and availability only; non-repudiation is not one of the three objectives. It is tempting because non-repudiation is a recognised security service in other models such as ISO 7498-2, but FIPS 199 impact analysis is confined to the C-I-A triad.

Publishing evidence to the company website

Why it fails: Publishing evidence publicly exposes it to alteration and destroys chain-of-custody control, so it cannot preserve integrity. It is tempting because publication supports transparency and disclosure, which is the correct aim when the requirement is stakeholder communication rather than evidential integrity.

Printing all evidence on paper

Why it fails: Paper printing neither prevents alteration nor proves authenticity; integrity depends on hashing, version control and chain of custody. It is tempting because physical copies feel tamper-resistant, and printing is genuinely correct when a signed, offline record is legally required.

Sharing sensitive server logs on a public forum

Why it fails: Publishing sensitive server logs to a public forum exposes credentials, internal hostnames and topology to anyone, breaching containment and evidentiary integrity. It is tempting because controlled log sharing with legal, forensic or vendor teams supports investigation, but that requires access-controlled, need-to-know distribution rather than public disclosure.

Disabling all security controls during an investigation

Why it fails: Removing all security controls mid-investigation leaves the environment unmonitored and undefended, allowing the attacker to persist or exfiltrate further while responders work. It is tempting when controls generate noise or block forensic tooling, but targeted, logged exceptions for specific artefacts preserve both evidence and protection.

The name of the software vendor

Why it fails: A risk acceptance memo records the specific risk, its assessed impact and likelihood, the accepting authority, the justification, and the review or expiry date; the vendor's name is procurement detail that documents no decision. It is tempting because vendor identity appears in related security documentation, and would be correct if the memo concerned supply-chain risk arising from that vendor.

The technical specifications of the server

Why it fails: Risk acceptance memos capture business-level risk statements, residual risk after existing controls, the accountable approver and the acceptance period; server technical specifications belong in architecture or configuration baselines. It is tempting because specifications evidence the controls in place, and would be correct if the memo were a technical control assessment rather than a formal acceptance of residual risk.

Host-based firewall

Why it fails: A host-based firewall is a technical control running on an endpoint, filtering traffic in software; it does not restrict physical access to premises or equipment. It is tempting because firewalls are foundational security controls, and it would be correct where the requirement is controlling network traffic to or from an individual host.

Strong password policy

Why it fails: A strong password policy is an administrative control governing user authentication behaviour, not a physical measure limiting access to facilities or hardware. It is tempting because password rules are a standard safeguard, and it would be correct where the requirement is enforcing credential strength and account authentication practices.

Encryption of database tables

Why it fails: Encryption of database tables is a logical/technical control protecting data at rest, not a physical barrier restricting site or hardware access. It is tempting because encryption is a core security safeguard, and it would be correct when the requirement is protecting stored data confidentiality against disclosure or theft of media.

Requiring every employee to rewrite each policy annually in their own words

Why it fails: Rewriting policies individually is inefficient and introduces inconsistency and error. Document maintenance should be centralized with designated owners and controlled changes. The scenario calls for current, authorized documentation, which is undermined by distributed rewriting. This activity would create multiple conflicting versions and make it impossible to maintain a single authoritative source for compliance purposes.

Publishing all documents to the public corporate website for transparency

Why it fails: Public disclosure is not required for internal compliance documentation and can expose sensitive control details. The goal is availability to the right audiences, not universal publication. Internal policies and standards often contain information that could aid attackers or reveal regulatory strategy. Publishing everything externally would conflict with the need for controlled access and could create legal or security risks.

Storing documents only in the personal drives of the GRC team members who wrote them

Why it fails: Personal drives lack centralized access control, versioning, and retention management. Storing documents there would make them unavailable to the broader organization and difficult to audit. The scenario requires documents to be available to the right audiences, which personal storage cannot support. This approach also risks loss of institutional knowledge when staff leave or change roles.

Reformatting the drive once

Why it fails: A single reformat leaves recoverable remnants, so it fails the sanitisation requirement for sensitive data; degaussing, cryptographic erase or physical destruction is needed. Reformatting is tempting because it clears the file table and appears to wipe the drive, and it would suffice for repurposing non-sensitive media.

Leaving the server powered on in the rack

Why it fails: Powering on preserves the data and keeps it accessible, so it fails decommissioning entirely. It is tempting because leaving hardware running supports temporary troubleshooting or a staged migration, and that would be acceptable if the server were being retained rather than retired.

Customer support agents

Why it fails: Customer support agents handle user enquiries and incidents, not the assessor, auditee or oversight functions a security assessment requires. They are tempting because they often surface security incidents, but that is operational escalation; the assessment roles sit with control owners, assessors and authorising officials.

External public relations firm

Why it fails: A public relations firm manages external communications and reputation, holding no assessment role such as assessor, auditee or oversight. It is tempting because stakeholder communication matters during audits, but that is a separate engagement; here the stem asks for the three roles performing the assessment itself.

Conduct a penetration test of the cloud provider's infrastructure to verify inherited controls.

Why it fails: Penetration testing the cloud provider's infrastructure is typically not permitted and may violate the provider's terms of service. Instead, the organization should rely on the provider's compliance reports and certifications. Penetration testing is not a standard method for verifying inherited controls.

Assume all controls are inherited because the cloud provider is responsible for security.

Why it fails: Assuming all controls are inherited is a common misconception. In cloud environments, security is a shared responsibility. The organization must still implement controls that are not covered by the provider. Blindly assuming inheritance leads to gaps and non-compliance.

Implement all controls from the baseline regardless of the provider's offerings.

Why it fails: Implementing all controls regardless of inheritance ignores the shared responsibility model and wastes resources. The organization should leverage inherited controls and focus on the remaining controls. This approach is inefficient and may lead to unnecessary duplication.