Software as a Service: Guiding Principles As the Office of Information Technology (OIT) works in partnership with colleges and business units across the University, its common goals are to: substantially increase IT effectiveness and quality; reduce costs; boost innovation. Software as a Service (SaaS) is a real and attractive option for achieving those goals. However, in implementing the SaaS model, there are guidelines to which the University must adhere in its adoption and use. Many applications can be implemented through a SaaS model, and the industry clearly is embracing this approach. The risk to the University varies with the type of application deployed, the information used in the application, and where the information is stored. The University can use a combination of contracts, monitoring, and internal processes and procedures to manage risk. The costs of managing risk should not be ignored, and should be part of any SaaS cost projection. SaaS Governance Models Vendor accountability The University should consider only vendors who take ultimate responsibility for customer satisfaction. Timely vendor communication of key strategy changes such as product roadmap decisions, organizational shifts, support levels, licensing, and pricing is essential. In addition, escalation processes should be defined and service level agreements should be mutually acceptable. Timely and valuable interactions Vendors should guarantee response times in writing for issues such as service requests and bug fixes. Penalties for significant issues outside the agreed upon Service Level Agreements (SLAs) should be in line with the business impact of a disruption to the University. Vendors should be able to provide a complete picture of University-vendor interaction history. Total ownership of and access to data In any SaaS agreement, the University must obtain contractual agreement that the University owns all its data and will have access to this data at all times throughout the relationship. Tools to access data should be provided to the University. 6/20/2011 Page 1 of 8
Ongoing vendor transparency For critical applications, the University should have confidence in the vendor s longterm viability. Transparency of vendor viability allows the University to develop risk management scenarios based on the vendor s actual financial and operational health, permitting time to migrate to a new service provider. Selection This section provides the scope of evaluation options the University should expect from software vendors during the process of making a decision on a product and vendor. Try before buying The University should be given access to the system and provided an environment in which to demonstrate the system. Vendors may charge for the proof of concept as appropriate. Access licensing and pricing terms and conditions Vendors that have existing relationships with the University or are state-approved are preferred. Pricing metrics, discounting criteria, and terms and conditions should be provided. Terms around user and usage metrics should be made clear. Standard contracts and renewal provisions should be made available for review. Provide a TCO analysis of SaaS during the sales cycle Vendors should be able to demonstrate the total cost of ownership (TCO) over a defined period of time. Vendors should project best and worst case scenarios regarding growth in user base, and increase in consumption of technical resources, such as storage. Key metrics should show comparisons of deployment options over multiple time frames. If possible, projections should include disengagement from the vendor at the end of the contract. Understand system configuration and architecture The University should receive details about the application s architecture. Key areas to detail include hardware, operating system, and configuration and customization processes. Other areas for disclosure should include batch processing, job queuing, and system monitoring. It is also critical for the University to receive detailed plans regarding the segregation of University data from other clients data in the hosted location(s). Receive disclosure about solution defects The University should expect full disclosure of known defects that relate to performance, availability, and integration. The vendor should also provide a list of 6/20/2011 Page 2 of 8
known bugs, integration risks, performance issues, and functional deficiencies. In addition, disclosure should include incomplete business process flows where the University s required use case scenarios cannot be completed. Stipulate data management requirements The University should expect full disclosure about how its data will be managed. Disclosure should include physical location, security mechanisms, access rights, disaster issues, and regulatory compliance. Critical factors such as host information and availability should also be provided. Perform due diligence on vendors The University should be able to examine a SaaS vendor s financial viability, security risks and legal liability. Key areas should include financial performance, legal risks, management team background, customer lists, and Statement on Auditing Standards No. 70 (SAS 70) compliance. (For a description of SAS 70, see the Regulatory Compliance section below.) The University should have the right to periodic reviews of SAS 70 certification results and have third-party auditors perform regular audits of the vendor data center. The vendor should provide customer references to the University. The University should engage in conversations with those customers about the solution and implementation plans they arrived at with the vendor. The University should also reach out to user-group leaders for honest and candid discussions. Reputation alone does not provide sufficient assurance that the vendor will perform as required and properly protect sensitive information. The depth of investigation must be appropriate to the level of risk the enterprise needs to manage and the security requirements that fall outside of the enterprise s security objectives. Regulatory Compliance To ensure the vendor is in compliance with both their stated security controls, and in alignment with the University s guidelines, the University must usually rely on thirdparty assessments of the vendor s security posture. The most common type of thirdparty assessment is the Statement on Auditing Standards No. 70: Service Organizations (SAS 70). The SAS 70 is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). The SAS 70 provides guidance that enables an auditor to issue an opinion on the organization s controls, but does not specify the controls. Rather, the vendor must specify the controls and the control objectives. The auditor will determine if the specified controls are actually in place. The preferred type of SAS 70 audit is a Type II report that includes the scope of the control, control objectives, and the results of 6/20/2011 Page 3 of 8
the auditor s tests of the controls. It should be noted that only certified public accounting firms can perform a SAS 70. The University should also verify that the SAS 70 is a Type II assessment and the vendor s controls meet the University s requirements for risk management. If the latter is true, then the assessment will have some value. If the controls described in the assessment are insufficient, the SAS 70 has limited or no value to the University. Testing This section presents the scope of options and services the University should expect from software vendors as systems are configured and tested prior to deployment. Testing Documentation The University should fully document and execute test plans prior to deployment. If working with an authorized implementation partner, the scope and timeline of this phase must be contractually agreed upon. This phase should include deliverables such as testing strategy, test plans and documentation of results. The scope of the testing should not only be the delivered functionality in the software but also external interfaces, data conversion into the new system, system performance testing and penetration testing. Deployment This section presents the scope of options and services the University should expect from software vendors as they implement and consume the technology. Support multiple implementation options The University should have the option of self-deploying, choosing a third party partner, or working with the vendor. The University should have the option to selfimplement with consideration for the speed of implementation. Receiving a clear statement of work Vendors should deliver large projects in accordance with project management best practices. Projects should follow clearly defined templates for rapid implementation. Deliverables, milestones, and escalation processes should be documented prior to project kick-off. Accessing training programs A vendor should provide access to training programs to ensure the University or their partner is able to complete a deployment. More importantly, the University 6/20/2011 Page 4 of 8
should expect adequate knowledge transfer activities from the vendor to ensure self-sufficiency. Impact to University Application Support With the introduction of SaaS into the University s landscape, long-standing processes may have to be modified. For example, incidents may originate within the SaaS vendor and the response procedures will have to be modified to identify new methods for determining an incident has occurred. The enterprise will need to create lines of communication between the vendor and the University response team. This analysis should also include identification of redundant legacy functionality, with documentation, decommissioning of redundant systems and signoff from support managers and key business stakeholders. Adoption This section covers the scope of services the University should expect from vendors as the SaaS solution is utilized across the organization. Freedom of speech The University should not be limited in discussing the SaaS solution with fellow customers, peers or media. The University should be able to freely discuss issues with the software including, but not limited to, security issues, bugs, and pricing. The University should not be limited to non-disparagement clauses. Both sides should be open in their communication. License equivalency If shifting from on-premise software to SaaS or other on-demand models, the University should be given the right to convert user and usage models across different deployment options. Integration and API support Vendors should deliver key access to public Application Programming Interfaces (API), web services, and other integration tools to support hybrid deployment. These integration points should be out-of-the-box, vendor-supported, and provide connectivity with the University s enterprise Identity Management, Enterprise Resource Planning (PeopleSoft ERP), Business Intelligence, Constituent Resource Management, and other enterprise applications. 6/20/2011 Page 5 of 8
Data quality support While a vendor cannot guarantee the quality of data being put into the system, tools should be provided to the University to address both a conversion and normal processing perspective. These tools should ensure short-term and long term efficient processing and should include robust reporting capabilities. Optimization This section covers the scope of services the University should request of vendors as changes occur in the expansion, maintenance, or contraction in usage of the solution. Affiliate assignment The University should be able to provide access and usage of the software to a majority of its affiliates. The University and vendors should determine how to treat assignment with related organizations such as the Foundation. Merger and acquisition scenarios The University should be given the option to combine contracts to achieve higher discount levels or tiers during mergers and acquisitions. In cases where the software will no longer be use, limited access licenses should be provided to access pre-merger files, compliance requirements, or historical trending data. Multiple support options The University should request support options that provide tiered pricing and service levels that correspond to actual usage. Install base transparency Vendors should inform the University when multiple installations have been deployed by the University. The University should be able to access information about usage by users to determine if multiple contracts have been signed with a single vendor. Ongoing performance metrics The University should expect a trust site to monitor service level agreements. Vendors should provide a regular, periodic report on key availability and continuity metrics. Renewal This section covers the scope of services the University should expect from software vendors as shifts in usage requirements and changes to how SaaS solutions are adopted occur at the University. 6/20/2011 Page 6 of 8
Provide input into future capabilities Vendors should provide an input mechanism for prioritization of requirements. Acceptance criteria for decisions regarding the application roadmap should be open to the University. The University should understand vendors might set aside a portion of future investment for upgrades. Vendors should provide confirmation and status on feature requests. Give ample notice before deployment While most SaaS solutions implement upgrades without notifying the end users, where applicable, vendors should proactively communicate regarding modifications to the software. For significant changes, vendors should give the University adequate time to prepare for an upgrade. This includes preparing the appropriate training materials, performing appropriate testing, and working with end users regarding functional risks and impacts. Transition to alternative deployment options Vendors with multiple deployment options for similar code lines should provide mechanisms for the University to transition among the different options. At no time should the University be locked in to one deployment option. The University should be able to access all its data at any given time. Vendors should provide access to public and private APIs to support transitions. Determine termination criteria Both the University and vendor should communicate clear termination criteria. Termination criteria should include transition language and migration assistance conditions for the University. Regardless of the contract, the University should always own its data and have the capability to migrate it. Receive migration assistance When leaving a SaaS provider, the University should be provided with the necessary transition tools to ensure business continuity. Tools could include temporary hosting privileges, data migration, and historical archive capabilities. Key items would include business rules that govern the data structures within which the data is stored, data models, and logical models. Cost for these transition tools and services should be determined during the selection process. Purchase the source code In some cases, such as vendor insolvency, the University may leave a SaaS vendor and require more than just the flat file extract of their data. Under these conditions, the University may find it necessary to purchase the source code. Such scenarios should be discussed during conversations with the vendor. 6/20/2011 Page 7 of 8
Summary of Contractual Terms The following list provides topics that a purchaser of SaaS should bring to the attention of the Office of Information Technology and The Office of General Counsel. Information ownership: It should be clear that any University information stored by the vendor still belongs to the University. Unauthorized disclosure: The vendor must take reasonable care to avoid unauthorized disclosure and modification of University information. Right to audit: The University must assert its right to perform audits of the vendor and to have periodic third-party assessment reports provided by the vendor. Source code in escrow: If the long-term viability of the vendor is in doubt, the University may wish to escrow the application source code so that the University can maintain the service if the vendor goes out of business. Export capabilities: If the University decides to leave a vendor, capabilities to export or transfer the University s data to another vendor should be clearly defined. Investigations: If there is an incident or security breach, the University retains the right to conduct an investigation at the vendor s facilities or at minimum, be kept abreast of developments in the vendor s investigation at the executive-level. E-discovery: The University s legal team should consider the ramifications of a subpoena for another customer s information given to the vendor and how this might bypass the University s legal team. Intellectual property (IP) indemnification: Vendors faced with lawsuits must provide the University with indemnification from IP legal claims. Remedies may include refund of the subscription costs, provision of a replacement solution at zero cost, and vendor-developed solution. 6/20/2011 Page 8 of 8