Your Roadmap to RPOC Designation
This guide walks you through every step required to achieve a RAISE 2.0 Registered Point of Connection (RPOC) designation, enabling your DevSecOps Software Factory (DSOP) to grant continuous Authority to Operate (cATO) for applications. Follow each phase in order, check off deliverables as you complete them, and your progress saves automatically.
RAISE 2.0 (Risk Assessment and Independent Security Evaluation) is the DoD framework for accrediting DevSecOps pipelines. An RPOC is a certified connection point where applications can be onboarded with automated security gates instead of traditional ATO packages.
Platform Foundation (Prerequisites)
Build your DevSecOps Platform (DSOP) — a hardened Kubernetes environment with all the supporting services that the 8 security gates and ongoing operations depend on. This is the foundation everything else runs on. Do not skip ahead; the security gates in Phase 2 depend on these services being operational.
- Provision infrastructure — Use OpenTofu (or Terraform) to create VMs/instances. For on-prem, Proxmox VE or vSphere work well. For cloud, AWS GovCloud or Azure Gov.
- Harden the operating system — Apply DISA STIG to Rocky Linux 9 (or RHEL 9) using Ansible. Enable FIPS 140-2 mode, SELinux enforcing, auditd configured.
- Install RKE2 Kubernetes — RKE2 is the only DISA STIG-certified K8s distribution. Install in HA mode (3 server + N agent nodes). Enable the CIS hardening profile.
- Bootstrap Flux CD — Install Flux CD for GitOps-based platform management. All services below are deployed as HelmReleases reconciled from Git.
- Deploy Istio service mesh — STRICT mTLS cluster-wide. Istio gateway for ingress. This satisfies SC-8 (encryption in transit).
- Deploy cert-manager — Automate TLS certificate lifecycle. Internal CA for cluster services, Let's Encrypt or DoD PKI for external.
- Deploy Kyverno policy engine — Pod Security Standards (baseline + restricted), image registry restrictions, label requirements. This becomes your policy enforcement backbone.
- Deploy monitoring stack — kube-prometheus-stack (Prometheus + Grafana + AlertManager). ServiceMonitors for all platform components.
- Deploy logging stack — Loki + Alloy for centralized logging. 90-day retention for audit logs.
- Deploy secrets management — OpenBao (or Vault) + External Secrets Operator. Kubernetes auth method. KV v2 engine for app secrets.
- Deploy container registry — Harbor with Trivy scanning enabled on push. Robot accounts for CI/CD. Cosign signature verification.
- Deploy runtime security — NeuVector for container runtime monitoring, network segmentation, CIS scanning, and admission control.
- Start with RKE2 — it ships FIPS-compliant and CIS-hardened by default, saving weeks of manual hardening work.
- Use Flux CD instead of ArgoCD for platform-level GitOps. It has no UI to secure and is what DoD Platform One uses.
- Deploy Kyverno instead of OPA/Gatekeeper — YAML policies are auditable by compliance officers who do not read Rego.
- Pin every image version explicitly. The
:latesttag will fail your own pipeline gates later. - If you are building on SRE Platform, sessions 1-13 of the
docs/session-playbook.mdcover this entire phase.
- Do not use vanilla Kubernetes (kubeadm). It has no published DISA STIG and you will spend months hardening it manually.
- Do not skip FIPS mode. The TA will check, and retrofitting FIPS after deployment is extremely painful.
- Do not use Docker. RKE2 uses containerd — Docker adds an unnecessary attack surface.
- NetworkPolicies must default to deny-all in every namespace. Add explicit allows from there.
- ✓Kubernetes cluster running (RKE2, HA mode, CIS profile enabled)
- ✓STIG-hardened OS (Rocky Linux 9 / RHEL 9 with FIPS enabled)
- ✓GitOps engine operational (Flux CD bootstrapped, reconciling from Git)
- ✓Service mesh with mTLS STRICT (Istio deployed and healthy)
- ✓Certificate management (cert-manager with ClusterIssuers)
- ✓Policy engine (Kyverno with baseline + restricted policies)
- ✓Monitoring stack (Prometheus + Grafana + AlertManager)
- ✓Logging stack (Loki + Alloy, 90-day audit retention)
- ✓Secrets management (OpenBao/Vault + External Secrets Operator)
- ✓Container registry (Harbor with Trivy scanning on push)
- ✓Runtime security (NeuVector deployed and scanning)
- ✓Default-deny NetworkPolicies in all namespaces
Implement the 8 Security Gates
Build a CI/CD pipeline that enforces all 8 RAISE 2.0 security gates. Each gate must be automated (except Gate 6: ISSM Review) and must produce machine-readable evidence. The pipeline must fail if any gate fails — this is non-negotiable. The TA will run your pipeline end-to-end during certification.
1 SAST — Static Analysis
Scan source code for vulnerabilities before build. Must produce SARIF output for evidence.
Recommended: Semgrep with p/owasp-top-ten + p/security-audit rulesets. Free, fast, SARIF output. Fail on High/Critical findings.
2 SBOM — Software Bill of Materials
Generate an SBOM for every container image. Must support SPDX or CycloneDX format.
Recommended: Syft generates both SPDX and CycloneDX. Attach as Cosign attestation to the image in Harbor. Store alongside the image as an OCI artifact.
3 Secrets Scanning
Scan source code and Git history for leaked secrets, tokens, and credentials.
Recommended: Gitleaks with --no-git for source scan + full history scan. Use .gitleaksignore for false positives. Pipeline must fail on any finding.
4 CSS — Container Security Scan
Scan the built container image for known CVEs. Must fail on CRITICAL severity at minimum.
Recommended: Trivy with --severity CRITICAL,HIGH --exit-code 1. Also runs automatically in Harbor on push. Double coverage.
5 DAST — Dynamic Analysis
Scan the running application for vulnerabilities. Runs post-deploy against a staging/dev environment.
Recommended: OWASP ZAP baseline scan (zap-baseline.py). Runs in Docker against the deployed service URL. Produces HTML + JSON reports.
6 ISSM Review — Manual Gate
Pipeline pauses for Information System Security Manager approval before production deploy.
Implementation: GitHub Environment with required reviewers, or GitLab manual job. This is the only manual gate. All evidence from Gates 1-5 is available for ISSM review.
7 Signing — Image Integrity
Cryptographically sign the container image and attach attestations (SBOM, scan results).
Recommended: Cosign keyless (Fulcio + Rekor) for public, or Cosign keypair for air-gap. Sign image + attach SBOM attestation + attach vulnerability scan attestation.
8 Storage — Secure Registry
Push signed image to a secured registry with scanning, RBAC, and audit logging.
Recommended: Harbor with Trivy auto-scan on push. Robot accounts for CI/CD (least privilege). Kyverno verifies signatures on deploy. Replication policy for air-gap.
- Build a reference pipeline with a sample app (e.g., simple Go/Node service) that passes all 8 gates. Use this as your demo artifact for the TA.
- Gates 1-4 and 7-8 run in CI (pre-deploy). Gate 5 runs post-deploy. Gate 6 is between pre-deploy and deploy.
- Store all gate artifacts (SARIF, SBOM, scan reports) as pipeline artifacts AND attach to the container image via Cosign attestations.
- Use
cosign attestto attach SBOM and vulnerability scan as in-toto attestations. The TA loves this. - Your Kyverno
verify-image-signaturespolicy in the cluster should enforce that only signed images from Harbor can run.
- Do not make any gate optional or "allow failure." The TA will reject the pipeline if any gate can be bypassed.
- DAST (Gate 5) is the most commonly forgotten. You need a running environment to scan against — deploy to a staging namespace first.
- Gitleaks on an old repo with many secrets in history can block your pipeline. Clean up history first or use
.gitleaksignorecarefully. - Cosign signing with a key stored in the pipeline environment (not a KMS) is acceptable for getting started but the TA may recommend KMS-backed keys.
- ✓CI/CD pipeline defined (GitHub Actions or GitLab CI YAML)
- ✓Gate 1: SAST — Semgrep configured with OWASP + security rulesets, SARIF output
- ✓Gate 2: SBOM — Syft generates SPDX + CycloneDX, attached via Cosign attestation
- ✓Gate 3: Secrets — Gitleaks scans source + history, fails on findings
- ✓Gate 4: CSS — Trivy scans container image, fails on CRITICAL/HIGH
- ✓Gate 5: DAST — OWASP ZAP baseline scan against deployed staging app
- ✓Gate 6: ISSM Review — Pipeline pauses for manual approval before prod deploy
- ✓Gate 7: Signing — Cosign signs image + attaches attestations
- ✓Gate 8: Storage — Image pushed to Harbor, Trivy re-scan on push
- ✓Reference application runs through full pipeline successfully
- ✓All gate artifacts saved (SARIF, SBOM, scan reports, signatures)
- ✓Kyverno enforces image signature verification on deploy
Security Categorization
Categorize your system using FIPS 199 and NIST SP 800-60. This determines the security controls you must implement and directly affects the rigor of assessment. Get this right early — changing categorization later means re-doing control selection and documentation.
- Identify information types — Use NIST SP 800-60 Vol II to determine what types of information your platform processes (e.g., C3.2.8 System Development, C3.4.1 General Information). List each type.
- Assign impact levels — For each information type, assign Confidentiality, Integrity, and Availability impact levels (Low, Moderate, High) per FIPS 199.
- Determine system high-water mark — Your system categorization is the highest impact level across all information types for each dimension (C, I, A).
- Document rationale — Write clear justifications for each impact level. The AO will review these.
- Select control baseline — Based on categorization, select NIST 800-53 control baseline (Low, Moderate, or High). Most DSOPs are Moderate.
- Most DevSecOps platforms hosting standard DoD applications land at Moderate-Moderate-Moderate. Unless you are processing classified data or critical weapon systems, Moderate is likely correct.
- If unsure, start with Moderate and let the AO guide you. Going lower is harder to justify than starting at Moderate.
- The DSOP itself has a categorization. Each application onboarded later has its own categorization that must be at or below the DSOP level.
- NIST SP 800-60 Vol I has the process. Vol II has the actual information types catalog. You need both.
- ✓Information types identified (per NIST 800-60 Vol II)
- ✓Impact levels assigned (C, I, A) for each information type
- ✓System high-water mark determined (e.g., Moderate-Moderate-Moderate)
- ✓Rationale documented for each impact level
- ✓NIST 800-53 control baseline selected (Low/Moderate/High)
Prepare Compliance Documents
Prepare the formal compliance documentation required for RPOC designation. This includes the SLA template (RAISE Appendix C), CI/CD Tools Certification (RAISE Appendix D), Plan of Action and Milestones (POA&M), and supporting artifacts. This is the most documentation-heavy phase — start early and iterate.
- SLA Template (RAISE Appendix C) — This is the Service Level Agreement between the DSOP and application owners. It covers all 21 items including vulnerability remediation timelines, patching cadence, monitoring SLAs, incident response, backup/recovery, and access management. Application owners sign this before onboarding.
- CI/CD Tools Certification (RAISE Appendix D) — A formal document listing every tool in your pipeline, its version, which gate it supports, pass/fail criteria, and evidence format. The TA reviews this to certify your pipeline.
- System Security Plan (SSP) — Describes the system boundary, architecture, and how each NIST 800-53 control is implemented, inherited, or planned. This is the core ATO document.
- Security Assessment Report (SAR) — Results of security testing. In RAISE, your automated pipeline results contribute to this.
- Plan of Action & Milestones (POA&M) — Any known vulnerabilities or gaps that are not yet remediated, with timelines for resolution.
- STIG Checklists — Completed DISA STIG checklists for your OS (Rocky Linux 9 / RHEL 9) and Kubernetes (RKE2). Export from STIG Viewer.
- Start the SLA template in Phase 1 and refine as you build. Do not leave it until the end — the ISSM needs to review and agree to it.
- The Appendix D is the TA's primary review artifact. Be extremely specific about tool versions, configuration, and fail criteria.
- Use OSCAL (Open Security Controls Assessment Language) for machine-readable SSP if possible. It enables automated compliance reporting.
- For the POA&M, any STIG finding that is "Not Applicable" or "Open" needs a justification and timeline.
- Get your ISSM involved early. Their buy-in on the SLA and pipeline design prevents rework later.
The RAISE Appendix C SLA covers these areas (not exhaustive — refer to the official template):
- Vulnerability remediation timelines (Critical: 15 days, High: 30 days, Medium: 90 days, Low: 180 days)
- Patching cadence for OS, K8s, and platform components
- Monitoring and alerting responsibilities
- Incident response procedures and timelines
- Backup and disaster recovery SLAs
- Access management and offboarding
- Configuration management (who can change what)
- Audit logging and retention requirements
- Image scanning and signing requirements
- Network segmentation and isolation guarantees
- Encryption in transit and at rest requirements
- ✓SLA template completed (RAISE Appendix C, all 21 items)
- ✓CI/CD Tools Certification completed (RAISE Appendix D)
- ✓System Security Plan (SSP) drafted with control implementations
- ✓Security Assessment Report (SAR) with pipeline evidence
- ✓POA&M created for all known open findings
- ✓Rocky Linux 9 / RHEL 9 STIG checklist completed
- ✓RKE2 Kubernetes STIG checklist completed
- ✓ISSM reviewed and agreed to SLA and pipeline design
Register in eMASS / MCAST
Register your DSOP system in eMASS (Enterprise Mission Assurance Support Service) or MCAST, upload all compliance artifacts, and configure the control inheritance chain. This is a bureaucratic phase — start getting access early because it takes weeks.
- Request eMASS access — This requires a CAC (Common Access Card) and can take 2-4 weeks to get approved. Start immediately. If you do not have a CAC, work with your ISSM to get one or have the ISSM register the system.
- Register the system — Create a new system entry with the official name, acronym, categorization (from Phase 3), owning organization, and system boundary description.
- Upload artifacts — Upload SSP, SAR, POA&M, STIG checklists, and architecture diagrams. Each artifact has a specific location in eMASS.
- Map controls — For each NIST 800-53 control in your baseline, mark it as Implemented, Planned, Inherited, or Not Applicable. For inherited controls, reference the parent system (e.g., the cloud provider's FedRAMP authorization).
- Mark inheritable controls — Critically, mark which controls your DSOP can provide to applications that onboard. This is what makes your RPOC valuable — apps inherit security controls from you instead of implementing them individually.
- Start eMASS access early. This is the single biggest schedule risk. Access takes 2-4 weeks and you cannot proceed without it.
- Submit your registration at least 90 days before you need the ATO. The AO review process has a queue.
- If you are supporting a specific contract/program, coordinate the system name and acronym with the program office before registering.
- If using AWS GovCloud, your cloud infrastructure inherits many controls from AWS's FedRAMP High authorization. Reference the AWS SSP in your inheritance chain.
- For on-prem deployments, you may inherit physical security (PE family) and some environmental controls from the facility's existing ATO.
- Keep a spreadsheet mapping every control to its eMASS status. eMASS's UI is not great for bulk editing.
- ✓eMASS/MCAST access granted
- ✓System registered (name, acronym, categorization, boundary)
- ✓All artifacts uploaded (SSP, SAR, POA&M, STIGs, diagrams)
- ✓Controls mapped (Implemented/Planned/Inherited/N-A for each)
- ✓Inheritable controls marked for application onboarding
- ✓ISSM concurrence on control status
CI/CD Tools Certification (TA Review)
Submit your Appendix D (CI/CD Tools Certification) to the Technical Authority (TA) for review. The TA will evaluate your pipeline, verify all 8 gates are functional, and certify your toolchain. This is the technical gatekeeper — pass this and you are most of the way to RPOC.
- Submit Appendix D — Send the completed CI/CD Tools Certification to the TA. Include tool names, exact versions, gate mapping, pass/fail criteria, and evidence format for each gate.
- Prepare the demo — Set up your reference application (from Phase 2) with a clean Git history. The TA will likely want to see a live pipeline run.
- Run a demo pipeline — Execute the full pipeline in front of (or recorded for) the TA. Show each gate running, producing evidence, and the pipeline failing when a gate fails.
- Show gate failure behavior — Intentionally trigger each gate failure (introduce a vulnerability, add a leaked secret, etc.) to prove the pipeline stops.
- Present evidence artifacts — Show stored SARIF reports, SBOMs, scan results, signed images, and attestations in Harbor.
- Address TA feedback — The TA may request configuration changes or additional gates. Iterate until they certify.
- All 8 gates are automated (except Gate 6 ISSM, which must be a manual approval step).
- Pipeline fails fast — if any gate fails, nothing deploys.
- Evidence is machine-readable — SARIF for SAST, SPDX/CycloneDX for SBOM, JSON for scans.
- Image signatures are verified at deploy time — not just at build time.
- Tools are current versions — no end-of-life or deprecated tools.
- ISSM review gate is enforceable — no way to skip it.
- Schedule the TA review meeting early. TAs have queues and you may wait 2-3 weeks for a slot.
- Record the demo pipeline run as a video. If the TA cannot attend live, a recording with narration works.
- Prepare a one-page pipeline diagram showing the flow through all 8 gates. Visual aids help.
- If the TA suggests a tool replacement (e.g., switching from Trivy to Twistlock), you will need to re-certify only that gate, not the full pipeline.
- ✓Appendix D submitted to Technical Authority
- ✓Demo pipeline run completed (live or recorded)
- ✓Gate failure behavior demonstrated for each gate
- ✓Evidence artifacts presented (SARIF, SBOM, scans, signatures)
- ✓TA feedback addressed and changes implemented
- ✓TA certifies CI/CD toolchain
RPOC Designation (AO Approval)
Present your complete RPOC package to the Authorizing Official (AO). The AO reviews all evidence, confirms the platform meets the 24 RPOC requirements, reviews inheritable controls, and formally designates the system as an RPOC. This is the finish line for platform accreditation.
- Compile the RPOC package — Gather all artifacts: SSP, SAR, POA&M, STIG checklists, Appendix C (SLA), Appendix D (certified by TA), eMASS registration, and architecture diagrams.
- Verify the 24 requirements — Cross-reference RAISE 2.0's 24 RPOC requirements against your implementation. Each must have documented evidence.
- ISSM recommendation — Your ISSM must formally recommend the system for RPOC designation. This is typically a signed memo.
- Present to AO — Brief the AO on the platform architecture, security controls, inheritable controls, risk posture (POA&M), and the certified CI/CD pipeline.
- AO reviews and signs — The AO signs the RPOC designation letter. This authorizes your platform to onboard applications.
- Schedule the AO meeting as early as possible. AO calendars fill up fast, especially at quarter-end.
- Prepare a 30-minute executive brief covering: what the platform does, what controls it provides, what risks remain (POA&M), and how applications will be onboarded.
- The AO is not deeply technical. Focus on risk posture, not technical implementation details.
- Bring your ISSM and TA to the AO meeting. Having their verbal support is powerful.
- If the AO has concerns, they typically result in additional POA&M items with timelines, not outright rejection.
The 24 requirements span these categories (refer to RAISE 2.0 official document for exact wording):
- Pipeline Security (1-8): All 8 security gates implemented and certified by TA
- Platform Security (9-16): Hardened OS, mTLS, RBAC, network segmentation, runtime monitoring, secrets management, audit logging, backup/recovery
- Governance (17-20): SLA signed, ISSM designated, continuous monitoring plan, vulnerability management process
- Documentation (21-24): SSP, SAR, POA&M, STIG checklists uploaded to eMASS
- ✓Complete RPOC package compiled (all artifacts)
- ✓All 24 RPOC requirements verified with evidence
- ✓ISSM signed recommendation memo
- ✓AO briefing delivered
- ✓AO signed RPOC designation letter
Onboard Applications
With RPOC designation in hand, you can now onboard applications. Each application follows a standardized process: the Application Owner signs the SLA, registers in DADMS/DITPRDON, and the application passes through your certified CI/CD pipeline. The beauty of RPOC is that app teams inherit your platform's security controls instead of building their own ATO packages.
- Application Owner signs SLA — The SLA (Appendix C) defines responsibilities, SLAs, and security requirements. Both parties sign.
- Register in DADMS/DITPRDON — The Application Owner registers the application in the DoD IT portfolio management system.
- Create tenant namespace — Use the onboarding script to create namespace, RBAC, NetworkPolicies, ResourceQuotas, Harbor project, and OpenBao path.
- Application passes CI/CD pipeline — All 8 security gates must pass for the application.
- ISSM reviews first deploy — Gate 6 (ISSM review) for the first production deploy of each new application.
- Application receives cATO — Continuous Authority to Operate via the RPOC. No separate ATO package needed.
- Create a reference application first (e.g., simple web service). Use it as the template for all future onboardings.
- Automate tenant onboarding with a script. SRE Platform includes
scripts/onboard-tenant.shthat creates namespace, RBAC, Harbor project, and OpenBao paths. - Provide app teams with a Helm chart template (
sre-web-app,sre-worker) that bakes in all security contexts, NetworkPolicies, and ServiceMonitors. - The first few onboardings will be slow. Document every issue and improve the process. By app 5-10, it should be routine.
- ✓Reference application created and deployed through full pipeline
- ✓Tenant onboarding script tested and documented
- ✓Helm chart templates available for app teams (web-app, worker, cronjob)
- ✓Developer onboarding guide published
- ✓First real application onboarded and deployed
- ✓cATO granted for first application
Quarterly Reviews (QREV)
Maintaining RPOC designation requires quarterly reviews with updated artifacts. Each QREV (1 through 7, then repeating) has specific deliverables. Prepare artifacts 14 days before each review. After 7 quarters (21 months), the cycle repeats from QREV 1.
- QREV 1: Baseline validation — Confirm all controls are still implemented. Update SSP if architecture changed. Run full STIG scan.
- QREV 2: Vulnerability focus — Review all CVEs from the quarter. Confirm remediation timelines met per SLA. Update POA&M.
- QREV 3: Pipeline re-certification — Verify all 8 gates still pass with current tool versions. Update Appendix D if tools changed.
- QREV 4: Incident review — Review any security incidents from the quarter. Document lessons learned. Update IR plan if needed.
- QREV 5: Access control audit — Review all user/service accounts. Remove stale access. Verify RBAC policies.
- QREV 6: Backup/recovery test — Execute a disaster recovery drill. Restore from backup. Document results and RTO/RPO metrics.
- QREV 7: Annual review — Comprehensive review of all controls. Recategorization if needed. Full SSP update.
- Automate as much reporting as possible. A weekly compliance CronJob that generates metrics drastically reduces QREV prep time.
- SRE Platform includes
scripts/validate-compliance.shand a compliance-scanner CronJob for automated evidence collection. - Keep a running QREV document throughout the quarter. Do not try to compile everything in the 14-day window.
- The 14-day rule is firm. Late artifacts = failed QREV = potential RPOC revocation.
- If a tool changes mid-quarter, update Appendix D immediately, do not wait for QREV 3.
- A failed QREV triggers a 30-day remediation window. If not resolved, the AO can suspend RPOC designation.
- Suspended RPOC = no new application onboarding until remediation.
- Two consecutive failed QREVs may result in RPOC revocation and full re-assessment.
- ✓QREV calendar established (dates for all 7 QREVs)
- ✓Compliance reporting automated (CronJob / scripts)
- ✓QREV evidence templates created for each review type
- ✓Running QREV document started (updated continuously)
- ✓First QREV completed successfully
Ongoing Operations
RPOC designation is not the end — it is the beginning of continuous operations. Your platform must maintain its security posture through continuous monitoring, vulnerability remediation, tool updates, and operational excellence. This is the steady-state that keeps your cATO valid.
- Continuous monitoring — Prometheus + Grafana dashboards reviewed daily. AlertManager alerts triaged within SLA timelines. NeuVector runtime alerts investigated.
- Vulnerability remediation — Trivy scans in Harbor catch new CVEs on existing images. Remediation per SLA: Critical (15 days), High (30 days), Medium (90 days), Low (180 days).
- Platform updates — RKE2 minor versions quarterly, patch versions monthly. Platform component updates via Flux (bump HelmRelease versions). OS patches via Ansible.
- Certificate rotation — cert-manager handles automated rotation. Monitor expiration alerts in Grafana. RKE2 internal certs rotate automatically.
- Secret rotation — OpenBao dynamic secrets rotate automatically. Static secrets (API keys, etc.) rotate per policy schedule.
- Backup verification — Velero backups run daily/weekly/monthly. Test restore quarterly (QREV 6). Monitor backup success in Grafana.
- Tool updates — When updating a CI/CD pipeline tool (e.g., new Trivy version), coordinate with the TA. Minor version bumps may not require re-certification; major version or tool replacements do.
- Incident response — Follow documented IR procedures. NeuVector + AlertManager trigger alerts. Grafana dashboards for investigation. Document all incidents for QREV 4.
- Treat your platform like a product. Version it, maintain release notes, and communicate changes to app teams.
- Set up a Slack/Teams channel for platform status. App teams need to know about maintenance windows, upgrades, and incidents.
- Automate everything possible: patching, certificate rotation, backup verification, compliance reporting. Manual processes do not scale.
- Keep your pipeline tools within one major version of latest. Falling too far behind creates upgrade cliffs.
- Build runbooks for every common operational task. When you are on vacation, someone else needs to handle incidents.
- Critical: 15 calendar days from discovery to remediation
- High: 30 calendar days
- Medium: 90 calendar days
- Low: 180 calendar days
- If you cannot remediate within the timeline, add to POA&M with a justification and extended timeline approved by the ISSM.
- Missing SLA timelines repeatedly will be flagged in QREVs and can lead to RPOC suspension.
- ✓Monitoring dashboards reviewed and actionable (daily rotation)
- ✓AlertManager routing tested (Slack/PagerDuty/email working)
- ✓Vulnerability triage and remediation process documented
- ✓Patch cadence established (OS monthly, K8s quarterly, components as needed)
- ✓Operational runbooks written (upgrades, DR, cert rotation, incident response)
- ✓Backup and restore tested successfully
- ✓Incident response plan documented and team trained
Share This Guide
This guide was built for the SRE Platform project. Share the HTML file directly — it is fully self-contained with no external dependencies. All progress is saved in the browser's localStorage.
Generated for the Secure Runtime Environment (SRE) — an open-source, government-compliant Kubernetes platform.