System Compliance practice questions

Authorizing Official

Why it fails: The Authorizing Official accepts residual risk and grants the ATO; continuous monitoring is performed by the Information System Security Officer or equivalent, who reports status upward. The AO is tempting because they own the authority to suspend or revoke an ATO, but that oversight role differs from executing the monitoring tasks themselves.

Chief Information Security Officer (CISO)

Why it fails: The CISO sets organisation-wide security policy and risk appetite rather than performing system-level continuous monitoring of individual controls. The CISO is tempting because they own the security programme and receive monitoring reports, but the hands-on task of tracking control status belongs to the system's security officer.

Security Control Assessor (SCA)

Why it fails: The Security Control Assessor conducts the independent assessment producing the evidence base for an authorisation decision; ongoing monitoring is an operational duty, not an assessment function. The SCA is tempting because assessors do evaluate control effectiveness, but that occurs during assessment cycles rather than as continuous post-authorisation monitoring.

System Security Plan (SSP)

Why it fails: The SSP is a baseline, but the other two are critical for the *decision*.

Hardware inventory list

Why it fails: Not essential for the decision.

Network diagram

Why it fails: Supporting document only.

Force an upgrade to the application

Why it fails: Forcing an upgrade exceeds the compliance determination remit, which is to assess and document existing controls, not remediate them. The enclave's physical isolation may already compensate for missing MFA, so the SAR should record the finding and residual risk. Upgrade would be right during remediation planning, after authorisation decisions.

Immediately revoke the Authorization to Operate (ATO)

Why it fails: An ATO is revoked only when risk is unacceptable; a documented compensating control such as physical isolation can justify continued authorisation with a caveat. The SAR records the finding, residual risk and compensating controls, leaving the authorising official to decide on revocation.

Mark the control as 'Not Applicable'

Why it fails: Marking the control Not Applicable is wrong because the MFA requirement applies; the enclave provides a compensating control, not an exemption. The SAR should document the finding and the physical isolation as compensating. It tempts because isolation reduces risk, but Not Applicable is correct only when a control genuinely does not apply.

Drafting the mitigation tasks

Why it fails: Drafting mitigation tasks belongs to the system owner and information system security officer, who build the POA&M content. It is tempting because the AO reviews and may direct priorities, but the AO's responsibility is adjudicating risk and authorising operation, not authoring remediation entries.

Conducting the security controls assessment

Why it fails: Assessors, not the AO, conduct security control assessments and produce the findings the POA&M records. It is tempting because the AO must understand residual risk, yet that understanding derives from the assessment report; the AO's role is authorisation decisions and accepting or rejecting risk.

Implementing the technical patches

Why it fails: System owners and administrators implement patches; the AO holds authorisation authority and does not perform remediation. It is tempting because the AO tracks whether weaknesses are resolved, but tracking milestone completion differs from executing the technical change itself, which stays with operational staff.

The system is unauthorized for production use

Why it fails: A conditional ATO authorises production use subject to stated conditions; it is not an unauthorised status. Treating it as unauthorised is tempting because conditions imply outstanding risk, but the Authorizing Official has accepted that risk, so the system may operate while the conditions are satisfied.

The system is prohibited from processing sensitive data

Why it fails: An ATO with Conditions permits operation while specific remediation or reporting conditions are met; it does not bar sensitive data processing. Prohibition of sensitive data is tempting because conditions can restrict scope, but that outcome reflects a denial or interim authority, not a conditional authorisation to operate.

The system is permanently compliant

Why it fails: An ATO with conditions authorises operation only while specific remediation actions, milestones or constraints are met, with ongoing monitoring and possible revocation. It is not permanent compliance. The option is tempting because the system is authorised to operate, but that authorisation is time-bound and conditional, unlike a full ATO.

During the 'Categorize' step

Why it fails: The SAR documents assessment results produced during the Assess step, so it cannot exist at Categorize, where only the system's impact level is determined. Categorisation is tempting because it shapes later control selection, but it generates no findings for an Authorizing Official to review.

After the 'Monitor' step

Why it fails: Monitoring follows authorisation, so presenting the SAR afterwards inverts the RMF sequence; the Authorizing Official needs it during the Authorize step to make the ATO decision. Continuous monitoring is tempting because it also produces assessment data, but that output feeds ongoing authorisation, not the initial ATO.

During the 'Prepare' step

Why it fails: Prepare establishes the authorisation boundary, roles and assessment plan, so no assessment evidence exists yet to compile into a SAR. It is tempting because preparation does define what will be assessed, but the SAR requires completed Assess-step findings presented during Authorize.

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.

Accept the findings as-is

Why it fails: Accepting the findings leaves the technical control unverified, since an interview cannot exercise the automated mechanism the control requires; evidence must come from tool output. Acceptance applies when assessment methods match control type and evidence is sufficient.

Escalate to the Chief Information Officer (CIO)

Why it fails: This is a technical deficiency in the assessment process, not an executive issue yet.

Update the System Security Plan (SSP) to match the interview

Why it fails: Interview evidence cannot substitute for the automated testing a technical control demands; the assessment method must match the control. Amending the SSP to mirror a deficient method conceals the gap. The correct response is to require reassessment using the appropriate automated method.

Security control baselines

Why it fails: The SAP scopes assessment procedures to the controls selected for the system, so the control baseline must be identified before coverage can be determined; without it there is nothing to assess. It is tempting because baselines underpin the whole RMF process, but they are an input to scoping, not the first SAP component.

Contingency plan testing

Why it fails: Contingency plan testing is a single control within CP family, not a scoping component of the SAP. It is tempting because testing is part of assessment activity, but identifying it first would leave the SAP without the control baseline and assessment methods needed to determine adequate coverage.

Risk acceptance threshold

Why it fails: Risk acceptance thresholds govern authorisation decisions after assessment results are known, so they cannot define assessment coverage. It is tempting because risk tolerance shapes the overall RMF, but the SAP must first identify the applicable controls and their assessment methods, not the organisation's acceptance criteria.

The service level agreement (SLA)

Why it fails: An SLA defines availability and service commitments, not control implementation evidence; it cannot demonstrate how encryption, access control or monitoring actually operate. It is tempting because it is the contract accompanying every cloud service, and would be the right artefact for measuring uptime credits or support response targets.

The organization's internal risk register

Why it fails: An internal risk register catalogues the organisation's own identified risks, treatments and owners; it holds no evidence of a provider's implemented controls. It is tempting because it is a governance artefact, but it is the right choice for tracking your own risk posture, not for evidencing a cloud provider's security.

The network topology map

Why it fails: A network topology map depicts connectivity and device placement, not the operational effectiveness of security controls. It is tempting because it documents infrastructure, but it is the correct artefact for tracing data flows or segmentation, whereas compliance evidence requires an independent audit report of the provider's controls.

To request funding for security improvements

Why it fails: Funding requests belong in budget or business-case documentation; the SAR presents assessor findings against security controls. It is tempting because findings often imply remediation costs, but requesting funding is the correct choice only when the deliverable is a budget submission rather than an assessment report.

To authorize the system for production

Why it fails: The SAR documents assessment findings, control effectiveness and residual risk; authorisation to operate is granted separately by the authorising official via the authorisation decision. It is tempting because the SAR feeds that decision, but the report itself never confers production approval.

To list all authorized users

Why it fails: The SAR reports control assessment results and residual risk; user authorisation records sit in access-control or account-management documentation. It is tempting because assessment scopes often touch identity controls, but listing authorised users is the correct choice only when the requirement is an access roster, not an assessment report.

System Security Plan

Why it fails: The System Security Plan describes the system boundary, controls and responsibilities; it supports authorisation but confers none. It tempts because it accompanies the authorisation package, yet the formal authority to operate is the signed Authority to Operate.

Risk Assessment Report

Why it fails: A Risk Assessment Report documents identified threats, vulnerabilities and impact; it does not grant permission to run a system. It tempts because risk informs authorisation decisions, but the formal authority to operate is the Authority to Operate issued after assessment.

Security Control Assessment

Why it fails: A Security Control Assessment tests whether controls are implemented correctly and produce evidence of effectiveness; it does not grant permission to run a system. It is tempting because assessments often precede authorisation, and it would be the right artefact when the requirement is to verify control implementation before an authorising official signs the authority to operate.

The POA&M contains vulnerabilities found by automated scans

Why it fails: Including automated scan findings is normal and expected; scans are a primary vulnerability source feeding POA&Ms. It is tempting because raw scan output can be noisy, but an ineffective process is shown by items lacking milestones, owners, or closure evidence, not by the detection method.

The POA&M is stored in a secure repository

Why it fails: Secure storage protects POA&M confidentiality and integrity, which supports an effective process. It is tempting because access restrictions could hinder remediation tracking, but ineffectiveness is evidenced by unreviewed, unassigned, or overdue items, not by where the document is kept.

The POA&M is reviewed by the CISO

Why it fails: CISO review is a governance strength, not a weakness; it demonstrates oversight and accountability. It is tempting because executive involvement can sometimes mask operational gaps, but POA&M ineffectiveness shows as missed milestones, stale items, or absent remediation evidence, none of which this indicates.

The estimated cost of an upgrade

Why it fails: Upgrade cost is a budget consideration, not the technical exposure the authorising official must weigh when accepting an unpatched critical flaw. It tempts because remediation funding often drives decisions, but the AO needs the likelihood and business impact of exploitation to judge whether acceptance is justified.

The manufacturer's release notes

Why it fails: Release notes describe vendor fixes and known issues, not the residual risk this system carries if the flaw stays unpatched. They tempt because patch documentation feels relevant, but the AO requires the assessed likelihood and impact of exploitation, plus compensating controls, to accept risk.

The CVSS score of the vulnerability

Why it fails: A CVSS score quantifies severity but gives the Authorising Official no basis to judge organisational impact or residual risk after compensating controls, which is what acceptance requires. It is tempting because CVSS is the standard severity metric and belongs in vulnerability tracking, yet it describes the flaw, not the business consequence of accepting it.

The ATO is suspended until the next fiscal year

Why it fails: Suspension tied to the fiscal year misstates the trigger: a major change requires reauthorisation before the system continues operating, regardless of budget cycles. Fiscal-year suspension is tempting because ATOs often carry expiry dates, but the governing factor is the change, not the accounting period.

The ATO remains valid until the expiration date

Why it fails: A major change alters the system's security posture, so the existing ATO cannot remain valid until its expiration date; reauthorisation is triggered by the change itself, not the calendar. Retaining validity is tempting because ATOs normally persist for a fixed period, which holds only when no significant change occurs.

The ATO is automatically extended

Why it fails: An ATO extension requires formal approval.

A waiver request to the CISO

Why it fails: A waiver request implies the control applies but is being excepted, whereas NA means the control is not applicable at all; these are distinct determinations. It is tempting because both involve the CISO, but NA requires documented justification in the SSP rather than an exception approval.

A copy of the vendor's warranty

Why it fails: A vendor warranty addresses product defects and support terms, not the justification for excluding a control from the SSP. It is tempting because procurement artefacts accompany systems, but NA determinations require documented rationale explaining why the control does not apply to the system's environment.

The procurement contract

Why it fails: A procurement contract governs commercial obligations between parties and says nothing about why a security control is inapplicable. It is tempting because contracts are readily available system documentation, yet the SSP requires a written justification establishing that the control genuinely does not apply.

The SSP is a summary of the SAR

Why it fails: The SSP documents the implemented controls and describes the system boundary; the SAR records the assessor's findings against those controls, so the SSP is not derived from the SAR. It is tempting because both cover the same control set, and a summary document would be the right artefact when consolidating assessment results for authorising officials.

They are independent documents with no relationship

Why it fails: The SAR assesses the controls documented in the SSP, so the two are directly linked rather than independent. It is tempting because they are separate deliverables with different authors and purposes, and treating documents as independent would be correct when no shared control baseline or assessment scope exists between them.

The SAR provides the controls to be documented in the SSP

Why it fails: The SSP defines the controls first; the SAR then reports assessment results against them, so the direction is reversed. It is tempting because the SAR does feed findings back into SSP updates, and deriving controls from assessment output would be right if the SSP were being rebuilt from an existing assessment baseline.

Grant them access to your internal ATO database

Why it fails: Granting a contractor access to your internal ATO database hands an external party your authorisation artefacts and potentially sensitive system data, expanding risk rather than evidencing compliance. Shared repositories suit internal teams collaborating on a joint authorisation package, not external assurance of a supplier.

Perform an audit of the contractor's office

Why it fails: A physical site visit inspects facilities, not the system's security posture, so it cannot evidence control effectiveness. On-site review is the right approach for verifying physical and environmental safeguards; compliance of a hosted contractor system requires evidence of its technical and administrative controls instead.

Trust the contractor's internal IT department

Why it fails: Internal IT assurance gives no independent evidence against your agreed control baseline, and the contractor's interests differ from yours. Self-attestation suits low-risk suppliers under a light-touch monitoring regime; here you need verification you can rely on, such as an independent assessment or your own review.

To implement the security controls

Why it fails: Implementing controls belongs to the system owner and control implementers; the assessor independently examines and tests those controls, then reports findings. Implementation is tempting because assessors often work alongside engineering teams, and it would be correct for a role actually building or configuring the safeguards.

To remediate vulnerabilities

Why it fails: Remediating vulnerabilities is the system owner's and implementers' responsibility; the assessor verifies controls and reports weaknesses without fixing them, preserving independence. Remediation is tempting because assessors identify flaws, and it would be correct for the engineering team tasked with correcting those findings.

To accept the risk on behalf of the agency

Why it fails: Risk acceptance is an authorising official's decision, not the assessor's; the assessor supplies evidence and findings so that authority can judge. Acceptance is tempting because assessment informs authorisation, and it would be correct for the authorising official who owns the system's residual risk.

Authorize

Why it fails: Authorize is the RMF phase that renders an accreditation decision from the assessment results; ongoing control monitoring sits in the Monitor phase. It is tempting because authorisation grants the authority to operate, which practitioners associate with the point where live monitoring begins.

Select

Why it fails: Select chooses and tailors the baseline controls and documents them in the system security plan; it precedes implementation and assessment, so no monitoring occurs there. It is tempting because selecting controls determines what will later be monitored.

Categorize

Why it fails: Categorize determines the system's impact level under FIPS 199, which drives baseline selection; it is an early RMF step with no monitoring activity. It is tempting because the assigned category shapes how rigorously controls are later assessed and watched.