Initial publication.
Minor prop updates.
The FedRAMP PMO resides within GSA and supports agencies and cloud service providers through the FedRAMP authorization process and maintains a secure repository of FedRAMP authorizations to enable reuse of security packages.
The organization that prepared this SSP. If developed in-house, this is the CSP itself.
The organization for which this SSP was prepared. Typically the CSP.
The individual or individuals accountable for the accuracy of this SSP.
The individual within the CSP who is ultimately accountable for everything related to this system.
The individual or individuals who must grant this system an authorization to operate.
The individual representing the authorizing official.
The highest level manager who responsible for system operation on behalf of the System Owner.
The individual or individuals leading the technical operation of the system.
A general point of contact for the system, designated by the system owner.
The individual accountable for the security posture of the system on behalf of the system owner.
The individual responsible for the privacy threshold analysis and if necessary the privacy impact assessment.
The point of contact for an interconnection on behalf of this system.
Remove this role if there are no ICAs.
The point of contact for an interconnection on behalf of this external system to which this system connects.
Remove this role if there are no ICAs.
Responsible for signing an interconnection security agreement on behalf of this system.
Remove this role if there are no ICAs.
Responsible for signing an interconnection security agreement on behalf of the external system to which this system connects.
Remove this role if there are no ICAs.
Any consultants involved with developing or maintaining this content.
Represents any customers of this system as may be necessary for assigning customer responsibility.
The provider of a leveraged system, external service, API, CLI.
This is a sample role.
This is a sample role.
The owner of an external system.
The highest level manager who responsible for an external system's operation on behalf of the System Owner.
The individual or individuals leading the technical operation of an external system.
An internal approving authority.
There must be one location identifying the CSP's primary business address, such as the CSP's HQ, or the address of the system owner's primary business location.
There must be one location for each data center.
There must be at least two data center locations.
For a data center, briefly summarize the components at this location.
All data centers must have a "type" property with a value of "data-center".
The type property must also have a class of "primary" or "alternate".
There must be one location for each data center.
There must be at least two data center locations.
For a data center, briefly summarize the components at this location.
All data centers must have a "type" property with a value of "data-center".
The type property must also have a class of "primary" or "alternate".
Replace sample CSP information.
CSP information must be present and associated with the "cloud-service-provider" role
via responsible-party.
This party entry must be present in a FedRAMP SSP.
The uuid may be different; however, the uuid must be associated with the "fedramp-pmo" role in the responsible-party assemblies.
This party entry must be present in a FedRAMP SSP.
The uuid may be different; however, the uuid must be associated with the "fedramp-jab" role in the responsible-party assemblies.
Generic placeholder for any external organization.
Generic placeholder for an authorizing agency.
Underlying service provider. Leveraged Authorization.
Zero or more
Exactly one
One or more
Exactly one
One or more
Exactly one
Exactly one
Exactly one
Exactly one
Exactly one
hello
This example points to the FedRAMP Rev 5 Moderate baseline that is part of the official FedRAMP 3.0.0 release.
Must adjust accordingly for applicable baseline and revision.
[Insert CSO Name] is delivered as [a/an] [insert based on the Service Model above] offering using a multi-tenant [insert based on the Deployment Model above] cloud computing environment. It is available to [Insert scope of customers in accordance with instructions above (for example, the public, federal, state, local, and tribal governments, as well as research institutions, federal contractors, government contractors etc.)].
NOTE: Additional description, including the purpose and functions of this system may be added here. This includes any narrative text usually included in section 9.1 of the SSP.
NOTE: The description is expected to be at least 32 words in length.
Remarks are required if service model is "other". Optional otherwise.
Remarks are required if deployment model is "hybrid-cloud" or "other". Optional otherwise.
A description of the information.
Required if the base and selected values do not match.
Required if the base and selected values do not match.
Required if the base and selected values do not match.
A description of the information.
Required if the base and selected values do not match.
Required if the base and selected values do not match.
Required if the base and selected values do not match.
A description of the information.
Required if the base and selected values do not match.
Required if the base and selected values do not match.
Required if the base and selected values do not match.
Remarks are optional if status/state is "operational".
Remarks are required otherwise.
A holistic, top-level explanation of the FedRAMP authorization boundary.
A diagram-specific explanation.
A holistic, top-level explanation of the network architecture.
A diagram-specific explanation.
A holistic, top-level explanation of the system's data flows.
A diagram-specific explanation.
For now, this is a required field. In the future we intend to pull this information directly from FedRAMP's records based on the "leveraged-system-identifier" property's value.
For now, this is a required field. In the future we intend to pull this information directly from FedRAMP's records based on the "leveraged-system-identifier" property's value.
Use one leveraged-authorization assembly for each underlying authorized cloud system or general support system (GSS).
For each leveraged authorization there must also be a "system" component. The corrisponding "system" component must include a "leveraged-authorization-uuid" property that links it to this leveraged authorization.
The user assembly is being reviewed for continued applicability under FedRAMP's adoption of Rev 5.
Currently, FedRAMP will only process user content if it includes the FedRAMP "separation-of-duties-matrix" property/extension. All other user entries will be ignored by validation rules, but may be displayed by tools.
This component represents the entire authorization boundary, as depicted in the system authorization boundary diagram.
FedRAMP requires exactly one "this-system" component, which is used in control implementation responses and interconnections.
A FedRAMP SSP must always have exactly one "this-system" component that represents the whole system.
It does not need system details, as those exist elsewhere in this SSP.
Briefly describe the leveraged system.
If 'yes', describe the authentication method.
If 'no', explain why no authentication is used.
If 'not-applicable', attest explain why authentication is not applicable in the remarks.
The "provider" role is required for the component representing a leveraged system. It must reference exactly one party (via party-uuid), which points to a party of type "organization" representing the organization that owns the leveraged system.
This is a leveraged system within which this system operates. It is explicitly listed on the FedRAMP marketplace with a status of "FedRAMP Authorized".
Each leveraged system must be expressed as a "system" component, and must have:
Where relevant, this component should also have:
Links to the vendor website describing the system are encouraged, but not required.
A service within the scope of the leveraged system's authorization boundary is considered an "authorized service". Any other service offered by the leveraged system is considered a "non-authorized service"
Represent each authorized or non-authorized leveraged services using a "service" component. Both authorized and non-authorized service components are represented the same in OSCAL with the following exceptions:
Both authorized and non-authorized leveraged services include:
"#11111111-2222-4000-8000-009000100001")Although SSP Table 7.1 also requires data categoriation and hosting environment information about non-authorized leveraged services, these datails are derived from other content in this SSP.
An authorized service provided by the Awesome Cloud leveraged authorization.
Describe the service and what it is used for.
This is a service offered by a leveraged system and used by this system. It is explicitly listed on the FedRAMP marketplace as being included in the scope of this leveraged system's ATO, thus is considered an "Authorized Service.
Each leveraged service must be expressed as a "service" component, and must have:
"#11111111-2222-4000-8000-009000100001")Where relevant, this component should also have:
Link(s) to the vendor's web site describing the service are encouraged, but not required.
The following fields from the Leveraged Authorization Table are handled in the leveraged-authorization assembly:
The following fields from the Leveraged Authorization Table are handled in the "system" component representing the leveraged system as a whole:
- Nature of Agreement, CSP Name
An non-authorized service provided by the Awesome Cloud leveraged authorization.
Describe the service and what it is used for.
If 'yes', describe the authentication method.
If 'no', explain why no authentication is used.
If 'not-applicable', attest explain why authentication is not applicable in the remarks.
This is a service offered by a leveraged system and used by this system. It is NOT explicitly listed on the FedRAMP marketplace as being included in the scope of the leveraged system's ATO, thus is treated as a non-authorized, leveraged service.
Each non-authorized leveraged service must be expressed as a "service" component, and must have:
"#11111111-2222-4000-8000-009000100001")The "leveraged-authorization-uuid" property must NOT be present, as this is how tools are able to distinguish between authorized and non-authorized services from the same leveraged provider.
Where relevant, this component should also have:
Link(s) to the vendor's web site describing the service are encouraged, but not required.
The following fields from the Leveraged Authorization Table are handled in the leveraged-authorization assembly:
- An "inherited-uuid" property if the leveraged system's owner provides a UUID for their system (such as in an OSCAL-based CRM).
Link(s) to the vendor's web site describing the service are encouraged, but not required.
The following fields from the Leveraged Authorization Table are handled in the leveraged-authorization assembly:
- Package ID, Authorization Type, Impact Level
The following fields from the Leveraged Authorization Table are handled in the "system" component assembly:
- Nature of Agreement, CSP Name
An unauthorized service from an underlying leveraged authorization must NOT have the "leveraged-authorization-uuid" property. The presence or absence of this property is how the authorization status of a service is indicated.
An external system to which this system shares an interconnection.
Each interconnection to one or more remote systems must have:
Each "system" component must have:
While not required, each "system" component should have:
Unlike prior FedRAMP OSCAL publications, avoid the use of FedRAMP properties/extensions for these roles, instead favor the core OSCAL responsible-roles constructs, and the NIST-standard roles of "authorizing-official", "system-owner", "system-poc-management and "system-poc-technical"
Describe the purpose of the external system/service; specifically, provide reasons for connectivity (e.g., system monitoring, system alerting, download updates, etc.)
If 'yes', describe the authentication method in the remarks.
If 'no', explain why no authentication is used in the remarks.
If 'not-applicable', attest explain why authentication is not applicable in the remarks.
Describe the hosting of the interconnection itself (NOT the hosting of the remote system).
Each interconnection to one or more remote systems must have:
Each "interconnection" component must have:
Authentication methods must address both system-authentication as well as user authentication mechanisms.
Describe the hosting of the interconnection itself (NOT the hosting of the remote system).
If the interconnection travels across the public Internet, the provider may be the cloud hosting provider or the Internet provider
While not required, each "interconnection" component should have:
Unlike prior FedRAMP OSCAL publications, avoid the use of FedRAMP properties/extensions for these roles, instead favor the core OSCAL responsible-roles constructs, and the NIST-standard roles of "system-poc-management" and "system-poc-technical". With an interconnection, the system POC roles reference parties that represent the connection provider.
For each external system with which this system connects:
Must have a "system" component (this component).
Must have an "interconnection" component that connects this component with the "this-system" component.
If the leveraged system owner provides a UUID for their system (such as in an
OSCAL-based CRM), it should be reflected in the inherited-uuid
property.
Must include all leveraged services and features from the leveraged authorization here.
For an external system, the "implementation-point" property must always be present with a value of "external".
Each interconnection must be defined with both an "system" component and an "interconnection" component.
Must include all leveraged services and features from the leveraged authorization here.
A service provided by an external system other than the leveraged system.
Describe the service and what it is used for.
If 'yes', describe the authentication method in the remarks.
If 'no', explain why no authentication is used in the remarks.
If 'not-applicable', attest explain why authentication is not applicable in the remarks.
This can only be known if provided by the leveraged system. such as via an OSCAL-based CRM, component definition, or as a result to the leveraged system's OSCAL-based SSP.
This is a service provided by an external system other than the leveraged system.
As a result, the "leveraged-authorization-uuid" property is not applicable and must NOT be used.
Each external service used from a leveraged authorization must have:
This component must always have:
Where relevant, this component should also have:
The following fields from the Leveraged Authorization Table are handled in the leveraged-authorization assembly:
- Package ID, Authorization Type, Impact Level
The following fields from the Leveraged Authorization Table are handled in the "system" component assembly:
- Nature of Agreement, CSP Name
An unauthorized service from an underlying leveraged authorization must NOT have the "leveraged-authorization-uuid" property. The presence or absence of this property is how the authorization status of a service is indicated.
This component represents any of the public API clients that may access this systems'API service.
When an API service is offered to a large community, this one component bay be used to represent the collection of API clients that may connect from that community. This must have:
A service offered by this system to external systems, such as an API. As a result, communication crosses the boundary.
Describe the service and what it is used for.
If 'yes', describe the authentication method in the remarks.
If 'no', explain why no authentication is used in the remarks.
If 'not-applicable', attest explain why authentication is not applicable in the remarks.
Terms of Use
Explain why authentication scans are not possible for this component. Provide evidence if available, such as scanner tool or vendor links.
This is a service provided by this system to external systems, such as an offered API. The following is required:
Because this is softare that exists within the boundary, it is also requires the following in satisfaction of inventory/CM/ConMon requirements:
A CLI tool used from within this system's boundary to manage a hypervisor, service, or other system outside this system's boundary, resulting in communication that crosses the boundary.
If 'yes', describe the authentication method in the remarks.
If 'no', explain why no authentication is used in the remarks.
If 'not-applicable', attest explain why authentication is not applicable in the remarks.
Terms of Use
Explain why authentication scans are not possible for this component. Provide evidence if available, such as scanner tool or vendor links.
When an internal CLI tool communicates with a system outside the boundary, such as for management of the underlying leveraged system or interaction with an external system, the following is required:
Because this is softare that exists within the boundary, it is also requires the following in satisfaction of inventory/CM/ConMon requirements:
A CLI tool used by systems outside the authorization boundary to manage or interact with this system..
If 'yes', describe the authentication method in the remarks.
If 'no', explain why no authentication is used in the remarks.
If 'not-applicable', attest explain why authentication is not applicable in the remarks.
Terms of Use
When a CLI tool outside the system communicates with this system, such as for management of the user's hypervisor in this system, the following is required:
As this is impelemented external to the system boundary, information such as "scan-type" and "allows-authenticated-scanning" are not applicable and should not be present.
This is a corporate policy used for the system.
The Access Control and Identity Management Policy governs how user identities and access rights are managed.
A policy component is required for each policy that governs the system.
The title, description and status fields are required by core OSCAL. The title field should reflect the actual title of the policy document.
For system-specific policies, the "implementation-point" property must be present and set to "internal".
For corproate policies, the "implementation-point" property must be present and set to "external" with its class set to "corporate".
For any policy that is niether system-specific, nor corporate, the "implementation-point" property must be present and set to "external", with a class set to anything other than "corporate" or no class attribute at all.
An "attachment" link field must be present that identifies the back-matter resource representing the attached policy.
The document version and date are represented in the linked resource. Not here.
At this time FedRAMP does not _require_ policy approver or audience information in the SSP; however, both may be represented here using the responsible-role field. If electing to include this information, use the "approver" role ID to represent approvers. Any other role listed is assumed to be audience.
The Awareness and Training Policy governs how access is managed and approved.
The Access Control Procedure governs how access is managed and approved.
A "process-procedure" component is required for each process or procedure that governs the system.
The title, description and status fields are required by core OSCAL. The title field should reflect the actual title of the document.
For system-specific processes or procedures, the "implementation-point" property must be present and set to "internal".
For corproate processes or procedures, the "implementation-point" property must be present and set to "external" with its class set to "corporate".
For any processes or procedures that is niether system-specific, nor corporate, the "implementation-point" property must be present and set to "external", with a class set to anything other than "corporate" or no class attribute at all.
An "attachment" link field must be present that identifies the back-matter resource representing the attached policy.
The document version and date are represented in the linked resource. Not here.
At this time FedRAMP does not _require_ policy approver or audience information in the SSP; however, both may be represented here using the responsible-role field. If electing to include this information, use the "approver" role ID to represent approvers. Any other role listed is assumed to be audience.
The Awareness and Training Procedure governs how access is managed and approved.
An encryptred communication between the web server and the database server for the purpose of performing SQL queries.
Any notes about this connection to appear in Table Q.
None
Provide a description and any pertinent note regarding the use of this CM.
For data-at-rest modules, describe type of encryption implemented (e.g., full disk, file, record-level, etc.)
Lastly, provide any supporting notes on FIPS status (e.g. historical) or lack of FIPS compliance (e.g., Module in Process).
Usage statement
If the same FIPS-validated cryptographic module is deployed in two or more different components, each deployment SHOULD have its own "validation" component entry, such as if the same module is embedded in a software product and an operating system.
The "asst-type" property is value is "cryptographic-module", and the class must be present with one of the following values:
Note that if the value is "other", additional detail must be provided in the property's remarks field.
Provide a description and any pertinent note regarding the use of this CM.
For example, any supporting notes on FIPS status (e.g. historical) or lack of FIPS compliance (e.g., Module in Process).
Usage statement
This is a web server that communicates with a database via an encrypted connection
This is a web server that communicates with a database via an encrypted connection
Provide a description and any pertinent note regarding the use of this CM.
For example, any supporting notes on FIPS status (e.g. historical) or lack of FIPS compliance (e.g., Module in Process).
Usage statement
A service that exists within the authorization boundary.
Describe the service and what it is used for.
This is a container image used to create container instances within the system.
FUNCTION: Describe typical component function.
COMMENTS: Provide other comments as needed.
FUNCTION: Describe typical component function.
COMMENTS: Provide other comments as needed.
Email Service
FUNCTION: Describe typical component function.
COMMENTS: Provide other comments as needed.
None
None
None
Vendor appliance. No admin-level access.
IPv4 Production Subnet.
IPv4 Management Subnet.
Legacy Example (No implemented-component).
If no, explain why. If yes, omit remarks field.
If no, explain why. If yes, omit remarks field.
Optional, longer, formatted description.
This links to a FIPS 140-2 validated software component that is used by this inventory item. This type of linkage to a validation through the component is preferable to the link[rel='validation'] example above.
COMMENTS: Additional information about this item.
Component Inventory Example
If no, explain why. If yes, omit remark.
COMMENTS: If needed, provide additional information about this inventory item.
None.
None.
None.
None.
Asset wasn't running at time of scan.
None.
None.
Asset wasn't running at time of scan.
Email-Service
This description field is required by OSCAL.
FedRAMP does not require any specific information here.
[Assignment: organization-defined personnel or roles]
This focuses on roles the POLICY is disseminated to.
[Assignment: organization-defined personnel or roles]
This focuses on roles PROCEDURES are disseminated to.
[Selection (one or more): Organization-level; Mission/business process-level; Systemlevel]
This is a SELECT parameter. Use one "value" field for each selection.
[Assignment: organization-defined official]
[Assignment: organization-defined frequency]
[Assignment:organization-defined events]
[Assignment: organization-defined frequency]
[Assignment:organization-defined events]
Describe how Part a is satisfied within the system as a whole.
FedRAMP prefers all policies and procedures be attached as a resource in the back-matter. The link points to a resource.
This is the "this-system" component, which represents the system as a whole.
There are two reasons to provide a response here:
Describe how this policy satisfies part a.
This is the "policy" component, which represents the Access Control and Identity Management Policy.
Describe how this procedure satisfies part a.
This is the "process-procedure" component, which represents the Access Control Process.
Describe how Part b is satisfied within the system as a whole.
Describe the plan to complete the implementation.
This is the "this-system" component, which represents the system as a whole.
There are two reasons to provide a response here:
Describe how this policy currently satisfies part a.
Describe the plan for addressing the missing policy elements.
Identify what is currently missing from this policy.
Describe how Part b-1 is satisfied.
Describe how AC-2, part a is satisfied within this system.
This points to the "This System" component, and is used any time a more specific component reference is not available.
This system's statement of capabilities which may be inherited by a customer's leveraging systems toward satisfaction of AC-2, part a.
Leveraged system's statement of a leveraging system's responsibilities in satisfaction of AC-2, part a.
Not associated with inheritance, thus associated this with the by-component for "this system".
Any content for the customer responsibility matrix must be included within export.
provided is a statement about what
For the portion of the control satisfied by the application component of this system, describe how the control is met.
Consumer-appropriate description of what may be inherited from this application component by a leveraging system.
In the context of the application component in satisfaction of AC-2, part a.
Leveraging system's responsibilities with respect to inheriting this capability from this application.
In the context of the application component in satisfaction of AC-2, part a.
The component-uuid above points to the "this system" component.
Any control response content that does not cleanly fit another system component is placed here. This includes customer responsibility content.
This can also be used to provide a summary, such as a holistic overview of how multiple components work together.
While the "this system" component is not explicitly required within every
statement, it will typically be present.
For the portion inherited from an underlying FedRAMP-authorized provider, describe what is inherited.
Optional description.
Consumer-appropriate description of what may be inherited as provided by the leveraged system.
In the context of this component in satisfaction of AC-2, part a.
The provided-uuid links this to the same statement in the
leveraged system's SSP.
It may be linked directly, but is more commonly provided via an OSCAL-based CRM (Inheritance and Responsibility Model).
Description of how the responsibility was satisfied.
The responsibility-uuid links this to the same statement in the
leveraged system's SSP.
It may be linked directly, but is more commonly provided via an OSCAL-based CRM (Inheritance and Responsibility Model).
Tools should use this to ensure all identified customer
responsibility statements have a corresponding
satisfied statement in the leveraging system's SSP.
Tool developers should be mindful that
Describe how AC-2, part a is satisfied within this system.
This points to the "This System" component, and is used any time a more specific component reference is not available.
Describe how Part a is satisfied within the system.
Legacy approach. If no policy component is defined, describe here how the policy satisfies part a.
In this case, a link must be provided to the policy.
FedRAMP prefers all policies and procedures be attached as a resource in the back-matter. The link points to a resource.
The specified component is the system itself.
Any control implementation response that can not be associated with another component is associated with the component representing the system.
Describe how this policy satisfies part a.
Component approach. This links to a component representing the Identity Management and Access Control Policy.
That component contains a link to the policy, so it does not have to be linked here too.
Describe how this procedure satisfies part a.
Component approach. This links to a component representing the Identity Management and Access Control Policy.
That component contains a link to the policy, so it does not have to be linked here too.
There
Describe the plan to complete the implementation.
Describe how this policy currently satisfies part a.
Describe the plan for addressing the missing policy elements.
Identify what is currently missing from this policy.
Describe how Part b-1 is satisfied.
SSP Signature
The FedRAMP PMO is formulating guidelines for handling digital/electronic signatures in OSCAL, and welcome feedback on solutions.
For now, the PMO recommends one of the following:
If your organization prefers another approach, please seek prior approval from the FedRAMP PMO.
Must be present in a FedRAMP SSP.
A single policy that addresses both the AC and IA families.
Each policy must be attached as back-matter resources, and must include:
Each policy must have a corrisponding "policy" component.
AT Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
AU Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
CA Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
CM Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
CP Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
IA Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
IR Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
MA Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
MP Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
PE Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
PL Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
PS Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
RA Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
SA Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
SC Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
SI Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
SR Policy document
Table 12-1 Attachments: Policy Attachment
May use rlink with a relative path, or embedded as
base64.
AC Procedure document
Procedures must be attached as back-matter resources, and must include:
AT Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
AU Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
CA Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
CM Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
CP Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
IA Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
IR Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
MA Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
MP Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
PE Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
PL Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
PS Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
RA Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
SA Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
SC Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
SI Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
SR Procedure document
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
User's Guide
Table 12-1 Attachments: User's Guide Attachment
May use rlink with a relative path, or embedded as
base64.
Rules of Behavior
Table 12-1 Attachments: Rules of Behavior (ROB)
May use rlink with a relative path, or embedded as
base64.
Contingency Plan (CP)
Table 12-1 Attachments: Contingency Plan (CP) Attachment
May use rlink with a relative path, or embedded as
base64.
Configuration Management (CM) Plan
Table 12-1 Attachments: Configuration Management (CM) Plan Attachment
May use rlink with a relative path, or embedded as
base64.
Incident Response (IR) Plan
Table 12-1 Attachments: Incident Response (IR) Plan Attachment
May use rlink with a relative path, or embedded as
base64.
A CSP-specific law citation
The "type" property must be present and contain the value "law".
Continuous Monitoring Plan
Table 12-1 Attachments: Continuous Monitoring Plan Attachment
May use rlink with a relative path, or embedded as
base64.
The POA&M attachment may either be a legacy Excel workbook or OSCAL file. The resource must have:
A "version" property is optional.
The appropriate media types for OSCAL content are, "application/xml", "application/json" or "application/yaml".
FedRAMP does not accept base64 POA&M contenta at this time.
Supply Chain Risk Management Plan
Table 12-1 Attachments: Procedure Attachment
May use rlink with a relative path, or embedded as
base64.
FedRAMP Logo
Must be present in a FedRAMP SSP.
CSP Logo
May use rlink with a relative path, or embedded as
base64.
FedRAMP prefers base64 for images and diagrams.
Images must be in sufficient resolution to read all detail when rendered in a browser via HTML5.
3PAO Logo
May use rlink with a relative path, or embedded as
base64.
FedRAMP prefers base64 for images and diagrams.
Images must be in sufficient resolution to read all detail when rendered in a browser via HTML5.
The primary authorization boundary diagram.
Section 8.1, Figure 8-1 Authorization Boundary Diagram (graphic)
This should be referenced in the system-characteristics/authorization-boundary/diagram/link/@href flag using a value of "#11111111-2222-4000-8000-001000000054"
May use rlink with a relative path, or embedded as
base64.
FedRAMP prefers base64 for images and diagrams.
Images must be in sufficient resolution to read all detail when rendered in a browser via HTML5.
The primary network diagram.
Section 8.1, Figure 8-2 Network Diagram (graphic)
This should be referenced in the system-characteristics/network-architecture/diagram/link/@href flag using a value of "#11111111-2222-4000-8000-001000000055"
May use rlink with a relative path, or embedded as
base64.
FedRAMP prefers base64 for images and diagrams.
Images must be in sufficient resolution to read all detail when rendered in a browser via HTML5.
The primary data flow diagram.
Section 8.1, Figure 8-3 Data Flow Diagram (graphic)
This should be referenced in the system-characteristics/data-flow/diagram/link/@href flag using a value of "#11111111-2222-4000-8000-001000000056"
May use rlink with a relative path, or embedded as
base64.
FedRAMP prefers base64 for images and diagrams.
Images must be in sufficient resolution to read all detail when rendered in a browser via HTML5.
Federal Acquisition Supply Chain Security Act; Rule,85 Federal Register 54263 (September 1, 2020), pp 54263-54271.
CSP-specific citation. Note the "type" property's class is "law" and the value is "citation".
CSP-specific citation. Note the "type" property's class is "acronyms" and the value is "citation".