Control Selection practice questions

FIPS 200.

Why it fails: FIPS 200 provides the minimum requirements but not the tailoring process.

NIST SP 800-37.

Why it fails: This covers the RMF process, not specific tailoring techniques.

CNSSI 1253.

Why it fails: This is for National Security Systems, not general federal systems.

Categorize.

Why it fails: Categorization comes before selection.

Assess.

Why it fails: Assessment occurs after implementation.

Implement.

Why it fails: Implementation follows selection.

A control that covers both physical and logical security.

Why it fails: This is a classification of scope, not responsibility.

A control that is always automated.

Why it fails: Hybrid refers to responsibility, not automation.

A control that is used in both cloud and on-premise environments.

Why it fails: This describes deployment, not control type.

Verifying that the controls are operating as expected.

Why it fails: This is the assess step.

Determining the impact categorization of the system.

Why it fails: This is the categorize step.

Authorizing the system for operation.

Why it fails: This is the authorize step.

Removing all controls related to physical security because the cloud provider is responsible for the data center.

Why it fails: While the cloud provider may implement many physical security controls, the organization cannot simply remove all physical security controls from its baseline. The organization must still ensure that the cloud provider's physical controls meet its requirements, often through inheritance or assessment. Removing them entirely without verification could leave gaps in the security posture and is not a valid tailoring action.

Documenting the tailoring decisions in the system security plan, including the rationale for scoping out or compensating controls.

Why it fails: Documenting tailoring decisions is a necessary step, but it is not an action that tailors the baseline itself; it is a documentation requirement. The question asks for appropriate actions when tailoring, which involve modifying the baseline. While documentation is crucial, it is not a tailoring action per se. The correct actions are those that directly modify the control set, such as scoping out or compensating.

Adding controls from the NIST SP 800-53 high baseline to ensure the system is secure, regardless of the system's impact level.

Why it fails: Adding controls from a higher baseline without justification is not appropriate tailoring. Tailoring should be based on the system's impact level, risk assessment, and specific requirements. Over-selecting controls can introduce unnecessary costs and complexity. The organization should select controls based on the moderate baseline (or appropriate level) and then tailor as needed, not arbitrarily add high baseline controls.

Using compensating controls to replace controls that cannot be implemented.

Why it fails: Compensating controls are used when a control cannot be implemented as specified, but they are not a scoping consideration. Scoping is about determining which controls apply to the system and where they apply. Compensating controls are an alternative implementation method, not a way to tailor the baseline by scoping. They are part of the tailoring process but not a scoping consideration in NIST SP 800-53B.

Selecting a different baseline from a higher impact level to ensure adequate security.

Why it fails: Selecting a higher baseline is not a scoping consideration; it is a baseline selection decision. Scoping involves adjusting the chosen baseline based on factors like system architecture, technology, and risk. Using a higher baseline may be appropriate in some cases but is not a method to reduce the control set. It would actually increase the number of controls, which is contrary to the goal of scoping.

Adding controls from a different framework to enhance security.

Why it fails: Adding controls from a different framework is not a scoping consideration; it is a form of supplementation. Scoping focuses on the NIST SP 800-53 controls and how they apply. While organizations may choose to add controls from other sources, that is not part of the scoping guidance in NIST SP 800-53B. Scoping is about reducing or focusing the baseline, not expanding it with external controls.

To categorize the control by its priority level.

Why it fails: Priority categorisation in NIST 800-53 comes from control baselines and the FIPS 199 impact level, not from assignment statements. The priority angle is tempting because baselines indicate which controls are essential, but assignment statements instead mark placeholders where the organisation inserts its own specific values.

To link the control to a regulatory requirement.

Why it fails: Assignment statements define organisation-defined values the implementer supplies when tailoring a control, not a mapping to regulatory requirements. The regulatory linkage is tempting because NIST 800-53 controls map to frameworks, but that mapping appears in separate catalogues, whereas assignment statements parameterise the control's own text.

To assign the control to a specific system administrator.

Why it fails: Assignment statements are not personnel assignments; they are placeholders requiring the organisation to insert specific values, such as frequency or role, when tailoring the control. Naming an administrator is tempting because controls often reference responsible roles, but that responsibility is captured in the control's own text, not its assignment statements.

Replace a control with a vendor-provided security feature.

Why it fails: Replacing a control with a vendor feature is compensating-control substitution, not supplementing. Supplementing adds controls or enhancements to the baseline, which is correct when the organisation must strengthen coverage beyond what NIST SP 800-53 already prescribes.

Remove controls from the baseline that are technically infeasible.

Why it fails: Removing controls addresses tailoring by scoping out inapplicable baseline items, which is the opposite of supplementing. Supplementing adds controls or control enhancements beyond the baseline to address organisation-specific risks, technologies, or environments. Deletion would be considered when a control genuinely does not apply to the system.

Adjust the parameters of existing controls to lower operational impact.

Why it fails: Parameter adjustment is tailoring, not supplementing; it changes values within existing controls. Supplementing adds controls or control enhancements beyond the baseline, which is correct when the organisation needs additional safeguards not present in the initial set.

Risk Acceptance.

Why it fails: Risk acceptance retains the residual exposure and formally documents it, without substituting anything; here a compensating control is actually applied, so the risk is mitigated rather than accepted. Acceptance is tempting because legacy constraints often force it, and it would be correct only when no compensating control exists and management signs off on the exposure.

Baseline Tailoring.

Why it fails: Tailoring selects or scopes controls from the baseline to fit the system, but it does not introduce a substitute control that differs from the catalogue entry. It is tempting because legacy constraints do drive scoping decisions, and tailoring would be correct when controls are omitted or parameterised, not replaced by an alternative mitigating mechanism.

Control Supplementation.

Why it fails: Supplementation adds controls beyond the baseline to strengthen coverage, whereas this scenario swaps an unimplementable control for a different one achieving the same objective. It is tempting because both involve adding controls, and supplementation would be correct when the baseline is insufficient and extra controls are layered on rather than substituted.

Control priority tag.

Why it fails: A control priority tag indicates implementation sequencing or emphasis, not family membership. It is tempting because priority values appear in catalogue fields, but the family is identified by the control's identifier prefix and family name, which priority tagging does not encode.

The assignment statement.

Why it fails: Assignment statements populate parameter values within a control, not the family to which it belongs. It is tempting because assignments appear alongside controls in the catalogue, yet family membership is conveyed by the control identifier prefix and family designation, which assignment statements do not carry.

The control parameter list.

Why it fails: The control parameter list holds the assignment and selection values for a control's parameters, not its family grouping. It is tempting because parameters appear within each control entry, but the family is identified by the control's two-letter identifier prefix and the family field, not by parameter data.

Replace the family with general security controls.

Why it fails: Tailoring permits scoping out controls that are not applicable, so PRIV controls can be marked not applicable with justification rather than swapped for security controls. It is tempting to substitute other controls, but the PRIV family addresses privacy risks that general security controls do not cover.

Keep the controls but set them to 'manual' mode.

Why it fails: NIST 800-53 controls have no 'manual mode'; the PRIV family is selected or scoped out during tailoring, not toggled between automated and manual execution. Keeping inapplicable privacy controls inflates the assessment boundary. Manual designation suits controls whose evidence collection genuinely requires human judgement, such as personnel screening or physical escort procedures.

Implement the controls as high-priority items.

Why it fails: Priority ranking does not determine applicability; PRIV controls address privacy requirements arising from PII processing, which this system does not perform. Marking them high-priority still forces implementation and assessment effort. High-priority designation is correct when a control is applicable but critical to the system's security categorisation, not when the family is out of scope.

Individual systems must override the common control.

Why it fails: Systems inherit common controls rather than overriding them; an override would break the shared inheritance model and duplicate the control. It is tempting because system-specific tuning of parameters feels necessary, but tailoring happens within the inherited control, not by replacing it.

Common controls cannot be used for password complexity.

Why it fails: Common controls are inherited by systems, so password complexity can absolutely be documented as one; the claim of impossibility is false. It is tempting because common controls are often infrastructure-level, yet password policy is a legitimate shared control inherited by every system in scope.

Individual systems must report their own password status.

Why it fails: Inheriting a common control means systems do not separately report that control's status; the common control provider does. It is tempting because each system still owns its own authorisation boundary, yet password complexity status is reported once at the common control level.

To remove all controls that do not apply to the local network.

Why it fails: Baseline selection starts from the NIST SP 800-53B catalogue for the system's impact level; tailoring then removes or scopes controls, not the initial selection. It is tempting because tailoring is a real later step, and it would be correct if the question asked how controls are adjusted to fit a specific system's environment.

To define the continuous monitoring strategy for the system.

Why it fails: Continuous monitoring strategy is defined later, in the monitor step of the RMF, not during initial baseline selection. It is tempting because monitoring is part of the wider RMF lifecycle, and it would be correct if the question asked how an organisation maintains ongoing situational awareness of control effectiveness after authorisation.

To identify all system-specific compensations.

Why it fails: Compensating controls address requirements a system cannot meet directly, so they are identified during tailoring, not baseline selection. The initial baseline derives from the FIPS 199 impact categorisation, which determines the starting control set. Identifying compensations would be correct later, when documenting how a specific control is satisfied by an alternative mechanism.

NIST SP 800-53A.

Why it fails: NIST SP 800-53A provides assessment procedures for determining control effectiveness, not the Low, Moderate and High baselines themselves. It is tempting because it accompanies SP 800-53, but its axis is assessment methodology, whereas SP 800-53B defines the baseline control sets.

FIPS 199.

Why it fails: FIPS 199 defines security categorisation of information and systems as Low, Moderate or High impact; it does not define the control baselines themselves. It is tempting because it uses the same three labels, but its axis is impact categorisation, whereas SP 800-53B maps those categories to baseline controls.

NIST SP 800-37.

Why it fails: NIST SP 800-37 describes the Risk Management Framework process for authorising systems, not the baseline control selections. It is tempting because it governs the RMF steps that consume baselines, but its axis is process, whereas SP 800-53B defines the Low, Moderate and High baseline control sets.

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.

The overlay is used only if the system is High impact.

Why it fails: Overlays are applied regardless of impact level; they tailor a baseline to specific technologies, environments or threat concerns, and can supplement Low or Moderate baselines too. Restricting them to High impact is tempting because High systems attract extra controls, but impact categorisation is not the trigger.

The baseline is discarded if an overlay is used.

Why it fails: The baseline stays selected and the overlay supplements it with mobile-specific controls; discarding the baseline removes the common control set the overlay builds upon. Overlays are tempting because they tailor controls to a technology, but they are additive by design, not a substitute that voids the underlying baseline.

The overlay replaces the entire baseline.

Why it fails: An overlay adds or strengthens controls for a specific technology or environment; it does not supersede the baseline, which remains in force. Replacing the baseline would drop the common controls the overlay assumes. Overlays are tempting because they are applied on top of a chosen baseline, but that layering is exactly why the baseline persists.

It replaces the need for FIPS 199 categorization.

Why it fails: FIPS 199 categorisation determines the confidentiality, integrity and availability impact level of an information system, and it drives control selection regardless of overlay. An overlay packages controls for a given platform or environment; it presupposes a categorisation rather than substituting for it. Overlays are the right tool when you need reusable, pre-tailored control sets.

It eliminates the need for manual tailoring.

Why it fails: An overlay supplies pre-tailored, pre-populated control sets for a specific technology, platform or environment, which reduces but never removes tailoring to organisational parameters. It cannot eliminate manual tailoring, since scoping, parameter values and inheritance decisions remain organisation-specific. Overlays are chosen precisely to streamline, not abolish, that tailoring effort.

It automatically tests the controls for compliance.

Why it fails: An overlay is a documented, pre-tailored set of controls and guidance for a defined environment; it contains no assessment engine and executes nothing. Automated control testing comes from continuous monitoring and assessment tooling, such as SCAP-validated scanners or cloud-native compliance services. Overlays are chosen to standardise control selection, not to run tests.

To automate the scanning process.

Why it fails: The catalog is a reference set of controls and enhancements, not a scanning engine; automation comes from tools such as SCAP-validated scanners configured against those controls. It is the right source when mapping controls to a system boundary, not when automating technical checks.

To mandate the order of implementation.

Why it fails: The Control Catalog is a structured listing of controls and their enhancements for selection and tailoring; it prescribes no sequencing, and SP 800-53 explicitly leaves implementation order to the organisation. It would be the right reference when building a control baseline, not when planning rollout order.

To identify which vendors are compliant.

Why it fails: The catalog describes controls, not vendor compliance status; that information comes from assessments, authorisation packages or FedRAMP listings. The catalog is the correct artefact when selecting and tailoring controls for a system, not when evaluating which suppliers meet them.

Use the default value provided in the appendix.

Why it fails: The bracketed assignment marker means the organisation must supply its own value; adopting the appendix default bypasses that obligation. Defaults are acceptable only where the catalog labels a parameter as non-assignment, which this one is not.

Remove the control since it is not fully defined.

Why it fails: Removing the control discards a required NIST 800-53 safeguard merely because its parameter is unfilled, rather than supplying the organisation-defined frequency. Deletion is tempting when a control appears incomplete, but tailoring may only remove controls that are genuinely inapplicable, documented in the SSP with justification.

Leave the assignment blank.

Why it fails: Leaving the parameter blank abandons the organisation-defined value the control requires, so the control cannot be implemented or assessed. It is tempting when the catalog text looks incomplete, but assignments exist precisely to be filled in; a blank is only acceptable where the control explicitly permits no value.

To configure the security appliances.

Why it fails: Configuring appliances is a system administrator's implementation task; the AO selects and approves controls, then accepts residual risk. It tempts because the AO oversees the security posture, yet configuration is operational execution, not authorisation, so the role boundary is crossed.

To write the security policy.

Why it fails: The AO authorises the system to operate and accepts residual risk; security policy authorship belongs to the security architect or policy owner. Writing policy would be the AO's task only in small organisations where that role is formally combined with information security responsibilities.

To perform the technical assessment.

Why it fails: Technical assessment is performed by assessors who test controls and report findings; the AO uses those results to make risk-based authorisation decisions. It tempts because the AO must understand assessment evidence, but hands-on testing belongs to the assessment team, not the authorising role.