5.4 Software and Services Specifications

The information below is provided by the TTUHSC IT Division and fully incorporated to Section 5.4 Software and Services Specifications of software and technology services related solicitations.

General Technical

NOTE: In completing the information in this section, please indicate whether the proposed solution is cloud-hosted Software as a Service (SaaS) or on premise (hosted at TTUHSC) solution. If your solution supports both models, please provide information about both models.

Software and Services
1. Provide an overview of the proposed software/services solution you are proposing.
2. Provide an overview of the implementation process for the proposed software/services solution you are proposing.
3. Provide sanitized copies of system architecture diagrams and data flow diagrams, as they pertain to the service being provided.
Provide a general description for each of the following as it relates to your proposed software/services solution:
1. Server platforms utilized (including hardware requirements).
2. Application or Web Server platforms utilized.
3. Database platform utilized (including hardware and software requirements).
4. Storage requirements.
5. Networking requirements.
6. Desktop platform utilized (including any hardware and software requirements).
7. Describe your supported methods of authentication. TTUHSC prefersprefers Single Sign On integration using Security Assertion Markup Language (SAML) 2.0 or Central Authentication Service (CAS).
8. Methodology for granting users access to your solution (include any information on roles, user imports, etc.).
9. Supported browsers (including versions).
10. Any supported integration points your solution may have with other systems.
11. Any APIs or Web Services that are available.
12. Schedule and method of delivery/implementation for software or services enhancements, modifications or bug fixes.
13. Methods available for data archiving or purging.
14. Methods for obtaining copies of data for our use locally.
15. Provide information related to the security of your solution. Include information related to your data center(s), application and database security, procedures related to breaches, etc.
Describe your implementation approach and address each of the following:
1. The timeline from award date.
2. Any challenges that should be addressed before implementation.
3. How installation is performed.
4. Handling and processing of enhancement/change requests.
  1. Costs.
  2. Turn-around time.
5. Test systems available for realistic testing prior to product launch.
6. Actions or decisions that can be made to accelerate implementation or reduce costs.
7. Description of Contractor roles and responsibilities.
8. Description of expected roles and responsibilities of TTUHSC staff.
9. Quality assurance and methodologies used to insure expected results.
Describe and provide information related to the customer service/support services that will be provided with your solution. Include any optional additional support services that may be available for consideration. Additionally, describe and provide information related to your solutions service level agreements (SLAs) and any hierarchy of options available.
Describe and provide information related to any user/client community, user groups, or other resources that may be available to users of your solution. Include information related to email lists, knowledgebases, user conferences, best practices, review panels/committees for setting software/service enhancement priorities, etc.
1. Describe the training options that are available with your solution. Provide information related to the delivery platform, training documentation, manuals, guides and cost of the training and associated materials.

Application Development (Web or Mobile)*

Periodically, the Texas Tech University Health Sciences Center (TTUHSC) engages third party vendors to provide website and web application development with the expectation that TTUHSC's IT Division will host these deliverable assets on institutional servers. In order to comply with established standards and policies, TTUHSC IT Programming, Applications, and Web Services (PAWS) has defined the following guidelines that all third-party vendors are expected to follow during the course of completing their contracted deliverable assets. If these guidelines are not followed, TTUHSC IT will not be able to host the resulting deliverable assets on Institutional servers.

Contractor Responsibilities
- Follow best practices in usability, user experience, navigation design, markup, search engine optimization (SEO), load speed optimization, etc.
- The vendor should provide evidence of usability, quality assurance, bug and other testing.
- Provide W3C valid HTML 5.0.
- Make browser-rendered deliverables (web applications, web pages, assets, etc.) crossbrowser compatible in the most current versions of modern browsers.
- Comply with:
  - Section 508 (accessibility) for markup, assets, etc.
  - Texas Administrative Code 206 State Web Sites, Sub-chapter C – Institutions of Higher Education Websites.
  - Texas Administrative Code 213 Electronic and Information Resources, Sub-chapter C – Accessibility Standards for Institutions of Higher Education.
  - TTUHSC IT Policies.
  - TTUHSC Identity Guidelines.
- Provide:
  - CSS stylesheets.
  - JavaScript or other scripts.
  - Images including source appropriate source files (Photoshop, Fireworks, etc.).
  - Source fonts.
  - All assets required for the web site to function.
- For HTML content to be incorporated into our CMS (Omni Update).
  - Provide Omni Update-ready templates, and all associated assets for implementation in Omni Update.
  - If Omni Update ready templates are not provided, the vendor must provide a set of fully functioning html pages and all associated assets to be integrated by IT into Omni Update.
  - In instances where TTUHSC's IT Division must develop/build the Omni Update templates based on fully functioning html pages and associated assets, the requesting TTUHSC Department will be responsible for the hours expended by IT for this development chargeable at IT PAWS standard rate stated on the PAWS Rate Sheet.
  - Important notes: TTUHSC does not utilize the Omni Update Live Delivery Platform (LDP) with their implementation of Omni Update. Any integration that requires the type of functionality found in LDP will need to be developed using a .NET solution.
  - For the web application development, the following applies.
    - Development must be in .NET (VB.NET/WebForms framework version 3.5-4.x).
    - Master page for all application interfaces.
    - Separation of the presentation and data into separate functional blocks (i.e., presentation and data layers).
    - Parameterized queries for all database interaction.
    - Appropriate data validation.
    - Backend databases must be MS SQL databases with appropriate scripts supplied upon delivery for database schema creation (table creation and setup, population of elements needed initially such as lookup table values, etc.).
    - Any dependent assemblies will include source code if they are not publicly available (such as the AJAX control tool kit).
    - Functional overview and/or walk through of the application, its objects and implementation so that TTUHSC staff can gain an appropriate understanding of the code base, its relationships, user roles, etc. Code will be scanned via WebInspect or Fortify SCA by TTUHSC staff prior to code delivery and/or after delivery and vulnerabilities must be remediated by the vendor prior to acceptance and deployment of the code base.
    - Source code must compile and run properly upon delivery or it will not be accepted (access to a test environment can be provided by TTUHSC with approval by IT Administration).
    - Make any changes requested by TTUHSC IT Division during implementation process and that result from code security analysis.
TTUHSC Responsibilities
- Provide information related to standards, laws, policies, etc. upon request.
- Perform code security analysis.
  Implement the html pages, CSS, etc. into Omni Update.
- Work within the TTUHSC procurement framework to assist in evaluating proposals which have IT components. Proposed systems that meet TTUHSC IT Standards will be implemented through the IT Project management process and supported as outlined in the current IT Service Level Agreement.

Information Security Questionnaire

For purposes of this RFP, Confidential records or information are defined as any and all information owned by TTUHSC – created, received from or on behalf of TTUHSC, or accessed in the course of performing/delivering service – of which collection, disclosure, protection, and disposition is governed by state or federal law or regulation, particularly information subject to the Family Educational Rights and Privacy Act (FERPA), the Gramm-Leach-Bliley Act (GLBA), Health Insurance Portability and Accountability Act (HIPAA), Payment Card Industry Data Security Standards (PCI-DSS), Texas Education Code (TEC), Texas Government Code, or Texas Administrative Code (TAC). This information includes, but is not limited to, Social Security Numbers, Patient Health Information, student records, financial records regarding students (or their parents or sponsors), financial and personal information regarding TTUHSC employees, identifiable human subject research data, and other personally identifiable information identified by law.

Data Protection:
1. Describe the security features incorporated into the solution.
2. List all licensed software, including imbedded products, in the solution and their corresponding ownership.
3. Does the Proposer have an Information Security Plan, supported by security policies and procedures, in place to ensure the protection of information and information resources? If yes, describe the outline of the Plan and how often it is updated. If no, describe what alternative methodology the Proposer uses to ensure the protection of information and information resources.
4. Does the Proposer have a Disaster Recovery Plan, supported by security policies and procedures, in place to ensure the timely recovery of information and information resources? If yes, describe the outline of the Plan (including SLA) and how often it is updated. If no, describe what alternative methodology the Proposer uses to ensure the timely recovery of information and information resources.
5. Describe the monitoring procedures and tools used for monitoring the integrity and availability of the systems interacting with the solution proposed, detecting security incidents and ensuring timely remediation.
6. Describe the physical access controls used to limit access to the Proposer's data center and network components only to authorized personnel.
7. List corresponding roles employed by Proposer and its third-party entities that would have access to the environment hosting all systems that would interact with the service proposed including any systems that would hold, process, or from which TTUHSC data may be accessed.
8. What additional administrative, technical and physical security controls does the Proposer have in place or plan to put in place?
9. What procedures and best practices does the Proposer follow to harden all systems that would interact with the solution proposed including any systems that would hold, process, or from which TTUHSC data may be accessed?
10. What technical security measures does the Proposer take to detect and prevent unintentional [accidental] and intentional corruption or loss of TTUHSC data?
11. If the Proposer requires remote connectivity to TTUHSC’s network to access TTUHSC data, or to perform support/administration tasks, does Proposer enforce secure remote access controls? If yes, describe the secure remote access controls Proposer intends to use when accessing TTUHSC’s network. If no, describe what alternative methodology the Proposer intends to use to ensure the security of remote access.
12. Does the Proposer have a process for security quality assurance testing of the systems interacting with the solution proposed? If yes, describe the activities designed to validate the security architecture and functionality.
13. Where Proposer may create, receive from or on behalf of TTUHSC, or have access to records or record systems that contain confidential information, describe the security features incorporated into the solution to safeguard confidential information.
14. Does the Proposer securely configure (harden) systems and devices using industry standard baselines? Systems and devices include, but not limited to, clients, servers, databases, applications, and network devices.
15. Does the Proposer have a documented change management process? If yes, does the process include notification to and coordination with clients such as TTUHSC during the change control review process?
16. Does the Proposer intend to store any TTUHSC data outside of the continental US? If yes, provide list of locations where the data will be stored.
17. What procedures and safeguards does the Proposer have in place for sanitizing and disposing of confidential data according to prescribed retention schedules or following the conclusion of a project or termination of a contract to render it unrecoverable and prevent accidental and/or unauthorized access to confidential data?
18. Describe any assumptions made in the preparation of your proposal regarding information security outside those already supplied by your company in the proposal.
Access Control:
1. Does the solution provide the capability to use federated authentication for user authentication and login? If yes, describe how the solution provides that capability. If no, provide detailed responses to (a) and (b) below.
  1. Describe how users authenticate to the proposed solution.
  2. Describe the Proposer's password policy including password strength, password generation procedures, and frequency of password changes. If passwords are not used for authentication to the proposed solution, describe what alternative controls are used to manage user access.
2. Does the solution allow for multiple security levels of access based on affiliation (e.g., staff, faculty, student), roles (e.g., system administrators, analysts, information consumers), and/or department? If yes, describe how the proposed solution provides for multiple security levels of access.
3. Does the solution manage administrator access permissions at the virtual system level? If yes, describe how this is done.
4. Does the solution provide the capability to limit user activity based on user type or role (i.e., who can create records, delete records, create and save reports, run reports only, etc.)? If yes, describe how the solution provides that capability. If no, describe what alternative functionality is provided to ensure that users have need-to-know based access to the solution?
5. What safeguards does the Proposer have in place to segregate TTUHSC data from system and other customers' data to prevent accidental and/or unauthorized access to TTUHSC data?
6. What safeguards does the Proposer have in place to prevent the unauthorized use, reuse, distribution, transmission, manipulation, copying, modification, access, or disclosure of TTUHSC data?
7. What administrative safeguards and best practices does the Proposer have in place to vet Proposer's employees and Proposer’s subcontractor employees that would have access to the environment hosting all systems that would interact with the service proposed including any systems that would hold, process, or from which TTUHSC data may be accessed to ensure that TTUHSC data and resources will not be accessed or used in an unauthorized manner.
8. List all subcontractors that may have access to TTUHSC data and their corresponding location.
Data Sharing:
1. What administrative safeguards and best practices does the Proposer have in place to vet Proposer's and third-parties' staff members that would have access to the environment hosting all systems that would interact with the service proposed including any systems that would hold, process, or from which TTUHSC data may be accessed to ensure need-to-know-based access.
Data Transmission:
1. How will TTUHSC data go between TTUHSC and Proposer's proposed solution? If connecting via a private circuit, describe what security features are incorporated into the private circuit. If connecting via a public network (e.g., the Internet), describe the way the Proposer will safeguard TTUHSC data.
2. Will the solution secure the data transmission between TTUHSC and the Proposer? If yes, describe how the Proposer provides that security. If no, what alternative safeguards are used to protect TTUHSC data in transit?
3. Will the solution secure the communications between the managed systems or administrators to the centralized manager server? If yes, describe how the solution provides that security.
4. Will the solution encrypt TTUHSC data in transit? If yes, describe how the solution provides that security. If no, what alternative methods are used to safeguard Confidential data in transit and at rest?
5. Will the solution encrypt TTUHSC data at rest? If yes, describe how the solution provides that security. If no, what alternative methods are used to safeguard Confidential data in transit and at rest?
Data Backup:
1. Describe the data backup procedures utilized for your solution. Include information about retrieving information from backups and the circumstances where this is allowed. Also, include information pertaining to the storage and rotation of backup copies to off site locations.
2. Will the Proposer protect TTUHSC data backups against unauthorized access? If yes, describe the methods used by the Proposer to provide that protection.
3. Will the Proposer encrypt TTUHSC data backups? If yes, describe the methods used by the Proposer to encrypt backup data. If no, what alternative safeguards does the Proposer use to protect TTUHSC data backups against unauthorized access?
Security Incident Management:
1. What procedures and methodology does the Proposer have in place to manage security incidents including detection, notification, and investigation to mitigate any damage and to restore any lost TTUHSC data? Security Incident has the same meaning as the term found in 45 CFR § 164.304.
2. How frequently does the Proposer log and review security-related events? Does the Proposer have the capability of sharing these logs with TTUHSC when requested?
3. What procedures, methodology, and timetables does the Proposer have in place to detect information security breaches and notify TTUHSC? Breach shall have the same meaning as the term found in 45 CFR § 164.402.
4. Describe what procedures the Proposer has in place to isolate or disable all systems that would interact with the solution proposed in case a security breach should be identified? Including any systems that would hold, process, or from which TTUHSC data may be accessed.
5. Describe the procedures and methodology in place to detect information security breaches and notify customers in a manner that meets the requirements of the Texas state breach notification law.
Protected Health Information (HIPAA):
Health Insurance Portability and Accountability Act of 1996 (HIPAA) (Pub. L. No. 104-191, § 264 (1996), codified at 42 U.S.C. § 1320d; Standards for Privacy of Individually Identifiable Health Information, 45 C.F.R. § 160, 45 C.F.R. § 164 subpts. A, E.
1. Where Proposer may create, receive from or on behalf of TTUHSC, or have access to, records or record systems that are subject to the Health Insurance Portability and Accountability Act (HIPAA) of 1996 (Public Law 104-191), describe the security features incorporated into the solution to safeguard records subject to HIPAA.
2. Does the Proposer monitor the HIPAA Security Rule (45 C.F.R. § 164 subpts. A, E (2002)) Required safeguards and the Proposer's own information security practices to ensure continued compliance? If yes, describe the Proposer's monitoring activities and their frequency.
Student Education Records (FERPA):
The Family Educational Rights and Privacy Act (FERPA) (Pub. L. No. 93-380 (1974), codified at 20 U.S.C. § 1232g)
1. Where Proposer may create, receive from or on behalf of TTUHSC, or have access to, records or record systems that are subject to the Family Educational Rights and Privacy Act ("FERPA"), 10 U.S.C. Section 1232g, describe the security features incorporated into the solution to safeguard FERPA records.
Credit Card Data:
If eCommerce is part of the RFP requirements and your solution provides this functionality, please answer the following:
1. Does the eCommerce portion of your solution integrate with TouchNet? If so, provide details.
2. If the eCommerce portion of your solution does not integrate with TouchNet, please describe in detail the eCommerce portion of your solution.
3. Does the Proposer conform to and meet PCI DSS standards? If yes, provide examples of Proposer practices that can assist with our understanding of how the Proposer meets PCI standards.
4. Does the Proposer monitor the PCI DSS standards and the Proposer's own information security practices to ensure continued compliance? If yes, describe the Proposer's monitoring activities and their frequency.
5. Would the Proposer be willing to provide a letter of certification or independent audit report to attest to meeting PCI DSS standard requirements? If no, Proposer must, as part of its proposal, identify and describe in detail the reasons for Proposer's objection.
Financial Information:
The Gramm-Leach-Bliley Act (GLBA) (Pub. L. No. 106-102 (1999), privacy protections are codified at 15 USC § 6801 et seq.).
1. Where Proposer may create, receive from or on behalf of TTUHSC, or have access to financial records or record systems that are subject to the Gramm-Leach-Bliley Act (GLBA) (Public Law), describe the security features incorporated into the solution to safeguard records subject to GLBA.
Email:
1. If the Proposer requires sending of electronic mail on behalf of TTUHSC, does Proposer enforce secure email controls? If yes, describe the secure email controls used by Proposer. If no, describe what alternative methodology the Proposer intends to use to ensure email security.
2. Does the proposed solution require spoofing of TTUHSC’s email domain? If yes, describe the methodology Proposer intends to use for spoofing TTUHSC’s email domain.
Security Audits and Scans:
1. Has the Proposer undergone and would be willing to provide the results of a Statement on Standards for Attestation Engagements (SSAE) No. 16 (formerly SAS 70) audit, HIPAA, PCI DSS, FERPA, ISO 27001, NIST/FISMA, or equivalent independent security audit, to attest to the strength of the Proposer's security practices and procedures? If Proposer objects to providing the audit results, Proposer must, as part of its proposal, identify and describe in detail the reasons for Proposer's objection.
2. How often does Proposer conduct internal security controls assessments? If yes, would Proposer be willing to provide previously performed assessment results on any systems that would hold, process, or from which TTUHSC data may be accessed? If Proposer objects to providing the assessment results, Proposer must, as part of its proposal, identify and describe in detail the reasons for Proposer's objection.
3. How often does Proposer conduct external security controls assessments? If yes, would Proposer be willing to provide previously performed assessment results on any systems that would hold, process, or from which TTUHSC data may be accessed? If Proposer objects to providing the assessment results, Proposer must, as part of its proposal, identify and describe in detail the reasons for Proposer's objection.
4. Does the Proposer maintain vulnerability management procedures that include identifying and remediating technical vulnerabilities? If yes, how often does Proposer scan information resources for vulnerabilities and what is the remediation timeline?

Standards, Laws, Policies, IT PMO and IT SLA

Upon request, information pertaining to standards, laws, policies, etc. will be provided.
TTUHSC IT Division representatives will review software and technology service-related proposals for the content required above.

*Required only if applicable.

Request for Proposal