What NIST 800-53 secure software development requires and who pays for it
When a customer, contract or FedRAMP path requires SA-11 and SA-15 evidence for software your organization builds, the controls remain yours to own. Cost and timeline depend on the scope of the systems and software in question and on how mature your development evidence already is, and NIST does not estimate compliance costs or set implementation timelines. Those figures must come from your own scoping, your assessor and a written quote from any implementation partner. Only an independent assessor issues the assessment report, and no partner or tool can do that on your behalf.
SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) are base controls in the System and Services Acquisition family of SP 800-53 Rev. 5. Release 5.2.0 added SA-15(13) Logging Syntax, which sets clearer logging requirements for developers, and added SA-24, a new control on cyber resiliency by design. SA-24 is not assigned to any SP 800-53B baseline, so it applies only if you select it through tailoring or an overlay. Confirm with your authorizing official or contract owner whether they expect it, because a baseline-only reading will not surface it.
Expect the main costs to be internal labor for process documentation, developer time for security testing and remediation, and assessor fees for testing the evidence. Implementation partners can be paid to build pipelines, test tooling and evidence collection under a fixed scope, while ongoing testing and upgrades are usually recurring retainers. Ask any quote to separate one-time setup from recurring work, to state which SA-11 testing frequency, depth and coverage it assumes, and to list the evidence it will produce. The NIST SP 800-53 Rev. 5 publication page is the natural next read for the control text.
What Release 5.2.0 changed for software development controls
Release 5.2.0 added SA-15(13) Logging Syntax as an enhancement to the Development Process, Standards, and Tools control. Its purpose is to set clearer logging requirements for the developer, so that the logs a development process produces can be read and handled consistently. The enhancement sits under SA-15, which already requires a documented development process and control over the tools it uses. NIST did not assign SA-15(13) to any SP 800-53B baseline, so a system at low, moderate or high impact does not inherit it automatically.
- What it adds: a specific expectation on how developers define the syntax of logs they produce, extending the general tooling and process requirements already in SA-15.
- Baseline status: not selected by the low, moderate, high or privacy baselines in SP 800-53B Release 5.2.0.
- When to select it: when a tailored baseline, agency requirement or overlay needs consistent developer log formats, for example to feed security monitoring or audit records under AU-2 and AU-12.
- Who owns it: the developer or development team, with the organization responsible for defining and documenting the requirement.
- What to confirm: whether your authorizing body or contract requires SA-15(13) by name, and how the logging syntax you define will be checked during developer testing.
Before you commit to this enhancement, confirm with your authorizing official or contracting officer whether it is in scope for your system and document the decision in your tailoring record.
SA-24 is a new control in Release 5.2.0, added in the final release after stakeholder feedback to address cyber resiliency by design. It asks organizations to build resiliency considerations into the system from the start rather than treating them as an afterthought. Appendix C of SP 800-53 Rev. 5 lists SA-24 as implemented by the organization (O) and marks it as an assurance-related control. SP 800-53B does not assign SA-24 to any security or privacy baseline, so it applies only when an organization selects it through tailoring or an overlay.
- What it adds: a new control dedicated to cyber resiliency by design, separate from the testing and process requirements in SA-11 and SA-15.
- Baseline status: not assigned to the low, moderate, high or privacy baselines.
- Implementation type: organization-implemented (O) and assurance-related, so the evidence must show the organization's own design decisions rather than only developer output.
- When to select it: when a mission, contract or overlay calls for resiliency to be designed in, such as systems that must keep operating under sustained attack or degraded conditions.
- What to confirm: how your organization will demonstrate the control at assessment, since assessors will look for documented design choices and their traceability to requirements.
Because the control is assurance-related, treat it as a question for your assessment plan as well as your build process. Confirm with your assessor how SA-24 will be tested under SP 800-53A before you select it.
Release 5.2.0 also updated SA-15 beyond the new enhancement and revised SI-7(12), which sits in the integrity family. NIST listed updates to SI-2(7) and to several discussions, and it updated related controls including AU-2, AU-3, CA-7, IR-4, IR-6, IR-8, SA-15, SI-2 and SI-7. The release was issued in response to Executive Order 14306 and focused on software update and patch security. Read these changes as one package: they tie development process requirements to how patches and updates reach production.
- SA-15: updated discussion text and the new enhancement (13), which changes what a development process must define for logging.
- SI-2(7): added in this release, linked to flaw remediation and the patch lifecycle covered in SI-2.
- SI-7(12): revised, which affects integrity verification for software and firmware updates.
- Baseline status: NIST summarized these as release changes. Check the SP 800-53B Release 5.2.0 profiles for the current baseline selection of each item before you assume its status.
- What to confirm: whether your development process already produces the evidence that the revised discussions expect, and whether your patch and integrity records line up with SA-15 and SI-2.
NIST published a summary of changes that lists each update. Use it to build a crosswalk from your current control evidence to the revised text.
Which FedRAMP classes require SA-11 and SA-15 enhancements
FedRAMP sets its own control selections for each impact class, so the SA-11 and SA-15 enhancements a cloud service must meet depend on the class it is authorized under. The cards below group the classes and the new Release 5.2.0 items, and show where each scoping question is answered. Confirm the exact enhancement list in the 2026 rules before you scope any development work.
Low impact class requirements
Low impact authorizations carry the lightest set of developer testing and development process expectations. Check the Low column of the FedRAMP Rev5 control reference for SA-11 and SA-15, and do not assume the Low selection matches the SP 800-53B low baseline. Record which enhancements the 2026 rules place at Low, and keep the developer's testing evidence and process documents ready for the assessor's sampling, even when the enhancement count is small.
Moderate impact class requirements
Moderate is the class most cloud services are authorized under, so its SA-15 development process and tooling expectations usually drive the scoping work. Map each Moderate SA-15 item to the documented development process, the approved tool list and the periodic review record. Confirm each enhancement in the rules repository, because FedRAMP can select enhancements that the SP 800-53B moderate baseline does not list, and the two sources can differ.
High impact class requirements
High impact authorizations add the most developer testing depth to SA-11, including the frequency, depth and coverage of testing and a verifiable flaw remediation trail. Check whether each SA-11 enhancement in the Rev5 reference applies to High, then plan recurring test runs, coverage reports and remediation tickets that can be sampled. Ask your assessor which artifacts they expect for each enhancement before the test cycle starts.
SA-15(13) logging syntax by class
SA-15(13) Logging Syntax is new in SP 800-53 Release 5.2.0 and sets clearer logging requirements for developers. NIST did not assign it to any SP 800-53B baseline, so its presence in a FedRAMP class is a decision made in the 2026 rules, not a given. Check each class in the rules repository, and if the enhancement applies, define a logging format for developer tooling and confirm that build and test logs follow it.
SA-24 cyber resiliency by design
SA-24 is also new in Release 5.2.0, added to address cyber resiliency by design after stakeholder feedback. It sits outside every SP 800-53B baseline and applies only when an organization or a FedRAMP class selects it. Confirm whether the 2026 rules select SA-24 for your class before you write it into the development process. If it is selected, document how design reviews consider resiliency and how the developer evidences those reviews.
Scoping against the 2026 rules
The Rev5 control reference shows the control text by class, and the rules repository provides the machine-readable selections that tooling can read. Use the two together, starting with the SA-11 and SA-15 rows for your class, then recording the decision for every enhancement, including those not selected. Ask the cloud provider and the assessor to confirm the same list, since a mismatch found late usually means rework across the development pipeline.
What secure development evidence costs and who gets paid
This table compares the cost components behind SA-11 and SA-15 evidence, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to structure a request for a written scope and quote, and to separate work your engineers must absorb from work you may outsource. No fee amounts are given here because none are published for this work.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Internal engineering time for developer testing (SA-11) | Your own staff, through salaries or contractors you already employ | Recurring, at each test cycle | Test frequency, depth and coverage you define, and the number of releases |
| Internal engineering time for process documentation and tool control (SA-15) | Your own staff | One-time to write, recurring to review | Number of teams, toolchains and standards in scope |
| Tooling licenses | Commercial tool vendors | Recurring, usually annual or per seat | Number of seats, scanned repositories and pipeline volume |
| Self-hosted open-source tooling | No license fee, but your staff or a partner runs and maintains it | One-time setup, recurring maintenance | Hosting, upgrades, rule tuning and who triages findings |
| Implementation partner fees for evidence work | A partner such as DeployOpen, under a fixed-scope written agreement | One-time for pipeline setup and evidence design | Number of systems, existing pipeline maturity and documentation gaps |
| Ongoing testing or review retainer | A partner or testing firm, under a retainer | Recurring | Release cadence, testing scope and the periodic review frequency you choose |
| Independent assessor fees | The independent assessor or certifying body, not the partner | Recurring at each assessment cycle | System boundary, assessment depth and the assessor's own fee basis |
What makes secure development evidence cost more or take longer
The cost of producing SA-11 and SA-15 evidence follows the size and shape of the development estate, not the control text itself. The drivers below are the ones a buyer can measure before asking for a quote, and each one has a lever the organization controls.
In-scope applications and repositories
Every application, service and repository that contributes code to the system falls under the developer testing and development process requirements. Count them first, then separate those that ship to production from internal tooling. Each in-scope repository needs its own test results, flaw tracking and review trail, so the evidence workload scales roughly with that count. Ask whether shared libraries and infrastructure code are counted as in scope.
Pipeline maturity
A pipeline that already runs builds, tests and security scans automatically produces evidence as a by-product. A pipeline that relies on manual steps, unrecorded approvals or ad hoc scripts needs redesign before any assessor can trace a change from request to release. Check whether test runs, approvals and deployments are logged centrally and whether those logs can be exported without manual reconstruction.
Tools to configure and document
SA-15 requires the organization to identify, configure and control the standards and tools its developers use, so each scanner, linter, build system and code host becomes a documented component. Every tool needs a recorded configuration, an owner, a version history and a periodic review. Tool count drives both the initial documentation effort and the recurring review effort, so consolidating tools is often the cheapest lever.
Testing frequency and depth
SA-11 asks the developer to test at a defined frequency, depth and coverage, and those three parameters are set by the organization, not by NIST. Frequent deep testing of every repository on every commit costs more compute and analyst time than periodic testing of higher-risk components. Agree the parameters in writing before work starts, because an assessor will test the organization against the values it defined.
Remediation backlog
SA-11 expects flaws to be fixed through a verifiable remediation process, so every finding needs a record from detection to closure. An inherited backlog of open findings from older scans can take more effort to triage, justify or close than new testing does. Ask for the count of open findings by age and severity, and whether accepted risks have documented approvals.
FedRAMP-bound systems
When the system is subject to FedRAMP, the SA-11 and SA-15 requirements that apply depend on the authorization class, and the FedRAMP rules and control references set those expectations. A FedRAMP-bound system usually needs more formal documentation, more independent assessment and a stricter evidence format than an internal system. Confirm the class and the applicable control set with the authorizing body before scoping the work.
How the path from scoping to assessor evidence runs
The sequence turns SA-11 and SA-15 from a set of expectations into a scoped, tested and documented development practice whose records an independent assessor can examine. Each step closes with an output that feeds the next, so gaps are found before the assessment rather than during it.
Scope the systems and developers in the boundary
The organization, with DeployOpen's help, lists every system in the authorization boundary that is built or changed in-house, plus the external developers and service providers whose work lands in it. For each one, the team records the development life cycle stages in use, the repositories, build pipelines and tools involved, and who owns each decision. The step is done when the owner of each system signs off on a scope statement that an assessor can trace against the system security and privacy plan. Timelines are set in the written scope.
Map existing SA-11 and SA-15 practice to the baseline
Compare current development practice against the SA-11 and SA-15 requirements in the baseline the system is assigned under SP 800-53B, and against the assessment procedures in SP 800-53A. The output is a gap register that records, for each requirement, what evidence exists today, where it lives, and which parts are undocumented or inconsistent across teams. Confirm with the assessing body which baseline and any tailoring apply, because SA-24 and SA-15(13) are not assigned to any baseline and only apply when selected.
Close process and tooling gaps
Fix the gaps in the register by changing the development process and the tools that enforce it. Typical work includes defining the security requirements the process must address, placing the standards and tools under configuration control with a documented change path, and adding automated security testing to pipelines where the gap register shows manual work. Where an organization wants self-hosted open-source tooling, DeployOpen installs, configures and hardens it inside the client's environment. The step is complete when each gap has a named owner and a change record.
Run and record developer security testing
Execute the security and privacy control assessments and developer testing that SA-11 requires, at the frequency, depth and coverage the organization defined in its plan. Each run should produce stored results tied to a build or release, and each flaw found should move through a tracked remediation process with a recorded fix and verification. The output is a test log and a remediation trail that show testing actually happened on a defined cycle, not only that tools were installed. Testing services are scoped and quoted separately from implementation.
Document the process and tool baseline
Write down the documented development process, the list of standards and tools with their configuration baselines, and the schedule for periodic review of both against the defined requirements. Record the first review and any changes it produced. The step is done when a reviewer who did not write the documents can follow them from a sample release back to the test results, the approved tool versions and the owner's review sign-off. This is the document set the assessor will read first.
Hand the evidence to the independent assessor
Assemble the scope statement, gap register, change records, test logs, remediation trail and process documentation into an evidence package, and give it to the independent assessor the organization has engaged. The assessor examines the evidence, interviews the people involved and decides whether each assessment objective is met. DeployOpen does not issue assessment results or attestations; the assessor does. The step closes when the assessor confirms receipt and lists any follow-up questions or findings the organization must address in its plan of action and milestones.
What must be in place before the assessor reviews developer testing
An assessor testing SA-11 and SA-15 looks for records that show the development process, tooling and testing were run as written, not just described. The five items below are the records that connect those controls, so each one should exist and be current before the assessment starts.
A written development process
SA-15 expects a documented development process that addresses security and privacy requirements, and the assessor will ask who wrote it, when it was last reviewed and whether the team follows it. Check that the document names security gates at design, build and release, and that a dated review record shows the process was examined against defined requirements. A process that exists only as a wiki page nobody opens will not satisfy the assessor.
A tool inventory with configuration baseline
SA-15 also requires the developer to identify and control the standards and tools used to build the system. Keep an inventory of compilers, scanners, CI runners, container base images and libraries, with the version and approved configuration for each. Check that a sample tool can be traced to its pinned version and to the change record that approved it.
A defined testing schedule with depth and coverage
SA-11 requires testing at a defined frequency, depth and coverage, so a schedule with no stated scope will fail. Document which test types run at each stage (static analysis, dependency scanning, dynamic testing, manual review), how often each runs and which components each covers. Check that the schedule matches what the pipeline logs actually show over the assessment period.
A flaw tracking and remediation record
SA-11 asks for evidence of results and a verifiable process for fixing flaws, which means every finding needs an owner, a severity, a due date and a closure reference. Check that a sample of closed findings links to a code change or a documented risk acceptance, and that open findings past their due date are visible to someone who can escalate them. A ticket marked closed with no linked fix is the most common gap.
A developer logging standard for SA-15(13)
Where the organization selects SA-15(13) Logging Syntax, added in Release 5.2.0 and not assigned to any SP 800-53B baseline, the developer needs a written logging standard that defines the syntax and fields for security-relevant events in the code it builds. Check that the standard names the required fields, that sample application logs conform to it, and that the logging requirement is included in the acceptance criteria for new features.
Who does what: your engineering team, a partner and the assessor
Your engineering and compliance leads own the developer testing program and the development process that SA-11 and SA-15 describe. Those duties sit with the people who write the code, approve changes and decide what counts as a flaw worth fixing. No partner can accept that accountability on your behalf, and the assessor will look for proof that your own staff run these activities day to day.
- Process ownership: Approve the documented development process, the security and privacy requirements it addresses, and the list of approved standards and tools.
- Testing cadence: Set the frequency, depth and coverage of security testing for each release path, and confirm that results are reviewed by someone accountable.
- Flaw remediation: Run the verifiable fix process, including ticket trails that link a finding to a change and to a retest.
- Tool governance: Identify, configure and control changes to pipeline scanners, linters and build tools, and schedule the periodic review of that tooling.
- Release 5.2.0 items: Decide how SA-15(13) logging expectations and any SA-24 resiliency choices apply to your systems, since neither is assigned to a baseline by default.
Before engaging anyone, confirm that your leads can name the owner of each duty and show where the resulting records are kept.
An implementation partner such as DeployOpen can plan, configure and document the systems and evidence that support SA-11 and SA-15. The partner prepares the environment, the pipeline and the paperwork. It does not decide the control design on your behalf, and it does not issue any assessment result, attestation or certification.
- Process documents: Draft the development process, tooling standard and review procedure for your review and approval, based on the written scope.
- Tooling setup: Install and configure self-hosted open-source scanners and pipeline stages inside your own infrastructure, including the configuration files that define what runs and where results go.
- Evidence capture: Design how test results, remediation tickets and tool change logs are stored so that an assessor can trace them.
- Training and handover: Show your staff how to operate the pipeline, read findings and maintain the tooling, so the program survives after the engagement.
- Gap identification: Report where current practice does not produce the evidence SA-11 or SA-15 calls for, and state what would close each gap.
Ask any partner to put scope, deliverables and the handover of ownership in writing before work starts, and confirm that it will not sign or certify any control on your behalf.
An independent assessor tests whether your SA-11 and SA-15 implementation works as described and reports the result. The assessor uses the assessment procedures in SP 800-53A, which combine determination statements with examine, interview and test methods. Its independence is what gives the report weight, so it must not be the same party that built the evidence.
- Examine: Review the development process document, tool inventory, test plans, scan outputs and remediation records for completeness and consistency.
- Interview: Speak with developers, security staff and release managers to confirm that the documented process is followed in practice.
- Test: Sample recent changes and trace them from finding through fix to retest, and check that tool changes were controlled.
- Report: Record findings, deficiencies and the basis for each determination in the assessment report that the organization then uses for its authorization decision.
- Independence limit: Accept evidence prepared by a partner as input, but form its own conclusions and never edit the evidence it has been given.
Before hiring an assessor, confirm that it is independent of the team that built your pipeline and that it is qualified for the assessment type your authorizing body or contract requires.
How to choose an assessor or implementation partner for SA-11 and SA-15
Assessors and implementation partners do different jobs for SA-11 and SA-15, and the organization that owns the system stays accountable for both. The cards below cover the checks that keep those roles separate, confirm the people involved can speak to secure development evidence, and make the work auditable from the start.
Confirm assessor accreditation for the program
Start by confirming the assessor is recognized for the program that applies to your system, such as FedRAMP or another authorization body that your contract names. Ask for the current recognition status in writing and check it against the program's own listing rather than a brochure. Confirm that the firm can assess SA-11 developer testing and SA-15 development process evidence, not only general NIST 800-53 controls. An assessor without that scope may still produce a report that a reviewer rejects.
Confirm the partner has no report role
The implementation partner prepares systems, test records and development process documents. Only an independent assessor issues the assessment report, so a partner that writes the findings it will later be assessed against has a conflict. Ask the partner to state in writing that it will not sign, attest or issue any assessment conclusion for SA-11 or SA-15. Ask the assessor to confirm it has not designed or remediated the controls it will test.
Ask for named secure SDLC experience
Request the names and roles of the people who will work on your engagement, and ask what each has done on secure development evidence. Useful answers describe specific artifacts, such as threat models, security test results from pipelines, remediation tickets with closure records, and reviews of build tooling. Ask whether those people have delivered this work for systems similar to yours in size and hosting model. Treat vague references to security expertise as a missing answer.
Request a written fixed scope
Ask for a written scope that lists the systems, repositories, pipelines and developer teams in the assessment boundary, along with each deliverable and its acceptance criteria. For SA-11, the scope should name the testing frequency, depth and coverage the organization has defined. For SA-15, it should name the development standards and tools under review. A scope that is not written down before work starts makes it hard to show later what was delivered and when.
Ask how open-source tools are documented
Ask how the partner records each open-source tool used in the development pipeline, including its version, configuration, owner and change history. SA-15 expects the organization to identify, configure and control changes to its tools, so an assessor will look for that record. Ask who approves tool changes, where configuration lives, and how periodic review of the tooling is scheduled and evidenced. Confirm that these records will transfer to your organization at the end of the engagement.
Questions buyers ask about SA-11 and SA-15
Is SA-15(13) logging syntax required for my system?
It depends on the baseline your system is assigned and on how your tailoring decisions treat it. SA-15(13) Logging Syntax was added in Release 5.2.0 to set clearer logging requirements for developers, and NIST did not assign it to any SP 800-53B baseline. It therefore appears in a moderate or high system only if an authorizing body, contract or FedRAMP rule selects it, or if your own tailoring adds it. Start with the baseline recorded in your system security plan, then check your tailoring record and any agency or FedRAMP requirement for the enhancement. Document the decision either way, because an assessor will look for a stated rationale for every selected control and enhancement. Confirm the current wording in the OSCAL catalog before you record the decision.
What drives the cost of meeting SA-11 and SA-15?
Cost is driven by scope and by how much of your development process already produces evidence. The main drivers are the number of systems and repositories in scope, the number of release pipelines, how many teams build or change code, the maturity of your existing secure development lifecycle, and whether test results are stored and traced to remediation tickets. Tooling adds cost whether it is open source or licensed, and documentation effort grows with the number of teams. One-time work includes writing the development process, configuring pipelines and mapping tools to the SA-15 requirements. Recurring work includes periodic review of the process and tooling, repeated testing, and keeping evidence current after changes. Ask any provider for a quote that lists each item separately, with who performs it and what it delivers. No figures appear here because the cost depends on the written scope.
Can our own engineering team meet SA-11 and SA-15 without outside help?
Often for parts of the work, but the question is whether your team has the capacity and skills to produce consistent evidence. The work divides into writing and governing the development process, configuring pipelines to run security tests, collecting results, tracking remediation, and reviewing tools on a schedule. Internal teams usually handle governance and remediation well because they know the code. Outside help is most often used for pipeline setup, tool configuration, specialist security testing and evidence packaging before an assessment. An organization owns its controls, so the decision to keep work in house is yours. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure and runs security testing, and it prepares the evidence. It does not issue assessment reports. A fixed-scope agreement lets you choose which parts to keep in house.
How long does it take to prepare SA-11 and SA-15 evidence?
Timing is set by scope, and NIST does not set implementation timelines. Under FISMA, federal timelines are set through OMB Circular A-130 and by the authorizing body or contract that governs your system. Your own timeline depends on how many systems and pipelines are in scope, how mature the existing process is, whether testing already runs automatically, and how large the remediation backlog is. The assessor also needs time to review the evidence, and that time is outside your control. Scope, deliverables and dates are agreed in writing before work starts, so ask any partner for a schedule that ties each phase to a named deliverable. Ask your authorizing official or assessor which evidence window they expect, because that often sets the earliest practical date for the assessment.
Does a vulnerability scanner satisfy SA-11 developer testing?
No. A scanner produces one kind of evidence, and SA-11 asks for more. The control requires the developer to plan and run ongoing security and privacy control assessments, test at a defined frequency, depth and coverage, produce evidence of the results, and fix flaws through a verifiable remediation process. Static analysis, dependency and container scanners can supply test results, but the plan that defines what is tested and how often, the coverage definition, the triage record and the remediation trail must also exist. Open-source scanners can form part of this program if their output is retained and linked to tickets. Specialist application or penetration testing may also belong in the evidence set. Confirm the expected depth and coverage with your assessor before you write the test plan.
Which FedRAMP impact levels require SA-15(13) and SA-24?
Confirm this against FedRAMP's own material, because requirements change with FedRAMP versions and rules. Start with the System and Services Acquisition entries in the FedRAMP Full Rev5 Control Reference. Then cross-check the machine-readable FedRAMP rules for the version your authorization uses. Look for which impact levels or classes list SA-15(13) and SA-24 as required, and whether any requirement applies only under a specific rule. Record the reference and version in your system security plan so the assessor can trace each decision. If a class requires an enhancement that your baseline does not include, add it to your control set and document the change. A FedRAMP-recognized assessor or your authorizing official can confirm how the requirement applies to your system.
Who issues the assessment report for SA-11 and SA-15?
Only an independent assessor or certification body issues the assessment report and any authorization decision. The organization owns its controls and its system security plan, and the authorizing official makes the risk decision. An implementation partner such as DeployOpen plans and implements the development process, configures testing on self-hosted open-source platforms, runs security testing and prepares the evidence that an assessor reviews. Preparation does not replace assessment. Ask your assessor which evidence formats they accept, how they sample pipeline runs and tickets, and whether they expect the procedures in SP 800-53A to be applied to each item. Keep the separation of roles clear in the statement of work so that no one mistakes preparation for an assessment result.
Does SA-24 apply to every system built under SP 800-53?
No, not automatically. SA-24 is new in Release 5.2.0. NIST added it in the final release, based on stakeholder feedback, to address cyber resiliency by design, and it did not assign the control to any SP 800-53B baseline. It applies when your organization selects it through tailoring or an overlay, or when a contract, agency or program requires it. Appendix C of SP 800-53 lists it as implemented by the organization and marks it as assurance related, so expect an assessor to ask how the design decision was made and how it was verified. If you select it, document the design rationale, the architecture decisions and the verification steps alongside your development process records. Confirm whether your program requires it before development begins.
How DeployOpen fits the secure development work
DeployOpen plans, implements and documents self-hosted open-source development and testing platforms inside the client's own environment, whether that is their cloud accounts, data center or air-gapped network. For SA-11 and SA-15, that work typically covers the build pipeline, source hosting, the code scanning and dependency tooling the team runs, the test environments where developer security testing happens, and the configuration records that show which tools and versions are in use. DeployOpen can also run security testing of applications and APIs on request, so the results of developer testing can be checked by a separate party. The organization still owns its development process, its testing frequency and depth, and its remediation decisions. Those are the points an assessor will ask the organization to explain.
DeployOpen prepares systems, configurations and evidence for SA-11 and SA-15, such as tool inventories, pipeline definitions, test result archives and records of how flaws were routed to fixes. It does not issue assessment reports, attestations or certifications. Only an independent assessor or certification body can do that, and the organization should confirm early which assessor will test the system and what format that assessor expects the developer evidence in. For SA-15(13) and SA-24, which were added in Release 5.2.0 and are not assigned to any SP 800-53B baseline, the organization should first confirm with its authorizing body or contract whether they apply at all before scoping any work on them.
How DeployOpen scopes, builds and documents developer testing evidence
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and runs security testing across applications, APIs and infrastructure. For NIST 800-53 secure software development, we agree a written scope first, then prepare the development process, test evidence and documentation that an independent assessor reviews. We do not issue assessment reports or authorizations.
How we scope
- Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
- The written scope names which SA-11 and SA-15 requirements apply, based on the system's baseline and tailoring decisions made by the organization.
- Confirm with your assessor which development tools, pipelines and repositories fall inside the SA-15 review and which are excluded.
How we build
- We configure the development toolchain, pipeline security tests and code review gates that generate developer testing results for SA-11.
- Tool versions, configuration baselines and change records are captured so the organization can show how SA-15 tooling is controlled.
- Testing covers applications, APIs and infrastructure, with frequency, depth and coverage defined in the agreed plan.
How we hand over
- Deliverables include the development process documentation, test plans, results, and flaw remediation records mapped to the agreed scope.
- Handover packages are organized so the organization's control owners and independent assessor can trace each artifact to its requirement.
- The organization owns its controls and evidence; we confirm with the assessor which formats and records they expect before finalizing.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover periodic review of development tooling against the defined requirements, as SA-15 expects.
- Ask any partner for a written quote that separates one-time build work from recurring support and testing.
