NIST 800-53 control baselines

SP 800-53 controls are mandatory for federal information systems, under OMB Circular A-130 and FISMA. A federal information system is one used or operated by an agency, by an agency contractor, or by another organization on behalf of an agency. That definition is why a contractor running a system for a federal customer inherits the obligation even though the contractor is not a federal body. Nongovernmental organizations that are not operating a system for an agency may adopt the controls and baselines voluntarily, and many do so as a common vocabulary for customers. Confirm with your contracting officer or customer which category your system falls into before you assume any obligation.

National security systems follow a different path. SP 800-53B points them to CNSSI 1253 for security categorization and control selection guidance instead of applying its own baselines. Outside the federal government, state and local programs usually reach SP 800-53 through contract language, not through a statute that names the baseline. Examples of such programs include IRS Publication 1075 and CMS ARS, which are referenced in agreements with agencies and their service providers. Read the agreement itself to find which control catalog, version and baseline it names, and whether it allows tailoring, because the obligation is only as wide as the text that imposes it.

The requirement comes from the contract, agency or regulator, but the organization still owns the decision of which baseline applies and how that decision is recorded. Start by asking the party imposing the requirement which impact level it expects for your system, then record the categorization and the resulting baseline in your system security and privacy plan. Any deviation from the baseline should appear there with a rationale, and a customer or assessor should be able to trace it back to the categorization. An implementation partner can prepare that documentation, but the decision and the sign-off remain with your organization and, for federal systems, with the authorizing official.

SP 800-53B treats a baseline as a starting point, not a finished control set. Not every SP 800-53 control or enhancement is assigned to a baseline at all, and the baseline you select is expected to be changed: controls are removed, added or specialized through tailoring. Before you accept a baseline as your requirement list, confirm with the authorizing official or contracting officer which baseline applies to each system, whether any controls outside that baseline are already required by the contract or agency policy, and which parameter values the agency has set. Those answers define the floor your tailoring cannot go below. Tailoring that is agreed informally, without a written record of who approved it, is the most common reason an assessment later reopens a scope decision.

The privacy baseline follows a different logic. It applies regardless of system impact level, and SP 800-53B expects you to tailor it using privacy risk assessments that examine the nature of the PII the system processes and how a failure would affect individuals. Ask the agency privacy office which privacy risk assessment method it accepts and who signs off on the result. A system that handles little PII may legitimately drop some privacy controls, but that conclusion should rest on documented analysis of the data flows, not on the system's security impact level alone. Plan for this review early, because privacy controls often touch policies, notices and data inventories that take longer to change than technical settings.

The mechanics of removing, adding and specializing controls, along with how each change is recorded, are covered on the NIST 800-53 tailoring and overlays page, so this section does not repeat them. Use it as the next step once you have confirmed the baseline, the required additions and the privacy scope with the people who own the authorization decision.

Before you select a baseline, confirm the system boundary in writing. The baseline attaches to a system, so the boundary decides which components, hosting accounts, administrative paths and data stores the categorization covers. Check whether shared services such as identity, logging or backup sit inside the boundary or are inherited from another authorization. Then pull the categorization record and confirm it is the one your authorizing official or contracting authority accepted, with confidentiality, integrity and availability each rated under FIPS 199. Recompute the high water mark yourself from those three ratings, because a single high rating moves the whole system to the high baseline.

Next, establish which rulebook applies. Ask the contracting authority whether the system is a national security system, since SP 800-53B points those systems to CNSSI 1253 instead of its own baselines. If you sell cloud services to federal agencies, confirm the FedRAMP impact class the provider or agency expects, because FedRAMP's Rev5 classes do not map directly onto the low, moderate and high baselines and may require a different control count. Also confirm whether a state or program-specific requirement, such as a published data-use agreement, names controls that sit outside the baseline you would otherwise choose.

Finally, check the privacy baseline trigger and the document versions. Determine whether the system processes personally identifiable information, since the privacy baseline applies regardless of impact level and needs its own privacy risk assessment. Then confirm which release of SP 800-53B and which OSCAL content your assessor, tooling and contract will reference. Ask the contracting authority to name the release in writing, and check the current release on the CSRC publication pages and the usnistgov/oscal-content repository before you generate a baseline profile, so the control list you implement matches the one you are assessed against.