Attachment 7 Clemson Unique Attachment 1.docx

Last Reviewed, April 11, 2022

RFP Technical Specifications Boilerplate FOR ERP (Procurement) General Requirements

· According to Clemson University (CU) policy, all of the selected vendor’s personnel providing services are responsible for protecting their access privileges and maintaining the confidentiality and proper use of the University’s data according to the University's policy. Personnel will not disclose or distribute data in any medium, except as required by responsibilities under the contract.

· Solutions must comply with all applicable laws and regulations within the higher education environment and the timely implementation of compliance with future changes to laws and regulations. The offeror must disclose all use and sharing of data and telemetry information. Current laws and regulations include but are not limited to the following standards:

· Family Educational Rights and Privacy Act (FERPA)

· Clery Act, Higher Education Act of 1965

· Americans with Disabilities Act of 1990, as amended,

· Rehabilitation Act of 1973, as amended,

· Children's Online Privacy Protection Rule ("COPPA"),

· Health Insurance Portability and Accountability Act of 1996 (HIPAA),

· CU’s Privacy Policy (http://www.clemson.edu/privacypolicy.html),

· CU’s Records Retention Schedules (https://libraries.clemson.edu/records-management/retention-schedules/).

· Offerors must provide a detailed implementation plan that includes a timeline with dates of initiation, milestones, and completion and include all requirements, if any, for university resources that must be used for each step of the implementation.

· The selected vendor must supply initial technical training on the proper use of any software solution. Offerors must include this training in the proposal. The training must be sufficient to enable technical individuals designated by CU to understand fully, test, validate, use tools, operate, and instruct others as to the features, functions, capabilities, and maintenance (e.g., trouble identification) of the software to perform all functions effectively and without error. Offerors must identify user groups and recommend additional training resources that might be beneficial to CU’s implementation.

Technical

· User Interface

· Browser Compatibility (if UI is browser-based)

· Offers must identify all platforms and browsers compatible with the proposed solution.

· Client (if UI is installed on local systems)

· Offerors must identify all operating systems/platforms compatible with the proposed solution.

· The solution should not require client-side Java but, if required, must be compatible with the then-current version of Java.

· The solution must not require unsupported client-side plugins (i.e., Microsoft Silverlight, Adobe Flash).

· Mobile Compatibility

· If a mobile application is part of the proposed solution it must, at a minimum, be compatible with iOS and Android.

· Virtual Desktop compatibility

· Offerors must identify if Virtual desktop configuration is possible and, if so, what virtual desktop configurations are compatible with the proposed solution.

· Assistive Technology Compatibility

· Offers must identify screen readers and assistive technology compatible with the proposed solution, including browser and screen reader combinations if applicable.

· Application Architecture

· The offeror must describe any compatibility or interoperability with desktop productivity tools (Microsoft Office, etc.)

· The offeror must describe the Application Programming Interface (API) if available.

· The offeror must describe the Application Server environment required for the proposed solution.

· Software sold or licensed to CU to be installed, maintained, or run by CU personnel must not have a dependency on Oracle Java (JDK, SE, EE, or ME) unless licensing and maintenance costs for Oracle Java, for the life of the product, are included in the purchase price. Preference for software based on Java technology will be given to vendors utilizing the OpenJDK framework.

· Offeror must include in their proposal recommended architectural designs for resilience.

· CU Hosted or Managed Database Services

· Solutions requiring CU support must be compatible with one of the following currently supported database technologies: Oracle or MS SQL. Other technologies will be evaluated individually.

· The offeror must provide technical documentation regarding configuration and installation, including backup/maintenance scripts for the proposed solution.

· CU Hosted or Managed Operating Systems Versions and Releases - minimums

· Solutions must be:

· For Linux-based on-premise systems:

· After 2022/02/02 Oracle Linux 8 (OL8)

· For Windows-based on-premise systems:

· Windows Server 2019 or above is acceptable

· On and after 2024/02/02 Windows Server 2022 is required (preferred now)

· Any other systems must be currently supported with the latest security patches installed and maintained. Other environments will be evaluated individually.

· Please note that Oracle Enterprise Linux is a variant of RedHat Enterprise Linux (RHEL)

· Accessibility

· Offerors must provide an Accessibility Conformance Report (ACR) for their solution.

· The ACR must be based on a Voluntary Product Accessibility Template® (VPAT®) version 2.1 or higher, provided by the Industry Technology Industry Council (ITIC).

· The ACR must include conformance to Web Content Accessibility Guidelines (WCAG) version 2.0 levels A and AA.

· The ACR must be completed according to the instructions.

· If the solution has multiple forms (i.e., web version, desktop version, mobile app, support documentation), then either the provided ACR clearly covers the results of each form or an ACR for each form is provided.

· Offerors must provide a supplemental accessibility statement including the following:

· Confirm the offeror’s commitment to providing accessible solutions.

· Processes and practices used to ensure accessibility, including the frequency in which the ACR is renewed and the process for resolving reported accessibility defects.

· List of any unsupported or partially supported criteria in the ACR that have since been remediated.

· Provide a roadmap, including target dates, for remediation of all applicable criteria in the ACR that are not listed as supported.

· Any accessibility or usability features provided by the solution.

· Describe any known accessibility limitations of the solution and known workarounds.

· Any configuration or installation requirements to provide accessibility.

· Contact information for reporting accessibility issues.

· If the solution is an authoring tool used to generate electronic content (e.g., documents, web pages, multimedia):

· Offerors must describe how the solution generates accessible content.

· Offerors must provide documentation to guide end-users in generating accessible content.

· Offerors must provide samples of accessible generated content.

· Offerors must be willing to provide a demonstration of the following:

· Operate the entire application using only the keyboard, including a visual focus indicator and logical navigation order.

· Operate the application with a screen reader (i.e., JAWS, NVDA, VoiceOver).

· Zoom the text size to 200% without loss of functionality.

· A color contrast ratio of at least 4.5:1 for text and images of text, with the following exceptions: large text should have a 3:1 contrast ratio; decorative text and logotypes have no contrast requirements.

· Show where a user can find accessibility features, settings, and support within the application, including contact information for assistance.

· Security

· If data is utilized, processed, or otherwise stored in the offeror’s solution and subject to any regulatory requirements, the offeror must describe and provide documentation of processes and practices that support the necessary regulatory controls for applicable data elements.

· If the solution requires confidential, sensitive, or otherwise protected data transmissions, the solution must utilize a secure, encrypted method of transport (e.g., Secure Socket Layer (SSL), VPN, etc.).

· The offeror must describe in detail the retention of any user activity logs and other system information (including but not limited to unauthorized login attempts, successful logins, event times, etc.) of the proposed solution.

· Upon request, the offeror must provide a timely review of any activity logs that are requested.

· The solution must provide multiple (tiered) security levels within the application (e.g. RBAC, etc).

· Offerors must include documentation of how CU University data is kept secure and confidential.

· CU requires an Annual review of SOC1 (SSAE16), SOC2 reports for all vendor-hosted solutions.

· Offerors must describe and provide documentation of how data is maintained in backup, the extent/duration and method of backups, timely destruction of backups (automated and upon request), and destruction (purge) of all client data upon separation.

· The offeror must describe and document the level of access to client data by the offeror’s staff or affiliates, safeguards in place to prevent any unauthorized access by the offeror’s staff or affiliates, and any regular review of access rights, privileges, and activity by the offeror’s staff.

· Offerors must disclose whether any data, telemetry or otherwise, is sent back to the vendor at any time during the license period. Offerors must disclose the nature of the data and provide representative data samples. If additions are made to the data sent back to the vendor, CU must be notified of the change at least 60 days in advance.

· Disaster Recovery

· Offerors’ software must be compatible with current CU disaster recovery strategies that meet the business expected Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

· Integration

· Authentication

· The solution must support one of the following for end-user authentication (not required for administrator access):

· Shibboleth (Preferred)

· Active Directory Federated Services (ADFS)

· Ability to configure Access Controls based on tier and/or instance.

· E.g. different users can access test instances vs prod instances.

· SHA-1 user/password hashing - any stored passwords must be encrypted

· API for provisioning -the solution should support one of the following

· REST (Preferred)

· SOAP

· NetIQ IDM driver

· other HTTPS based protocols

· CU Hosted Configuration/Deployment Management

· SaltStack is the configuration/deployment management system used by CU.

· If a CU Hosted system is to be installed or configured by the offeror’s personnel, the offeror should provide SaltStack “ states “ to facilitate automated provisioning and configuration. If unable to provide the SaltStack “states,” the offeror must allow in the contract sufficient consulting hours to develop the appropriate Saltstack “states” in collaboration with CU personnel.

· Any license management solution based on a physical object, such as a USB key or dongle, is unacceptable.

· There must not be a requirement for software to run on a bare-metal (not a VM) server.

· i.e. VMware ESX 7.0U3 and above must be supported.

· Network

· The offeror must describe in detail what network access and bandwidth are required for the proposed solution.

· The solution must be IPV6 compliant.

· The solution must use DNS to find resources on the network: hard-coded IP addresses are not acceptable.

· Cloud based solutions should have peering with Internet2

· Credential Technologies While many universities continue to issue plastic ID cards with magnetic stripes, CU has moved to contactless technologies. The TigerOne Mobile ID for Apple and Android represent the majority of credentials issued while the TigerOne Card relies on HID SEOS technology. As such, users can be issued several IDs of their choice.

· Any system utilizing a “card” of some kind must be compatible with a CU issued credential – a vendor must not introduce another credential into our ecosystem;

· The system must be capable of using HID SEOS technology; and compatible with CU’s Mobile IDs; and

· Systems must support at least three credentials issued to a person, i.e. TigerOne Card, Mobile ID (Android or Apple), Apple Watch

· Right to Audit (Fair Audit Clause) We have a recent audit finding that mentions the need to add “Right to Audit” language in our future purchases. Here is an example of a standard. We will have it vetted by GCO or our procurement reviewer (Jennifer Soldano).

· The contractor agrees to perform an independent third-party audit at least once a year. The audit results (generally provided in a SOC report) and the Contractor’s plan for addressing audit issues shall be shared with the Institution upon request.

· CU Hosted Solutions

· The offeror must describe in detail the minimum and recommended server configurations including, but not limited to, Operating System, CPU, Memory, Disk Space, and firewall exceptions for each server and instance required.

· The offeror must describe in detail any 3rd party software (including version) required for the proposed solution.

· Any system must be currently supported with the latest security patches installed and maintained. Other environments will be evaluated individually

· Vendor Hosted Solutions:

· Data may only be used in such a way as to accomplish the assigned task or as directed by CU.

· The solution must provide a mechanism for CU to control user and system-level access to all functions of the hosted system where applicable. This access must include utilizing CU's Shibboleth implementation for user-level access.

· Most systems will require use of CU’s existing and future 2fa solutions.

· The solution must provide a mechanism for CU to monitor the system status including accurately, but not limited to, the up/down status of the hosted system.

· The vendor must not store any CU data in a facility (or cloud, storage device, laptop, etc) outside of the United States.

· Or release any data for any reason outside of the United States

· Or allow access to data from outside the United States unless express permission is granted

· The solution must provide a mechanism to allow CU to receive data files for consumption by, but not limited to, the current (or future) CU Data Warehouse and similar systems. The vendor must design this transfer in a way that allows it to be scheduled and fully automated as well as fully controlled by CU. Data in transit must be encrypted or use a secure encrypted link.

· The vendor must provide CU with a mechanism to review and export security data from the hosted solution. This data must include, but not be limited to, login history, record modifications, and user location information.

· CU requires an Annual review of SOC1 (SSA16) reports

· CU data and (metadata / metrics) must be extractable back to CU (or any location deemed appropriate) on demand without any special requests or work.

· The data brought back to CU (backups, exports, downloads, dumps) must be in such a format that it is usable without any specialized software or hardware, (IT hardware/software we currently run is acceptable)

· CU may choose to export all data daily (or at least changes daily if there is a high volume of data).

· Data in transit must be encrypted or use a secure encrypted link.

· The vendor must provide an annual third party review of the vendor's disaster recovery plan or a SOC2 report. The SOC2 report should indicate annual disaster recovery tests proving a Recovery Time Objective (RTO) and Recovery Point Objective (RPO) that is acceptable to the purchaser’s business requirements in the event of an event at the vendor site that will impact CU’s ability to do business.

· The vendor must provide an exit strategy that can be tested annually. This will consist of a database backup of CU data being recoverable at a CU datacenter. The application may not be present but the system administrator must be able to recover the database of CU data at the CU primary data center and validate record counts.

· The primary and secondary hosting sites must be located a minimum of 150 straight-line statute miles apart and from Clemson, SC.

image1.png