The DoD Software Acquisition Pathway (SAP, established under DoDI 5000.87) created a purpose-built acquisition approach for software-intensive programs — replacing the traditional waterfall milestone structure with iterative delivery requirements. Programs using SAP must deliver software to users frequently (the guidance targets no longer than 6-month delivery cycles to operational users), demonstrate value at regular review points, and maintain continuous ATO through a cATO or equivalent.
For cloud engineering subcontractors, SAP-aligned programs have specific delivery expectations. Here's what primes need from cloud subs on SAP programs, and how Rutagon meets those requirements.
What the Software Acquisition Pathway Changes
Traditional ACAT program delivery used Major Defense Acquisition Program (MDAP) milestone structures — Milestones A, B, and C gates with multi-year development phases before anything reaches users. Software programs under the traditional MDAP structure routinely took 3-5 years to deliver initial capability to operators.
SAP inverts this: users receive software updates frequently, and the program's authorization to continue is tied to demonstrated user value, not document completion. The key SAP mechanisms:
Capability Need Statement (CNS) instead of an ORD: Simplified capability description focused on what users need to accomplish, not a lengthy requirements document.
Iterative development cycles: Software is developed and deployed on a cadence (typically 6-week to 6-month sprints) to a user population that provides continuous feedback.
Continuous ATO: SAP programs pursue cATO rather than traditional point-in-time ATOs — continuous authorization based on demonstrated security hygiene, automated evidence collection, and ongoing ISSO monitoring.
Adaptive Acquisition Framework context: SAP is one of six AAF pathways. Programs can enter SAP and transition to other pathways as they mature (or if they become too large for SAP constraints).
What SAP Means for Cloud Sub Delivery
On a SAP-aligned program, the cloud infrastructure sub must:
Deliver on SAP's iteration cadence: If the program delivers software updates to users every 6 weeks, the cloud infrastructure changes (environment updates, pipeline improvements, new compliance controls) must also be delivered on that cadence. A cloud sub that operates on quarterly delivery cycles creates a bottleneck for a 6-week delivery program.
Support cATO from the start: SAP's continuous authorization model depends on continuous evidence generation. Rutagon's automated evidence collection (scan reports, configuration baselines, ConMon metrics) must be running before the program's first user delivery — not added as a compliance activity when the ISSO requests it.
Maintain deployment velocity: SAP programs measure delivery frequency as an output metric. If the cloud pipeline introduces friction (long queue times, manual approval gates that can't be bypassed for speed), it directly degrades the program's ability to meet SAP's delivery requirements.
Enable user feedback loops: Telemetry and monitoring infrastructure must be in place from the first user delivery — SAP programs make decisions based on user usage patterns and error rates. Without visibility into production system behavior, the feedback loop that SAP depends on doesn't function.
The cATO Infrastructure Stack
SAP programs pursuing cATO need specific automation infrastructure in place before the authorization event:
Automated STIG scanning: STIG findings are monitored continuously, not just at assessment time. Rutagon's pipeline-integrated scanning produces finding reports on every deployment.
Continuous ConMon dashboard: Security posture metrics (open findings by severity, compliance coverage percentage, vulnerability discovery-to-remediation latency) visible to the ISSO and AO in real time.
ATO evidence artifact storage: All evidence produced by automated scanning and assessment is stored in a durable, access-controlled location (S3 with appropriate IAM controls and object versioning) and timestamped for the continuous authorization record.
Change management integration: Infrastructure changes are tracked in the IaC repository with PR review, automated compliance checks before apply, and deployment records linking each deployed configuration to a review-and-approval event.
# cATO evidence collection stage — runs after every deployment
collect-ato-evidence:
stage: .post
script:
- collect-evidence.sh \
--environment=${DEPLOY_ENV} \
--pipeline-id=${CI_PIPELINE_ID} \
--commit-sha=${CI_COMMIT_SHA} \
--scan-results=reports/ \
--infra-plan=terraform-plan.json \
--output=s3://${ATO_BUCKET}/evidence/${CI_PIPELINE_ID}/
when: on_success
Delivering Under SAP: What Rutagon Provides
Pre-built SAP-ready pipeline: Rutagon's CI/CD pipeline template includes cATO evidence collection, automated scanning, deployment frequency metrics, and change management integration — configurable for a program's specific requirements in days, not months.
Sprint-cadenced infrastructure delivery: Rutagon operates on bi-weekly sprints with demonstrable deliverables at each sprint review. For SAP programs with 6-week deployment cycles, Rutagon's 2-week sprint cadence allows 3 sprint cycles per deployment — infrastructure stays ahead of application delivery needs.
ISSO support tooling: ConMon dashboards, finding export tools, and evidence archive navigation that reduce ISSO workload. The ISSO's job is to assess risk — they shouldn't be spending time manually aggregating security scan data.
View Rutagon's government capabilities → rutagon.com/government
Frequently Asked Questions
Is the Software Acquisition Pathway appropriate for all defense software programs?
SAP is best suited for software-intensive programs where iterative delivery provides value. It's less appropriate for programs with significant hardware components (where software is secondary to hardware development schedule), highly classified programs with specialized authorization pathways, or programs where the user community can't receive frequent software updates. DoDI 5000.87 provides selection guidance for program managers choosing among AAF pathways.
How does SAP handle traditional milestone reviews?
SAP replaces Milestones A/B/C with a different review structure — Capability Needs Statement approval, initial capability delivery to users, and ongoing program review through User Operational Reviews (UORs) and Software Acquisition Reviews (SARs). These reviews are less document-intensive than traditional milestone reviews and focus on demonstrated user value and program health metrics.
What is a User Operational Review under SAP?
UORs are the primary accountability mechanism in SAP — program leadership reviews deployment frequency, user adoption, performance metrics, and feedback data. A program that isn't delivering to users frequently enough, or whose deployments aren't being used, risks adverse review findings. Cloud infrastructure performance (availability, latency, deployment pipeline reliability) directly feeds into UOR health metrics.
How does SAP interact with CMMC requirements for defense programs?
SAP doesn't replace CMMC requirements. Programs under SAP that handle CUI are still subject to CMMC compliance requirements. The cATO model under SAP is compatible with CMMC compliance — continuous CMMC assessment feeds the same continuous authorization model. The difference is that SAP's cATO reduces the administrative burden of periodic reauthorization, but doesn't exempt programs from meeting CMMC control requirements.
What's the threshold for a program to use the Software Acquisition Pathway?
There's no formal dollar threshold for SAP eligibility, but it's typically used for programs in the ACAT II range and below where the software-intensive nature warrants the pathway's flexibility. Very large programs (ACAT I, Major Defense Acquisition Programs) have more complex stakeholder dynamics that may require the additional oversight structure of traditional MDAP pathways, though hybrid approaches exist.