SA-2 Allocation of resources: requirements and evidence

What SA-2 allocation of resources asks an organization to prove

SA-2 asks an organization to show that security and privacy requirements are determined during mission and business planning, that the resources needed to protect the system are allocated through capital planning and investment control, and that security and privacy appear as a discrete line item in budgeting documents. When an assessor or a contract asks for SA-2, the first place they look is not the firewall or the code. They look for the planning records and the budget paper that show someone decided, and paid for, the protection before the system was built or bought.

The governance risk is that security gets absorbed into the cost of a project or a platform. A team can build a system with reasonable controls, yet if the budget never named security and privacy as their own line, nobody can show the money was set aside, nobody can see when it was cut, and nobody can explain why a known gap was left open. Buyers often overlook SA-2 because it sits in the planning and governance layer rather than in a technical configuration, and because the budget team has rarely been asked to produce security funding evidence before.

Before the next assessment, confirm three things with finance and the system owner: where security and privacy requirements were recorded at project initiation, which capital planning or investment review decision funded them, and whether the current budget document names security and privacy as a separate item. Ask your assessor which examine objects they expect to see, since SA-2 assessment procedures point to acquisition strategy, plans and programming and budgeting documentation. The exact wording of those procedures is in the NIST SP 800-53A Rev. 5 publication, which you should read rather than rely on a summary.

Which systems, budgets and teams SA-2 reaches

SA-2 reaches further than the security budget. It applies wherever a system's security and privacy needs are decided during planning and funded through the organization's capital planning and investment processes. The cards below cover the decisions that set the work: the boundary, the budget owners, the baseline and the FedRAMP classes.

Systems inside the authorization boundary

Start with the systems the organization has already authorized or plans to authorize. SA-2 applies to the system as a whole, so every component, environment and service inside the boundary needs its security and privacy requirements traced to a funded line. Check whether shared platforms, identity services and logging pipelines sit inside the boundary or are inherited from another authorization. A system left outside the boundary can still need funding if the organization depends on it for mission functions. Confirm the boundary with the authorizing official before scoping SA-2 evidence.

Budget owners and portfolio processes

SA-2 requires a discrete security and privacy line item in budgeting documents, so the assessor will look for it in the programming and budget records rather than in the security team's plan. Identify who owns each system's budget, who approves capital investments and how security requests enter that process. Ask whether a security request can be rejected or deferred without a documented risk decision. Evidence is usually the budget submission, the investment review minutes and the approved funding line.

Planning-stage requirements owners

The control expects high-level security and privacy requirements to be set during mission and business planning, before procurement or build work starts. The people who write business cases, product roadmaps and architecture proposals therefore need to know the SA-2 expectation. Map who drafts each planning artifact and who signs off that security and privacy needs were considered. If requirements first appear in a late security review, the control is not operating as written, even when a budget line exists.

How the baselines change applicability

SP 800-53B assigns SA-2 to the low, moderate and high baselines and to the privacy baseline, so it applies at every impact level. The depth of evidence still scales with the system's categorization and the privacy scope. Confirm which baseline a system was categorized under and whether the privacy baseline also applies to it. Because SA-2 has no parameters and no enhancements in Release 5.2.0, the tailoring question is mainly about who owns the evidence, not how many sub-requirements apply.

FedRAMP Class B, C and D requirements

FedRAMP's Rev5 baselines require SA-2 at Classes B, C and D. Confirm which class a cloud service offering is authorized under, since the class sets which set of controls the provider must show. Cloud providers should also check how FedRAMP 20x ties SA-2 to its investment review indicator, because the question assessors ask is how security investment decisions are made and recorded. Confirm current class requirements in the FedRAMP documentation before writing the evidence plan.

SA-2 and its neighbors in SA

SA-2 sits in the same family as SA-3 and SA-4, which govern engineering and acquisition, but it concerns funding governance. SA-3 covers how the lifecycle builds security in, SA-4 covers what contracts require, and SA-2 covers whether the money and planning exist to deliver them. Treat SA-2 evidence as the bridge: a funded line item that matches the requirements in SA-3 and SA-4. Assessors often find gaps where engineering requirements exist but no budget follows them.

How a discrete security budget line is built and kept

SA-2 turns security and privacy requirements into money only if they travel through three documents: the mission and business plan, the capital planning and investment control process, and the budget. The discrete line item is the visible end of that chain, and it is easiest to build backward from the question an assessor will ask: can the organization show where the security money for this system was planned, approved and spent? Start by listing the high-level security and privacy requirements the system must meet during mission and business planning, then tag each one to a funding request. Assessors reviewing SA-2 examine the acquisition strategy and plans and the organizational programming and budgeting documentation, so the reader should confirm that these two artifacts reference the same requirements and the same system identifier.

The catalog ties SA-2 to PM-3 (Information security and privacy resources), PM-11 (Mission and business process definition), PL-7 (Concept of operations), SA-9 (External system services), SR-3 (Supply chain controls and processes) and SR-5 (Acquisition strategies, tools and methods). PM-3 is the program-level counterpart: it asks for resources to be planned and budgeted across the organization, so the system line item should roll up into that program view rather than stand alone. PM-11 supplies the mission context that decides which requirements matter. PL-7 is where the concept of operations describes the mission the funding protects. A practical check is to trace one system from its PL-7 concept of operations through its PM-11 mission definition to its budget entry, and to flag any requirement that appears in none of them.

How an assessor tests SA-2 across six determination statements

This table maps the examine, interview and test methods that SP 800-53A applies to SA-2 against the evidence an assessor will request and the findings that commonly appear. Read it as a checklist for what to have ready before an assessment begins, since most SA-2 gaps are found in budget documents and planning records rather than in technical systems.

Assessment method	What the assessor examines or asks	Evidence that passes	Common finding
Examine: acquisition strategy and plans	Whether security and privacy requirements appear in the acquisition strategy and whether they were set during mission and business planning	Dated planning documents that list high-level security and privacy requirements and show who approved them	Requirements added after budgets were set, or planning documents that never mention security
Examine: programming and budgeting documentation	Whether a discrete line item for security and privacy exists in budget submissions for the system	Budget or program submissions with a separate security and privacy line tied to the system	Security funded only as a shared IT line with no traceable amount
Interview: priority setters	How mission owners and program leads decide which security and privacy needs get funded and when	Consistent answers that match the planning and budget records, with named decision owners	Answers that differ from the written records or depend on one person
Interview: spending approvers	How capital planning and investment review decisions account for security and privacy	Investment review minutes or decision records that reference security and privacy requirements	No investment review step covers security spending
Test: capital planning and investment control	Whether the investment control process is applied to the resources that protect the system	Investment review records showing the security request was evaluated and the outcome was recorded	Investment process exists on paper but was not applied to the system
Examine: alignment across documents	Whether the requirements in plans, budgets and approvals describe the same scope and amounts	A traceable chain from the planning requirement to the budget line and the approval	Mismatched scope or amounts between the plan and the budget

Implementing SA-2 in the planning and budget cycle

This sequence turns SA-2 from a policy statement into a traceable chain: security and privacy requirements identified early, funded by a named owner, visible as a budget line, tied to investment decisions and approved on record. Each step leaves a document an assessor can examine.

Identify requirements during mission and business planning
Before the next planning cycle closes, the system owner and the security and privacy leads list the high-level security and privacy requirements for each planned system or major change. Mission and business planning is where SA-2 expects these requirements to surface, so they should appear in the same documents that set scope, purpose and expected users. The output is a short requirements summary per system, dated and signed by the system owner, that states the requirements in business terms. Confirm that the summary names the system it covers, because assessors will test whether requirements exist for each system in scope.
Agree the funding owner for each requirement
Each security and privacy requirement needs a named owner who can commit money. This is usually the budget holder for the system or business line, with the CISO or privacy officer advising but not funding by default. Record the owner against each requirement in the summary, along with the cost center that will carry it. The output is a responsibility table that shows who funds, who delivers and who approves. Without this step, requirements tend to be accepted in planning and then disappear when budgets are set.
Add a discrete security and privacy budget line
SA-2 calls for a separate line item for security and privacy in budgeting documents, so the amount is visible rather than buried in general IT spend. Work with finance to add the line to the budget template for each planning cycle, with sub-lines for the major requirement groups if the organization tracks them that way. The output is the budget template and the approved budget entries that show the security and privacy line for each system. Ask finance to confirm the line survives the consolidation and approval steps, since it is often merged away there.
Link investment decisions to the requirements
Capital planning and investment control is the mechanism SA-2 relies on to fund protection. Each investment request for a system or major change should reference the requirements it satisfies and the budget line that funds them. Investment reviewers then decide whether the proposal meets the requirement, and a request without a stated security or privacy basis is returned. The output is an investment record for each request that cross-references the requirement identifiers and the budget line, so the chain can be followed in either direction.
Record approvals and retain the decision trail
Approval of the budget and investment decisions should be recorded in a form that can be produced on request. Minutes, signed approvals or workflow records should state which requirements were funded, which were deferred and who accepted any residual risk from deferral. Deferred items should also appear in the plan of action and milestones where the organization uses one. The output is an approval record per cycle that an assessor can examine alongside the budget template. Confirm the retention period with the organization's records policy.
Confirm the sequence in the next assessment cycle
Before an assessment, walk the chain from one system's requirements to its budget line, investment record and approval. Any break, such as a requirement with no owner or an investment with no security basis, should be fixed or documented as a known gap. The output is a short traceability check that the assessment team can examine directly. This check is also the most efficient way to find out whether SA-2 is working or only exists on paper.

Evidence that passes an SA-2 assessment

An assessor testing SA-2 looks for a paper trail that connects security requirements to money. The cards below cover the documents that carry that link, how to keep them current between assessments, and how the same set answers FedRAMP's investment review question.

Acquisition strategy and plans

The acquisition strategy and plans show that high-level security and privacy requirements were set during mission and business planning, before procurement began. Assessors examine these documents directly under SA-2. Check that each planned acquisition names its security and privacy requirements, the owner who approved them, and the date they were last reviewed. A strategy that omits security entirely is a common finding.

Capital planning submissions

Capital planning submissions show how the organization allocates resources to protect the system through its investment process. Keep the submitted cost estimates for security controls, the justification tied to identified risks, and any changes made during review. Confirm that the submission matches the budget actually approved, since a mismatch between the two is an easy question for an assessor to ask.

Budget documents with a discrete line

SA-2 requires a discrete line item for security and privacy in budgeting documents, so this is the artifact most often missing. Assessors look for a labeled entry, not security costs buried inside infrastructure or staffing totals. Keep prior-year budgets, the current approved budget and the amendments that changed the line. The line should be traceable to the capital planning submission it funds.

Investment approval records

Investment approval records prove that a named decision maker reviewed and accepted the security funding. Keep signed approvals, the date of each decision, and any conditions attached, such as funding released in phases. Where a request was declined or deferred, keep that record too, along with the documented risk acceptance. Assessors treat undocumented deferrals as unresolved risk.

Meeting minutes linking funding to risk

Minutes from governance or investment meetings show that funding decisions were discussed against identified risks. Record which risk register entries, audit findings or plan of action items were weighed, the outcome and the owner of each follow-up. Minutes that only list attendance give an assessor little to test. Confirm the meetings occur on a schedule the organization can actually show.

Keeping evidence current and reusing it

Evidence goes stale when budgets change and nobody updates the file, so set a recurring review of each artifact and log every revision with a date and owner. The same set answers FedRAMP's KSI-PIY-RIS question about reviewing investments in security, which lists SA-2 among its related controls. Confirm with your authorizing body which format and cadence it expects before you build the package.

What meeting SA-2 costs in money and effort

This table breaks down who is paid for each part of the SA-2 funding work, whether each cost is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so use the rows to build a scope and ask vendors and reviewers for written quotes.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Planning time to set high-level security and privacy requirements	Mission owners, security staff and architects during business planning	Recurring, at each planning cycle and each major system change	Number of systems in scope, how often mission plans change, and whether requirements already exist
Security staff time to write requirements	Internal security or GRC staff, or an implementation partner under a fixed-scope agreement	One-time for the first set, then recurring updates	Number of system types, existing requirement libraries, and how many acquisitions reference them
Budget template and line item changes	Finance and planning staff who build budgeting documents	One-time to add a discrete security and privacy line item, then recurring	How many budget templates exist, and whether capital planning already tracks security separately
Annual budget and capital planning cycles	Finance, planning and system owners who justify and approve funds	Recurring every budget cycle	Number of funded investments, how often reviews happen, and approval layers
Investment control reviews	Governance board or investment committee members	Recurring, usually tied to funding decisions	Number of decision points and whether reviews are combined with existing governance meetings
External review or assessment support	Independent assessors or consultants if the organization buys outside review	Usually one-time per assessment, repeated at reassessment	Assessment scope, how well evidence is organized, and whether the assessor needs to interview finance staff
Software or tooling license	Not applicable to SA-2 itself	Not applicable	SA-2 has no tooling license component, and self-hosted open-source tools do not remove the funding work

Who owns the budget decision and who can help

The organization owns SA-2. Executives and finance leaders decide which security and privacy requirements are considered during mission and business planning, how the protection of the system is funded through capital planning and investment control, and whether security appears as a discrete line item in budgeting documents. No outside party can make those decisions on the organization's behalf, and an assessor will ask to see the documents that record them.

Planning decisions: Confirm that high-level security and privacy requirements are raised during mission and business planning, not added after the budget is set.
Capital planning: Confirm that investment reviews name the resources that protect each system, including people, tooling and external support.
Discrete budget line: Confirm that security and privacy appear as their own line in the budget, so the spending can be traced in programming documents.
Decision records: Keep minutes or approvals that show who accepted or deferred funding for each requirement.
Recurring review: Confirm when the budget is revisited, because the line item must still exist in the next cycle.

Before engaging any partner, check that a named executive owns the SA-2 line item and can answer assessor questions about it.

Gaps that cause SA-2 findings and how to close them

SA-2 is a governance control, so most findings come from how security money and requirements move through planning, not from missing tools. The gaps below recur across assessments, and each one has a closing action that an assessor can verify from budget documents, planning records and investment decisions.

Security funded inside general IT

Security spend sits in a general IT or infrastructure line, so no budget document shows a discrete security and privacy item. An assessor testing the budgeting requirement looks for that line in the programming and budgeting documentation. Closing action: ask finance to create a named security and privacy line in the next budget cycle, with the systems it covers listed beneath it. Check that scanning tools, logging storage, backup and monitoring licenses are all mapped to that line rather than split across cost centers.

Requirements written after budget approval

Budgets are approved first, then security requirements are added to projects that have no money left for them. SA-2 expects high-level security and privacy requirements to be set during mission and business planning, before funding decisions are made. Closing action: add a security and privacy requirements step to the project intake form, and require the requirements to be signed off before the budget request is submitted. Keep the dated sign-off as evidence.

Investment decisions disconnected from risk

Capital planning decisions are made on cost and features without reference to the risk register or known weaknesses in a system. An assessor will ask how a funding decision was informed by risk, and a blank answer is a finding. Closing action: require each capital request above an agreed threshold to cite the risk entries or open plan of action items it addresses, and record the decision in the investment review minutes.

Evidence scattered across finance systems

Planning notes live in project tools, approvals in email, and spend in the accounting system, so no single record connects a requirement to the money spent on it. Assessors need to trace a requirement from planning through budget to contract. Closing action: agree on one register that links each security requirement to its budget line, approval date and purchase reference, and confirm that finance and security both can export it for an assessment.

No named owner for the line

The security and privacy budget has no accountable owner, so requests are negotiated case by case and nobody reports on whether the line was spent as planned. Closing action: assign a named owner with authority to propose reallocations, record who approved each change, and review the line against the requirements at a set interval. Ask the owner to document the review so an assessor can see that the resource decisions were actively managed.

Questions buyers ask about SA-2 cost, time and ownership

How much effort does SA-2 take to implement?

SA-2 is a governance control, so its effort lies in planning and budgeting documents and is measured by what those documents show. The control has three parts: determine high-level security and privacy requirements during mission and business planning, allocate resources to protect the system through capital planning and investment control, and create a discrete line item for security and privacy in budgeting documents. Effort rises with the number of systems in scope, the maturity of your planning process and whether security already appears in capital requests. SP 800-53A Release 5.2.0 breaks the control into 6 determination statements, which is the checklist an assessor works through. Expect the heaviest work in the first cycle, when you must show how past and planned investments connect to the security requirements. Ask any partner to list which artifacts they prepare and which your team must produce.

Does SA-2 require a separate security budget line item?

Yes. The control asks for a discrete line item for security and privacy in budgeting documents, so security spending hidden inside general IT costs does not meet the wording on its face. The control does not prescribe a dollar amount or a format, so your organization defines what the line contains and confirms the approach with its assessor. Assessors typically examine programming and budgeting documentation, which SP 800-53A names directly, to confirm the line exists and connects to capital planning decisions. Costs usually split into one-time items, such as initial design and tooling, and recurring items, such as staff, licenses, hosting and testing. NIST does not publish figures for any of these, so build the line from your own vendor quotes and staffing plan.

How long does the SA-2 cycle take?

No researched fact gives a duration for SA-2, and the control sets no timeline. The cycle follows your budgeting calendar: security requirements must be identified during mission and business planning, then carried into the next capital planning or investment review. Fiscal cycles and governance meeting dates therefore set the timing, and they differ between organizations. For federal systems, NIST leaves implementation timelines to OMB Circular A-130, and the assessor's schedule and the authorization timeline will drive the final date. Ask a partner to tie the work to your next budget submission and to the assessment date, and confirm both dates with your assessor before work starts.

Can an implementation partner prepare the evidence for SA-2?

A partner can prepare the technical and documentary material that supports SA-2, but it cannot make the funding decision or issue the assessment result. Only your organization can approve budgets and allocate capital, and only an independent assessor can test the control and report on it. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports or certifications. Under a written, fixed scope, a preparation package might include a map of security requirements to the system boundary, cost models for planned platform work and a draft showing how the security line item links to the system security plan. Confirm in writing which artifacts the partner delivers, which your team signs off and who holds final budget approval.

What must our team provide to satisfy SA-2?

Your team owns the planning, funding and approval records that SA-2 examines. Prepare these four categories:

Mission and business planning records showing where security and privacy requirements were set for each system
Capital planning and investment control records linking those requirements to funding decisions
Programming and budgeting documents containing a discrete security and privacy line item
System and services acquisition strategy and plans that reflect the same requirements

SP 800-53A lists these as examine objects. Interviews will test whether finance and program owners understand how the line is set and who approves changes to it. Keep the records dated and versioned so the assessor can trace each requirement from planning to funding.

Does SA-2 apply at every baseline?

Yes. SP 800-53B assigns SA-2 to the low, moderate and high security control baselines and to the privacy baseline. Appendix C of SP 800-53 Rev. 5 marks it as implemented by the organization and as an assurance-related control. In Release 5.2.0 it has no organization-defined parameters and no control enhancements, so the control text is the same at every level. Your assessor will confirm how much supporting evidence each system needs based on its categorization. FedRAMP's Rev5 baselines also require SA-2 at Classes B, C and D, so cloud services pursuing FedRAMP authorization carry the same expectation. Confirm the baseline for each system before you scope the evidence. FedRAMP's SA family reference shows how the control is presented for cloud services.

How does SA-2 differ from SA-3 and SA-4?

SA-2 concerns funding and governance: it establishes that security requirements exist and that money is set aside to meet them. SA-3 covers the system development life cycle, which sets how security and privacy are built into each development phase. SA-4 covers acquisition, which sets the security and privacy requirements written into contracts and what suppliers must deliver. The three controls depend on one another, because SA-2 funds the requirements that SA-4 writes into contracts and SA-3 builds into the lifecycle. SA-2's related controls in the Release 5.2.0 catalog are PL-7, PM-3, PM-11, SA-9, SR-3 and SR-5, so it sits closer to program management and supply chain controls than to development controls. An assessor tests each control separately, so evidence for one does not automatically satisfy the others.

How DeployOpen prepares SA-2 evidence

DeployOpen's part of SA-2 is preparation, not decision-making. Before any work starts, the scope of SA-2 support is agreed in writing: which systems are in the planning cycle, which planning and budgeting documents the client already uses, and which evidence the client's assessor is expected to examine. Because most engagements are fixed-scope, the written scope also fixes the deliverables and timelines. The client owns the budget, the investment decisions and the control itself. DeployOpen does not set budgets, issue reports or certify compliance, and any quote follows from that written scope.

Within the agreed scope, DeployOpen prepares the material the client's own capital planning cycle needs. That typically means a requirements document that states the high-level security and privacy requirements identified during mission and business planning, a budget template with a discrete line item for security and privacy, and an evidence pack that maps each item to the planning and budgeting documents an assessor would examine for the six determination statements in SP 800-53A. Each document is drafted for the client's finance and program owners to review, amend and approve through their own process. Ask us to show the template structure in the scoping stage so you can check it against your budget format before committing.

The support continues into assessment. DeployOpen can walk the client's assessor through how the requirements were set and funded, answer technical questions about the systems in scope and update the evidence pack when the budget cycle or system boundary changes. Cost drivers to raise in a quote include the number of systems in scope, how many planning cycles the evidence must cover, and whether ongoing support is needed as a retainer after the initial pack is delivered. Confirm with your assessor which artifacts they will accept, because the examine objects they expect may differ from the ones listed here.

SA-2 Allocation of resources