Knowledge is Power

Sitewide Search

Search Bare Metal Cyber

Search courses, individual lessons, wiki entries, books, podcasts, magazine articles, Daily Cyber News, and Darwin.

NIST SP 800-53 Learning Center

SA-2 — Allocation of Resources

Read the official control and assessment content, then use the separately labeled Bare Metal Cyber perspective to connect the requirement to implementation, evidence, and sustained operation.

0Enhancements
0Parameters
4Baseline memberships
3Assessment methods

SA — System and Services Acquisition · NIST SP 800-53 Release 5.2.0

LowModerateHighPrivacy
Official NIST control content

Control statement

  1. a.Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;
  2. b.Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and
  3. c.Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.
Official NIST discussion

Discussion

Resource allocation for information security and privacy includes funding for system and services acquisition, sustainment, and supply chain-related risks throughout the system development life cycle.

Original Bare Metal Cyber perspective

From control text to operational evidence

Use Allocation of Resources as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to secure acquisition, engineering, development lifecycle, supplier expectations, and system integrity by design.

Implementation workflow

  • Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
  • Resolve each organization-defined parameter before declaring the control implemented.
  • Document how the implementation satisfies every clause of the official control statement.
  • Collect evidence as a normal byproduct of operation rather than only before an assessment.
  • Review exceptions, changes, and monitoring results on a risk-based cadence.

Evidence examples

  • security requirements in contracts and specifications
  • architecture and design review records
  • development lifecycle evidence
  • supplier assessment and acceptance records

Common failure patterns

  • security requirements added after procurement
  • supplier claims accepted without evidence
  • development exceptions become permanent
  • security architecture not tied to testable requirements

Questions practitioners should ask

  • What risk decision is this control intended to support in this system?
  • Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
  • Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
  • What event or threshold requires the implementation to be reviewed or changed?
Official NIST SP 800-53A content

Assessment objectives and methods

Show the assessment objective
  1. SA-02a.
    1. SA-02a.[01]the high-level information security requirements for the system or system service are determined in mission and business process planning;
    2. SA-02a.[02]the high-level privacy requirements for the system or system service are determined in mission and business process planning;
  2. SA-02b.
    1. SA-02b.[01]the resources required to protect the system or system service are determined and documented as part of the organizational capital planning and investment control process;
    2. SA-02b.[02]the resources required to protect the system or system service are allocated as part of the organizational capital planning and investment control process;
  3. SA-02c.
    1. SA-02c.[01]a discrete line item for information security is established in organizational programming and budgeting documentation;
    2. SA-02c.[02]a discrete line item for privacy is established in organizational programming and budgeting documentation.

Examine

  • System and services acquisition policy
  • system and services acquisition procedures
  • system and services acquisition strategy and plans
  • procedures addressing the allocation of resources to information security and privacy requirements
  • procedures addressing capital planning and investment control
  • organizational programming and budgeting documentation
  • system security plan
  • privacy plan
  • supply chain risk management policy
  • other relevant documents or records

Interview

  • Organizational personnel with capital planning, investment control, organizational programming, and budgeting responsibilities
  • organizational personnel with information security and privacy responsibilities
  • organizational personnel with supply chain risk management responsibilities

Test

  • Organizational processes for determining information security and privacy requirements
  • organizational processes for capital planning, programming, and budgeting
  • mechanisms supporting and/or implementing organizational capital planning, programming, and budgeting
Official relationships

Related controls

These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.

Source record

Authoritative sources