SA-20 customized development: requirements and evidence

What SA-20 customized development of critical components asks for

SA-20 requires an organization to reimplement or custom develop defined critical system components instead of relying on readily available versions. It is one of the few SA family controls that sits outside every SP 800-53B baseline, so it applies only when an organization selects it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 treats it as an organization-implemented, assurance-related control. The control exists for the case where an off-the-shelf component cannot be made trustworthy enough by other controls, usually because its behavior cannot be verified, its source cannot be inspected, or its vendor cannot be held to the assurance you need.

In Release 5.2.0, SA-20 has one organization-defined parameter and no control enhancements. That parameter is where the organization names the components in scope, so the decision is made in writing before any engineering starts. The related controls in the catalog are CP-2, RA-9 and SA-8, which point to contingency planning, criticality analysis and security engineering principles. An assessor will expect the criticality analysis that justifies the list to exist and to match what was actually selected, so confirm that RA-9 and the SA-20 parameter tell the same story before the assessment.

The hard part is not the wording of the control but the two judgments it forces. First, the organization must define what counts as critical, which means tying components to mission or essential functions and to the impact of their compromise, not to how interesting the code is. Second, it must show that a custom build is more trustworthy than the alternative. That comparison is easy to assert and hard to evidence, because a home-built component carries its own defects and maintenance obligations. Plan for design documentation, configuration management records and testing evidence for the custom component, and ask the independent assessor early how they expect that comparison to be documented.

Which components and teams SA-20 reaches

SA-20 reaches only the components an organization decides are critical, and only when it selects the control through tailoring or an overlay. The cards below cover the scoping decisions that bring it in, the teams that share the work, and the third-party components most likely to be replaced.

Defining the critical component list

SA-20 has one organization-defined parameter, so the organization must name the system components that get custom development instead of readily available versions. Start from the mission or business functions the system supports and list the components whose failure or compromise would defeat those functions. Ask the assessor to see the written definition and the reasoning behind each entry, because a list with no rationale is hard to defend in an examination.

High-impact and mission-essential environments

Systems in high-impact or mission-essential environments are the usual reason SA-20 is selected. SP 800-53B does not assign SA-20 to any baseline, so an organization reaches it by deciding its risk warrants the control. Confirm with the risk owner whether the system's impact level, mission role or threat model justifies custom development, and record that decision in the system security plan.

Tailoring and overlays that bring SA-20 in

SA-20 enters a system's control set only when the baseline is tailored or an overlay adds it. SP 800-53B describes the tailoring process and overlay approach. Whoever owns the baseline selection should document the addition, and the security plan should show why each component was included. Confirm whether any overlay your authorizing body uses already references SA-20.

FedRAMP Rev5 does not require SA-20

FedRAMP's Rev5 baselines do not require SA-20 at Class B, C or D. Cloud providers pursuing those classes do not need it by default, but a provider may still choose it for specific components. Check the current FedRAMP control reference for the class in scope and confirm with the authorizing official whether any additional requirement applies to your environment.

Architecture and development ownership

Architecture decides which components are critical and how custom replacements fit the enterprise design. Development builds, tests and maintains the custom code, and its SDLC and configuration records become the examine evidence. Agree in writing who approves each component's custom build, who owns its backlog and who signs off on design documentation before work starts.

Security, procurement and third-party components

Security reviews the replacement design and its configuration settings, while procurement identifies which vendor-supplied components are candidates for replacement and what contract terms apply to exiting them. Third-party components most often in scope include proprietary libraries, closed-source authentication services and commercial middleware that cannot be patched on the organization's schedule. Ask each vendor for its support and end-of-life dates before deciding.

How to implement SA-20 in six steps

This sequence turns SA-20 from a parameter left blank into a documented decision set: which components are critical, why each one was custom built or kept, how that work runs through the SDLC, and how the decisions stay current. The organization owns each output, and an independent assessor tests it.

Name the critical component classes
Start by filling in the organization-defined parameter for SA-20, which asks you to name the system components that are critical enough to be considered for custom development. Security architecture, system owners and mission or business owners should agree on the list, using the system categorization and any criticality analysis already done under the RA family. Write each class at a level that a reviewer can match to real assets, such as an authentication broker, a payment message parser or a telemetry collector, not as a general statement about the whole estate. The output is a signed list of component classes with named owners. You know the step is done when every class maps to at least one inventoried component and a single accountable owner.
Assess each candidate against available controls
For every named class, document whether existing products, open-source projects or vendor-supported components can be made trustworthy enough through the controls you already run. Evaluate each candidate against its configuration options, its vendor or community security history, available patches, SBOM visibility, and the controls in the SA, SI and CM families that would apply to it. The assessment should be written as a short analysis per component, not a yes or no. The output is a candidate assessment record with the controls considered and the residual risk for each option. The step is complete when the assessment shows why the reasonable alternatives fell short, or confirms that none is needed.
Record the custom build decision and rationale
For each component where the assessment finds no viable path to trustworthiness, record a formal decision that names the component, the controls and products considered, the reason they were insufficient, and the risk owner who accepted the decision. Keep the decision separate from the implementation plan so that an assessor can see the reasoning without reading the design. Where a component is not custom built, record that decision too, since SA-20 assessments check that the organization made a conscious choice. The output is a decision register entry for each component. The step is done when every class from step one has either a custom build decision or a documented decision not to build, approved by the risk owner.
Define the custom development process in the SDLC
Bring each custom build into the system development life cycle documented under SA-3 and the secure development process under SA-15. The process should state who designs, writes, reviews and tests the code, which security requirements apply, how threat modeling is done, and how the component is released into production. Use the same SDLC roles, gates and tooling used for other software so that custom components are not handled as exceptions. The output is an SDLC addendum or procedure that names the custom component classes and their development steps. You know the step is done when a developer could follow the procedure from requirements to release without asking who approves the next gate.
Bring custom components under configuration management and design documentation
Put the source code, build pipelines, dependencies and design documents for each custom component under configuration management. Protected branches in GitLab Community Edition can restrict who can push or merge, block direct pushes to the main branch, and keep force pushes disabled, which supports the developer configuration management expectations in SA-10 and the baseline and change controls in CM. Generate and store a software bill of materials for each build with Trivy, and load it into OWASP Dependency-Track to track known vulnerabilities and license use. Run Semgrep in the pipeline to scan the code for defects. Keep design documentation for each component current with its release. The output is a repository, pipeline and SBOM record per component. The step is done when a sample build can be traced from a commit to an SBOM and a documented design.
Set up periodic review of the decisions
A custom build decision is only valid while its assumptions hold, so schedule a review of each decision and the components it covers. The review should check whether the critical component classes have changed, whether an off-the-shelf product has matured enough to replace the custom component, whether the vulnerability and license findings in Dependency-Track are being resolved, and whether the design documentation still matches the release. Set the review frequency in the SA-1 policy and record each review's findings. The output is a review log with dated entries, owners and any resulting decisions to retire, keep or rebuild. The step is complete when the first review is scheduled, has a documented owner and a template for its findings. Ask your assessor which review cadence they expect for your risk level.

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

This table maps the single SA-20 determination statement in SP 800-53A Release 5.2.0 to the examine, interview and test methods an assessor uses, the objects each method touches and the evidence to prepare. Read it as a preparation checklist: each row names what the assessor will ask to see and where organizations commonly fall short.

Assessment method	Objects the assessor examines or questions	Evidence to prepare	Common finding
Examine	System development life cycle documentation that addresses custom development of critical system components	Written SDLC procedure section stating when a critical component is reimplemented or custom built and who approves it	SDLC text is generic and never mentions custom development of critical components
Examine	Configuration management records for the custom component	Version-controlled change history, baseline records and approval trail for the custom build	Custom code is tracked as ordinary changes with no link to the critical component decision
Examine	System design documentation	Design record explaining why the component is custom built and how its security properties are established	No documented rationale for choosing custom development over a supported product
Examine	System configuration settings and associated documentation	Configuration exports and settings documents for the custom component, tied to the defined critical components	Settings for the custom component are not documented or cannot be reproduced from records
Interview	Personnel responsible for the SDLC, system design and component ownership	Named owners and a short walkthrough of how critical components are identified and built	Staff disagree on which components count as critical or who decides
Test	The custom component as built and deployed in the system	Test results or demonstration showing the component operates as the design and configuration records describe	No evidence the deployed build matches the documented design
Determination	Organization-defined parameter that names the critical system components	A defined and approved list of critical components within the system boundary	The parameter is left undefined, so the assessor cannot test scope

Which evidence passes an SA-20 assessment

An assessor testing SA-20 looks for a paper trail that connects a defined list of critical components to the decision to custom build or reimplement them. The cards below cover the artifacts that tie that chain together, and each one needs a regular refresh so it still matches the system when the assessor arrives.

SDLC section on custom development

This is the procedure in your system development life cycle documentation that says when a critical component is reimplemented or custom built instead of adopted as-is. It should name the trigger, the reviewers and the approval record. Check that it covers the SA-3 life cycle phases where the decision is made, and that the wording matches what teams actually do. Review it whenever the SDLC changes, and at least on your normal policy review cycle.

Critical component list with the parameter value

SA-20 has one organization-defined parameter, so you must define which system components count as critical. The list should name each component, its owner, the function it supports and the reason it is critical. An assessor will compare this list against the system inventory, so keep the two synchronized. Update it after architecture changes, new services or a changed risk assessment.

Documented build-or-reuse decisions

For each critical component, record whether the organization reuses an existing product or reimplements it, and why. The record should show the alternatives considered, the trust gaps that drove the decision and the approver. Tie each entry to the risk assessment (RA-9 is a related control). Refresh decisions when a component's upstream support, licensing or threat picture changes, not only at audit time.

Design documents showing custom components

System design documentation should show where custom components sit in the architecture, what security functions they perform and how they interact with the rest of the system. Assessors use it to confirm that the custom components in the list are the ones described in the design. Keep diagrams and interface descriptions in version control next to the code they describe, and update them when the design changes.

Configuration management records for those components

Configuration management records show how custom components are baselined, changed and approved. For self-hosted open-source platforms, this usually means protected branches, required reviews and change tickets linked to commits. Protected branches in GitLab can block direct pushes and keep force pushes disabled, which gives you a reviewable history. Confirm that the records cover the custom components specifically, not only the repository in general.

Configuration settings and their documentation

Keep the configuration settings of each custom component, along with the documentation that explains each setting and its security purpose. Assessors examine these settings to confirm they match the approved baseline. Export configuration as code where possible so the state is reproducible, and record drift findings. Re-verify settings after each release and after any change to the deployment environment.

What meeting SA-20 costs in money and effort

This table breaks down the cost components of meeting SA-20 Customized development of critical components, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices are stated because no researched figure is available, so use the drivers to shape a written scope and quote.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Engineering time to reimplement or custom build the critical component	Internal developers or an implementation partner under a fixed-scope agreement	One-time for the build, recurring for maintenance and upgrades	Number of defined critical components, language and maturity of the custom code, and how much existing code can be reused
Design and security review	Internal architects, security engineers or an external reviewer	One-time per design, repeated when the design changes	Size of the component's attack surface and whether SA-17 or SA-11 review practices already exist
Configuration management and repository tooling	Platform team; open-source tools such as GitLab Community Edition carry no license fee	Recurring for hosting, administration and access reviews	Number of repositories, branch protection rules to configure, and whether the platform is already self-hosted
Dependency, SBOM and static analysis tooling	Platform team; Dependency-Track, Trivy and Semgrep Community Edition are open source, so license spend is removed	Recurring for running scans, triaging findings and keeping rules current	Number of languages in the custom code, scan frequency, and volume of third-party components pulled in
Evidence upkeep	Compliance or security staff, with engineering support	Recurring for each assessment cycle and each significant design change	How well SDLC records, design documents and configuration records are kept during development rather than reconstructed later
External review or penetration testing	Independent testing firm or assessor, paid by the organization	Usually one-time per release of the critical component, plus periodic retests	Complexity of the component, depth of testing scope, and whether testing is already part of SA-11 activity
Auditor or assessor sampling	Independent assessor, paid by the organization	Recurring at each assessment	Number of custom components in scope, quality of traceability from requirements to design to tests, and assessor familiarity with the system
Ongoing maintenance of custom code	Internal engineering team or a retained support partner	Recurring for the life of the component	Ownership model, upgrade cadence, and how many people understand the custom code

Which open-source tools produce SA-20 evidence

SA-20 is judged on whether custom-built critical components are developed under controlled processes, with recorded changes, tested code and known component inventories. The four tools below cover the repository controls, code scanning and software bill of materials (SBOM) work that produce that evidence. None of them decides whether a component is critical or whether custom development is the right answer; those decisions stay with the organization and its assessor.

Protected branches in GitLab

GitLab Community Edition (MIT) supports protected branches that restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. For SA-20, the export of these branch settings and the merge history show who could change a custom critical component and how changes were approved. Confirm that the Community Edition feature set covers your approval rules, since some review controls may sit in higher tiers. Use branch protection exports as dated evidence rather than screenshots taken during an assessment.

Custom code scanning with Semgrep

Semgrep Community Edition (LGPL-2.1-only) scans code in languages including C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform, using community or custom rules. Run it in CI/CD so every commit to a custom critical component is scanned. The scan logs and rule configuration support SA-20 because they show the custom code was checked against defined criteria before release. Check that your languages are covered and that your custom rules reflect the threats relevant to the component.

Component tracking in Dependency-Track

OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components, and tracks license risk using SPDX license IDs. For a custom critical component, it shows which third-party libraries it actually contains, which were modified, and which carry license obligations that affect reuse. Confirm the license caveat with your counsel: a dependency's license terms apply to your custom build, and Dependency-Track reports license data without giving legal advice.

SBOM generation and scanning with Trivy

Trivy (Apache-2.0) identifies the OS packages and software dependencies in a target, can produce them as an SBOM, and can scan existing SBOMs. In SA-20 work, it generates the inventory of what a rebuilt component is made from, and the SBOM it outputs can feed Dependency-Track. Keep each SBOM tied to a specific build so the evidence matches the released version. Confirm that Trivy's detection covers your package managers and base images, because an incomplete inventory weakens the custom development record.

Who owns SA-20, who can help, and what the auditor does

Your organization owns SA-20 in full. The decision to custom build a critical component, the choice of which components qualify as critical, and the accountability for the result all sit with your leadership and system owners. SA-20 is an organization-defined control, so you must define which components are critical enough to justify reimplementation and document why existing products could not be made trustworthy enough. No partner can make that call for you.

Deciding what is critical: Name the components in scope and record the reasoning, usually in the system security and privacy plan or a linked design decision.
Owning the build decision: Record why commercial or open-source alternatives were rejected, and who approved the custom build.
Staffing the work: Assign internal engineers or accountable product owners who can answer for design choices after the build is finished.
Keeping the control current: Revisit the decision when the component changes, when a replacement product becomes viable, or when the system boundary moves.
Governing the outcome: Track the custom component through your change management and vulnerability processes like any other production system.

Check that the critical component list, the decision record and the named owner exist in writing before any outside party starts work.

Questions buyers ask about SA-20

Does SA-20 apply without an overlay or tailoring decision?

No. SP 800-53B does not assign SA-20 to the low, moderate, high or privacy baseline, so it applies only when your organization selects it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the organization, which means the decision and the evidence sit with you, not with a vendor. FedRAMP's Rev5 baselines also do not require SA-20 at Class B, C or D. Confirm your baseline and any overlay your contract or authorizing body applies before treating SA-20 as in scope.

How much effort does a custom build decision add to a program?

The effort depends on how many components you select and how far from readily available versions you must go. SA-20 has one organization-defined parameter and no enhancements, so the control itself is compact, but the decision behind it is not. Expect work in three areas: a documented justification for why no viable control set can make an existing component trustworthy enough, the engineering to build or re-implement the component, and the records that show it. Ask any partner to break the quote into scoping, build, testing and evidence so you can see which part drives the cost.

How long does preparation take, and what drives the duration?

No public source supplied here gives a duration for SA-20 preparation, so treat any timeline as a claim to verify. The main drivers are the number of critical components in scope, whether source code, build pipelines and design documents already exist, how mature your configuration management is, and whether the component must pass through an external assessor. A fixed-scope engagement agrees deliverables and dates in writing before work starts, which lets you compare proposals on the same basis.

What does the work need from our internal team?

Internal staff must own the decisions that a partner cannot make for you: which components are critical, what mission function they support, and whether custom development is justified. Engineering leads must approve the design, and the security team must review the risk rationale. Configuration management and development teams must keep design documentation, configuration records and development life cycle documentation current, because those are the examine objects an assessor uses for this control. Ask the partner which artifacts they expect you to supply and which they will produce.

Can an implementation partner handle SA-20 alone?

A partner can design, build, document and test the custom component, and prepare the evidence package. It cannot accept the risk on your behalf or issue an assessment result. The organization owns the control, and only an independent assessor or certification body can issue findings or reports. Where an external assessor is involved, agree the evidence format with them early. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications.

Can a self-hosted open-source toolchain produce the SA-20 evidence?

A self-hosted toolchain can produce much of the supporting evidence, though it will not replace the risk decision or the design documentation. GitLab Community Edition protected branches can restrict who pushes or merges and keep force pushes disabled, which supports configuration management records. Semgrep Community Edition can scan code in many languages in CI/CD pipelines. OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX and tracks license use, and Trivy can generate SBOMs. Confirm with each tool's documentation which languages and outputs fit your components before you rely on them.

What should we ask for in a quote for SA-20 work?

Ask for a written scope that names the components in scope, the justification method for choosing custom development, the build and test activities, and the evidence deliverables mapped to the examine objects in SP 800-53A. Request the assumptions behind effort and schedule, the roles that will be paid for each activity, and what remains with your team. Also ask what recurs after delivery, such as SBOM updates, dependency monitoring, and re-review when a component changes. Fixed-scope proposals make these items comparable across bidders.

How DeployOpen prepares SA-20 evidence

DeployOpen works on SA-20 as a fixed-scope implementation engagement inside the client's own infrastructure. The organization decides which components are critical and owns the control; DeployOpen helps prepare the development records, configuration evidence and documentation an independent assessor would examine.

How we scope

Written scope names which critical components are candidates for custom development and why off-the-shelf versions were rejected.
Scope records the organization-defined parameter for SA-20 so the selected components are explicit and testable.
Scope lists the SDLC documentation, configuration records and design documents that will be produced as evidence.

How we build

Custom components are developed in self-hosted GitLab repositories with protected branches restricting who can push or merge.
Semgrep runs in the CI pipeline to scan custom code against community or custom rules in the languages the project uses.
Dependency-Track and Trivy track SBOM contents, known vulnerabilities and license risk for every custom component's dependencies.

How we hand over

Handover includes design documentation, configuration management records and the SDLC documentation covering each custom component.
Evidence is organized against the SA-20 examine objects so the organization's assessor can trace each artifact to the control.
Written runbooks explain how the organization maintains custom components after handover, including who approves changes.

How we support

Ongoing support, upgrades and continuous testing of custom components are available as a retainer.
Retainer reviews keep dependency findings, pipeline configuration and component documentation current as the system changes.
Confirm with your assessor which evidence formats they accept before the engagement starts, since the final determination rests with them.

SA-20 Customized development of critical components