Compliance Maintenance practice questions

Move the system to a secure storage area for indefinite holding.

Why it fails: Indefinite holding is not a decommissioning step; disposal is required.

Reformat the drive for reuse in a non-sensitive project.

Why it fails: Classified media cannot be reused in lower-sensitivity environments.

Conduct a full security control assessment of all system controls immediately.

Why it fails: A full SCA is a point-in-time assessment, not a continuous monitoring activity. While it may be part of the overall process, the question asks for monitoring strategy actions. Continuous monitoring relies on automated and ongoing assessments. A full SCA would be resource-intensive and not sustainable for continuous monitoring, and it is not specifically required by SP 800-137 for strategy updates.

Schedule penetration testing of the external interface on an annual basis.

Why it fails: Penetration testing is a valuable assessment technique but is typically event-driven or periodic, not a core continuous monitoring component. SP 800-137 focuses on automated, near-real-time monitoring of controls. Annual penetration testing alone would not provide the continuous visibility needed. It can complement monitoring but is not a critical action to include in the strategy update.

Update the system security plan to document the new interface and its security controls.

Why it fails: While updating the SSP is necessary for documentation, it is not a monitoring action per se. The continuous monitoring strategy focuses on ongoing assessment and metrics. The SSP update supports compliance but does not directly ensure that monitoring activities are in place. The question asks for actions critical to the monitoring strategy, so this is less critical than defining metrics and establishing reporting.

System security plan (SSP).

Why it fails: The SSP is a fundamental document that describes the system and its controls, but it is not the most critical artifact for assessing the continuous monitoring program itself. The SSP provides context, but the SAR and POA&M directly reflect the monitoring results and remediation efforts. The SSP is updated as part of continuous monitoring, but the assessment focuses on the outputs of monitoring.

Business continuity plan (BCP).

Why it fails: While the BCP is important for overall resilience, it is not a primary artifact for assessing continuous monitoring compliance. The focus of the annual assessment is on the ongoing monitoring of security controls, not on continuity planning. The BCP may be referenced for contingency controls, but it is not as critical as the SAR and POA&M for this specific review.

Incident response plan (IRP).

Why it fails: The IRP is essential for handling incidents, but it is not a primary artifact for reviewing continuous monitoring compliance. Continuous monitoring focuses on the ongoing assessment of controls, while the IRP addresses incident handling. The IRP may be part of the overall security program, but it is not the most critical for this specific annual review.

The Nessus scanner plugin needs an update to recognize the patch.

Why it fails: A stale plugin can only misreport a patch it cannot detect, yet Tenable.io already flags the vulnerabilities as open, so detection is working. Plugin updates address genuinely new CVEs or unrecognised patch signatures. The real cause is that the CMDB records deployment, not remediation verification, so patched status never reconciles with scan evidence.

The scan policy is set to 'Discovery' instead of 'Audit'.

Why it fails: A Discovery scan enumerates hosts and services without performing credentialed vulnerability checks, so it cannot report patch status at all — yet the stem shows vulnerabilities being detected and tracked as open. Discovery is the right choice for asset inventory when you need to map what exists on the network before enabling authenticated auditing.

The scan agent was decommissioned prematurely.

Why it fails: A decommissioned agent stops reporting, so Tenable.io would show stale or missing data rather than a patched-but-open mismatch. The tempting logic is that agent loss explains any discrepancy. Agents are the right mechanism when hosts cannot be reached by credentialed network scans, but here the CMDB patch record and scan result both exist and conflict.

Immediately decommission the system.

Why it fails: Decommissioning is a drastic response that discards the system without assessing whether the software update actually introduced unacceptable risk. Decommissioning is tempting as a way to eliminate exposure, but it is reserved for systems whose risk cannot be remediated or accepted, not routine continuous monitoring of changes.

Update the System Security Plan (SSP) and submit for re-certification.

Why it fails: NIST SP 800-37 R2 continuous monitoring expects the change to be assessed and its security impact analysed first, not an immediate re-certification submission. Updating the SSP is tempting because it is a required artefact, but it follows the impact assessment rather than initiating the response to a significant change.

Wait until the annual assessment cycle to review the change.

Why it fails: Deferring to the annual assessment ignores the requirement to evaluate significant changes when they occur, leaving the authorisation decision based on stale information. Annual cycles are tempting because they are scheduled and predictable, but continuous monitoring exists precisely to handle changes between those reviews.

Application Catalog.

Why it fails: Application Catalog publishes user-facing applications and packages for self-service installation; it holds no mechanism for reading registry key values on workstations. It is tempting as a central MECM console view, but it would be the right choice when offering optional software to users, not for verifying configuration state.

Client Health Reports.

Why it fails: Client Health Reports surface agent status, heartbeat and remediation data, not the values of specified registry keys. It is tempting because it reports on every workstation's state, but it fits diagnosing client agent problems, whereas compliance verification of registry settings requires configuration item baselines with desired-value rules.

Software Metering.

Why it fails: Software Metering records executable usage counts and durations to inform licence reconciliation; it never reads registry key values. It is tempting because it collects data from all workstations, but it would be the correct choice for tracking application usage, not for verifying whether specific registry keys are set correctly.

Update the asset inventory list.

Why it fails: Updating the asset inventory records the disposal for accountability but does nothing to the sensitive data still residing on the drive. Inventory updates belong to asset lifecycle tracking, and would be correct alongside sanitisation, not as the step that prevents disclosure from released hardware.

Remove the BIOS password.

Why it fails: Removing the BIOS password merely clears a firmware access control; the storage media still holds recoverable sensitive data. Clearing BIOS credentials suits repurposing or troubleshooting a machine, whereas disposal requires sanitising or destroying the drive itself before release.

Format the primary operating system partition.

Why it fails: Formatting the primary partition leaves data in slack space, other partitions, and remapped bad sectors recoverable. Media sanitisation, such as degaussing or cryptographic erasure, is required before disposal. Formatting suits repurposing a disk within the same controlled environment, not releasing hardware.

Deactivate the user accounts associated with the system.

Why it fails: Deactivating user accounts removes logical access but leaves the sensitive data intact on the drive, so anyone with physical possession can recover it. Account deactivation belongs to offboarding staff, whereas decommissioning hardware demands media sanitisation before the asset leaves the organisation's control.

AWS CloudTrail Event Selectors.

Why it fails: CloudTrail Event Selectors control which management and data events CloudTrail logs to a trail; they record API activity and cannot evaluate bucket policy or trigger remediation. They would be correct when the requirement is capturing specific S3 data events for auditing, not enforcing bucket privacy.

AWS Config Aggregators.

Why it fails: Aggregators consolidate Config rule and resource compliance data from multiple accounts and Regions into one view; they only report, never remediate. They would be the correct choice when you need centralised, cross-account compliance visibility, not automatic correction of non-compliant S3 buckets.

AWS Config Conformance Packs.

Why it fails: Conformance Packs deploy a collection of managed rules and remediation actions as a single governance artefact; they do not themselves perform the automatic remediation the scenario requires. They are tempting because they package compliance at scale, and would be correct when standardising rule sets across many accounts rather than remediating individual buckets.

Clear the file system using a standard OS format command.

Why it fails: A standard OS format rewrites file system structures only, leaving the underlying PII blocks intact and recoverable with laboratory tools; this is Clear at best, not Purge. It is tempting because formatting appears to remove files, but it is the correct choice only when media is reused within the same controlled environment.

Overwrite the drive once with zeros.

Why it fails: A single pass overwrite is insufficient to meet the highest standard of sanitization for sensitive data.

Purge the data using a cryptographic erase (CE) method.

Why it fails: Cryptographic erase only sanitises data when the media encrypts it and the key is destroyed; a legacy database server's drives may lack self-encrypting hardware, so the data remains recoverable. It is tempting because CE is a valid NIST SP 800-88 Purge method, but only where encryption is already implemented on the media.

The organization failed to report the breach to the US-CERT.

Why it fails: No breach is described; the audit found outdated Security Control Assessment results. US-CERT incident reporting applies when a breach occurs, not to assessment scheduling. The violation is failing to conduct control assessments at the required continuous monitoring frequency, usually annually.

The system failed to undergo a full re-accreditation.

Why it fails: Re-accreditation is not the requirement triggered by stale assessment results. The violation is failing to assess security controls at the required frequency under continuous monitoring, typically annually. Full re-authorisation would apply after significant changes, not merely because assessment results aged.

The System Security Plan (SSP) was not updated in the FISMA database.

Why it fails: The finding concerns stale Security Control Assessment results, not the System Security Plan's currency in the FISMA database. SSP updates address documented controls and boundaries. The violation is failing to assess controls at the required frequency, typically annually, under continuous monitoring requirements.

To automate the deployment of new software patches.

Why it fails: A configuration baseline is an approved snapshot of settings used to detect drift, not a patch deployment engine. It is tempting because baselines underpin change control, but automated patch distribution is performed by configuration management or update tools, not by the baseline record itself.

To identify all users with administrative privileges.

Why it fails: A configuration baseline records approved component settings and versions, not user privilege assignments. It is tempting because both concern system state, but administrative access review is an identity and access management activity; baselines compare configuration items against an approved reference.

To serve as a temporary backup for system files.

Why it fails: A configuration baseline is a formally approved reference configuration retained for comparison, not a temporary file backup. It is tempting because both preserve system state, but backups support recovery, whereas baselines support drift detection and compliance verification against the approved configuration.

To provide encrypted tunnels for administrative access.

Why it fails: SCAP expresses checklists and vulnerability data in standard formats for automated assessment; encrypted administrative tunnels are provided by VPN or SSH gateways. The option tempts because both appear in monitoring programmes, but tunnelling secures transport rather than enabling standardised, machine-readable compliance evaluation.

To monitor network traffic for anomalous behavior.

Why it fails: SCAP standardises vulnerability and configuration data for automated assessment; detecting anomalous traffic is the role of IDS, IPS or SIEM analytics. The option tempts because both feed continuous monitoring, yet anomaly detection analyses behaviour rather than evaluating systems against SCAP-expressed benchmarks.

To manage the lifecycle of cryptographic keys.

Why it fails: SCAP automates configuration and vulnerability checking against standardised benchmarks such as OVAL and XCCDF, producing machine-readable compliance data; key lifecycle management belongs to a KMS or HSM. The option tempts because both support continuous monitoring, yet cryptographic key custody is a distinct function.

Daily vulnerability scanning of the production environment.

Why it fails: Daily vulnerability scanning detects software flaws but does not verify that the authorised control baseline itself remains implemented and effective after each release. It is tempting because frequent scanning supports continuous monitoring, which is valuable for patch management rather than confirming baseline conformance.

Annual penetration testing of the application.

Why it fails: Annual penetration testing occurs once a year, so it cannot detect control drift introduced by releases shipping weekly or daily, leaving the baseline stale between tests. It is tempting because penetration testing validates control effectiveness deeply, which suits point-in-time assessments rather than continuous monitoring.

Manual sign-off by the CISO before every code commit.

Why it fails: Manual CISO sign-off before every commit creates a human bottleneck incompatible with frequent DevOps releases, and it reviews code rather than verifying control baseline effectiveness. It is tempting because executive authorisation is central to traditional authorisation decisions, which suits infrequent, high-assurance releases.

Document them in the System Security Plan (SSP) as 'accepted risks'.

Why it fails: Recording ATO conditions as accepted risks misrepresents them: conditions are binding requirements to remediate, not risks the organisation has chosen to tolerate. Documenting them in the SSP is tempting because the SSP is the system's authoritative record, but accepted-risk entries belong to formally accepted risks, not to AO-imposed conditions.

Ignore them until the next major system upgrade.

Why it fails: Conditions attached to an ATO remain binding throughout continuous monitoring and must be tracked, evidenced and reported until formally closed. Deferring them to a future upgrade is tempting because upgrades often remediate findings, but conditions require active monitoring now, not postponement until a major release.

Submit a request to the AO to remove the conditions without changes.

Why it fails: Conditions are imposed by the Authorising Official and can only be lifted through that authority's formal review, not by a simple removal request. Requesting removal is tempting because conditions feel like administrative overhead, but the AO needs documented evidence that each condition's underlying risk has been remediated before closure.

System Security Plan (SSP).

Why it fails: The SSP documents the implemented controls and their descriptions, but it is not the vehicle for tracking changes over time. That role belongs to the Plan of Action and Milestones, which records weaknesses, remediation and status. The SSP is tempting because it describes controls, yet it is a static baseline, not a change log.

Risk Assessment Report (RAR).

Why it fails: The RAR records risk assessment findings and severity determinations, not the status of individual control modifications. It is tempting because risk feeds continuous monitoring, and it would be the right document when assessing risk before authorisation or after a significant change.

Authority to Operate (ATO).

Why it fails: An ATO is the authorising official's approval decision, recording acceptance of risk at a point in time, not a register of control changes. It is tempting because it is central to authorisation, and it would be correct when granting, renewing or revoking permission to operate after assessment.

Domain controller event logs.

Why it fails: Domain controller event logs record authentication, Kerberos and directory changes, not firewall configuration modifications. They are tempting because they are a rich security-monitoring source for identity events, but detecting a firewall configuration change requires the firewall's own configuration or audit logs.

DHCP server logs.

Why it fails: DHCP logs record IP address leases and hostname assignments, revealing nothing about firewall rule or configuration changes. They are tempting for asset-to-address correlation during investigations, but detecting a configuration change requires the firewall's own configuration or audit logs, not lease data.

Endpoint antivirus logs.

Why it fails: Endpoint antivirus logs capture malware detections and host-level security events, not firewall configuration modifications. They are tempting as a general security telemetry source, but alerting on a firewall configuration change demands the firewall device's own configuration-change or audit logs.

Delete the VM snapshot from the management console.

Why it fails: Deleting a snapshot removes one stored copy, yet other replicas, backups or cached blocks may still hold personal data, so it cannot be the final compliance step. It is tempting because snapshots are obvious data stores, and deleting them is correct when reclaiming storage or removing a specific restore point.

Revoke the access rights of the VM administrator.

Why it fails: Revoking administrator access removes human privileges but does not address residual copies of regulated data, which is the compliance obligation after deletion. It is tempting because least-privilege cleanup is genuine decommissioning work, and would be correct earlier, when the VM still runs and access must be withdrawn before teardown.

Shut down the VM and wait for the provider to recycle the hardware.

Why it fails: Shutting down the VM leaves the data intact on the provider's storage; deletion must be verified and attested, not assumed from hardware recycling. It is tempting because physical media destruction is a valid end-of-life control for owned hardware, but cloud decommissioning requires cryptographic erasure or a certificate of data destruction instead.

/etc/hosts.allow

Why it fails: /etc/hosts.allow governs TCP wrapper access by host or network, not sshd's own configuration directives. The PermitRootLogin setting lives in /etc/ssh/sshd_config. Hosts.allow is tempting because it does control service access, and would be correct if the audit concerned restricting which remote addresses may reach the daemon at all.

/etc/shadow

Why it fails: /etc/shadow stores hashed account passwords and ageing data, containing no SSH daemon directives. It is tempting because it is a security-relevant file auditors routinely inspect, so it would be correct when verifying password hashing, account expiry or locked accounts rather than daemon configuration.

/etc/passwd

Why it fails: /etc/passwd lists local user accounts and their shells, holding no SSH daemon settings. It is tempting because it is a standard file for auditing accounts, so it would be correct when checking whether a user exists or has a valid login shell rather than whether root login is permitted.

Performing a full system re-installation annually.

Why it fails: Re-installation is a rebuild action, not continuous monitoring; Ongoing Authorization depends on automated data feeds and periodic assessment of control effectiveness against the authorisation decision. It would be correct in a disaster-recovery or system-refresh scenario, which is what makes it tempting here.

Changing the system administrator's password every month.

Why it fails: Password rotation is a routine operational security control, not an authorisation activity; Ongoing Authorization requires continuous monitoring of security controls and reporting to the Authorising Official. It would be correct under a configuration-management or access-control policy question, which is why it tempts.

Increasing the budget for information security.

Why it fails: Budget increases are a resourcing decision, not a monitoring or authorisation step; Ongoing Authorization requires reviewing continuous-monitoring results and updating the authorisation package. It would be correct in a security-programme funding or governance question, which is why it appears plausible.

The availability of security personnel to perform the tests.

Why it fails: NIST guidance bases monitoring frequency on risk tolerance, system categorisation and impact, not staffing capacity. Personnel availability is tempting because resourcing genuinely limits how often assessments can be executed in practise, but it is a constraint on implementation, not the factor that determines the required frequency.

The vendor's recommendation for maintenance windows.

Why it fails: NIST SP 800-137 ties frequency to risk, threat, vulnerability and impact, plus system categorisation, not vendor maintenance schedules. Vendor guidance is tempting because patching windows affect when scans can run, but that constrains scheduling, not the risk-based frequency selection itself.

The total number of users accessing the system.

Why it fails: NIST SP 800-137 selects frequency from risk, threat, vulnerability and impact data, not raw user counts. User numbers are tempting because they can indicate exposure and load, but population size alone says nothing about the system's categorisation, control effectiveness or the threats it faces.