System and Services Acquisition Plan

Approach basics → §4.x

Frameworks, vehicles, and tooling that anchor the rest of the plan.

SDLC framework (one-liner) * SDLC methodology in use (e.g., 'DevSecOps with NIST SSDF integration', 'Agile (Scrum) + SSDF', 'Waterfall with security gates at each phase').

Acquisition vehicles * Primary contract vehicles (e.g., 'GSA Schedule 70 + GWAC + agency-specific BPA', 'Open-market FAR Part 12 commercial-item acquisitions', 'CRADAs with academic partners').

Security-requirements source * Where contract security requirements originate (e.g., 'Org standard contract language at /contracts/security-clauses.md derived from FAR 52.204-21 + DFARS 252.204-7012 + NIST 800-171').

External-service evaluation framework * How external services are vetted (e.g., 'FedRAMP authorization required for cloud services; SOC 2 Type II for non-FedRAMP SaaS; org SCRM review for partner integrations').

Developer CM tool (one-liner) Repository / pipeline tooling (e.g., 'GitHub Enterprise + GitHub Actions; protected main branch; signed commits required'). Reference the CM Plan for system-side CM.

Developer testing tooling SAST / DAST / SCA / IAST tools (e.g., 'GitHub CodeQL (SAST) + OWASP ZAP (DAST) + Snyk (SCA); Burp Suite for manual review').

Resource Allocation (SA-2) → §4.x

Security funding and staffing in capital planning.

Capital-planning integration How security resource needs are captured in capital planning (Exhibit 53 / 300 for federal). Investment-class line items, justification, multi-year planning.

Security staffing model Roles + FTE allocation for security on this system (System Owner, ISSO, ISSM, security engineer, dev-security liaison, etc.).

Budget-review cadence How often security budget is reviewed against actuals (typically tied to org budget cycle, e.g., 'Quarterly').

Unfunded-requirements register Where unfunded security requirements are tracked (so they don't get lost). Often surfaces in the POA&M as risks pending funding.

SDLC Integration (SA-3) → §4.x

Where in the SDLC security activities are integrated.

SDLC phases recognized

Initiation / requirements Acquisition / development Implementation / deployment Operations / maintenance Disposal / decommission

Security activities by phase What security activity happens at each phase. Initiation: categorization + risk assessment. Development: threat modeling, secure coding, testing. Deployment: ATO. Operations: continuous monitoring. Disposal: sanitization + records retention.

Threat-modeling approach — Select — STRIDE per design / per architecture-significant change PASTA full process Attack trees Quick / lightweight (data flow + risk identification) Not formally performed (with POA&M)

Developer-security training cadence Required training cadence for developers (e.g., 'Annual secure-coding training with role-based modules'). Reference AT plan if authored.

SDLC-governance role Role accountable for SDLC-security adherence (e.g., 'Application Security Lead', 'CISO delegate').

Acquisition Requirements (SA-4) → §4.x

Security clauses and deliverables required in contracts.

Required security clauses

FAR 52.204-21 — Basic Safeguarding of Covered Contractor Information DFARS 252.204-7012 — Safeguarding CDI / Cyber Incident Reporting DFARS 252.204-7019 / 7020 / 7021 — CMMC FedRAMP authorization required (if cloud service) NIST SP 800-171 compliance attestation EO 14028 SSDF self-attestation Section 889 — Prohibition on Certain Telecommunications Equipment Section 508 — Accessibility Privacy clauses for PII handling

Required security deliverables

SBOM in CycloneDX or SPDX format (SA-4(10)) Functional security requirements (SA-4(1)) Security implementation information (SA-4(2)) Source-code escrow (high-impact systems) Penetration-test attestation (SA-4(9)) Security-architecture diagram Cryptographic-module list with FIPS 140-3 numbers Privacy threshold analysis Continuous-monitoring requirements (FedRAMP)

Continuous-monitoring contract clause (SA-4(7)) How ongoing monitoring is required of vendors. ConMon deliverables, security-event reporting, vulnerability-disclosure obligations.

SBOM acceptance criteria (SA-4(10)) What an acceptable SBOM looks like (format, depth — direct vs transitive, machine-readable, signing). Reference EO 14028 / OMB M-22-18.

Section 889 attestation evidence How vendor compliance with Section 889 (no Huawei / ZTE / Hikvision / Dahua / Hytera covered telecom) is collected and recorded.

System Documentation (SA-5) → §4.x

Admin docs, user docs, and architecture documentation.

Administrator documentation scope

Installation / configuration guides Operational runbooks Security configuration baselines (cross-reference CM-6) Backup + restore procedures (cross-reference CP) Incident-response playbooks (cross-reference IR) Disaster-recovery runbook (cross-reference CP) Change-management procedures

User documentation scope

End-user functional guides Security-awareness reminders embedded in UX Acceptable-use policies Account-recovery instructions Reporting-suspected-incidents instructions

Documentation storage location Authoritative location for system documentation (e.g., 'Confluence space CTLS at /docs.acme/CTLS', '/repo/docs in version control').

Documentation currency-review cadence How often documentation is reviewed for currency (e.g., 'Annual + on significant change to architecture / configuration').

Security and Privacy Engineering Principles (SA-8) → §4.x

Principles applied during engineering decisions.

Principles applied

Least privilege (SA-8(2)) Layered defense / defense-in-depth (SA-8(3)) Secure default configuration (SA-8(11)) Fail securely (SA-8(13)) Economy of mechanism / simplicity (SA-8(7)) Complete mediation (SA-8(8)) Open design — no security through obscurity (SA-8(9)) Separation of duties (SA-8(4)) Least common mechanism (SA-8(5)) Reduce trust dependency / minimize TCB (SA-8(6)) Explicitly trusted components (SA-8(14)) Trusted communications channels (SA-8(18))

Evidence of application How application of these principles is evidenced (e.g., 'Architecture Decision Records (ADRs) in /repo/adr cite which principle each decision aligns with'; 'Threat model captures principle-violation findings').

Architecture-review role Role accountable for security-architecture review (e.g., 'Application Security Lead'; 'Security Architecture Review Board').

External System Services (SA-9) → §4.x

Cloud services, SaaS, partner integrations.

External-service inventory location Where the inventory of external services in scope is maintained (CMDB section, dedicated SaaS-management tool, /repo/external-services.md).

Authorization types accepted

FedRAMP Moderate / High / Tailored DoD Cloud Computing SRG IL2 / IL4 / IL5 / IL6 StateRAMP Vendor SOC 2 Type II ISO 27001 PCI-DSS (where payment data flows) HIPAA BAA + audit Internal SCRM review

Data-flow documentation requirement How data flows between the system and each external service are documented (data classification labels exchanged, encryption-in-transit requirements, retention obligations).

Authorization-currency tracking How authorization status is tracked through expiration (FedRAMP ATO sunset, SOC 2 report annual cadence). Renewal tickler process.

Identification of functions / ports / protocols (SA-9(2)) Per SA-9(2), the org identifies external service functions, ports, protocols, and other services for each external service in use.

Service-termination procedure What happens when an external service contract ends (data return, sanitization attestation per MP / SC-28).

Developer Configuration Management (SA-10) → §4.x

How developer-side configuration management is governed.

Repository protections

Protected main branch (no direct push) Required pull-request review (≥1 approver) Required PR review (≥2 approvers for security-sensitive paths) Signed commits required Branch protection on release branches CODEOWNERS gating security-sensitive paths Status-check gating (CI passing, SAST clean)

Developer-change classification How developer changes are classified (security-sensitive, normal, hotfix). Mapping to system-side CM-3 change classes.

Release process From merge → release. Tagged releases, build artifacts, signing, deployment promotion through environments. Reference SI-7 for code authentication.

Developer-baseline tracking (SA-10(1)) How developer-side baselines (build configurations, dependency lockfiles, container base images) are tracked. Reference CM-2 system-side baselines.

Integrity protection of build pipeline (SA-10(5)) How the build pipeline itself is protected (RBAC on CI, secrets management, ephemeral runners, attestation per SLSA).

Developer Testing and Evaluation (SA-11) → §4.x

SAST, DAST, SCA, IAST, fuzzing, code review.

Testing types

Static analysis (SAST) — SA-11(1) Dynamic analysis (DAST) Interactive analysis (IAST) Software composition analysis (SCA) Manual code review (security-sensitive paths) Fuzzing Penetration testing — SA-11(5) Threat modeling and vulnerability analyses — SA-11(2) Independent verification of correctness Attack-surface analysis — SA-11(6)

Testing cadence by type How often each test type runs. Example: 'SAST + SCA on every PR; DAST nightly against staging; fuzz-testing of parsing libraries weekly; manual pen-test annually + on significant change'.

Finding-severity SLAs How developer-test findings are triaged. Severity-to-fix-time mapping (e.g., 'Critical SAST: blocks merge; High SAST: 7 days; Medium: next sprint').

Results distribution Where developer-test results are recorded and who reviews them. Trends, regressions, exceptions.

Independent review (SA-11(3)) Per SA-11(3), independent verification of developer-test results. By a separate team within the org or by an external assessor.

Secure Development Process / Standards / Tools (SA-15) → §4.x

The development process itself, the tooling chain, and standards.

SSDF (NIST SP 800-218) alignment — Select — Fully aligned (all four practice groups) Partial — Prepare + Protect Partial — Produce + Respond Self-attesting per EO 14028 / OMB M-23-16 Not formally aligned

Secure-development tooling chain End-to-end tooling: IDE security plugins, version control with branch protection, CI with security gates, artifact signing, attestation generation. Reference SLSA levels if used.

Secure coding standards followed

OWASP ASVS Level 1 / 2 / 3 OWASP Top 10 OWASP API Security Top 10 OWASP Mobile Top 10 CWE Top 25 CERT Secure Coding Standards (C / C++ / Java) SEI CERT MISRA (safety-critical)

Criticality analysis in development (SA-15(3)) Per SA-15(3), criticality analysis applied during development. Reference RA-9 for system-level. SBOM-based dependency criticality, mission-essential-function tracing.

Developer screening (SA-15(8)) — Select — All developers in scope of org background investigation (typical for federal) Background-checked for sensitive paths only Vendor staff screened per contract clause Screening not formally required (with rationale)

Unsupported System Components (SA-22) → §4.x

Components past vendor support — replacement, alternative-source, or compensating control.

Unsupported-component inventory location Where unsupported components are tracked (CMDB flag, dedicated EOL register). Linked to vendor product life-cycle calendars.

Allowed remediation paths

Replace with supported component Source extended support from vendor (paid) Source alternative support from third party Develop in-house support / fork Apply compensating controls (isolate + monitor) with formal risk acceptance Decommission the component

Pre-EOL lead time target Time before vendor EOL by which remediation should be planned (e.g., '12 months').

Compensating-controls inventory if isolation chosen Examples: network isolation, restricted access, increased monitoring, virtual patching via WAF / IPS rules. Reference RA-7 risk acceptance for the formal decision record.

Acquisition / Development Scope → §2.x

Quantitative scope numbers that anchor metrics later in the plan.

External services in scope Approximate count of external system services (cloud, SaaS, partner) in scope of SA-9.

Active acquisition vehicles Approximate count of active acquisition vehicles supporting the system.

Developers in scope of SA-3 / SA-11 Approximate count of in-scope developers (gov, contractor, vendor staff).

Unsupported / approaching-EOL components Current count of unsupported or pre-EOL components in the SA-22 register.

Acquisition / Development Metrics & KPIs → §6.x

Metrics tracked to demonstrate SA control effectiveness.

Tracked metrics

Add item

Suggested: + % Solicitations including required security clauses + % Deliverables including SBOM at acceptance + SAST critical findings per release (target: 0) + DAST critical findings per release (target: 0) + SCA findings remediated within SLA + % Developers current on annual security training + External-service authorization currency rate (% with valid auth) + Unsupported-component count + Unsupported-component remediation SLA compliance + Developer-CM adherence rate (% PRs meeting protection gates) + Open POA&M items linked to SA controls

External-Service Posture Verification → §6.x

How the org continuously verifies external services remain authorized.

Authorization-status check cadence How often external-service authorization status is checked (FedRAMP marketplace, SOC 2 receipt, ISO certificate currency).

Action on lapsed authorization What happens when an external service falls out of authorization (immediate suspension, grace-period processing, alternate-service fallback).

Cross-references to other RMF artifacts → §7

Where this plan plugs into the broader RMF package.

SSP section reference Where in the SSP the SA control implementations are summarized (e.g., 'SSP §13.12').

POA&M ID prefix for SA findings Convention for SA-related POA&M items (e.g., 'POAM-SA-' for general; 'POAM-SA22-' for unsupported-component-specific).

CM family handoff How SA-10 developer CM feeds CM-2 system baselines and CM-3 change control. Where the handoff line sits (build → release → deploy).

RA family handoff How SA-11 testing outputs feed RA-5 vulnerability data. SA-15(3) criticality echo with RA-9 system-level criticality.

SR family pointer Pointer to the SR plan if authored. SA-4 / SA-9 / SA-15(3) are the primary SA-side hooks into SR.

SI family handoff How artifacts produced by SA-15 secure tooling (SBOMs, signed packages, attestations) feed SI-7 integrity verification.

AT family handoff How SA-3-mandated developer / acquisition-staff training is delivered through the AT-3 role-based training program.

CA-7 continuous-monitoring strategy reference Pointer to the CA-7 monitoring strategy document tying SA continuous-monitoring metrics to the broader ConMon plan.