FEDRAMP is a US government inspired way of seeking to address risk management of data that are stored in the cloud rather than locally. That has jurisdictional and operational considerations. It is a great pity they have not looked at the ISO/IEC standards for EDI and security 14662 and 15944 where the security of personal data are addressed in some considerable detail, because that would have saved them repeating a lot of work.
In the ordinary course, we do not store the publisher’s data, except for a very small component, being the encrypted access mechanisms used for licensing purposes. So our conventional Viewer services fall outside of the ambit of their control approach. A compromise of our system would not result in disclosure of personal data since we hold no such information. Our own risk analysis approach says that you would not attempt to attack the distributed protected files head on because you are trying to attack AES-256 in its CBC mode of operation, which NIST say is rather difficult. There is no point in trying to attack the admin database unless you are going for a DDOS class attack since the information does not allow you to issue new licenses or grant new authorities. The only valid attack vectors are against a licensed user’s machine when they are authorized to open a document, and that is outside the scope of the FEDRAMP scheme.
There is the outside possibility that the Web Viewer system could fall within the ambit of the FEDRAMP scheme, in that we are holding actual user data in a database for access by users/customers. Documents are stored however using an appropriate level of encryption (AES 256 bit) for storage purposes.
So the long and the short is that we are not acting as a cloud supplier hosting the data of the organization, so we do not fall within the ambit of the FEDRAMP intent. Where we actually act as host to serving data we use AES 256 bit encryption for both data at rest (database and target device) and in transit.