GT System Security Plan (SSP)

These documents are the current iterations of the System Security Plan (SSP) Template. Please click on the images below to open and view:

 

Project SSP Template
Project SSP Template

System-Wide SSP Template
System-Wide SSP Template

Lab-Wide & Environment-Based SSP Template
Lab-Wide/Environment-Based SSP Template


 

The Cyber Security GRC Team will assist with drafting an SSP. If you have any questions about the process, please go to this page:

Georgia Tech NIST 800-171 Process

 

What System Security Plan Will Work Best for You?

There are a few different general scopes where a System Security Plan can be written.

Important: All SSPs are valid for one year. Assessments of the SSPs will occur within that year as validations of the solutions to the controls listed. SSPs will be renewed and assessed yearly. OSP is the authority or final word whether an SSP is acceptable and may require Project SSPs even if there is a Lab-Wide SSP.

Lab-Wide/Environment-Based SSP

  • This SSP is more practical for PIs who work on many projects at once using the same personnel and equipment.
  • More precisely, it will cover an environment that processes and stores CUI for multiple projects, and is a consideration when all of the following are true:
    • The Principal Investigator is the same across multiple projects.
    • Personnel working on all projects and equipment used on all projects in the environment are accounted for.
    • Personnel working in the environment are authorized to work on all projects in the environment covered by the SSP.

Important Note: Projects completed for labs or environments that have a Lab-Wide or Environment Based SSP will need to have a close-out completed for projects based on what happens with the data when the project is over:

  • If the data is saved:
    • A Closeout ROC will need to be completed that will follow the lab-wide SSP as a guideline
  • If the data is destroyed:
    • A Data Destruction Attestation form will need to be completed and signed by the PI to attest that the data is destroyed
  • If the PI wishes to attest that no CUI was received or processed as part of the project:
    • An attestation to this effect will need to be completed and signed by the PI to attest that no CUI was received or processed as part of the project.

Project-Based SSP

  • This SSP is best for researchers that do not generally work with CUI, but work on a project ad-hoc that either:
    • has the DFARS 7012 clause
    • requires designation of processed and/or stored data as CUI.
  • This SSP will cover either a single project or BOA (Basic Ordering Agreement) only
    • Depending on the requirements set forth by OSP, a unique document will need to be written for each project or BOA for which the PI is responsible.
  • When the project ends, there will be a closeout to address either:
    • An assessment to confirm the resulting CUI is securely stored
    • An attestation that the CUI was destroyed after the project ended.
  • Note: Fundamental Research Exception (FRE) SSPs fall into this category.

Solution-Based SSP

  • This SSP, much like the Environment-Based SSP, is to ensure that solutions offered on campus confirm to the controls of NIST 800-171 and are suitable to process and store CUI.
    • It will map the NIST 800-171 controls to a solution offered on campus and the users that are authorized to administer the solution.
  • Once assessed, the SSPs are kept on file and the solutions will be maintained on the general SSP template as an acceptable method to meet controls for projects and environments.