SA-1 Policy and procedures: requirements and evidence

What SA-1 policy and procedures requires before an assessor arrives

SA-1 asks the organization to maintain a documented system and services acquisition policy and the procedures that implement it, to disseminate both to the roles that need them, to name an official who manages them, and to review and update them at a defined frequency and after defined events. The control is about governance, not engineering. An assessor who asks for SA-1 wants to see one current, approved set of rules that explains how the organization buys, builds and oversees systems and services, and who is accountable for keeping those rules true. SP 800-53B assigns SA-1 to the low, moderate and high baselines and to the privacy baseline, and Release 5.2.0 gives it 9 organization-defined parameters, so the organization must fill in its own values (such as the review frequency and the triggering events) before the control can be tested.

The other SA controls depend on this one. Acquisition requirements in SA-4, developer configuration management in SA-10, developer testing in SA-11 and external service oversight in SA-9 all need an approved policy and procedure to point to. When SA-1 is weak, assessors tend to find the same gaps elsewhere: contract templates that do not reflect current security requirements, engineering standards that nobody has reviewed since the last platform change, and supplier reviews run by people who were never told to run them. The control is hard in practice for two common reasons. Policies exist but were written for an earlier system landscape and have not been reviewed, and no single named official owns the document, so updates depend on whoever remembers.

Before an assessor arrives, confirm three things. Identify the official who owns the policy and write that name into the document. Compare the review frequency and triggering events you have defined against what your own change history shows, since a policy that claims an annual review but was last updated three years ago fails on its face. Then check that the procedures reference current roles, tools and contract clauses. Teams often keep these records in a wiki or document system. Tools such as XWiki keep version history and let reviewers compare and roll back versions, which helps show when each change was made and by whom, and BookStack assigns permissions by role so that the people who must read the policy can, while only the owner can approve changes. Your own environment will determine which tool fits, and the assessor will still expect you to show the approval and review trail, not just the current text.

Which acquisition, development and supplier activities SA-1 governs

SA-1 does not run any acquisition or development activity itself. It sets the policy and procedures that tell procurement, engineering, security and privacy teams how the other SA controls apply, and the organization records the scope choices that decide where those rules reach. The cards below cover the scoping decisions and the controls the policy governs in practice.

Choosing the policy level

SA-1 lets the organization write the policy at the organization, mission or business process, or system level. A single organization-wide policy is easier to keep consistent, while system-level policy suits a single high-impact system. Record the chosen level, the systems it covers and any exceptions in the policy itself, so an assessor can match scope to the systems in the authorization boundary. Confirm the choice against the organization-defined parameters in your SP 800-53 Rev. 5 control text.

Assigning teams that must follow it

The policy only works if the people who buy, build and assess systems know it applies to them. Procurement, engineering, security and privacy each own parts of the SA family, such as contract language, development practice, security review and privacy requirements. Name the designated official who manages the policy, and list the roles that receive it. Procedures should state which team performs each step, so no SA activity falls between departments.

Governing system development life cycle work

SA-1 sets the rules that SA-3 relies on for the development life cycle. The policy should state which life cycle phases require security and privacy review, who signs off on each phase, and how risk decisions are recorded. Check that the procedures match the life cycle the engineering team actually uses, including how changes move into production.

Governing acquisition and supplier oversight

The policy reaches SA-4 acquisition requirements and SA-9 external system services. It should require security and privacy terms in procurement, define what a supplier must provide, and name the oversight role that monitors ongoing compliance. Check that contracts for cloud and other external services are reviewed against the policy before signature, and that the file records who approved any exception.

Governing developer and testing controls

SA-10 covers developer configuration management, SA-11 covers developer testing and evaluation, and SA-15 covers development process, standards and tools. The policy should require that these apply to internal and external developers alike. Procedures should name who reviews test results, who tracks flaw remediation and who approves changes to development tools. Confirm that the evidence for each activity is stored where an assessor can find it.

Governing unsupported components and related controls

SA-22 requires identifying end-of-life hardware, software and firmware and documenting a risk decision for each. The policy should assign an owner for that register and set how replacement or alternative support is approved. The catalog also lists PM-9, PS-8, SA-8 and SI-12 as related controls, so check that the policy references the governance, personnel, engineering principles and information lifecycle rules those controls depend on.

How an assessor tests SA-1 under SP 800-53A

An assessor testing SA-1 under SP 800-53A works from 17 determination statements, and assesses them using the examine and interview methods only. There is no test method for this control, so the evidence is documents and people, not a system being exercised. The assessor will ask whether the organization has a system and services acquisition policy and implementing procedures that meet what the control requires, and whether those documents are actually followed. Your job before the assessment is to make sure every statement can be answered with a document or a named person. Examining the policy means reading it as the assessor would. Confirm the document has a current version number, an approval record from the designated official, the defined roles it is disseminated to, and a review date that falls within the frequency you organization-defined for SA-1. Check that the review triggers you set (such as after specified events) appear in the document and that the change history shows they were applied. The procedures should name who performs each acquisition, development and supplier task and where the working instructions are kept. Gaps here are usually simple, such as an expired review date or a policy that refers to a retired role.

Interviews check whether the policy is real to the people it governs. The assessor will typically ask procurement staff, system owners and developers whether they know the policy exists, where the procedures live and who to ask when a supplier does not meet them. Answers that differ between teams are a finding even when the written documents are correct. Then the assessor compares what is written with what the team does: a procedure that requires security requirements in every acquisition should match a sample of recent contracts and project records. Confirm that you can produce those samples and the people who can explain them before the assessment begins.

What assessors request for SA-1 and where findings usually come from

This table maps each part of SA-1 to the test approach an assessor uses, the evidence they ask for and the findings that appear most often. Read it as a checklist for preparing the policy and procedure set before an assessment begins. The main takeaway is that SA-1 findings are usually about missing parameters, unclear ownership and undated reviews rather than about the existence of a document.

Area	Test approach and evidence requested	Common findings
Policy existence and organization-defined parameters	Examine the documented acquisition policy and confirm it is set at the organization, mission or business process, or system level. Confirm every organization-defined parameter (9 in Release 5.2.0) has a value.	Policy exists but parameters such as review frequency or event triggers are left blank or described only in general terms.
Dissemination to defined roles	Interview the defined roles and examine distribution records, such as publication locations, acknowledgments or access logs, showing the policy reached them.	Policy is posted on a shared drive, but the named roles cannot say where it is or have never been told it changed.
Designated official	Examine the document for a named official or role who manages the policy, and confirm the assignment in an appointment record or governance charter.	The owner is a former employee or a team name with no accountable person, so no one approves updates.
Review frequency and event-driven updates	Examine revision history and the defined review frequency. Confirm reviews happened on schedule and after the defined events, such as a major system change or a new regulation.	No review date on the document, or the last revision predates a significant change in suppliers, tooling or the SA family.
Procedures that implement the policy	Examine the procedures for acquisition, development and supplier controls. Trace a sample procedure to the policy statement it implements and to a completed record that shows it was followed.	Procedures are missing for some SA controls, or they restate the policy without steps, owners or evidence outputs.
Link to related SA and governance controls	Examine how the policy points to SA-8, SA-9, SA-22 and the related PM-9, PS-8 and SI-12 controls, and confirm those controls reference it in turn.	Cross-references are broken, or the policy is silent on supplier controls that the SA family and related controls depend on.

How to write and operationalize the SA-1 policy and procedures

This sequence turns SA-1 from a document that exists into a governed set of acquisition, development and supplier rules that named people own, review on a schedule and can show were distributed. Each step ends with a record an assessor can inspect.

Confirm scope and organization-defined parameters
Start by agreeing the boundary the policy covers: which organization, mission or business process, or which systems, it governs. Then work through the nine organization-defined parameters in SA-1 of the Release 5.2.0 catalog, recording the value chosen for each, such as the policy level and the review frequency. Compliance, security and procurement leads should sign off on the list. The output is a parameter record that maps every value to a decision and a named approver.
Assign the designated official
Name one person accountable for the system and services acquisition policy and its procedures. This is usually a role such as the CISO or a director of security engineering, not a committee. Write the appointment into the policy itself and into the acquisition governance charter so the authority is traceable. Confirm the role has the standing to require changes from development teams and procurement. The output is a signed appointment that states the official's responsibilities.
Draft the policy and procedures at the chosen levels
Write the policy statement at the level selected in step one, whether organization, mission or business process, or system. Then write procedures that tell delivery teams and buyers how to meet it: how security requirements enter an acquisition, how development work is checked, and how supplier obligations are tracked. Keep the policy short and the procedures specific enough that a reviewer can test them. The output is an approved policy and a set of procedures, each with a version number and an owner.
Set review frequency and triggering events
Write down the review interval chosen in the parameter record and the events that force an earlier review, such as a new regulation, a material incident, a major platform change or a change in the acquisition model. Assign who initiates each review and who approves the result. Confirm the procedures reference the same events so that nothing is reviewed on one schedule and changed on another. The output is a review schedule and a review log template that records each review, its date, the reviewers and the changes made.
Disseminate to defined roles and record acknowledgment
Send the approved policy and procedures to every role the parameter record names, typically procurement, architecture, development, product owners and the managers of external suppliers. Ask each recipient to acknowledge receipt and confirm they understand their responsibilities. Keep the documents in a controlled repository with version history so the copy each person received can be identified later. The output is a distribution record listing recipients, dates, versions and acknowledgments.
Link procedures to SA-3 through SA-22
Map each procedure to the SA controls it governs, including the development lifecycle in SA-3, acquisition requirements in SA-4, external services in SA-9, developer configuration management in SA-10, developer testing in SA-11 and unsupported components in SA-22. Where a procedure is the only evidence for a child control, say so explicitly. Check the mapping with the people who run each process. The output is a traceability matrix that shows which procedure satisfies which control and which record proves it.
Test the procedures against live records
Choose a recent acquisition, a development release and a supplier onboarding, then trace each one back through the procedures. Confirm the steps happened, the designated official was involved and the records exist in the places the procedures name. Record gaps and fix either the procedure or the practice. An independent assessor will perform its own examination and interviews, so this internal test is a rehearsal, not a substitute. The output is a dated test record with findings and corrective actions.

Evidence that passes an SA-1 test and how to keep it current

An assessor testing SA-1 reads the documents themselves and then checks whether they were approved, distributed, and reviewed as the policy says. The six artifacts below link together: each one proves a different part of the control, and each goes stale unless someone owns its update cycle between assessments.

Approved policy with version record

The system and services acquisition policy itself, with a version number, an effective date, and a named approver who holds the designated authority. Assessors check that the approved version matches the one employees can find, and that the approval is traceable to a person with the right role. Keep superseded versions rather than deleting them, so you can show what governed acquisitions in any earlier period. Confirm whether your organization sets policy at the organization, mission, or system level, because the evidence must match the level you chose.

Implementing procedures

Procedures turn the policy into steps that acquisition, development, and supplier teams follow, such as who reviews security requirements in a new contract or how a developer test plan is accepted. Assessors look for procedures that cover each area the policy names and that point to real owners and forms. A procedure that cites a retired tool or an absent role will fail an interview. Walk through two or three recent acquisitions or system changes and confirm the procedures describe what those teams actually did.

Distribution and acknowledgment record

This record shows that the policy and procedures reached the defined roles, such as acquisition staff, system owners, and development leads. Keep the distribution list, the publication date, and signed or electronically logged acknowledgments from each role. Assessors commonly sample individuals and ask them to describe where the current version lives. Missing acknowledgments for new hires or for staff who changed roles are a frequent gap, so tie acknowledgment to onboarding and role changes.

Designated official appointment

SA-1 expects a managing official for the policy. The appointment record names that person, states the authority and duties, and shows the date of appointment and any handover. Assessors check that the named official is still in post and that the appointment letter or role description matches what the official actually does. If the role changed hands, keep the prior appointment record so the review history stays continuous.

Review log with dated changes

The review log records each scheduled review and each event-driven review, with the date, the reviewer, the outcome, and the change made. Your organization sets the review frequency and the triggering events in its own policy, so the log must show that reviews happened on that cadence and after those events, such as a major acquisition or a change in applicable law. An empty review entry is evidence of a missed review, so record reviews that changed nothing too.

Organization-defined parameter record

SA-1 has organization-defined parameters that set the policy level, the managing official, the dissemination roles, and the review frequency and events. Record the value you chose for each parameter, the rationale, and the approval, then reference that record from the policy. Assessors compare the parameter values with what the policy and procedures actually say. A parameter that changed in the policy but not in the record, or the reverse, is a common finding.

What meeting SA-1 costs in money and effort

This table separates the cost components of meeting SA-1 into one-time and recurring work, shows what drives each one, and suggests how to contain it. Read it to decide where internal effort is needed and what to request in written quotes from advisers or vendors. No figures are given because none are supplied for this control.

Cost component	One-time or recurring	What drives it	How to keep it down
Writing the acquisition policy and procedures	One-time, then updated on review	Number of acquisition paths (commercial, open source, cloud, outsourced development), how many business units own acquisitions, and whether existing procurement policies can be extended	Reuse existing procurement and SDLC documents, scope the policy to the systems in the authorization boundary, and keep procedures short enough to be followed
Parameter decisions	One-time, revisited at each review	SA-1 has organization-defined parameters that set the policy owner, dissemination roles and review frequency. Decisions made by senior staff take time to agree and document	Agree the parameter values in a single workshop, record the rationale once, and reuse the same values across SA-family policies
Dissemination and acknowledgment	Recurring with staff and supplier changes	Headcount of acquisition, engineering and procurement staff, turnover, number of external developers who need the procedures, and how acknowledgments are collected	Publish procedures in one controlled location, link them from onboarding and contract templates, and use the wiki or documentation system's access controls to limit who must sign
Annual or event-driven review	Recurring	Review frequency and triggering events defined in the policy, the rate of acquisition or regulatory change, and the number of approvers who must sign off	Tie reviews to an existing governance calendar, limit approvers to named roles, and record changes in version history so reviews stay short
Documentation tooling	Recurring license line, or none with self-hosted open source	Whether the organization already runs a wiki or document platform, licensing model, hosting, and the effort to administer access and version history	Ask whether a self-hosted wiki with version control and role-based permissions already exists. Confirm the feature set and hosting cost with the vendor or implementation partner in writing
Assessor time	Recurring at each assessment cycle	Number of determination statements the assessor examines and interviews on, how quickly evidence can be found, and whether prior assessment results are reusable	Prepare a dated evidence index, keep policy versions and approval records in one place, and brief interviewees on their roles before the assessment
Advisory or implementation support	One-time for readiness, optional recurring	Scope of the written engagement, whether an outside party drafts or only reviews the policy, and how many workshops and review rounds are included	Define deliverables and review rounds in the written scope, draft internally where staff have the knowledge, and request a fixed-scope quote before work starts

Who owns SA-1 and what an implementation partner can prepare

Your organization owns SA-1. The policy is an organizational statement of how acquisition, development and supplier controls in the SA family will be governed, so the decisions behind it cannot be delegated to a vendor. Your leadership must name the designated official who manages the policy, decide the scope (organization, mission or business process, or system level), and approve each review and update. The procedures that follow from the policy also need owners who will run them day to day.

Scope and level: Decide whether the policy applies across the enterprise, to a mission or business process, or to a single system, and record that choice.
Designated official: Name a role, not only a person, who is accountable for the policy and its review cycle.
Review frequency and triggers: Set the review interval and the events that force an early review, such as a change in law or a significant incident.
Approval and dissemination: Record who approved each version and to which roles the policy was distributed.
Procedure owners: Assign operators for acquisition, developer oversight and supplier monitoring so the procedures are executed, not just written.

Before engaging any partner, confirm that the named official has authority over acquisition and development teams, because a policy that those teams do not recognize will not produce evidence.

Where SA-1 programs usually fall short

SA-1 is easy to write and hard to keep true. The gaps below tend to appear after the policy is approved, when ownership drifts, reviews slip and the documents stop matching how acquisition and development actually run. Each card names one gap and the check that closes it.

No named official owns the policy

SA-1 requires the policy to be managed by a designated official, yet many documents list only a department or a committee. When the owner is unnamed, nobody answers an assessor's question about who approves exceptions or who updates the policy after a staff change. Confirm one named role, the deputy who covers it, and where that appointment is recorded. Give the role authority over acquisition and development standards, not only the IT policy library.

Review dates that have lapsed

The policy defines a review frequency and events that trigger an update, such as a major system change or a new regulatory requirement. Programs often approve the document once and then miss the next review without noticing. Check the last review date against the frequency written in the policy, and confirm that a change to the SA family, including the Release 5.2.0 updates, was assessed for impact on your own text.

Procedures that differ from practice

A procedure that describes a security review gate which teams skip is worse than no procedure, because the gap is documented. Assessors interview staff and compare what they say with the written steps. Walk through a recent acquisition or a recent release with the people who did the work, then mark every step that was skipped, merged or done by a different role. Update either the procedure or the practice, and record why.

Organization-defined parameters left blank

SA-1 leaves several values to the organization, including the review frequency, the events that trigger review and the roles that receive the policy. Templates often ship with brackets or placeholder text that nobody replaced. Read the control's parameters one by one, record a concrete value for each, and check that the values match the policy's stated review cycle. An assessor treats an undefined parameter as an undocumented decision.

Policies stored without version history

When the policy lives in a shared folder as a set of files named final_v3 or revised_new, it is hard to show which version was in force on a given date. Keep each policy and procedure in a wiki or document system that records changes, authors and dates, and that can compare versions and restore an earlier one. Confirm that approval records are kept alongside the versions, so that the approved text at any past date can be produced on request.

Policy covers IT but not suppliers

Many SA-1 documents describe internal projects and ignore the vendors, cloud providers and contract developers that build or run the system. The acquisition policy should reach contract language, supplier security assessments, developer configuration management and unsupported components, all of which sit in the SA family. Map each SA control to the policy section that governs it, and flag any control that no section covers.

Questions buyers ask about SA-1 policy and procedures

How much effort does SA-1 policy and procedures take?

The effort depends mostly on whether your organization already has an acquisition or system development policy that can be adapted. SA-1 asks for a documented system and services acquisition policy, implementing procedures, named roles, a designated official, and a defined review cycle with defined triggers for updates. If a policy exists, the work is usually review, alignment with the other SA controls, and approval. If nothing exists, the work includes deciding the scope (organization, mission or business process, or system level), defining the nine organization-defined parameters that the Release 5.2.0 catalog attaches to SA-1, and getting leadership sign-off. Ask any provider to break the effort into drafting, review, approval and dissemination so you can see where your own staff time goes.

Can a small team write the SA-1 policy alone?

A small team can usually draft the policy and procedures itself, provided one person understands the systems in scope and another has authority to approve them. The control is primarily a governance document, so the harder part is not the wording but agreeing who owns acquisition decisions, who signs off on developer and supplier requirements, and how the policy connects to the SA-3, SA-4 and SA-9 processes it governs. Small teams often struggle with the review frequency and event triggers, because those must be defined and then actually followed. A useful test is whether the team can show a past review or a dated change record within the defined cycle.

How long does a first version of the SA-1 policy take?

There is no fixed duration that applies to every organization, and no figure in this page should be read as a benchmark. The timing depends on the size of the organization, the number of systems the policy must cover, how many approval layers exist, and how much of the material is already written. An organization with a mature procurement and development policy may need a short adaptation cycle, while one without written standards will spend more time on scope and stakeholder agreement than on drafting. Ask any provider for a written schedule tied to a defined scope, and confirm which reviews and approvals are included in that schedule.

What does the work need from our team?

The work needs time from people who can make decisions, not only people who can write. You will need a named designated official, owners for acquisition, system development and supplier management, and a reviewer from risk or compliance who can check the policy against the assessment procedures in SP 800-53A. Engineering leads should confirm that the procedures describe how work actually happens, because a policy that differs from practice creates findings. Plan for at least one workshop to agree scope and parameter values, and one approval cycle with senior leadership. Keep the record of who approved each version, since an assessor will ask for it.

Which evidence shows that SA-1 is in place?

Assessors look for a signed or approved policy, procedures that implement it, evidence that both were disseminated to the defined roles, and records showing reviews at the defined frequency and after defined events. SP 800-53A uses examine and interview methods for SA-1, so the assessor will read the documents and ask the people named in them what they do. Good evidence includes version history with dates and approvers, distribution records, meeting minutes from reviews, and change logs showing updates after events such as a major system change. Wiki platforms with version control, such as XWiki, can keep that history in one place, and BookStack role settings can show who may edit or approve each page.

Is an outside partner worth bringing in for SA-1?

An outside partner is most useful when the policy must align with several frameworks, when internal staff lack time, or when the organization needs a second view on whether the procedures are testable. DeployOpen prepares systems, controls and evidence for compliance assessments under a fixed scope agreed in writing before work starts, but it does not write the organization's risk decisions and does not issue audit reports or certifications. An independent assessor will test the policy later, so the organization should own its content. When comparing providers, ask what is delivered, who approves it, what is excluded, and how changes after an assessment are handled. A written quote follows from the scope you define.

Can open-source tools reduce the work of maintaining SA-1 documents?

Open-source tools can keep documents current and make review history easy to show, but they do not decide what the policy should say. A self-hosted wiki or documentation platform inside your own infrastructure can hold the policy, its procedures and their approval records, while role-based permissions limit who can change them. A compliance platform such as CISO Assistant can track control mappings and assessment status for many frameworks, but you should confirm that its framework content and mapping options match the SP 800-53 Release 5.2.0 control text you use before relying on it. Keep the tool choice secondary to the review and approval process.

Using self-hosted documentation tools to keep SA-1 evidence

The most useful thing a self-hosted documentation tool can do for SA-1 is keep a provable record of who approved the system and services acquisition policy, what changed, and when. SA-1 expects a documented policy and procedures that are disseminated, reviewed and updated, so an assessor will ask for the current version, the previous versions and the trail between them. XWiki keeps version history for every change to a page, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one, which gives the reader a direct way to show the approved text at a given review date. Confirm with your own administrators that page history is retained for the full period your review cycle requires, since retention depends on how the instance is configured and backed up.

*BookStack* handles the other half of the evidence: who can edit and who can only read. User abilities come from the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. For SA-1, this lets you keep the acquisition policy in a restricted book that only the designated policy owner can edit, while the SA-related procedures sit in a book that engineering and procurement can read. Document the role matrix as part of the policy itself, and check it at each review, because an override set years ago on one page is easy to forget.

How DeployOpen scopes and prepares SA-1 for your assessment

DeployOpen works on SA-1 as a set of documents, owners and review records that your organization approves and runs. We prepare the policy and procedure package, the systems that hold it and the evidence an independent assessor will ask for, while your organization keeps ownership of the control.

How we scope

Confirm which systems, business processes and acquisition functions the SA-1 policy must cover, at organization, mission or system level.
Identify the designated official, the defined roles that receive the policy and the review frequency your organization has set for SA-1.
Agree in writing which SA family controls the policy governs, including SA-3, SA-4, SA-9 and SA-22, before work starts.

How we build

Draft or revise the SA-1 policy and implementing procedures against the organization-defined parameters for the baseline in scope.
Set up a documented wiki or knowledge base with version history so every policy change records what changed, when and by whom.
Configure role-based access in the documentation platform so only the defined roles can approve, edit and disseminate the SA-1 documents.

How we hand over

Deliver the approved policy, procedures, review log and distribution record in a format your assessor can examine.
Provide a mapping from each SA-1 determination statement in SP 800-53A to the document or record that addresses it.
Walk your designated official and compliance team through how to run the next review cycle without DeployOpen involved.

How we support

Offer ongoing support, upgrades and documentation maintenance as a retainer if your organization wants help with periodic SA-1 reviews.
Update the policy and procedures when the organization-defined review events occur, such as significant system changes or new acquisition rules.
Confirm with your assessor and your own environment which evidence they accept, since the independent assessor, not DeployOpen, decides sufficiency.