FAQ by Document Type ​

To avoid unexpected behavior, DOCX documents must be opened with Microsoft Word. Also, when opening a document the first time, please click "Yes" when prompted to update the fields in the document.

Your General System Description comes from the "System Function or Purpose" located in a project's Project Overview.

This field is populated by specifying the "Information Types Received" field in both FedRAMP System and Interconnection components.

1. Create an Agreement Component and specify the Nature of Agreement field.
2. In the FedRAMP System or Interconnection component, set Agreement field to the newly created Agreement.
3. In project overview, ensure that Leveraged Authorizations and System Interconnections have the desired selections. (either automatic or manual)
4. The Nature of Agreement should be populated the with the appropriate value.

Paramify's goal is to generate all feasible SSP ATO Package documents for the user. The table below outlines the current progress.

For the documents indicated in the column titled Requiremed FedRAMP Template Available, the FedRAMP template is available for downloaded within the Paramify platform in the relevant Attachment page.

^* Paramify added Appendices to simplify responses to Access Controls around least privilege and separation of duties.

Refer to FedRAMP Initial Authorization Package Checklist from FedRAMP.gov to confirm package requirements.

Risk Solutions are single origination by design. Multi-responsibiliy Risk Solutions should be broken up for best results.

If you are converting legacy documentation into custom control responses, you can use a combination of originations to model a hybrid or shared control.

Hybrid is simply System Provider Specific AND System Provider Corporate.

Shared is a combination of system provider and customer originations.

• Example: System Provider Specific AND Customer Provided
• Example: System Provider Corporate AND Customer Configured

Last check on the Fedramp Documents & Templates page, FedRAMP does NOT have a template for Separation of Duties Matrix. Here is an example for your reference:

Example: Separation of Duties Matrix ​

The following table outlines the separation of duties for user roles within the FedRAMP System Name cloud environment.  The table is categorized by a user’s role, whether he/she is an internal employee or external entity such as a contractor, the user’s functions, and the level of access granted to the system.

Note: The focus is typically on privileged and not-privileged access so, for the purpose of the example above, no logical access roles are not included.

Paramify's Recommendation ​

Your organization likely spent a boatload of money already creating an SSP. This is why some Paramify users who already have ATO packages hesitate to adopt our Risk Solutions platform.

And yes, Paramify will still improve and simplify your organization’s SSP creation and management processes without Risk Solutions. But, you’ll get the most accurate OSCAL SSPs and reduce your daily headache significantly when you adopt Risk Solutions.

Your previous efforts are not a sunk cost when you adopt Risk Solutions. We can use your existing SSP to create custom Risk Solutions to meet your specific control requirements. With Risk Solutions, your SSP becomes more accurate, your GRC org can work more efficiently and your teams can collaborate better.

Why Adopt Risk Solutions: ​

1. Accuracy: Manually written SSPs are riddled with errors that slow down audits and authorizations. Our OSCAL-based Risk Solutions platform automatically maintains and updates to prevent human error.
2. Efficiency: Your security requirements grow with your organization. Responding one by one to individual requirements is tedious and inefficient. A Risk solution can map to multiple controls across any security catalog – allowing you to be flexible and agile as your security objectives increase.
3. Collaboration: Risk Solutions provide a platform to drive shared risk adoption across the organization. Security becomes a collective organizational effort that’s not owned only by the GRC team

Three ways to respond to control requirements: ​

Risk Solution Guiding Principles ​

What is a Risk Solution:

1. Describe a security capability that addresses the who, what, how, and when
2. Standardized language that is catalog-agnostic to fulfill multi-catalog set of requirements
3. Flexible and agile to lift and replace the who, what, and when elements as the business evolves
4. Defines shared risk ownership across the organization and leveraged third party providers

Steps to Convert Custom / Existing Responses to Risk Solutions Architecture ​

1. Initial Intake based on Existing SSP

   • Perform self-served intake / SSP ingestion to define elements and Risk Solutions inventory from existing SSP
   • Import all elements and Risk Solutions inventory based on existing SSP into client's workspace
   • Apply suggested Risk Solutions produced from step #1 to list of all security objective catalog requirements

2. Defining Foundation for Security Capabilities

   • Assess what is necessary vs. superfluous in existing custom response to meet associated control requirement
   • Consolidate multi-component capability existing custom responses to a generic main component capability
   • Define the security capability key elements from existing custom response:
     • Who - primary responsible owner of the capability
       • Multiple Who scenarios:
         • Partially inherited from a third party provider + Shared internal organizational ownership
         • Customer responsibility + Shared internal organizational ownership
     • What - main component driving the capability (ideally this is owned by the Who party)
     • How - procedures for implementing the capability (driven from the What element potentially in conjunction with other components)
     • When - frequency with which the capability is performed

3. Content Merge to Risk Solutions Architecture (see proposed template to complete this phase here)

   • Refine suggested Risk Solutions created from the intake process based on outputs of phase #2 (custom responses and Risk Solutions can be viewed together in the controls implementation view as well as the Document Robot eMass deliverable)
   • Associate additional Risk Solutions not mapped to the requirement based on context from custom response not addressed in suggested Risk Solutions

Custom Response vs Risk Solutions ​

Paramify's goal is to generate all feasible TX-RAMP documents for the user. The table below outlines the current progress.

For the documents indicated in the column titled Template Available, the template is available for downloaded within the Paramify platform in the relevant Attachment page.

^* Paramify added Attachments to simplify responses to Access Controls around least privilege, separation of duties, and continuous monitoring.

Refer to TX-RAMP Overview and TX-RAMP Vendor Guide - Completing TX-RAMP Assessment Questionnaire from dir.texas.gov to confirm requirements.