Select

Now we can have a better conversation about safeguards. What requirements apply? Which risks need attention? Who will provide the protection? A long control list can look reassuring, but we still need to explain how each selected requirement fits the system and who is responsible for it.

NIST’s Select guidance covers choosing and tailoring controls, assigning them to providers and system components, planning continuous monitoring, and getting the resulting security and privacy plans reviewed and approved. NIST’s Select step describes the expected outcomes.

Check where the starting point comes from

First establish the governing requirements and the control catalog, baseline, and revision the organization is expected to use. SP 800-53 is a catalog of controls. A baseline is an initial selection from that catalog. Applicable overlays add context for particular communities or operating conditions.

That distinction is worth slowing down for. Two teams can say they’re “using NIST” and mean different things. Confirm the applicable selection method and approval authority before comparing their lists. A familiar baseline from another project may give you questions to ask, but its applicability still needs to be established here.

Make the choices explainable

Tailoring is where you apply the permitted adjustments and explain the result. Consider scope, control enhancements, organization-defined parameters, and any additional protections the risk assessment calls for. Record the rationale and obtain the approvals the governing process requires.

Pay attention to phrases that leave a value for the organization to define. A review frequency or response period needs a reason that fits the requirement and the risk. If a control is difficult to implement, bring the constraint and possible responses into the conversation. Difficulty alone doesn’t establish that a requirement can be removed.

Follow the responsibility all the way through

A system-specific control is implemented for that system. A common control is provided for inheritance by other systems. A hybrid control splits responsibility between the system and a common control provider. The useful question is what each party actually does and what the system can rely on.

For inherited protection, establish the provider, scope, conditions, and available assessment information. For shared responsibility, make the handoff explicit. Start planning monitoring here as well: what will tell us the protection is still working, who will review that information, and what should trigger action?

How this applies on SAP networks

NIST gives us the control requirements and the process for selecting and tailoring them. For SAP networks, JSIG directs how the NIST-based control set is selected through CNSSI 1253, applicable overlays, and tailoring. It also addresses inherited controls, monitoring, and approval of the plan. Exceptions to baseline and overlay controls require AO approval. That gives us a practical conversation: can we trace each selection to a requirement, a reason, and someone responsible for it? 2016 JSIG §2.3.2 gives the SAP-specific instructions for this step.

Let’s talk it through

Pick a question and compare how you’d approach it. Ask what information would change your answer.

• Could we explain our tailoring decisions without referring to what the last project did?
• If a provider says a control is covered, what scope and conditions would we need to confirm?
• Which control would be hardest to monitor, and does that reveal a problem with how we plan to implement it?

What do we carry forward?

Move into Implement with an approved control selection, clear responsibilities, and a monitoring approach. The people doing the work should be able to explain both the requirement and the outcome they’re expected to deliver.

The Select section of Body of Evidence & Artifacts connects this work to the artifacts and body of evidence (BOE) you produce and maintain.