UIS.501.2 Software-as-a-Service Guidelines

In support of UIS.501 Vendor Security Policy

Georgetown University has adopted the security audit and accountability principles established in NIST SP 800-53 “Risk Assessment” guidelines as the official policy for this security domain. Each departmental technology requisitioner, sponsor, administrator, steward and owner must adhere to the guidelines and procedures associated with this policy in order to support and be compliant with the University information security framework.  

Software as a Service (SaaS) Business Requirements  

1. The product provides functional support for Georgetown’s business
   • The product must satisfy the Georgetown functional business requirements
   • The product must fit well with other products in the University department’s portfolio 
2. The technology vendor is viable and provides support for the product 

   • The technology vendor must be a stable entity running on a sustainable business model and unlikely to disappear. The technology vendor must interact with other services or tools supporting activities in their segment of the market.

   • The technology vendor must lead in their segment of the market, matching and exceeding user expectations. Strength in this area ensures that the product continues to be viable as competitors emerge. 

   • The technology vendor must offer multiple levels of support and define them clearly in their terms. Roles and contacts must be clearly documented, and the department responsible party should verify that contacts are responsive.

   • UIS must understand a full support model before broad deployment of any SaaS product or service. Even inexpensive or “free” SaaS products have an associated cost to consider in terms of data, resources, or support. 

   • UIS must clearly understand the lifecycle of the product, including the business workflow, contractual obligations, and the technology vendors responsibilities for supporting an exit strategy for the University.

3. The technology vendor has a process to notify Georgetown about changes in the product
   • This includes any changes to user interface, APIs, integrations, data structure, or physical location (if appropriate).  

Software as a Service Technical Integration  Requirements 

1. The product integrates with Georgetown’s access management and account provisioning systems

   • SaaS products universally provide some application programming interface (API) to integrate with other products and services. APIs are also the principal method of bulk data loading and extraction, which facilitate onboarding and exit from the SaaS provider. Where data or protocol standards exist for data exchange and/or transactions, the SaaS provider must support them. 

   • The SaaS provider must support account provisioning and authentication integrations with the University’s infrastructure. To enable GU users to use their central single-sign-on credentials, and to centrally control the authentication process and group membership/access control, the cloud service must ensure that:

     • SAML2 is supported by the product

     • There is a way to provision and control group memberships programmatically by some integration 

2. The product has the capability for service health monitoring
   • SaaS technology vendors must include a companion status and health check monitoring service that shows UIS the current health of the service.  

3. The product includes log and/or event notification (e.g., it tracks administrative access or configuration changes to deployment)

   • The SaaS provider must have incident notification mechanisms in place (such as email or SMS) for any service outage or security incident 

4. The product has testing and staging environments
5. The product is scalable and fault-tolerant 
   • SaaS providers must be scalable and highly available by design and in practice, so that any spike in demand by their consumer base does not affect the performance of any individual user. Similarly, the overall system must be designed to be fault-tolerant so that if any subsystem failure occurs, there is no resulting service outage. 

Software as a Service Risk Management Requirements  

1. The product supports Georgetown’s data security requirements

   • The product must comply with the appropriate standards for the University’s risk classifications. For restricted and sensitive data or business processes (for example, related to financial or student data), you must contact the Georgetown University Information Security Office (UISO) before selecting or using a SaaS provider. 

   • The SaaS provider must document their alignment with relevant compliance standards/processes.  

2. The product complies with University policy and applicable legal requirements

   • Beyond the operational reporting necessary for incidents, the SaaS provider must define their responsibilities for reporting timeliness, completeness, root cause, and mitigation strategy.

   • Depending upon the type of data/business process involved with a SaaS provider, statutory regulations (such as PCI-DSS or HIPAA) may constrain the location of the data and require very specific notification requirements. 

   • In the case of breaches or outages, in addition to the necessary operational reporting, there must be defined technology vendor responsibilities for reporting timeliness, completeness, root cause, and mitigation strategy.

   • The product must conform with University accessibility standards. 

3. The product supports business continuity and disaster recovery

   • The SaaS provider must have a track record for availability, both on uninterrupted normal service and during upgrades/changes. 

   • A third-party audit assesses the disaster recovery readiness of the SaaS provider, and that information can be provided to the University upon request. 

   • An exit strategy must exist upon termination of the services by the department or the University. The destruction or return of University data is required as per University standard contract terms.