What we've found to be important in FedRAMP from technical perspective:
* Classify the data your system uses by sensitivity/risk- PII, PHI, etc- and architect your data flows have clear segregation between those that involve sensitive data and those that don't. This is super important good practice anyway. When the time comes, the sensitive data flow sub-architecture fits in what FedRAMP calls the "authorization boundary"
* Per above, understand what FedRAMP level your system will fall into. High in practice is really different from Moderate which is really different from Low. PHI, PII or similar sensitive data custody will be FedRAMP High.
* Have clear change control and separation of duties around the sensitive data subarchitecture. Again with sensitive data this is just a best practice, but quite a lot of FedRAMP revolves around documenting and demonstrating maturity in these areas.
* Be able to use FIPS 140 cryptography. This can be really tricky because cryptography- TLS, hashing, random number generation, etc- is everywhere and no operating system and no application/language stack is OOB FIPS 140 compliant. The stock golang toolchain, for instance, is deliberately not FIPS-compliant, so if your system involves go doing anything cryptographic, it will be your responsibility to adopt one of the toolchains that support FIPS.
From a business perspective:
* What FedRAMP is- an extensive compliance process. It's like the union of all compliance processes, 16 different "families" of controls, not one but 2 distinct audits, etc.
* What FedRAMP is not- not a sales channel. Identify and sell to your prospects first, keeping in mind that this is long, slow enterprise selling. Once you have a prospect for a relationship, and FedRAMP becomes a requirement for establishing that relationship, there are quite a lot of parties in the space- project managers, security folks, etc- to help folks get through it.
* So- don't start down the FedRAMP path before you have an agency customer. Even apart from FedRAMP, a federal agency is not in a position to be any kind of an early solution adopter. FedRAMP would come into play almost as part of implementation/onboarding- after product/market/pricing/etc discovery is long done, and there is capability for delivery and end-to-end functionality. Of course prior to that stage you can take steps to shape your architecture and ergonomics to eventually align with FedRAMP, most of which is best practice. But don't start planning specifically for FedRAMP before having a working system and having found an agency customer.
Phenomenal insights thank you. We are working with an agency sponsor and definitely down the path a bit, and I'm hoping to identify best in class resources and case studies to learn from as a contributor on the team.
* Classify the data your system uses by sensitivity/risk- PII, PHI, etc- and architect your data flows have clear segregation between those that involve sensitive data and those that don't. This is super important good practice anyway. When the time comes, the sensitive data flow sub-architecture fits in what FedRAMP calls the "authorization boundary"
* Per above, understand what FedRAMP level your system will fall into. High in practice is really different from Moderate which is really different from Low. PHI, PII or similar sensitive data custody will be FedRAMP High.
* Have clear change control and separation of duties around the sensitive data subarchitecture. Again with sensitive data this is just a best practice, but quite a lot of FedRAMP revolves around documenting and demonstrating maturity in these areas.
* Be able to use FIPS 140 cryptography. This can be really tricky because cryptography- TLS, hashing, random number generation, etc- is everywhere and no operating system and no application/language stack is OOB FIPS 140 compliant. The stock golang toolchain, for instance, is deliberately not FIPS-compliant, so if your system involves go doing anything cryptographic, it will be your responsibility to adopt one of the toolchains that support FIPS.
From a business perspective:
* What FedRAMP is- an extensive compliance process. It's like the union of all compliance processes, 16 different "families" of controls, not one but 2 distinct audits, etc.
* What FedRAMP is not- not a sales channel. Identify and sell to your prospects first, keeping in mind that this is long, slow enterprise selling. Once you have a prospect for a relationship, and FedRAMP becomes a requirement for establishing that relationship, there are quite a lot of parties in the space- project managers, security folks, etc- to help folks get through it.
* So- don't start down the FedRAMP path before you have an agency customer. Even apart from FedRAMP, a federal agency is not in a position to be any kind of an early solution adopter. FedRAMP would come into play almost as part of implementation/onboarding- after product/market/pricing/etc discovery is long done, and there is capability for delivery and end-to-end functionality. Of course prior to that stage you can take steps to shape your architecture and ergonomics to eventually align with FedRAMP, most of which is best practice. But don't start planning specifically for FedRAMP before having a working system and having found an agency customer.
Good luck.