Consolidated 20x Phase 2 pilot Q&A / discussion

[pete-gov]

FedRAMP is requesting that participants ask questions in public during Phase 2 instead of sending emails to FedRAMP.

This will encourage continued transparency, reduce effort on FedRAMP staff, and ensure everyone has access to information they need by addressing questions that someone else might be wondering but doesn't feel up to asking. This also provides a single thread to ensure previously asked questions are easy for folks to quickly review.

Please use this thread to ask questions about the Phase 2 pilot. Thank you for your continued public participation!

[pete-gov]

I'm going to close out this other thread asking about Cohort 1 application and submission but carry the content over here for reference.

@pete-gov Is the assumption correct? If 5 CSPs submit their application in for Cohort 1, only 3 will be selected and the remaining 2 are completely out. Meaning the ones not selected cannot go into Cohort 2. In this scenario, the two that are voted off the island will have to wait for the public submission which is now targeted to be late Q3? Thanks.

After a pilot proposal, providers will either be accepted into the pilot or disqualified from the pilot. 3 will be accepted into Cohort 1, while 7 will be accepted into Cohort 2. Any providers who qualify during Cohort 1 but aren't chosen for that cohort will be entered into Cohort 2.

We are, in generally, strongly discouraging folks from over-indexing on trying to be first, trying to rush into Cohort 1, etc. It will be a brutal slog. Folks should NOT be trying to rush their way into this pilot.

[wahlay5497]

Thank you @pete-gov. Some additional question around P2 submission:

• What would the definition of done be during the collaborative workshop/process?
• If we are accepted into cohort 1, the ultimate deliverable is submitting the package on Jan 27, but are there other milestones or expectations of completeness throughout that timeframe?
• Are there any specific technical pieces that need to be ready by time of application? Specific standards have to already be defined in the submission, percentages or coverage of KSIs already in place, etc?

[pete-gov]

Some of this will adjust during the pilot, and I'd caution against approaching this thinking there are firm acceptance criteria in place that be banked on in advance - that wouldn't be much of a pilot. ;)

• What would the definition of done be during the collaborative workshop/process?

We want the cloud service provider, their assessor, and FedRAMP to all be confident that the provider is ready to finalize a package and submit it. This will take as long as it takes, and if we can't get there then the cloud service provider will be asked to step back.

• If we are accepted into cohort 1, the ultimate deliverable is submitting the package on Jan 27, but are there other milestones or expectations of completeness throughout that timeframe?

Cohort 1 collaborative workshops will take place during December - we'll expect them to have been finished before we start Cohort 2.

• Are there any specific technical pieces that need to be ready by time of application? Specific standards have to already be defined in the submission, percentages or coverage of KSIs already in place, etc?

At time of application? Providers should have enough in place that we can be confident completion is achievable within two months. If you come into a pilot proposal without anything done (no trust center, no authorization data sharing prototype, no VDR proof of concept, etc.) then you've got quite an uphill battle convincing us you can do that in two months. :)

The overall number of requirements and recommendations to address between Phase 1 and Phase 2 went from like ~80 to ~400. I really don't expect many folks to be crazy enough to try to build all of that in two months.

[KenPalmer517]

Thanks @pete-gov for the response, really appreciate the information here. I had one question on the collaborative workshop schedules in December because the back half of December is pretty US holiday heavy. If a CSP was accepted to Cohort 1, is there a timeframe around the holidays where these meetings would not take place? (like can we assume that Christmas Eve, Christmas, New Years Eve, New Years won't have workshops scheduled?)

[pete-gov]

If a CSP was accepted to Cohort 1, is there a timeframe around the holidays where these meetings would not take place? (like can we assume that Christmas Eve, Christmas, New Years Eve, New Years won't have workshops scheduled?)

Oh yeah def, we have families too. ;) I'm hoping to front load these workshops from Dec 10 to Dec 19 and am expecting to spend up to ~4hrs/day on them to get through them. This is a big reason why Cohort 1 is limited to 3 participants and I'll expect them to be READY TO GO, won't have enough time to get through them before January otherwise.

[pete-gov]

Update on 20x Phase 2 sent to qualified Phase 1 participants

For public transparency, the following email was sent to all qualified Phase 1 participants today:

---

Hi again all! For your awareness, I'm sending this note to all Phase 1 participants who are eligible to apply for Phase 2 participation via bcc at the contact email you provided during your submission.

This week, shortly after the conclusion of the longest government shutdown in history, we shared an updated plan for Phase 2. It aligns with some of what we have previously shared but tightens up requirements, applies stricter participation criteria, and includes a multi-cohort approach to ensure that we can spend time directly with participants to save everyone time and effort in the long run during the Phase 2 pilot.

Importantly, we are now placing a strict 10 participant cap on the pilot (vs the previous soft goal) and will require interested participants to apply for participation with a detailed proposal. During the pilot itself, providers will be required to engage in multiple collaborative workshops with the FedRAMP team to review your approach to each and every requirement in advance of finalizing a package. We have also added a new KSI theme called "Authorization by FedRAMP" that effectively increases the number of requirements and recommendations that must be addressed by 5x.

If you haven't dug in yet, please review our Key FedRAMP Updates After the Shutdown blog post from earlier in the week for all the details (you'll want to carve out a solid couple of hours to work through all the new content and finalized requirements).

The Phase 2 pilot will be by far the most difficult phase of 20x for any cloud service provider. Phase 1 was deliberately quite simple while future phases will be supported by more explicit guidance, best practices, and (most importantly) more readily available third-party tools for automating these requirements. Participants will need to commit considerable engineering resources to build to each requirement and engage a FedRAMP recognized independent assessor on a recurring time-and-materials basis over the course of 6-8 weeks at their own expense.

I do not expect most of you to apply for participation in the Phase 2 pilot. I strongly encourage you to review all of the requirements in depth, every single one, and discuss them with your engineering and compliance teams (as well as senior leadership) prior to determining if you should apply. If you still do decide to apply, I encourage you to apply for Cohort 2 where you can have a solid 6 weeks to prepare an approach that you can be confident in (and make sure you have contracts in place for assessment/etc.). Plus folks in Cohort 2 won't have to work as much over the holidays! ;)

For those of you still going through review during Phase 1, know that we are committed to completing your review and you can still come through this with a 20x Low pilot authorization while we work with others on Phase 2. You'll have a year to integrate all of the requirements being tested in Phase 2.

All that said - I'm looking forward to catching up with some of you and hearing from you during the upcoming Cohort 1 application period starting on December 1, and I hope everyone else will continue to participate at your own pace.

If you have any questions about any of this, please post them in the (new) Consolidated 20x Phase 2 pilot Q&A / discussion thread on GitHub. Thank you - we'll keep building 20x together. 💪🔒☁️ 🇺🇸

[arpita-vanta]

Hi Pete, I have a question regarding the application periods and the distinction between the proposal vs the presentation timing. Is the expectation that the proposal and presentation will both take place between the application period (so December 1-5 or January 5-9), or is that simply when we will be proposal is due, and then the pilot proposal presentation follows sometime after the application period.

[emu-gov]

Not Pete, but for Phase 2 we are scheduling presentations for eligible CSPs as we receive their intent to apply. Things will move fast.

Your proposal & presentation IS your application for Phase 2, so that is why we advise preparing your proposal before notifying us of your intent.

[arpita-vanta]

Thank you!

[lesley-hess]

"KSI-IAM-06 Suspicious Activity" is missing the applicability designation on https://www.fedramp.gov/docs/key-security-indicators/#ksi-iam-05-least-privilege. Is that intentional or an error?

[emu-gov]

Impact is missing from our source data on this, will file a PR. Thanks!

This was an OG KSI from Phase 1 that was updated, so applicability should be Low & Moderate. Will @ you when updated.

[pete-gov]

This is fixed now - and I've added validation to ensure impact level is always included in the future. Thank you for the spot!

[jnguyen1294]

Hi PMO, we're evaluating the requirements for the Phase 2 pilot proposal and being a bit pedantic to make sure we provide the expected answers.

1. How the cloud service provider will approach defining objectives and validation criteria for Key Security Indicators.
2. The planned high-level approach to addressing all requirements and recommendations in the KSI-AFR theme, including how authorization data will be shared in alignment with KSI-AFR-03 (ADS).

Coming from Phase 1, Key Security Indicators were all of the controls that we implemented automation for to evaluate our security posture. With the updated guidelines published earlier this week, what was referred as KSIs in Phase 1 are now "embedded" into KSI-AFR-02.

For the requirements for the pilot proposal, is requirement 1. referring to the subset of KSIs under KSI-AFR-02? Or is it referring to all of the KSIs including the ones under the AFR theme? If the latter, then I that'd be redundant with requirement 2., so I'm thinking the prior (similar to what was asked for Phase 1 in terms of approach to automatically validating the KSIs under KSI-AFR-02). The confusion we simply have is what we considered as KSIs in Phase 1 is now KSI-AFR-02, but the new documentation also refers to KSIs as everything inclusive of AFRs.

Perhaps instead of answering my question directly, if the requirements for pilot submission can be reworded to clear up which "Key Security Indicator" it is referring to, that would give us more clarity when putting together our pilot proposal. Thank you in advance!

Reference screenshot taken from the right sidebar of https://www.fedramp.gov/docs/key-security-indicators/

[emu-gov]

The AFR "KSI theme" (what folks may have previously called KSI category or family) is specifically called out as this was an area we saw proposals for other, non-KSI standards being missed in Phase 1. This theme includes the newer standards that have been released since the start of Phase 1 (AFR, VDR, ICP, etc).

So yes, describe how you will define objectives and validation criteria for the Key Security Indicators (CED, INR, CNA, etc) but also review the standards individually addressed within the AFR theme and explain your approach for each.

Hope that helps!

[pete-gov]

Yep you're right that KSI-AFR-02 can create an infinite loop. The easiest way to handle this is probably just to have KSI-AFR-02 itself be a summary of the implementation plans/statistics of all of the other KSIs rather than a full nested list of all the KSI's that goes to infinity. Pretty much agree with Emu here.

We'll work through this with pilot participants - the other KSI-AFR theme stuff will probably have massive nested objects addressing each requirement and recommendation in the associated theme while KSI-AFR-02 should definitely not do that (unless someone thinks that's cooler).

For the requirements for the pilot proposal, is requirement 1. referring to the subset of KSIs under KSI-AFR-02? Or is it referring to all of the KSIs including the ones under the AFR theme?

lol. We added the KSI-AFR theme to explicitly require addressing every single requirement and recommendation in every single 20x policy/standard/etc. as well as all the KSIs from other themes. This way instead of saying "You have to meet the KSIs and these 12 policies" we can just say "you have to meet the KSIs." That was the intent of this structure. I'm laughing because we hoped this would make things more clear but maybe that didn't work. :)

So KSI-AFR-04 (Authorization Data Sharing), for example, means that you have to address everything related to Authorization Data Sharing, starting at FRR-ADS-01 all the way through, in order to demonstrate how that indicator is met.

Remember, FRR-KSI-01 applies: "Cloud service providers SHOULD apply ALL Key Security Indicators to ALL aspects of their cloud service offering that are within the FedRAMP Minimum Assessment Scope. "

Supplemented by the KSI-AFR overall theme indicator: "A secure cloud service provider seeking FedRAMP authorization will address all FedRAMP 20x requirements and recommendations, including government-specific requirements for maintaining a secure system and reporting on activities to government customers. "

[jnguyen1294]

Thanks for both of your responses! This gives clarity to what type of information we should include in the pilot proposal.

[ElaineFR]

Hi @pete-gov , question from my team regarding a third party tool. If you have a non-FR system that does not have FIPS enforcement on their end, can we encrypt the actual data in flight and in storage on OUR end before sending to them and maintain compliance? We would assure that ALL usage of this system would be encrypted on our side before sending it to the non-FR system.

[ElaineFR]

Thanks for the insight Pete! I'll take this back to the team.

[pete-gov]

Side note: FedRAMP doesn't require use of NIST validated crypto modules for 20x Moderate or Low because agencies typically do not use FIPS-140 based cryptographic modules for accessing and transmitting data between agencies and SaaS cloud services that are typically accessed via a browser over the internet; therefore these AOs have already accepted the risk of not relying on FIPS-140 based cryptographic modules for sending information over the public internet and it does not make sense for them to expect the data to be encrypted by such when stored at a provider facility.

If an agency doesn't consider data sensitive enough to be encrypted using a NIST validated crypto module in transit to a cloud service then it shouldn't matter if the cloud service uses such modules either. There are situations with Moderate impact cloud services where an agency would have NIST validated crypto modules in place for transit and expect the provider to meet those requirements due to sensitivity though.

You can expect at some point we'll have little badges that say "All federal customer data is encrypted using a NIST validated crypto module at all times" for cloud services that support it so agencies can align their use cases appropriately.

[fv-ian]

Thanks @pete-gov . The challenge we have is there is a tooling (without naming names today in a public forum) which offers the ability for us to control the keys and encrypt all the data we send to them in a pretty smart way. The SaaS provider can't decrypt it. All the SaaS provider sees is an encrypted payload. From our end we need to assure that all of our services when talking to this SaaS provider are forced to be encrypted by a variety of methods like firewall controls on outbound, internal reviews, a proxy system.

If I'm hearing you correctly, as long as we do in good faith and document to prove we are being as secure as we can be plus some, it ultimately falls to the agency to decide that's a risk worth accepting or not.

[pete-gov]

The SaaS provider can't decrypt it. All the SaaS provider sees is an encrypted payload.

Documenting that is key then, and yes it does considerably lower (but not eliminate) the risk. Turns it into a bit of a wild chain that would be necessary for compromise (exfiltrated encryption keys + exfiltrated third party saas data dump) so for most workloads that would be sufficient protection with appropriate attention paid to keys/etc.

If I'm hearing you correctly, as long as we do in good faith and document to prove we are being as secure as we can be plus some, it ultimately falls to the agency to decide that's a risk worth accepting or not.

Yes, that's exactly right! In this case I'd very much encourage this documentation (and more important, ongoing validation to ensure it's working that way and that keys aren't being sent) make it clear that the third party will not have access to unencrypted data or keys (even BYOK style stuff where the key is provided to them) and that you chose a strong encryption algorithm etc. Should make it fairly easy to accept for anything but the most sensitive data.

[dan-fedramp]

You should also be sure to document how you will manage rotating the encryption key(s). When you change the encryption key it would be necessary to download all the data encrypted with the old key, decrypt it locally, re-encrypt it with the new key, and then upload it all again. Depending on the amount of data being stored this could become a significant workload and may limit the usefulness of the service or increase the cost if there are fees for inbound or outbound traffic. You can mitigate this risk by using individual encryption keys for discrete files or data sets. But this would require more complex key management.

However you choose to approach key management in a situation like this it is important to have the process well documented and to monitor the process for any potential errors.

[pete-gov]

Adding a couple general updates for folks:

• We pushed out some minor documentation updates today, with the primary change being that FedRAMP 20x requirements and recommendations are no longer called "standards" to avoid confusion with NIST standards. Instead these will generally be referred to as a "process" or "documentation."
• Some structure was added to the Docs site to make things a bit more progressive and easier to read through.
• The underlying JSON structure of the FRMR materials was restructured a bit - apologies in advance as this may break various importers/etc. but it should be easy to update based on the supplied JSON Schema. In short we moved effective/applicability information out of the specific release array and into a general top level object (and added a bunch of Rev5 stuff).
• We recommend folks work from the FRMR JSON rather than the markdown docs for actual implementation.
• Finally, we added a high level summary table of all requirements, it's a bit janky but the estimate is around ~150 total requirements and recommendations to address in addition to the 65 KSIs for Moderate.

This week we'll be running interested (and qualified) Phase 2 participants through the initial Cohort 1 shark tank - so far we have 5 cloud service providers signed up!

[adamchuneit]

I’ve been following along with 20x discussions and have heard things about pentesting in 20x but was unable to find guidance specifying the requirement for pentesting and red team in 20x assessments. Will pentests and red team be required for 20x? If so, do will they match the currently posted guidance based on rev.5?

Also, I noticed that the latest draft version of the penetration testing guidance which included a red team section was removed from public access. Is there another version we should use or look out for other than the version on the website dated 2022-06-30?

[pete-gov]

I’ve been following along with 20x discussions and have heard things about pentesting in 20x but was unable to find guidance specifying the requirement for pentesting and red team in 20x assessments. Will pentests and red team be required for 20x? If so, do will they match the currently posted guidance based on rev.5?

Under 20x, penetration testing and red-teaming is part of Vulnerability Detection and Response. Cloud service providers are not required to perform these activities but are instead expected to determine if those activities will have positive security outcomes and leverage them as appropriate for their specific situation.

In general, cloud service offerings that regularly run penetration testing and perform red-team style exercises are more likely to have better security and will receive better scoring on FedRAMP assessments if they can prove the beneficial security outcomes from those activities.

Also, I noticed that the latest draft version of the penetration testing guidance which included a red team section was removed from public access. Is there another version we should use or look out for other than the version on the website dated 2022-06-30?

Nope, that's the only current official guidance for Rev5 penetration testing. If FedRAMP produces updated materials for this it will go through our RFC process but we do not currently plan to provide updated guidance for Rev5 on this. Draft guidance shouldn't be used as if it is formal guidance - we switched to the RFC process to avoid that confusion in the future.

[tnnrjmsn-eit]

Under 20x, penetration testing and red-teaming is part of Vulnerability Detection and Response. Cloud service providers are not required to perform these activities but are instead expected to determine if those activities will have positive security outcomes and leverage them as appropriate for their specific situation.

One could also say that [if they go grepping through the VDR--pronounced like Luke and Leia's father, I digress--and see a goose egg] that red-teaming is implied by KSI-PIY-04 | CISA Secure by Design as a "MAY" process/guidance [to use the new terminology], as "red team exercises" is mentioned in the CISA paper under Secure by Default Practices > 2. Conduct field tests, as a Note:

To gain deeper insights into these elements, software manufacturers may wish to partner with customers to conduct red team exercises to see how the product resists attacks. These field tests might take place at the customer’s physical site, virtually, or via telemetry from the application in a privacy-preserving manner.

[DataDude100]

I apologize for posting this question here; however, the other seemingly more appropriate sections (Discussion 4 and Discussion 6) have been closed.

With respect to the significant change process, my organization has received external guidance (not from any FedRAMP-affiliated source) indicating that, in order to initiate this process, our CSO must possess both a FedRAMP 20x program authorization and an agency-issued ATO.

I have been unable to locate any such requirement within the FedRAMP 20x GitHub repository, including guidance pertaining to “transformative” changes. The only related directive I have found states that, if an agency partner exists, it must be notified in advance of the intent to invoke the significant change process.

Could FedRAMP please confirm whether this dual-authorization requirement is accurate? Any clarification would be greatly appreciated. Thank you in advance for your assistance.

[pete-gov]

I think @pete-gov meant Feb. 27th, 2026:

Yes, thank you. Edited the statement above to avoid confusion. We definitely are NOT waiting until 2027. ;) We're currently in Fiscal Year 2026 so my brain keeps wanting to pretend like we're in 2026 and only a couple of months away from 2027.

[DataDude100]

I may have written the question poorly so perhaps an example will help.

Let's say in the future a CSP has achieved a FedRAMP 20x Moderate authorization for its new CSO but has no agency users of it yet. (The CSO has no rev5 FedRAMP status or ATO.) The CSP makes a "transformative change" to the offering and desires to invoke the significant change notification (SCN) process (whatever that turns out to be for FedRAMP 20x) to maintain its existing 20x authorization. Can the SCN be invoked with no agency users of the offering (i.e., no agency ATOs have been issued)?

Note this situation is strictly within the FedRAMP 20x domain so I'm confused as to why rev5 SCN guidance is referenced in the previous responses (unless rev5 SCN policy shall become 20x policy).

Thanks again for the responses.

[tnnrjmsn-eit]

We're currently in Fiscal Year 2026 so my brain keeps wanting to pretend like we're in 2026 and only a couple of months away from 2027.

Been there. Done that. 😁 (I figured that was the case. 👃)

[pete-gov]

I may have written the question poorly so perhaps an example will help.

Ah, that's probably my bad, I misread your question on my phone as asking if someone had to have a 20x authorization to follow the SCN process.

Let's say in the future a CSP has achieved a FedRAMP 20x Moderate authorization for its new CSO but has no agency users of it yet. (The CSO has no rev5 FedRAMP status or ATO.) The CSP makes a "transformative change" to the offering and desires to invoke the significant change notification (SCN) process (whatever that turns out to be for FedRAMP 20x) to maintain its existing 20x authorization. Can the SCN be invoked with no agency users of the offering (i.e., no agency ATOs have been issued)?

The Significant Change Notification process is intended to allow cloud service providers to make changes to their services without explicit government approval. There is no requirement in the SCN process for an agency AO to approve any part of the process.

Under 20x, cloud service providers simply need to follow the process and address all requirements and recommendations in the process - this is how they earn and maintain their FedRAMP authorization. It doesn't matter if there is an agency ATO of the system or not. FedRAMP will validate that providers are following the process and take corrective action against those who don't.

It's worth noting that 20x requirements are designed to allow a prospective agency customer to see how well a cloud service has done at meeting 20x requirements historically (such as Significant Change Notifications, Vulnerability Detection and Response, etc.) so that this can factor into the authorization decision.

[DataDude100]

Thanks for the clarity @pete-gov!

[ethanolivertroy]

This project from Defense Unicorns seems like it could be super useful to establishing a gitops process
https://github.com/defenseunicorns/lula

[ElaineFR]

Hi @pete-gov , hope you are having a great day! Question for you: To apply to cohort 2, do automations need to be built for the
[Jan 5, 2026 - Jan 9, 2026 | Cohort 2 application period, up to 7 cloud services selected]? Or is it a presentation of the plans to build automations?

Also, do you have an approximate timeline for FR20x Moderate opening to the public after the pilots conclude?

Thank you for any help!
Elaine

[pete-gov]

Hi @pete-gov , hope you are having a great day!

I am having a very wonderful day, thank you! ;D

Question for you: To apply to cohort 2, do automations need to be built for the [Jan 5, 2026 - Jan 9, 2026 | Cohort 2 application period, up to 7 cloud services selected]? Or is it a presentation of the plans to build automations?

We're looking for the planned high-level approach to address all requirements... but that approach should demonstrate how you will do so within two months as the submission deadline for Cohort 2 is March 10. If a cloud service's proposal includes a bunch of stuff that isn't implemented yet then it's unlikely we'd select them over cloud services whose proposal shows they don't have a whole let left to do.

In Cohort 1, the 3 services we selected all demonstrated considerable progress with minor gaps. It will be the same for Cohort 2.

Also, do you have an approximate timeline for FR20x Moderate opening to the public after the pilots conclude?

That is part of Phase 3, which is currently planned for FY26 Q3 to Q4:

• https://www.fedramp.gov/20x/#phased-delivery-of-fedramp-20x
• https://github.com/FedRAMP/roadmap
• https://www.fedramp.gov/disclaimers ;)

[ElaineFR]

Thank you Sir!

[ethanolivertroy]

Just something to consider for the builders - TruffleHog is a good thing to put in your pipelines - https://github.com/trufflesecurity/trufflehog

https://trufflesecurity.com/blog/scanning-5-6-million-public-gitlab-repositories-for-secrets

[stepheneng-jpg]

Hi @pete-gov and @emu-gov, happy holidays!

I noticed that in FRMR.SCN.significant-change-notifications.json, the individual FRR IDs starting with FRR-SCN-04 and onward do not include a name field. I was not sure if this was intentional, since all the other FRR IDs do include names, so I wanted to flag it in case this was a mistake.

Here is a link to the relevant section for reference:
https://github.com/FedRAMP/docs/blob/main/FRMR.SCN.significant-change-notifications.json#L170-L274

I would have opened an issue directly, but it looks like issues are restricted on the repo.

[pete-gov]

This is just a direct result of me not carving out the time to do the rest of them for the SCN and not prioritizing going back and finishing. ;) Hopefully there will be some down time this week I can crank those out, thank you for the reminder!

[stepheneng-jpg]

@pete-gov @emu-gov it’s me again :) I know things are still changing a lot, but I wanted to flag in case it’s helpful to you all.

In the Recommended Secure Configuration JSON, starting with FRR-RSC-03, the requirements statement uses SHOULD, but the primary_key_word is set to MUST. Not sure if that mismatch is intentional.

Relevant section:
https://github.com/FedRAMP/docs/blob/main/FRMR.RSC.recommended-secure-configuration.json#L112-L154

[pete-gov]

In the Recommended Secure Configuration JSON, starting with FRR-RSC-03, the requirements statement uses SHOULD, but the primary_key_word is set to MUST. Not sure if that mismatch is intentional.

Thank you! That is a bug and has been hotfixed in the docs repo. Much appreciated!

[stepheneng-jpg]

Thanks @pete-gov !! I appreciate it. I just saw the commit, and I think FRR-RSC-04, FRR-RSC-05, and FRR-UCM-02 might have the same issue (SHOULD vs MUST)

[pete-gov]

lol well, created a quick script to verify these keywords match and rapidly found a bunch of other mismatches which are (in theory) ALL fixed now... probably should've done this earlier. Will make a note to add this to the testing at some point. Thank you!!!

[pete-gov]

For public awareness and transparency, the following message was sent to all cloud service providers eligible to apply for Cohort 2 today:

(this message from FedRAMP is informational and all action is optional - no response is necessary)

The first cohort for the 20x Phase 2 pilot is off working hard to incorporate feedback and finalize their 20x Phase 2 packages, the holidays are (mostly) in the bag, and we're ready to tackle the second cohort! If you're receiving this message then you are eligible to apply for participation in Cohort 2 next week.

As a reminder, Phase 2 is much more complicated than Phase 1 and we do not expect most of you to participate in Phase 2. A big shift in Phase 2 is that we're moving well past the boolean "do you do this yes/no" from Phase 1 and focusing heavily on measuring outcome and effect. Plus we added 100+ additional requirements and recommendations in the KSI-AFR theme that must be addressed - and all of this will need to be done prior to March 10.

In short, if you don't already have a strong prototype implementation from Phase 1 or haven't started implementing the requirements and recommendations in the KSI-AFR theme then you're unlikely to meet the Phase 2 pilot requirements in the expected timeframe.

If that didn't scare you off, the next step is a pilot proposal next week. This pilot proposal is a simple presentation that you'll make to FedRAMP that shows us how ready you are to meet all of the Phase 2 pilot requirements in the expected timeframe. It's not a product pitch or even about your product at all - instead, we expect to hear about how much you've already implemented, how little you have remaining, and how you're going to tackle the KSI-AFR theme.

And don't forget you need a FedRAMP recognized 3PAO who you've already been working with to share how they are going about the independent verification and validation of your approach! Pro-tip: Review the Cohort 1 pilot proposals and consider that the bar is definitely higher for Cohort 2.

To apply for Cohort 2: Head over to this Google calendar link, check the time slots the week of Jan 5, and book a pilot proposal slot!

A final heads up: Based on the discussions in Cohort 1 we will be releasing updated Key Security Indicators very soon. These updates won't change the intent of any KSI but will hopefully add clarity and specificity to a few that are a bit confusing and will remove a couple more that have become redundant. We're also going to do 1.5hr collaborative workshops instead of 2hr workshops because we learned that 2hrs was a lot. Things change, just in case you forgot it was a pilot. ;)

[ElaineFR]

Thank you @pete-gov , this link seems to take me to a YouTube video. Can you please provide a refreshed link to schedule?

…

> To apply for Cohort 2: Head over to this Google calendar link<https://youtu.be/dQw4w9WgXcQ>, check the time slots the week of Jan 5, and book a pilot proposal slot!

[stepheneng-jpg]

haha nice rick roll. @ElaineFR i think this is just the "for public awareness version" on github. If im not mistaken, the CSPs eligible received the up to date link.

[pete-gov]

haha nice rick roll. @ElaineFR i think this is just the "for public awareness version" on github. If im not mistaken, the CSPs eligible received the up to date link.

This is correct. ;)

[ElaineFR]

Thanks - I have not seen one for Filevine yet, but I'll keep an eye out. :)

[pete-gov]

Thanks - I have not seen one for Filevine yet, but I'll keep an eye out. :)

I sent you a direct note, these messages went to the primary contact address for most folks!

[pete-gov]

Big Key Security Indicators Update!!

For everyone's awareness, we just released version 25.12A for the Key Security Indicators:

• Machine Readable Version (which I'm sure you're already using if you're in the pilot)
• Human Readable Version

From the changelog:

This release updates a significant number of KSIs to improve clarity and expectations; in general the measures required to meet each KSI remain unchanged but these updates should make it easier to address them. In additional, some KSIs have been retired.

After these retirements, there are now 56 low and 61 moderate KSIs.

Detailed changes

You can likely generate the delta quite easily from the machine readable versions but here are the notes I worked off when making these changes for reference.

KSI-CED-01 General Education
Require and monitor the effectiveness of training given to all employees on policies, procedures, and security-related topics.
New: Persistently review the effectiveness of training given to all employees on policies, procedures, and security-related topics.

KSI-CED-02 Role-Specific Education¶
Require and monitor the effectiveness of role-specific training for high risk roles, including at least roles with privileged access.
New: Persistently review the effectiveness of role-specific training given to employees in high risk roles, including at least roles with privileged access.

KSI-CED-03 Development and Engineering Education¶
Require and monitor the effectiveness of role-specific training provided to development and engineering staff that covers best practices for delivering secure software.
New: Persistently review the effectiveness of role-specific training given to development and engineering staff that covers best practices for delivering secure software.

KSI-CED-04 Incident Response and Disaster Recovery Education¶
Require and monitor the effectiveness of role-specific training to staff involved with incident response or disaster recovery.
New: Persistently review the effectiveness of role-specific training given to staff involved with incident response or disaster recovery.

KSI-CMT-02 Redeployment¶
Execute changes though redeployment of version controlled immutable resources rather than direct modification wherever possible
New: Execute changes to machine-based information resources through redeployment of version controlled immutable resources rather than direct modification wherever possible.

KSI-CMT-04 Change Management Procedure¶
Always follow a documented change management procedure.
New: Persistently review the effectiveness of documented change management procedures.

KSI-CNA-01 Restrict Network Traffic¶
Configure all machine-based information resources to limit inbound and outbound network traffic.
New: Persistently ensure all machine-based information resources are configured to limit inbound and outbound network traffic.

KSI-CNA-02 Minimize the Attack Surface¶
Design systems to minimize the attack surface and minimize lateral movement if compromised.
New: Persistently ensure machine-based information resources have a minimal attack surface and that lateral movement is minimized if compromised.

KSI-CNA-05 Unwanted Activity¶
Protect against denial of service attacks and other unwanted activity.
New: Persistently review the effectiveness of protection against denial of service attacks and other unwanted activity.

KSI-CNA-06 High Availability¶
Design systems for high availability and rapid recovery.
New: Appropriately optimize machine-based information resources for high availability and rapid recovery.

KSI-CNA-07 Best Practices¶
Ensure cloud-native information resources are implemented based on host provider's best practices and documented guidance.
New: Persistently ensure cloud-native machine-based information resources are implemented based on the host provider's best practices and documented guidance.

KSI-IAM-05 Least Privilege¶
Configure identity and access management with measures that always verify each user or device can only access the resources they need.
New: Persistently ensure that identity and access management employs measures to ensure each user or device can only access the resources they need.

KSI-INR-01 Incident Response Procedure¶
Always follow a documented incident response procedure.
New: Persistently review of the effectiveness of documented incident response procedures.
KSI-INR-02 Incident Logging¶
Maintain a log of incidents and periodically review past incidents for patterns or vulnerabilities.
New: Persistently review past incidents for patterns or vulnerabilities.

KSI-INR-03 Incident After Action Reports¶
Generate after action reports and regularly incorporate lessons learned into operations.
New: Generate incident after action reports and persistently incorporate lessons learned.

KSI-MLA-02 Audit Logging¶
Regularly review and audit logs.
New: Persistently review and audit logs.

KSI-MLA-05 Infrastructure as Code¶
Perform Infrastructure as Code and configuration evaluation and testing.
New: Persistently evaluate and test the configuration of machine-based information resources, especially infrastructure as code.

KSI-PIY-01 Automated Inventory¶
Use authoritative sources to automatically maintain real-time inventories of all information resources.
New: Use authoritative sources to automatically generate real-time inventories of all information resources when needed.

KSI-PIY-02 Security Objectives and Requirements¶
Document the security objectives and requirements for each information resource or set of information resources.
New: Retired / Superseded by KSI-AFR-01 MAS

KSI-PIY-03 Vulnerability Disclosure Program¶
Maintain a vulnerability disclosure program.
New: Persistently review the effectiveness of the provider’s vulnerability disclosure program.

KSI-PIY-04 CISA Secure By Design¶
Monitor the effectiveness of building security and privacy considerations into the Software Development Lifecycle and aligning with CISA Secure By Design principles.
New: Persistently review the effectiveness of building security and privacy considerations into the Software Development Lifecycle and aligning with CISA Secure By Design principles.

KSI-PIY-05 Evaluate Implementations¶
Document methods used to evaluate information resource implementations.
New: Retired / Superseded by KSI-AFR-04 VDR

KSI-PIY-06 Security Investment Effectiveness¶
Monitor the effectiveness of the organization's investments in achieving security objectives.
New: Persistently review the effectiveness of the organization's investments in achieving security objectives.

KSI-PIY-07 Supply Chain Risk Management¶
Document risk management decisions for software supply chain security.
New: Retired / Superseded by KSI-TPR-03

KSI-PIY-08 Executive Support¶
Regularly measure executive support for achieving the organization’s security objectives.
New: Persistently review executive support for achieving the organization’s security objectives.

KSI-RPL-01 Recovery Objectives¶
Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
New: Persistently review desired Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).

KSI-RPL-02 Recovery Plan¶
Develop and maintain a recovery plan that aligns with the defined recovery objectives.
New: Persistently review the alignment of recovery plans with defined recovery objectives.

KSI-RPL-03 System Backups¶
Perform system backups aligned with recovery objectives.
New: Persistently review the alignment of machine-based information resource backups with defined recovery objectives.

KSI-RPL-04 Recovery Testing¶
Regularly test the capability to recover from incidents and contingencies.
New: Persistently test the capability to recover from incidents and contingencies, including alignment with defined recovery objectives.

KSI-SVC-07 Patching¶
Use a consistent, risk-informed approach for applying security patches.
New: Retired / Superseded by KSI-AFR-04 VDR

KSI-SVC-08 Shared Resources¶
Do not introduce or leave behind residual elements that could negatively affect confidentiality, integrity, or availability of federal customer data during operations.
New: Persistently review plans, procedures, and the state of information resources after making changes to limit and remove unwanted residual elements that would likely negatively affect the confidentiality, integrity, or availability of federal customer data.

KSI-TPR-03 Supply Chain Risk Management¶
Identify and prioritize mitigation of potential supply chain risks.
New: Persistently identify, review, and mitigate potential supply chain risks.

[pete-gov]

Since these should not change the actual implementations for anything, we'll expect all 20x Phase 2 participants (including Cohort 1) to use this updated KSI package.

[iteuscher]

KSI-INR-01 Incident Response Procedure¶
Always follow a documented incident response procedure.
New: Persistently review of the effectiveness of documented incident response procedures.

One minor item of feedback, the new wording for INR-01 may want to be adjusted for smoother grammar. Either "Persistently review the effectiveness of" (removing the first of) or "Persistent review of the effectiveness of" (removing the -ly from Persistently) would read more smoothly.

[pete-gov]

One minor item of feedback, the new wording for INR-01 may want to be adjusted for smoother grammar.

Ah yes, thank you, that is supposed to be "Persistently review the effectiveness of documented incident response procedures." The continued perils of editing JSON files in VSCode without grammar checking 🤣

I've hotfixed that immediately in the FRMR JSON data but we won't roll that into a deployment into docs on the website until next week.

[fv-ian]

In the intent of the trust center tooling, is the idea that we have a historical capture of point in time state of our monitoring or is an active up to date viewpoint considered acceptable in showing each KSI? Then if we have the point in time in a given assessment that we can compare that against a previous point in time audit status to show improvements?

Example:

Using Wiz we can create links that show the current status of different KSI evidence. If I put that into our trust center, that link always shows the latest data for that evidence (say TLS is enabled for encryption and TLS 1.3 is the minimum on all load balancers). It is not a point in time capture of our status for compliance against an assessment of Jan for the FedRAMP 20x Low KSI.

Put another way.

Should we have point in time data uploads done on a regular scheduled of weekly that are effectively immutable on time of upload or is a dynamically changing proof of evidence considered acceptable?

[pete-gov]

For traditional FR Moderate and higher the expectation is that metrics and results of activities related to the Key Security Indicators will be tracked and presented over time rather than being a simple boolean. These should be maintained persistently in a cycle that makes sense per-metric (rather than per-KSI or per-CSO) and information about them also made available persistently in a cycle that makes sense (and doesn't necessarily match 1:1 with how it's collected).

This is a big part of what we're working to refine in the Phase 2 pilot so it's VERY fuzzy at the moment and we're very much leaning into the approach that makes the most sense for the pilot participant based on getting value out of these things rather than just having a dashboard spamming a bunch of stuff no one cares about.

For example, let's take something like KSI-AFR-10 (Incident Communications Procedures). For traditional FR Low and in the Phase 1 pilot we'd let people get away with having a boolean around "is there a policy that is up to date" and that's okay.

For traditional FR Moderate in Phase 2 we're going to expect that the CSP tracks the # of incidents to which the policy applies, the # of times they've notified FedRAMP as required, and the time to notify FedRAMP as well as how frequently that time was slower than required, plus all of the followup actions. So the persistent cycle for tracking that would be every time an incident is closed out and while the persistent cycle for adding that to the trust center is up to the CSP it'd probably make sense to also do that as part of incident closeout. There's no point in scheduling this to be weekly unless, uh, you're having incidents weekly. ;)

But that would be very different from the persistent cycle for other KSIs and each one needs to be considered appropriately!

[pete-gov]

To add:

The purpose of the trust center information for 20x is for any agency customer to assess the overall historical effectiveness of security activities of the cloud service offering any time they view it with minimal drift in time frame from the most recent activities.

[dan-fedramp]

One of the recurring themes in 20x is that tooling should be something you, the CSO, use as part of your normal business operations. So for the specific example about TLS, my question would be how often do YOU want to check to make sure that TLS is properly configured? Ideally the trust portal would show the current status as well as the results of any previous checks. Maybe not to the dawn of time but think about your own comfort level. If you suddenly found that TLS was misconfigured how much historical data would you want to have and at what time interval to help identify the root cause of that change.

[pete-gov]

The following notification was sent today to all Phase 2 pilot participants (including 3PAOs) - also sharing this with the public (no rickrolls this time, promise!).

---

Almost all of you have completed our collaborative workshops, and some of you have submitted authorization packages already during the Phase 2 pilot. You've all put so much time and effort into that and I can't express how valuable we have found your participation. We are continuing to build and iterate on our side based on the interactions we're having with you during the pilot.

A big part of this pilot is also for folks following along and thinking about the future. It's in FR's interest to make changes as we learn from you just as you make changes based on conversations with us, so that others can see what we're learning and how the pilot is providing value.

To that end, I have publicly updated the FedRAMP Machine-Readable Docs from v0.4.0-alpha to v0.9.0-beta. This includes a significant rework of the underlying JSON structure and complete labeling overhaul. Many items were condensed, restructured, renamed, and reordered. This updated model builds on many lessons learned while we built this first-of-a-kind structured ruleset for 20x.

Phase 2 pilot participants are NOT REQUIRED to update from the v0.4.0-alpha ruleset. You may complete your Phase 2 authorization using the same ruleset that you've been working on. A full copy of the v0.4.0-alpha ruleset is available on GitHub at https://github.com/FedRAMP/docs-alpha and the human-readable version of that snapshot is available at https://fedramp.github.io/docs-alpha/.

When v1 is released as part of the formal 20x requirements (in May) I expect there will be additional changes to each ruleset, though the structure of the JSON data itself is unlikely to shift like this again. It's totally fair to wait until v1 is released to update. However, if you want to get started with v0.9.0 this ruleset is available at https://fedramp.gov/docs and the release notes are available on GitHub here at https://github.com/FedRAMP/docs/releases/tag/v0.9.0-beta.

And I've finally decided to lift interaction limits on the FRMR Docs repository - that means we are open for issues and comments directly. Feels like things are in a good enough place to consider our options for opening up wider community contributions as well, at least tentatively.

Cheers,

-Pete

[apolaniaklaus]

Joining late to the party. This is probably covered somewhere but I cannot find it. Thank you for your continued leadership and efforts to modernize the FedRAMP program in alignment with the July 2024 memorandum. The momentum around FedRAMP 20X is appreciated.
I am currently advising several organizations that are planning to pursue FedRAMP 20X Moderate authorization (outside of Cohort 2) and have prior experience operating under FedRAMP Rev. 5. I am seeking clarification on a few scoping questions to ensure accurate guidance.

1. FedRAMP Authorization Requirements for Third-Party Tools
   Based on the current FedRAMP 20X guidance, it is unclear to me whether certain commonly used third-party tools must themselves be FedRAMP-authorized when used within a FedRAMP 20X Moderate Cloud Service Offering (CSO). Examples include:
   • Vulnerability scanning tools (e.g., Wiz, Checkmarx)
   • Ticketing systems used for vulnerability remediation (e.g., Jira)
   • Customer support platforms that may contain PII or potential federal data entered by customers (e.g., Zendesk)
   • Web Application Firewalls that process or transmit federal data (e.g., Fastly)
   • SIEM platforms (e.g., Splunk)
   I have heard from 3PAOs indicating that vulnerability scanning tools must be FedRAMP-authorized, while others tools just need to be explained (MAS-CSO-TPR) following this format and do not need to be FedRAMP authorized (in this case Moderate Authorized)

In reviewing the FedRAMP 20X definition of Federal Customer Data (FRD-FCD), it appears that telemetry, metadata, analytics, and similar CSP-generated data are explicitly excluded from that definition. However, the Minimum Assessment Scope (MAS) guidance (updated 02/04/2026) states that metadata and third-party services must be considered and documented when scoping a CSO.
Given this, could you please clarify:
• Whether any of the above categories of tools are required to be FedRAMP Moderate authorized under FedRAMP 20X, or
• Whether documentation and risk consideration alone is sufficient when these tools do not store or process federal customer data?
Additionally, does FedRAMP 20X impose any requirements on the underlying cloud infrastructure (e.g., AWS) to reside in a FedRAMP-authorized region, or is this no longer a strict requirement under the 20X model?

2. Metadata Scope Under FedRAMP 20X
   Related to the above, I would appreciate clarification on whether metadata protection is explicitly in scope for FedRAMP 20X Moderate, and how this expectation compares to FedRAMP Rev. 5. Many of the tools referenced above primarily handle metadata (except AWS) rather than federal customer data, and it is unclear how materially different the assessment expectations are under 20X.
   Thank you

[pete-gov]

Prior to the FedRAMP Authorization Act and M-24-15, FedRAMP authorizations were structured as a high bar that "guaranteed" a bunch of things were in place, primarily based on what the JAB required in order to provide a JAB P-ATO for a service. That world established a bunch of requirements around "federal metadata" of dubious legality and incentivized the general idea that everything had to be FedRAMP authorized (FR did not enforce this for agency authorizations but was not always consistent and 3PAOs and advisors were therefore incentivized to say this was necessary)... mostly because this made it easy from a reviewer perspective, black and white, everything was treated like it was a critical component.

Modern FR (and historical agency authorizations for FR) allow more flexibility in the implementation so that an authorizing official can make an informed decision based on their own specific agency use case; this applies to Rev5 as well as 20x, though 20x is very much designed to focus on signals about security in a way that natively encourages far more flexibility.

Regardless, across the entire history of FR past, present, and future, you need to consider the environment related to federal customer data, not just the data itself:

1. Entirely in scope by default: Anything that handles federal customer data. This is just straight up relevant and needs to be dealt with in entirety.
2. In scope to varying degrees depending on risk: Anything likely to impact the CIA of federal customer data. This should be addressed based on the likelihood and impact. This is different for every environment and is where most confusion exists. The MAS explicitly makes this the responsibility of the CSP to determine.

It's (2) above that folks often missed in the past or created significant arguments about such as the idea that all of these need to be included in the scope. For example, a SIEM platform might never touch any actual federal customer data so (1) wouldn't apply, but if the SIEM is being relied on to detect a breach of confidentiality or integrity of federal customer data then a compromise of that system could likely be used in an attack to ensure the provider does not know there is a confidentiality/integrity problem with federal customer data, therefore both the risk of this happening (if it's actually likely) and the compensating controls in place need to be addressed in the package. etc. etc. etc.

Telemetry is another example like that - some telemetry doesn't matter at all. Other telemetry might matter quite a lot (for example if you're sending a hash of a file to an antivirus service then making files unavailable based on what it returns - if that antivirus service is compromised to say federal customer data is a virus and you accept that and disable all the federal customer data then you have a loss in availability). Only the cloud service provider is positioned to understand what's likely to impact the CIA of federal customer data, and it's their responsibility to determine this and address it.

Same thing for metadata. Whether or not it's in scope, and the degree to which it needs to be addressed, will vary wildly depending on the specific implementation. It's up to the cloud service provider to determine and explain this depending on their specific environment.

[apolaniaklaus]

thank you for this super timely response. This makes sense. I just can see opinions varying all over the place with the auditors, CSPs etc. Reminds me of documenting justification for exclusions/ inclusion. thank you so much.

[ElaineFR]

Hi @pete-gov , have you heard any chatter on third-parties using anthropic? There are a few folks asking if we can still use this as an organization if we sell to gov. From what I've read, the agencies can't use tools from anthropic, but there are no mentioned restrictions on government using third-party tools that include its usage.

[tnnrjmsn-eit]

Here's a pretty good piece I read recently that seems relevant: https://www.mayerbrown.com/en/insights/publications/2026/03/anthropic-supply-chain-risk-designation-takes-effect--latest-developments-and-next-steps-for-government-contractors

It covers the legal authority cited by The Pentagon, and some practical advice for federal contractors.

[pete-gov]

FedRAMP is required by law to "establish and maintain a public comment process for proposed guidance and other FedRAMP directives that may have a direct impact on cloud service providers and agencies before the issuance of such guidance or other FedRAMP directives."

The lack of an RFC on a topic means we don't have any proposed guidance or directives related to that topic.

[ElaineFR]

Thank you @pete-gov !

[Spock67]

FedRAMP is requesting that participants ask questions in public during Phase 2 instead of sending emails to FedRAMP.

This will encourage continued transparency, reduce effort on FedRAMP staff, and ensure everyone has access to information they need by addressing questions that someone else might be wondering but doesn't feel up to asking. This also provides a single thread to ensure previously asked questions are easy for folks to quickly review.

Please use this thread to ask questions about the Phase 2 pilot. Thank you for your continued public participation!

Pete. I am not a FedRAMP professional but a business guy looking forward to FedRAMP 20x. With the close date for the pilot just passed, big picture, how do you think the pilot is going?

[pete-gov]

Real good. ;) We're expecting to publish formal 20x rules by the end of June inside the upcoming FedRAMP Consolidated Rules for 2026. I expect there will be a bit of a stall as folks adjust to everything changing out of the pilots but overall the thrust is there, approach appears to work, and it's mostly a matter of formalizing the approach and seeing how many cloud-native services out there are able to adapt for it.

[ericmoss54]

Pete and the 20x PMO team,
Having completed two 20x Low and two 20x Moderate assessments, the FITS team compiled the following observations and questions for the PMO's consideration.

1. Code Review in the 20x Assessment Process: We found this to be essential in the 20x process. The dashboards presented data cleanly, but going under the hood found several instances of static data, checks that always returned positive, logic loopholes and the like. This is something that needs to be a part of the 20x assessment process going forward.

2. CSP Does Not Meet its Own Checks: It occurred frequently that a CSP’s check would be correctly written and pass the assessment result, but they may be failing the check itself. An example may be that we validated a check to verify CIS benchmarks are installed, but several machines are missing that config. If the data is represented correctly on the trust center, is this a pass, partial, or fail? This issue is contentious within FITS on to what the assessment result should be. Arguments for passing are that we are primarily validating the trust center. If the data presented is accurate, it should be a PMO/agency decision to decide if that is a problem for their risk tolerance. Arguments against it are a bit cleaner: if a CSP isn’t fully meeting a KSI we call that out. Some clarification or comments here would be helpful.

3. Validation of KSI’s Security Intent: We would like confirmation on how to interpret the Assessor's responsibility for checking a CSP's choice of how to meet a KSI and its security intent. As an example, suppose a CSP chose to satisfy KSI-SVC-SNT "Encrypt or otherwise secure network traffic" by requiring passwords on all accounts. They have a policy saying that's how they secure network traffic, and they have code that checks every day to see if all accounts have passwords. When they do, it puts a green light on the FedRAMP 20x dashboard for this KSI. The 3PAO can validate that the automated process that confirms passwords are in place is effective and complete, and that it covers all user accounts. But this implementation misses the security intent of the KSI.

If requirements like Part 3 of PVA-TPX-UNP, or PVA-TPX-OUC, and/or other PVA requirements, are meant to require 3PAOs to validate that the CSP implementation actually satisfies the security intent of the KSI, that is not entirely clear, or at least is not explicit and forceful. For example, an additional PVA requirement with verbiage such as "Assessors must validate that the security controls providers use to demonstrate Key Security Indicators meet the security intent of the Key Security Indicator." would ensure that 3PAOs have the authority to identify instances where a CSP implements an accurate automated process that completely misses the security objective of the Key Security Indicator.

4. Intent vs Wording of KSIs: There are situations where a CSP is not meeting a KSI, but is meeting the intent. One prominent example would be for IAM-SUS. In instances where it doesn’t fit the CSP’s operations to automatically disable accounts, and a reasonable compensating control is in place should the 3PAO assess it as pass or partial? This also applies to the reverse situations where a CSP is meeting the wording of a KSI, but not the intent. An example may be persistently reviewing logs for MLA-RVL but doing so manually instead of with an alerting system. We need clarification here on how closely we are aligning to the intent and the wording of the KSI.

5. Automation Data Quality: Automation in the assessments was often split between pulling actual system data and events and data that was manually updated to be pulled in an automation script. There are always going to be some instances where manual evidence makes more sense for a CSP, and these should be embraced on those occasions instead of trying to automate for automation’s sake. A clearer definition for automation data quality would go a long way to help CSP’s understand the dos and don’ts here.

6. 20x – MITRE ATT&CK Mapping: While not strictly on the assessment side, this is a product that FITS recommends the PMO look into developing. A mapping would show the security outcomes that the KSI’s are designed to address. The 20x framework is still new and showing how the KSI’s map to real world attack vectors would build confidence in the framework.

7. AI in the CSP Validation Process: A novel use of AI would be a CSP building prompts for each KSI and then instructing an AI agent to validate the KSI is implemented. Would something like this be accepted by the PMO, and what would you expect the 3PAO to focus on validating in this instance?

P.S.
Thanks for setting up some time for the 3PAOs to provide feedback, we are looking forward to attending.