Skip to content Skip to site navigation

Software-as-a-Service (SaaS) Considerations

SaaS Checklist

A SaaS product used for the Stanford community must meet these requirements:

Business requirements:

The product provides functional support for Stanford's business.
The service provider is viable and provides support for the product.
The service provider has a process to notify the user about changes in the product (e.g., functionality, UI).

Technical/integration requirements:

The product integrates with Stanford's IAM (Identity and Access Management) and account provisioning systems.
The product has the capability for service health monitoring.
The product includes log and/or event notification (e.g., it tracks administrative access or configuration changes to deployment).
The product has testing and staging environments.
The product is scalable and fault-tolerant.

Risk management requirements:

The product supports Stanford's data security requirements.
The product complies with University policy and legal requirements.
The product supports business continuity and disaster recovery.

See the content below for details about the items in this checklist. If the product meets these criteria, see Choosing and Purchasing a Cloud Solution, Step 3 for next steps in acquiring and managing the product.

The product provides functional support for Stanford's business.

  • The product must satisfy to a high degree the functional business requirements of the Stanford community.
  • The product must fit well with other products in your unit’s portfolio. Can you leverage the combined power of as many of your products and the broader University’s products as possible?

The service provider is viable and provides support for the product.

  • The service provider must be a stable entity running on a sustainable business model and unlikely to disappear. The service provider must interact with other services or tools supporting activities in their segment of the market.
  • The service provider 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 service provider must offer multiple levels of support and define them clearly in their terms. Roles and contacts must be clearly documented, and you should verify that contacts are responsive.
  • Stanford must understand a full support model before broad deployment of any SaaS product or service. Even inexpensive or “free” SaaS products cost something to offer and extend to the Stanford community. The funding model must match the cost (e.g., ongoing licensing or support costs).
  • Stanford must clearly understand the lifecycle of the product, including the business workflow, contractual obligations, and the service provider's responsibilities for supporting an exit strategy for Stanford.

The service provider has a process to notify the user about changes in the product.

  • This includes any changes to user interface, APIs, integrations, data structure, or physical location (if appropriate).

The product integrates with Stanford IAM 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 Stanford's infrastructure. To enable Stanford users to use their central SSO credentials, and allow Stanford to centrally control the authentication process and group membership/access control, ensure the following:
    • SAML2 is supported by the product. SAML2 is a mainstream standard that exists in order to redirect a user authentication from the service provider back to Stanford’s IAM infrastructure, allowing single sign-on (SSO).
    • There is a way to provision and control group memberships programmatically by some integration.

The product has the capability for service health monitoring.

  • SaaS service providers must include a companion status and health check monitoring service that shows Stanford the current health of the service.

The product includes log and/or event notification.

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

The product has testing and staging environments.

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.

The product supports Stanford's data security requirements.

  • The product must comply with the appropriate standards for the University's risk classifications. For particularly sensitive data or business processes (for example, financial or health care transactions), you must contact the Stanford University Information Security Office (ISO) before selecting or using a SaaS provider.
  • All reputable SaaS providers document their alignment with relevant compliance standards/processes. For example, ISO 27001 is a compliance standard and framework that ensures a range of security practice and controls are performed by the service provider. This and similar objective audits can help you gain and maintain assurance for a range of business uses.
  • For more information see Security When Using a Cloud Product.

The product complies with University policy and legal requirements.

  • Beyond the operational reporting necessary for incidents, the service 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 the PCI Data Security Standard or HIPAA) may constrain the location of the data and require very specific notification requirements. If you have questions about these requirements, contact the relevant compliance group at Stanford.
  • In the case of breaches or outages, in addition to the necessary operational reporting, there must be defined service provider responsibilities for reporting timeliness, completeness, root cause, and mitigation strategy.
  • The product must conform with University accessibility standards.

The product supports business continuity and disaster recovery.

  • Any established SaaS provider must have a track record for availability, both on uninterrupted normal service and during upgrades/changes. You need to assure that the records shows an acceptable level of service availability for your business needs.
  • Usually a third party audit assesses disaster recovery readiness, and Stanford gets the information indirectly. The acceptable level of RTO/RPO (Recovery Time Objective/Recovery Point Objective) demonstrated by a provider is a business decision.
  • The exit strategy must include devolving business process, data, and the references to the service provider which will not convey directly (e.g., name of SaaS provider in web links).

Comments or questions?

Do you have questions or feedback about this page? You can use our request form to contact the Cloud Program’s core team members.