System Security Plan Working Outline
Use this as Markdown source material for the official FedRAMP SSP template. Do not submit this file as the SSP; transfer approved content into the current FedRAMP template when the boundary, impact level, and control matrix are stable.
System Identification
| Field | Value |
|---|---|
| System name | [FILL IN] |
| Cloud service offering | [FILL IN] |
| Service model | SaaS |
| Deployment model | [FILL IN: public cloud, GovCloud, community cloud, or other] |
| Authorization boundary | See 02-fips-199-and-boundary.mdx. |
| FedRAMP baseline | [FILL IN: Low, Li-SaaS, Moderate, or High] |
| System owner | [FILL IN] |
| Package owner | [FILL IN] |
| 3PAO | [FILL IN] |
System Purpose
[FILL IN: describe the mission, users, business processes, and government use case. Keep this factual and specific.]
Architecture
The system uses a modern web application architecture with React and Astro SSR at the presentation layer, API services in TypeScript and Go, Postgres and SQLite data stores where approved, and Kubernetes-managed workloads delivered through Helm and Argo CD. GitHub Actions performs build, test, security scanning, artifact generation, and deployment promotion.
| Layer | Components | Security Responsibility |
|---|---|---|
| Client | Browser UI, design-system components | Secure UI behavior, accessibility, session handling, input validation |
| Application | Astro SSR, API routes, Go Fiber services | Authentication enforcement, authorization, audit events, validation |
| Data | Postgres, SQLite, object storage | Encryption, backups, access control, retention |
| Platform | Kubernetes, Helm, Argo CD | Network segmentation, policy admission, runtime configuration |
| Delivery | GitHub Actions, package registry, container registry | Change control, scanning, SBOM, signing, provenance |
| Observability | OpenTelemetry, Prometheus, logs, dashboards | Monitoring, alerting, audit retention, ConMon evidence |
Authorization Boundary
[FILL IN: summarize the production boundary and link to the boundary diagram.]
| Boundary Item | In Boundary | Shared | Inherited | Notes |
|---|---|---|---|---|
| Application code | Yes | No | No | Owned by dmwd.io engineering. |
| Kubernetes runtime | Yes | Yes | Yes | Shared with cloud provider infrastructure. |
| Cloud physical facilities | No | No | Yes | Inherited from cloud provider authorization. |
| GitHub source control | No | Yes | Yes | Requires enterprise policy evidence. |
| Identity provider | [FILL IN] | [FILL IN] | [FILL IN] | Confirm IdP and assurance level. |
| Logging and audit store | [FILL IN] | [FILL IN] | [FILL IN] | Confirm retention and immutability. |
Roles and Responsibilities
| Role | Responsibility | Evidence |
|---|---|---|
| System Owner | Owns mission, boundary, and risk decisions. | Charter, approval records |
| Platform Engineering | Owns Kubernetes, GitOps, CI/CD, scanning, and infrastructure evidence. | Pull requests, workflow logs, Argo CD sync history |
| Application Engineering | Owns application controls, secure coding, tests, and application evidence. | Test results, code review, audit event tests |
| Security | Owns control mapping, review, risk acceptance, and POA&M triage. | Review issues, POA&M records |
| Privacy | Owns data inventory, minimization, retention, and privacy impact analysis. | Data inventory, privacy review |
| Operations | Owns incident, backup, restore, and ConMon execution. | Runbooks, drill records, monthly reports |
Control Implementation Statements
Use one short implementation statement per control or control family before expanding in the official template. Every statement should name enforcement points, evidence, owner, and open gaps.
Access Control
Access is enforced through identity-provider groups, application roles, repository permissions, Kubernetes RBAC, and database grants. Production changes require non-author review and protected-branch controls. Quarterly access reviews produce evidence for user, administrator, repository, CI/CD, and cluster access.
Identification and Authentication
Authentication uses federated identity and MFA. The target posture is phishing-resistant MFA for privileged users and federal-boundary administrators, with WebAuthn or PIV/CAC support where required. Session policy, re-authentication, stale-account removal, and break-glass use must be evidenced.
Audit and Accountability
Application, administrative, CI/CD, identity, Kubernetes, and database security events are logged centrally. Audit logs must preserve event time, actor, action, target, result, source, and correlation ID. FedRAMP-ready operation requires retention, integrity protection, review cadence, and alerting evidence.
Configuration Management
Configuration changes flow through GitHub pull requests, code owners, status checks, signed or protected commits where configured, Helm charts, and Argo CD sync. Baselines are expressed as code and checked by CI/CD, policy admission, and periodic drift review.
Risk Assessment and Vulnerability Management
Dependency, container, IaC, application, secret, and Kubernetes scans run in CI/CD and on a recurring schedule. Findings are triaged by severity and tracked through the POA&M when they cannot be closed within the remediation window.
System and Communications Protection
The system requires TLS for external traffic, service-to-service encryption where practical, encrypted storage, managed secrets, network policy, and least-privilege egress. FIPS 140-3 validation status must be confirmed for cryptographic modules in the federal boundary.
Incident Response and Contingency
Incident response, backup, restore, disaster recovery, and communications processes are documented and exercised. Evidence must include incident tickets, after-action reviews, backup job history, restore-test records, and continuity drill records.
Supply Chain and Secure Development
The build pipeline produces dependency scan results, SBOMs, provenance, container scan results, test results, and release approvals. Supply-chain controls must cover pinned actions or reviewed actions, dependency update automation, artifact signing, and admission controls for trusted images.
Evidence Handling
| Evidence Class | Storage Location | Retention | Owner |
|---|---|---|---|
| CI/CD logs | [FILL IN] | [FILL IN] | Platform Engineering |
| SARIF reports | [FILL IN] | [FILL IN] | Security |
| SBOMs | [FILL IN] | [FILL IN] | Platform Engineering |
| Signed artifacts | [FILL IN] | [FILL IN] | Platform Engineering |
| Access review records | [FILL IN] | [FILL IN] | Security |
| Incident records | [FILL IN] | [FILL IN] | Operations |
| Backup and restore results | [FILL IN] | [FILL IN] | Operations |
| Monthly ConMon package | [FILL IN] | [FILL IN] | Security |
SSP Drafting Rules
- State what is implemented today, not what is intended.
- Mark future work as
Plannedand create a POA&M item. - Use
Inheritedonly when provider evidence exists. - Use
Sharedwhen dmwd.io and a provider both perform part of the control. - Avoid tool-only claims; describe the process and evidence.
- Keep official control language in the FedRAMP template and local implementation detail in this template file.