Reports Comments Summary :root { --accent: #2d6be4; --accent-dim: #e8effe; --border: #dde1e9; --surface2: #f0f2f5; --muted: #6b7280; --tag-open: #16a34a; --tag-arc: #92400e; --radius: 6px; --mono: "JetBrains Mono", "Fira Mono", monospace; } .cr-meta { font-size: .8rem; color: var(--muted); margin-bottom: 16px; } .cr-toc { border: 1px solid var(--border); border-radius: var(--radius); padding: 14px 18px; margin-bottom: 28px; background: var(--surface2); } .cr-toc h2 { font-size: .7rem; text-transform: uppercase; letter-spacing: .1em; color: var(--muted); margin-bottom: 8px; } .cr-toc ul { list-style: none; padding: 0; margin: 0; } .cr-toc li { margin-bottom: 2px; } .cr-toc a { color: var(--accent); text-decoration: none; font-size: .88rem; } .cr-toc a:hover { text-decoration: underline; } .cr-toc .cr-toc-book { margin-left: 16px; font-size: .82rem; } .cr-shelf { margin-bottom: 40px; } .cr-shelf-h { font-size: 1.25rem; font-weight: 700; border-bottom: 2px solid var(--accent); padding-bottom: 4px; margin-bottom: 18px; } .cr-shelf-h a { color: inherit; text-decoration: none; } .cr-shelf-h a:hover { text-decoration: underline; } .cr-book { margin-bottom: 28px; margin-left: 4px; } .cr-book-h { font-size: 1rem; font-weight: 600; color: var(--muted); margin-bottom: 10px; padding-left: 10px; border-left: 3px solid var(--accent); } .cr-book-h a { color: inherit; text-decoration: none; } .cr-book-h a:hover { text-decoration: underline; } .cr-page { border: 1px solid var(--border); border-radius: var(--radius); margin-bottom: 14px; overflow: hidden; } .cr-page-h { background: var(--surface2); padding: 9px 14px; font-weight: 600; font-size: .9rem; display: flex; justify-content: space-between; align-items: center; border-bottom: 1px solid var(--border); } .cr-page-h a { color: var(--accent); text-decoration: none; } .cr-page-h a:hover { text-decoration: underline; } .cr-page-counts { font-size: .72rem; color: var(--muted); font-weight: 400; white-space: nowrap; } .cr-section-label { font-size: .68rem; font-weight: 700; text-transform: uppercase; letter-spacing: .1em; padding: 5px 14px; border-bottom: 1px solid var(--border); } .cr-section-label.open { color: var(--tag-open); background: #f0fdf4; } .cr-section-label.arc { color: var(--tag-arc); background: #fffbeb; } .cr-comment { padding: 12px 14px; border-bottom: 1px solid var(--border); } .cr-comment:last-child { border-bottom: none; } .cr-comment.archived { background: #fafaf7; } .cr-cmeta { display: flex; flex-wrap: wrap; align-items: center; gap: 4px 10px; margin-bottom: 6px; font-size: .76rem; color: var(--muted); } .cr-cid { font-family: var(--mono); font-size: .7rem; background: var(--accent-dim); color: var(--accent); padding: 1px 5px; border-radius: 3px; text-decoration: none; } .cr-cid:hover { text-decoration: underline; } .cr-cauthor { font-weight: 600; color: #1a1d23; } .cr-badge { font-size: .62rem; font-weight: 700; text-transform: uppercase; letter-spacing: .05em; padding: 1px 5px; border-radius: 20px; } .cr-badge.open { background: #dcfce7; color: var(--tag-open); } .cr-badge.arc { background: #fef3c7; color: var(--tag-arc); } .cr-cbody { font-size: .9rem; line-height: 1.65; } .cr-cbody p { margin-bottom: .4em; } .cr-cbody p:last-child { margin-bottom: 0; } .cr-cbody a { color: var(--accent); } .cr-cbody code { font-family: var(--mono); font-size: .84em; background: var(--surface2); padding: 1px 4px; border-radius: 3px; } .cr-replies { margin-top: 10px; margin-left: 20px; border-left: 3px solid var(--border); padding-left: 12px; } .cr-reply { padding: 8px 0; border-bottom: 1px dashed var(--border); } .cr-reply:last-child { border-bottom: none; } /* ── Top-level section headings ── */ .cr-top-section { margin-bottom: 52px; } .cr-top-section-h { font-size: 1.5rem; font-weight: 700; font-family: system-ui, sans-serif; padding: 10px 16px; margin: 0 0 24px 0; border-radius: var(--radius); display: flex; align-items: center; justify-content: space-between; } .cr-top-section-h.open { background: #f0fdf4; color: #15803d; border-left: 5px solid #16a34a; } .cr-top-section-h.arc { background: #fffbeb; color: #92400e; border-left: 5px solid #d97706; } .cr-top-section-h.deleted { background: #fff1f1; color: #b91c1c; border-left: 5px solid #dc2626; } .cr-top-section-count { font-size: .85rem; font-weight: 400; opacity: .75; margin-left: 12px; } /* ── Recycle bin section ── */ .cr-deleted-section { border-top: 3px solid #dc2626; padding-top: 24px; } .cr-deleted-note { background: #fff1f1; border: 1px solid #fca5a5; border-radius: var(--radius); padding: 10px 14px; margin-bottom: 20px; font-size: .85rem; color: #7f1d1d; } .cr-deleted-note a { color: #dc2626; } .cr-deleted-page-h { background: #fff1f1; padding: 9px 14px; font-weight: 600; font-size: .9rem; border-bottom: 1px solid #fca5a5; display: flex; justify-content: space-between; align-items: center; } .cr-deleted-page-name { color: #7f1d1d; } .cr-deleted-at { font-size: .72rem; color: #b91c1c; font-weight: 400; white-space: nowrap; } .cr-page.deleted { border-color: #fca5a5; } Generated: 2026-06-13 06:00:09  ·  6 open  ·  19 archived  ·  3 in recycle bin Contents Open Comments (6) Core OSCAL System Security Plans FedRAMP Supporting Resources and Valid Content FedRAMP System Security Plan (SSP) Archived Comments (19) FedRAMP FedRAMP Common FedRAMP System Security Plan (SSP) ⚠ Recycle Bin (3) Open Comments 6 Core OSCAL System Security Plans Components 1 open · 0 archived Open Comments # 1 Brian Ruf 2026-04-15 14:45:23 Open Needs work FedRAMP Supporting Resources and Valid Content Baselines 1 open · 2 archived Open Comments # 3 Brian Ruf 2026-02-25 13:16:08 Open In the TFG meeting, highlighted the need to verify FedRAMP has not changed the baselines since these were drafted in Jan 2025. Archived Comments # 2 Brian Ruf 2026-02-25 13:15:28 (edited 2026-04-02 15:20:44) Archived In the TFG meeting we discussed putting more content at the top to clarify tools should be using the profiles and performing the resolution themselves. Tools may cache as appropriate depending on frequency of updates to these profiles and any overlays. @Brian Ruf taking action to draft content. Clarify this is important to ensure baselines remain fresh. # 5 Brian Ruf 2026-04-02 15:20:40 This is complete. # 1 Valinder Mangat 2026-02-18 20:49:21 (edited 2026-04-13 19:05:24) Archived The SSP OSCAL guidance for “import-profile” specifically discourages the use of a “resolved profile catalog” for good reasons. It makes sense to create the “tailoring-profile” and have the other profiles pull from the tailoring-profile, while this approach is useful from authoring effort perspective, it adds runtime burden for having to resolve multiple layers of profiles. Is there an approach to resolve “multiple stacked profiles” into single profiles so that they can be referenced directly in the SSP? The baselines are not likely to change very often, so perhaps a more efficient runtime solution bears better. # 4 Brian Ruf 2026-04-02 15:20:29 While I completely agree that multi-layer profile resolution is the the preferred approach and the only way to handle overlays and multi-frameworks, we are looking to initially reduce complexity to the greatest degree practical for MVP/Core adoption, then allow organizations to mature their capabilities over time based on their needs and priorities. # 6 Brian Ruf 2026-04-08 12:35:04 Discussed in today's TFG. We agree that that resolved profiles allow an easy quick-start. Verified that we show it initially in the adoption and moving to proper profile processing by the "Normalized" phase.. Considering this closed. Examples 1 open · 0 archived Open Comments # 1 Brian Ruf 2026-02-25 13:19:06 (edited 2026-04-08 14:32:29) Open Needs end-to-end review for alignment with FedRAMP templates and defined OSCAL patterns. FedRAMP System Security Plan (SSP) 6. Leveraged FedRAMP-Authorized Services 1 open · 0 archived Open Comments # 1 Brian Ruf 2026-04-01 03:58:56 Open We need to fix the link in the "Important for Leveraged Systems" callout once the controls section is complete and the location is not likely to change again. Control Origination 1 open · 0 archived Open Comments # 1 Brian Ruf 2026-04-15 03:24:29 Open This page needs work and the concept needs to be re-evaluated, especially use of the FedRAMP extension. # 2 Brian Ruf 2026-04-15 12:27:25 In TFG meeting we agree that: - We favor aggregation, but must be clear about HOW to aggregate. - We also need to cover override/exception indicators. Implementaiton Status 1 open · 0 archived Open Comments # 1 Brian Ruf 2026-04-15 03:23:26 Open This page requires more analysis and the associated FedRAMP extension should be carefully re-considered. # 2 Brian Ruf 2026-04-15 12:27:11 In TFG meeting we agree that: - We favor aggregation, but must be clear about HOW to aggregate. - We also need to cover override/exception indicators. Archived Comments 19 FedRAMP FedRAMP Common Roles 0 open · 1 archived Archived Comments # 1 Erik Cass 2026-03-17 16:28:16 (edited 2026-04-08 14:32:43) Archived According to the fedramp-automation validator, the following additional role appears to be required: - fedramp-pmo: FedRAMP Project Management Office (PMO) # 2 Brian Ruf 2026-04-08 01:09:41 Good catch. I'm more inclined to remove this from the validator, but we should discuss either way. Title Pages 0 open · 1 archived Archived Comments # 1 Erik Cass 2026-03-26 02:11:43 (edited 2026-04-08 12:48:24) Archived @Brian Ruf I added an additional prop reference based upon the guidance formally found on the FedRAMP documentation website (since decomissioned). I preserved it mostly as is, but change the verb from "must" to "should" since the implied reference no longer exists. However, it seems like a useful addition. If not, my edit should be reverted. # 2 Brian Ruf 2026-04-08 01:19:45 I like the catch and addition of `marking`. Thank you! I removed the `fedramp-version` prop as that was tied to the validation file version, which is no longer relevant as PMO is no longer maintaining or publishing validation files. If we end up maintaining validation files and want to address that with a prop, it will need to be a different prop name. FedRAMP System Security Plan (SSP) 11. Seperation of Duties Matrix 0 open · 1 archived Archived Comments # 1 Brian Ruf 2026-02-25 13:21:53 (edited 2026-04-13 19:04:31) Archived @Brian Ruf to add content. # 2 Brian Ruf 2026-04-13 19:04:29 complete. 3. System Information 0 open · 2 archived Archived Comments # 2 Erik Cass 2026-03-10 22:31:43 (edited 2026-04-08 14:33:07) Archived There doesn't seem to be a pattern for the Digital Identity Level (DIL) Determination (folliow Service Model). As much a test of my own understanding as it is a recommendation, but what about this? As indicated above must be either IAL3/FAL3/AAL3 , IAL2/FAL2/AAL2 , or IAL1/FAL1/AAL1 . # 3 Brian Ruf 2026-03-11 19:13:45 It's actually covered in Appendix E, but should be linked from this page. I'll make that update. I haven't yet converted the example to YAML, but you can see it with XML here : # 4 Brian Ruf 2026-04-08 01:16:28 I didn't completely respond to your comment in my last response, and it's a fair question. I'd prefer to keep the three levels (IAL, FAL, AAL) separate even though the historic guidance is that all three are the same for a given baseline. If that guidance ever changes, I don't want people to have to change the props they use. Also, I believe the three separate props we are using are recognized as core OSCAL whereas a single prop would need to be a FedRAMP extension. # 1 Brian Ruf 2026-02-25 13:25:50 (edited 2026-04-08 14:33:20) Archived Switch XML to YAML Switch XPath to JSON Pointer (https://datatracker.ietf.org/doc/html/rfc6901) Apply to all pattern content. # 5 Brian Ruf 2026-04-08 14:33:18 Per TFG discussion, we are not including paths/pointers in the documentation at this time. 7. External Systems and Services Not Having FedRAMP Authorization 0 open · 1 archived Archived Comments # 1 Rene M. Tshiteya 2026-03-31 17:58:53 (edited 2026-04-13 19:00:36) Archived Todo: Convert XPath queries to JSON Pointer # 2 Brian Ruf 2026-04-13 19:01:47 We have agreed to skip any form of path for now. 8. Illustratred Architecture and Narratives 0 open · 1 archived Archived Comments # 1 Rene M. Tshiteya 2026-03-31 18:11:24 (edited 2026-04-13 19:00:48) Archived Todo: Replace XPath queries with JSON Pointer # 2 Brian Ruf 2026-04-13 19:01:39 We have agreed to skip any form of path for now. 9. Services, Ports and Protocols 0 open · 1 archived Archived Comments # 1 Rene M. Tshiteya 2026-03-31 18:50:06 (edited 2026-04-08 14:31:34) Archived To do: Replace XPath queries with JSON Pointer # 2 Brian Ruf 2026-04-08 00:51:00 We have since agreed not to include paths at this time. Appendicies Overview 0 open · 1 archived Archived Comments # 1 Rene M. Tshiteya 2026-03-18 03:28:40 (edited 2026-04-13 19:03:20) Archived Should Separation of Duties matrix be listed as an optional attachment (e.g., for MVP) or do we have a good way to represent this in OSCAL? # 2 Brian Ruf 2026-04-13 19:03:15 Separation of duties matrix is now addressed in Section 11 . Inventory: Normalized Approach 0 open · 1 archived Archived Comments # 1 Rene M. Tshiteya 2026-03-31 19:42:57 (edited 2026-04-08 14:31:14) Archived To do: Replace XPath queries with JSON Pointer # 2 Brian Ruf 2026-04-08 14:31:10 Per TFG discussion, we are not including paths/pointers in the documentation at this time. Native Adoption Path 0 open · 1 archived Archived Comments # 1 Brian Ruf 2026-04-15 12:35:33 (edited 2026-04-15 14:21:56) Archived Add note to clarify FedRAMP PMO prefers new systems to start with 20x. # 2 Brian Ruf 2026-04-15 14:21:54 done. Prepared By/For 0 open · 2 archived Archived Comments # 3 Brian Ruf 2026-04-08 21:05:22 (edited 2026-04-13 19:06:21) Archived Add link to callout # 4 Brian Ruf 2026-04-13 19:06:19 done # 1 Rene M. Tshiteya 2026-03-18 03:19:26 (edited 2026-04-08 20:46:52) Archived Typo in the page heading / title # 2 Brian Ruf 2026-04-08 01:11:31 Looks like this was resolved. If you agree, please archive this comment. Retrofit Adoption Path 0 open · 3 archived Archived Comments # 6 Brian Ruf 2026-04-08 12:55:17 (edited 2026-04-14 18:57:17) Archived Add note to adoption pages that anything not converted to machine readable should still be attached as a Word artifact. # 7 Brian Ruf 2026-04-14 18:57:15 Done. # 2 Brian Ruf 2026-03-18 12:16:56 (edited 2026-04-02 15:53:02) Archived Per today's TFG, need to clarify that this approach is focused on legacy Word SSP conversion. Need a different approach for "New" SSP authors who should likely start with components. # 4 Brian Ruf 2026-03-26 18:40:04 This page is now part of a larger adoption topic that covers both retrofit and new adoptions. # 1 Rene M. Tshiteya 2026-03-18 03:05:26 (edited 2026-04-02 15:53:48) Archived The SSP adoption strategy described on this page is well suited for systems that are already authorized / already have an SSP. However, CSPs that are early in their authorization journey may be better positioned to attempt the "advanced" / "ideal" path from the get go, especially if they have access to OSCAL-ready GRCs and tooling. # 5 Brian Ruf 2026-04-02 15:53:42 This is now addressed as the New Adoption Path. SSP Adoption Strategies 0 open · 1 archived Archived Comments # 1 Brian Ruf 2026-04-15 12:35:38 (edited 2026-04-15 14:22:11) Archived Add note to clarify FedRAMP PMO prefers new systems to start with 20x. # 2 Brian Ruf 2026-04-15 14:22:09 done ⚠ Recycle Bin 3 The following comments are attached to pages currently in the Recycle Bin . They are likely no longer relevant. You can permanently delete or restore the pages via the Recycle Bin . Background Deleted: 2026-04-08 12:27:33  ·  1 open · 0 archived Open Comments # 1 Erik Cass 2026-04-06 16:44:32 Open Note: the above repos have been removed as of April 6th, 2026. However, forks are available: https://github.com/search?q=fork%3Atrue%20fedramp-automation%20GSA%20in%3Aname&type=repositories https://github.com/search?q=fork%3Atrue+automate.fedramp.gov+GSA+in%3Aname&type=repositories Use at your own discresion as they may not represent the lastest content as of source decomissioning. # 2 Brian Ruf 2026-04-08 12:25:51 Either: - remove or background page (leaning in this direction) - keep, but don't include links - keep and link to oscal-foundation forks System Roles Deleted: 2026-03-13 18:41:09  ·  1 open · 0 archived Open Comments # 1 Brian Ruf 2026-02-25 13:21:05 Open Add Section 5 roles here. Then point section 5 here. Document Attachments Deleted: 2026-03-11 04:05:43  ·  1 open · 0 archived Open Comments # 1 Erik Cass 2026-03-10 22:16:15 (edited 2026-03-10 22:17:20) Open @Brian Ruf Looking at the schema, i think the correct prop name under resource is "Published" not "Publication".