Answers to Questions.docx

DOCX document 261 KB Posted

Attached to
TRAVEL MANAGEMENT SERVICES
Solicitation number
5400029816
Issued by
Charleston County, South Carolina

About this file

This is an Answers to Questions document for a Travel Management Services procurement issued by the Medical University of South Carolina (MUSC) on June 25, 2026. MUSC is seeking a Travel Management Company to provide comprehensive travel services including technology-enabled solutions with Global Distribution Systems connectivity, online booking tools with MUSC branding and policy enforcement, mobile compatibility, 24/7/365 multilingual support, duty-of-care services, and integration with MUSC's Workday ERP system. The non-mandatory virtual pre-bid conference is scheduled for July 2, 2026 at 11:00 AM EST via Microsoft Teams, with questions due by July 2, 2026 at 5:00 PM EST and proposals due August 3, 2026 at 11:00 AM EST. The contract commences September 15, 2026 with an initial one-year term and four optional one-year renewal periods, for a maximum five-year contract life, with award notification expected September 3, 2026.

Key clarifications provided in the Q&A include that MUSC will not extend the question deadline despite it coinciding with the pre-proposal conference, and a Q&A amendment will be issued before the August 3 deadline. MUSC's FY2026 travel spend totaled $5,821,193.62 for air, $396,281.89 for car, and $9,654,762.47 for hotel. Offerors must be registered to do business with South Carolina before submitting proposals and must provide a Service Provider Security Assessment Questionnaire. Sample reports must be submitted as a separate document due to the 10 MB technical proposal cap, and VIP and hospital-specific travel pricing should be included under the Ancillary Services tab of the Business Proposal workbook. MUSC currently uses Workday as its Enterprise Resource Planning system and already has a Travel Management Company in place. Vendor proposals must follow specified section formats and subsection headings, and offerors must demonstrate compliance with HIPAA-adjacent data considerations, PCI compliance, and carry Cyber/Privacy liability insurance of at least $5 million per occurrence.

View the file

Other files

File Type Posted
Solicitation.rtf RTF text file

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Medical University of South Carolina

Amendment One

Solicitation:

Date Issued:

Procurement Officer:

Phone:

E-Mail Address:

Mailing Address:

5400029816 6/25/2026 Ray Brindle 843-985-2964 brindlra@musc.edu 1 S. Park Cir Suite 402 Charleston, SC. 29407

ONLY QUESTIONS REGARDING THIS AMENDMENT WILL BE ANSWERED

DESCRIPTION: Travel Management Services

USING GOVERNMENTAL UNIT: Medical University of South Carolina

SUBMIT YOUR OFFER ON-LINE AT THE FOLLOWING URL: http://www.procurement.sc.gov

SUBMIT OFFER BY (Opening Date/Time): 08/03/2026 11:00 AM EST (See "Deadline For Submission Of Offer" provision)

QUESTIONS MUST BE RECEIVED BY: 7/2/2026 7/16/2026 at 5:00 PM EST

NUMBER OF COPIES TO BE SUBMITTED: 1 Electronic copy submitted in SCEIS

CONFERENCE TYPE: Non-Mandatory Virtual Pre-Bid Conference

DATE & TIME: 07/02/2026 11:00 AM EST

(As appropriate, see "Conferences - Pre-Bid/Proposal" & "Site Visit" provisions) LOCATION: Microsoft Teams Email brindlra@musc.edu at least one hour prior for login information.

AWARD & AMENDMENTS
Award will be posted on 09/03/2026 The award, this solicitation, any amendments, and any related notices will be posted at the following web address: http://www.procurement.sc.gov

You must submit a signed copy of this form with Your Offer. By signing, You agree to be bound by the terms of the Solicitation. You agree to hold Your Offer open for a minimum of one hundred-twenty (120) calendar days after the Opening Date. (See "Signing Your Offer" provision.)

NAME OF OFFEROR

(full legal name of business submitting the offer) Any award issued will be issued to, and the contract will be formed with, the entity identified as the Offeror. The entity named as the offeror must be a single and distinct legal entity. Do not use the name of a branch office or a division of a larger entity if the branch or division is not a separate legal entity, i.e., a separate corporation, partnership, sole proprietorship, etc.

AUTHORIZED SIGNATURE

(Person must be authorized to submit binding offer to contract on behalf of Offeror.)

DATE SIGNED

TITLE

(business title of person signing above)

STATE VENDOR NO.

(Register to Obtain S.C. Vendor No. at www.procurement.sc.gov)

PRINTED NAME

(printed name of person signing above)

STATE OF INCORPORATION

(If you are a corporation, identify the state of incorporation.)

OFFEROR'S TYPE OF ENTITY: (Check one) (See "Signing Your Offer" provision.)

___ Sole Proprietorship ___ Partnership ___ Other_____________________________

___ Corporate entity (not tax-exempt) ___ Corporation (tax-exempt) ___ Government entity (federal, state, or local)

AP COVER PAGE - ON-LINE ONLY (MAR. 2015)

PAGE TWO

(Return Page Two with Your Offer) HOME OFFICE ADDRESS (Address for offeror's home office / principal place of business)

NOTICE ADDRESS (Address to which all procurement and contract related notices should be sent.) (See "Notice" clause)

Area Code - Number - Extension Facsimile

E-mail Address

PAYMENT ADDRESS (Address to which payments will be sent.) (See "Payment" clause)

____Payment Address same as Home Office Address ____Payment Address same as Notice Address (check only one) ORDER ADDRESS (Address to which purchase orders will be sent) (See "Purchase Orders and "Contract Documents" clauses)

____Order Address same as Home Office Address ____Order Address same as Notice Address (check only one)

ACKNOWLEDGMENT OF AMENDMENTS

Offerors acknowledges receipt of amendments by indicating amendment number and its date of issue. (See "Amendments to Solicitation" Provision)

Amendment No.
Amendment Issue Date
Amendment No.
Amendment Issue Date
Amendment No.
Amendment Issue Date
Amendment No.
Amendment Issue Date

DISCOUNT FOR PROMPT PAYMENT

(See "Discount for Prompt Payment" clause)

10 Calendar Days (%)
20 Calendar Days (%)
30 Calendar Days (%)
_____Calendar Days (%)

PREFERENCES - A NOTICE TO VENDORS (SEP. 2009): Preferences do not apply per SC Consolidated Procurement Code Section 11-35-1524 (E) (2)

PREFERENCES - ADDRESS AND PHONE OF IN-STATE OFFICE: Preferences do not apply per SC Consolidated Procurement Code Section 11-35-1524, part (2).

____In-State Office Address same as Home Office Address ____In-State Office Address same as Notice Address (check only one)

AMENDMENTS TO SOLICITATION (JAN 2004)

(a) The Solicitation may be amended at any time prior to opening. All actual and prospective Offerors should monitor the following web site for the issuance of Amendments: www.procurement.sc.gov(b) Offerors shall acknowledge receipt of any amendment to this solicitation (1) by signing and returning the amendment, (2) by identifying the amendment number and date in the space provided for this purpose on Page Two, (3) by letter, or (4) by submitting a bid that indicates in some way that the bidder received the amendment. (c) If this solicitation is amended, then all terms and conditions which are not modified remain unchanged. [02-2A005-1]

COVER PAGE - ON-LINE ONLY (MAR. 2015)

QUESTIONS FROM OFFERORS - AMENDMENT (JUN 2017)

The solicitation is amended as provided herein. Information or changes resulting from questions will be shown in a question-and-answer format. All questions received have been reprinted below. The “state’s response” should be read without reference to the questions. The questions are included solely to provide a cross-reference to the potential Offeror that submitted the question. Questions do not form a part of the contract; the “state’s response” does. Any restatement of part or all of an existing provision of the solicitation in an answer does not modify the original provision except as follows: underlined text is added to the original provision. Stricken text is deleted.

[02-2a097-1]

DUTY TO INQUIRE (FEB 2015)

Offeror, by submitting an Offer, represents that it has read and understands the Solicitation and that its Offer is made in compliance with the Solicitation. Offerors are expected to examine the Solicitation thoroughly and should request an explanation of any ambiguities, discrepancies, errors, omissions, or conflicting statements in the Solicitation. Failure to do so will be at the Offeror's risk. All ambiguities, discrepancies, errors, omissions, or conflicting statements in the Solicitation shall be interpreted to require the better quality or greater quantity of work and/or materials, unless otherwise directed by amendment. Offeror assumes responsibility for any patent ambiguity in the Solicitation that Offeror does not bring to the State's attention. See clause entitled "Questions from Offerors." [02-2A070-2]

Questions and Answers QUESTION 1: Given the question deadline falls on the same day as the pre-proposal conference (7/2), will MUSC extend the question window?

ANSWER 1: No, the question deadline will not be extended.

QUESTION 2: Will MUSC issue a Q&A amendment before the 8/3 due date? If so, when will the amendment be available?

ANSWER 2: Yes, MUSC will issue a Q&A amendment before the 8/3 due date, once all questions have been answered.

QUESTION 3: The RFP references a “required” Service Provider Security Assessment Questionnaire (SPSAQ) and says it's attached, but it isn't in the Attachments List or provided as an embedded link. Where can we obtain that questionnaire?

ANSWER 3: The Service Provider Security Assessment Questionnaire (SPSAQ) has been provided below.

QUESTION 4: The RFP references a Software Table in “Critical Instructions,” but no table is attached or provided as an embedded link. Is this part of contracting to occur later? If not, where can we obtain the software table?

ANSWER 4: The Software Table has been provided below.

QUESTION 5: “Sample reports” are included in the evaluation criteria but never requested. Do we need to provide examples? If so, can they be provided separately, given the 10 MB cap on the technical proposal?

ANSWER 5: Yes, sample reports must be provided and can be submitted as a separate document.

QUESTION 6: Where should VIP and hospital-specific travel pricing go, given there are no lines for them in the Business Proposal workbook?

ANSWER 6: VIP and hospital-specific travel pricing fees should be added under Ancillary Svcs tab.

QUESTION 7: The RFP requires using the same section titles and numbers in Section III for the technical proposal, but this section does not have that format—it is presented in unnumbered bullet points. Please clarify what format the proposal should follow.

ANSWER 7: Submittals must follow the subsections of Section III, using the bolded headings and presented in the same order.

QUESTION 8: What are your 3 top objectives for our RFP?

ANSWER 8: The top three objectives of this RFP are to

· Obtain a high-quality solution that meets our operational needs

· Partner with a qualified and responsive vendor

· Achieve the best overall value for the Enterprise

QUESTION 9: What Enterprise Resource Planning is MUSC using?

ANSWER 9: The Enterprise Resource Planning is MUSC using is Workday

QUESTION 10: What is the universities total spend for air, car, & hotel?

ANSWER 10: The Enterprise’s travel spend for FY2026 (July 1, 2025-June 30, 2026) were

· Air = $5,821,193.62

· Car = $396,281.89

· Hotel = $9,654,762.47

QUESTION 11: The RFP requires that we Provide 24/7/365 support with Multilingual Agents, what language is in high demand?

ANSWER 11: The language is in high demand is English

QUESTION 12: Will the State waive the requirement for out-of-state (foreign) Secretary of State business registration/Certificate of Authority for the awarded vendor, or must a Florida-based corporation still complete South Carolina business registration prior to contract execution?

ANSWER 12: No, the state this requirement.

QUESTION 13: Does our company need to be registered to do business with the State of SC before submitting our proposal?

ANSWER 13: Yes, your company needs to be registered to do business with the State of SC before submitting a proposal

QUESTION 14: Do you currently have a TMC?

ANSWER 14: Yes, we currently have a Travel Management Company

QUESTION 15: How many travel consultants are currently handling your travel?

ANSWER 15: The number of travel consultants are currently handling our travel vary based on our needs and travel volume.

QUESTION 16: Please elaborate on Sample Reports (page 23) ANSWER 16: Please provide a sample of the standard reports you regularly provide to your customers.

QUESTION 17: What is your biggest pain point?

ANSWER 17: Our biggest pain point is the amount of time and effort required to manage travel arrangements, policy compliance, and reporting across multiple processes and stakeholders. We are looking for a solution that simplifies the travel booking experience, improves visibility into travel activity and expenditures, and provides responsive customer support when issues arise.

image2.emf

Security Assesment Questionaire.docx Attachment A- MUSC IS Risk

SERVICE PROVIDER SECURITY ASSESSMENT QUESTIONNAIRE

Instructions: (1) Attach additional pages or documents as appropriate and make sure answers cross reference to the questions below. (2) As used in this Questionnaire, the phrase “government information” shall have the meaning defined in the clause titled “Information Security.” (3) This Questionnaire must be read in conjunction with both of the following two clauses (a) Service Provider Security Assessment Questionnaire – Required, and (b) Service Provider Security Representation.

1. Describe your policies and procedures that ensure access to government information is limited to only those of your employees and contractors who require access to perform your proposed services.

2. Describe your disaster recovery and business continuity plans.

3. What safeguards and practices do you have in place to vet your employees and contractors who will have access to government information?

4. Describe and explain your security policies and procedures as they relate to your use of your contractors and next-tier subcontractors.

5. List any reports or certifications that you have from properly accredited third parties that demonstrate that adequate security controls and assurance requirements are in place to adequately provide for the confidentiality, integrity, and availability of the information systems used to process, store, transmit, and access all government information. (For example, an ISO/IEC 27001 compliance certificate, an AICPA SOC 2 (Type 2) report, or perhaps an AICPA SOC 3 report (i.e., a SysTrust or WebTrust seal)). For each certification, describe the scope of the assessment performed. Will these reports / certifications remain in place for the duration of the contract? Will you provide the state with most recent and future versions of the applicable compliance certificate / audit report?

6. Describe the policies, procedures and practices you have in place to provide for the physical security of your data centers and other sites where government information will be hosted, accessed or maintained.

7. Will government information be encrypted at rest? Will government information be encrypted when transmitted? Will government information be encrypted during data backups, and on backup media? Please elaborate.

8. Describe safeguards that are in place to prevent unauthorized use, reuse, distribution, transmission, manipulation, copying, modification, access or disclosure of government information.

9. What controls are in place to detect security breaches? What system and network activity do you log? How long do you maintain these audit logs?

10. How will government information be managed after contract termination? Will government information provided to the Contractor be deleted or destroyed? When will this occur?

11. Describe your incident response policies and practices.

12. Identify any third party which will host or have access to government information.

Offeror’s response to this questionnaire includes any other information submitted with its offer regarding information or data security.

SIGNATURE OF PERSON AUTHORIZED TO REPRESENT THE ACCURACY OF THIS INFORMATION ON BEHALF OF CONTRACTOR:

By: ____________________________________

(authorized signature)

Its: ____________________________________

(printed name of person signing above)

(title of person signing above)

Date: ____________________________________

SPSAQ (JAN 2015) [09-9025-1]

SAMPLE MUSC INFORMATION SECURITY AGREEMENT

THIS MUSC INFORMATION SECURITY AGREEMENT (this “ISA”) is made effective as of the date of last signature by both parties below (the “Effective Date”) by and between the Medical University of South Carolina (“MUSC ENTITY”) and INSERT VENDOR NAME (“VENDOR”). MUSC Entity and Vendor may singularly be identified in this ISA as “Party” and collectively as “Parties.”

WHEREAS, MUSC (as defined below) has executed one or more agreements whereby by Vendor provides certain Services and/or Products to MUSC which involve Vendor (i) processing, receiving, maintaining, accessing, and/or creating data on behalf of MUSC and/or (ii) accessing MUSC Systems in order to provide such services or products (the “Agreement(s)”).

NOW THEREFORE, by way of this ISA, the following modifications shall be made to the Agreements, which modifications shall survive, and take precedence over any conflicting terms contained in, the Agreements, subject to Section 17.4 below:

1. Definitions.

1.1. “Affiliate(s)” includes, insofar as they are not named above as a Party, the Medical University of South Carolina and entities comprising “MUSC Health,” including but not limited to: (i) the Medical University Hospital Authority, the University Medical Associates of the Medical University of South Carolina, Carolina Family Care, Inc. and (ii) any supporting organization of MUSC that is (or whose sole member/owner is) a party to an affiliation agreement with MUSC, but excludes any joint venture with a third party where one or more members of MUSC do not collectively have the power to appoint a majority of the governing body.

1.2. “Authorized Persons” means Vendor’s employees and contractors who have a specific need for access to MUSC Data or MUSC Systems in order for Vendor to perform the Services for MUSC.

1.3. “Cardholder Data” means data as defined by the Payment Card Industry (PCI) Security Standard Council Cardholder Data.

1.4. “Industry Standards” means National Institute of Standards and Technology (NIST) 800 Series, NIST Cybersecurity Framework and ISO 27001, or equivalent wholistic industry-standard information security frameworks.

1.5. “MUSC” means MUSC Entity and its Affiliates.

1.6. “MUSC Data” means any information that may reasonably be determined to be proprietary to the business of MUSC or that is expressly deemed protected or confidential whether by contractual obligations or any other federal, state or local law or regulation, including, but not limited to: personal data and information (such as name, address, social security number, patient number, employee number, or date of birth), employee records, patient health information, including protected health information (“PHI”) as defined in 45 C.F.R. 160.103 of Health Insurance Portability and Accountability Act of 1996, as amended, and de-identified PHI, Cardholder Data, authentication credentials, intellectual property of MUSC, insurance information, financial information, pricing, processes, statistics, software programs and documentation, research, development, and any third-party information that MUSC is required to keep confidential, or that it keeps confidential in order to retain its business, commercial or market advantage. For purposes of this ISA, MUSC Data does not include Public Data.

1.7. “Public Data” means any specific information or data that MUSC has actively and intentionally disclosed, disseminated, or made available to the general public.

1.8. “Security Vulnerability” means a weakness in Vendor Product or Services that could be exploited by a threat source and, if exploited, may adversely impact the confidentiality, integrity, or availability of MUSC Data or integrity or availability of a Vendor Product.

1.9. “System” means a computer system or set of components owned, leased or otherwise used for collecting, creating, storing, processing, and distributing information, typically including hardware and software, system users, and the data itself. For the avoidance of doubt, “System” includes all systems utilized by a party regardless of where located and may include cloud systems used by a party regardless of whether owned and controlled by a party or a third party.

1.10. “Vendor Product” or “Product” means any software, hardware, operating system, computer equipment or product provided by Vendor to MUSC pursuant to an Agreement, including, without limitation, any new version, replacement version, patch, error correction, new release or security patch.

1.11. “Vendor Services” or “Services” means any service provided by Vendor to MUSC pursuant to an Agreement, including but not limited to, SaaS (Software as a Service or similar hosted services), maintenance and support service, program development service, consulting service, outsourcing service, or other professional service involving access to MUSC Data or an MUSC System.

2. Vendor Security.

2.1. Security Program. For so long as MUSC receives Products and/or Services pursuant to an Agreement, Vendor covenants to implement and maintain a comprehensive written security program that is consistent with generally recognized Industry Standards and best practices that reflects the size and type of Vendor's business as well as the types of services, products and equipment produced or sold by Vendor and the volume and nature of any customer data that may be stored, accessed or transmitted by Vendor.

2.2. Ongoing Risk Assessments. Without limiting the generality of the foregoing, Vendor’s security program shall provide for ongoing assessments and re-assessments of reasonably foreseeable risks to the security of MUSC Data and Vendor’s Product(s) and/or Service(s). Such assessments shall include ongoing (1) identification and assessment of internal and external threats that could result in unauthorized disclosure, alteration, loss or destruction of MUSC Data, (2) review of the sufficiency of Vendor’s administrative, technical and physical controls to mitigate the risks presented by such threats, and (3) prompt and appropriate steps to track and remediate identified Security Vulnerabilities in Vendor controls.

2.3. Vendor Personnel. Vendor agrees that personnel and contractors involved with the development, maintenance and support of Vendor Product(s) and Services possess the appropriate qualifications to handle and/or provide such Vendor Products and Services, and that, to the extent not prohibited by applicable law, each has passed a background check. Vendor shall require personnel who have access to MUSC Data to complete privacy and data security training on a periodic basis. Vendor’s information security awareness training shall include the following: protection against malicious software (such as viruses), social engineering and phishing; password protection and password management; applicable compliance requirements; and procedures for reporting Security Incidents.

3. Data Security. To the extent that Vendor is responsible for creating, accessing, transmitting, maintaining, hosting or using MUSC Data under an Agreement:

3.1. Data Protection. Vendor shall preserve the confidentiality, integrity and availability of MUSC Data by implementing and maintaining administrative, technical and physical controls that conform to generally recognized Industry Standards. Implemented security controls shall provide a level of security which is commensurate with the sensitivity of the data to be protected. MUSC Data shall be encrypted using industry standard encryption algorithms and protocols when transmitted over public and wireless networks and when stored on Vendor portable media such as laptops and flash drives.

3.2. Data Use and Access. Vendor shall use MUSC Data only and exclusively to support the performance of Services for MUSC under the applicable Agreement and not for any other purpose. Absent MUSC’s prior written consent, Vendor shall not at any time during or after the term of an Agreement disclose MUSC Data to any person, other than Authorized Persons and MUSC personnel, in connection with the performance of the Services (except as required by law). If such disclosure is required by law, Vendor shall notify MUSC prior to such disclosure, unless such notification is prohibited by law.

3.3. Data Backup. Where appropriate to protect the integrity and availability of MUSC Data, Vendor shall maintain and use (and cause any third-party hosting company that it uses to maintain and use) backup data processes and systems and the ability to recover MUSC Data in the event that the data is lost, corrupted, improperly destroyed or encrypted or otherwise improperly made unavailable.

3.4. Return of MUSC Data; Transition Services. Vendor shall ensure that MUSC can retrieve its data from the Product and/or Service upon termination of the Agreement. In the event of such termination, upon MUSC’s written request, the Vendor will provide MUSC Data to MUSC, or otherwise permit MUSC to extract such data, in a mutually acceptable, commonly available format at no additional cost to MUSC.

3.5. Destruction of Data.

3.5.1. During the term, where Vendor disposes of media containing MUSC Data, Vendor shall release or dispose of any such media in a manner that ensures that it is securely sanitized prior to such release or disposal. Secure sanitization is that which renders MUSC Data unrecoverable.

3.5.2. Following the return of data pursuant to Section 3.4 above, or at the request of MUSC, Vendor shall erase, destroy, and/or render unrecoverable all MUSC Data remaining in Vendor’s possession that is no longer required for the performance of its duties under the applicable Agreement. Vendor shall certify in writing that these actions have been completed within 30 days of the termination of its duties under the applicable Agreement or within seven (7) days of the request of an agent of MUSC, whichever shall come first.

4. Vendor Product and Service Security.

4.1. Product and Service Development and Specifications. Vendor agrees that it has established and will maintain Industry Standard security controls and processes that must be adhered to during all Vendor Product and Service development activities.

4.2. Product and Service Security Configuration. Prior to Product installation or Service “go-live,” Vendor will provide MUSC with documentation of recommended security configurations which MUSC is responsible for configuring.

4.3. Illicit Code. Vendor shall ensure that Vendor Products and Services are free from Illicit Code. “Illicit Code” is defined as any harmful or hidden programs, access routes, or data incorporated therein, knowingly by Vendor or otherwise, that destroys, impairs, or maliciously appropriates the Product, Service, and/or MUSC Data. Illicit Code includes but is not limited to malicious code, viruses, worms, logic bombs, Trojan horses and/or other harmful or malicious code, files, scripts, agents or programs or any backdoors or other code that would permit or make easier access to MUSC Systems or MUSC Data.

4.4. Common Vulnerabilities. Employing static and dynamic testing as well as third party audits, Vendor shall ensure that software developed by Vendor is free from Common Vulnerabilities. “Common Vulnerabilities” are those described in (i) The Open Web Application Security Project’s (OWASP) “Top Ten Project” – see http://www.owasp.org, (ii) The CWE/SANS Top 25 Programming Errors- see http://cwe.mitre.org/top25/ or http://www.sans.org/top25-programming-errors/, or (iii) other generally recognized and comparable industry practices or standards.

4.5. Vendor Security Vulnerability Disclosure. In the event Vendor validates the existence of a real or potential material Security Vulnerability, such as via an internal vulnerability assessment or third-party notification, which creates, or stands to create, a substantial risk to the confidentiality, integrity or availability of MUSC Data, Vendor shall promptly notify MUSC and conduct the activities as required under Section 9. Vendor expressly agrees that MUSC may take any and all actions that it, in its sole discretion, deems necessary to address, mitigate and/or rectify any Security Vulnerability, and that no such action shall impact, limit, reduce or negate any Vendor warranties or any of Vendor’s obligations under the applicable Agreement.

4.6. Inability to Remediate Security Vulnerabilities. To the extent the parties are unable to agree upon a plan to remediate any material Vendor Product or Services Security Vulnerabilities, MUSC shall have the right to terminate the underlying Agreement on thirty (30) days written notice, without liability for any costs, fees or expenses not incurred up through the effective date of termination.

4.7. Vendor Product Maintenance and Support, Protection and Monitoring. To the extent Vendor is responsible for maintaining or hosting MUSC Data, Vendor Products, or Systems under an Agreement, Vendor shall ensure that:

4.7.1. Security patches and upgrades for all Products and Systems are applied in a timely manner according to a written policy/procedure. Patches and upgrades include third party software that Vendor’s Product/System relies upon for its operation;

4.7.2. Vendor Products and Systems are hardened and configured according to Industry Standards, including configuration according to the principle of least privilege and running current and regularly updated malware protection services, e.g., anti-virus and antispyware;

4.7.3. Where Vendor Products and/or Systems are located on MUSC’s network or premises, any default or unused accounts are removed or disabled, or Vendor will utilize a password which is unique to MUSC for each account that Vendor cannot remove or disable; and

4.7.4. Vendor Products and Systems are monitored on an ongoing basis for events that create risks to Vendor Products, Systems and/or MUSC Data. Upon learning of such an event, Vendor shall take appropriate measures to contain and eradicate the threat creating the risk and return Vendor Product or Systems to a safe state.

4.8. Audits and Certifications. To the extent MUSC Data will be hosted or maintained by Vendor (such as in Vendor’s data center or the cloud), Vendor shall perform and require its contractors, if any, to perform compliance audits of the security controls of its processing environment in accordance with Industry Standards and applicable laws, which shall include, at a minimum, annual third-party audits by a reputable audit firm and penetration tests to test the security of Vendor’s processing environment. Vendor will provide to MUSC, upon MUSC’s reasonable request, but no more frequently than once per calendar year and after a Security Incident, and for no additional charge to MUSC, an ISO 27001 certification, HITRUST certification, SOC 2 Type II third-party audit report, its current PCI-related attestation documents (if applicable), or other Industry Standard audit report/certification mutually agreed upon by MUSC and Vendor.

4.9. Federated Authentication. Vendor-hosted Services which involve authentication by MUSC personnel shall support federated authentication (e.g. Single Sign-On, SAML, ADFS).

4.10. Remote Support. Where required, unless otherwise agreed to in writing, Vendor shall provide remote support via a secure connection method that includes industry standard encryption of data in transit, individual user accounts, multifactor authentication, sessions which are individually authorized by MUSC, detailed audit logs, and that is limited to the minimum necessary Authorized Persons, on an as needed basis. If applicable, Vendor shall provide such audit logs to MUSC as reasonably requested.

5. PCI DSS. Where Vendor has access to Cardholder Data (otherwise this provision does not apply), Vendor and any Product or Service which processes, stores or accesses Cardholder Data will, as applicable, adhere to all current and future versions and requirements of the Payment Card Industry (“PCI”) Data Security Standard (i.e. PCI-DSS) and/or the Payment Application Data Security Standard (“PA-DSS”), for any payment application developed by Vendor and made available to MUSC. Vendor further acknowledges and agrees that it is responsible for the security of Cardholder Data in the possession or control of Vendor relating to the Products and Services.

6. Vendor Access to MUSC Systems. During the course of providing the Services, it may become appropriate for MUSC to provide Authorized Persons with credentials to access certain MUSC Systems. MUSC’s decision to grant such access shall be at MUSC’s sole discretion and MUSC reserves the right to revoke Vendor’s access to MUSC Systems at any time and for any reason. Additionally, Vendor agrees to the following with respect to Authorized Persons who are granted access to MUSC Systems:

6.1. Authorized Persons shall create passwords which are unique to MUSC and shall not share or otherwise disclose MUSC login credentials to any other party.

6.2. Vendor shall notify MUSC immediately, but in any event within two (2) business days, whenever (i) MUSC login credentials have been or are believed to have been compromised or disclosed to an unauthorized party, (ii) an Authorized Person with access to MUSC Systems no longer requires access to provide the Services, or (iii) an Authorized Person ceases to be employed by Vendor or its contractor. Such notification shall be provided by calling the MUSC Help Desk at (843) 792-9700; and

6.3. Vendor shall be responsible for (i) each Authorized Person’s compliance with the applicable terms of this ISA, MUSC’s Acceptable Use Policy (available at https://netid.musc.edu), and applicable Federal and State privacy laws and (ii) any inappropriate access by an Authorized Person to MUSC Systems or abuses of an Authorized Person’s access privileges.

7. Data Ownership. As between Vendor and MUSC, MUSC is and shall continue at all times to be the sole and exclusive owner of all MUSC Data. The foregoing includes, without limitation, all patent, copyright, trademark, trade secrets, and all other proprietary, licensing and privacy rights in and to MUSC Data. MUSC reserves all rights not specifically granted or licensed in this ISA or in any Agreement with respect to MUSC Data. Vendor (including any division, subsidiary or affiliate of Vendor), its agents, and any third party other than MUSC will not be permitted to have access to, or use of, MUSC Data or data or information derived from MUSC Data, except as required by law, other than as strictly required for its performance under the applicable Agreement. Unless expressly permitted in the applicable Agreement, in no event will Vendor, its affiliates, or its agents directly commercially exploit MUSC Data or data or information derived from MUSC Data, including, without limitation, developing information, statistics, compilations, summaries, surveys, abstracts, analytics, or combinations with or matches against other data, for use by anyone other than MUSC.

8. Data Location. Unless otherwise agreed to in writing, MUSC Data shall only be geographically stored, accessed and processed from within the fifty (50) States of the United States and the District of Columbia.

9. Security Incident and Breach Notification. Vendor agrees to notify MUSC upon learning of any event that (i) creates, or stands to create, a substantial risk to the confidentiality, integrity or availability of MUSC Data; (ii) involves a breach of any of Vendor’s security obligations under this ISA; or (iii) involves any other security, breach or privacy event requiring notification to any person or entity under applicable law (collectively a “Security Incident”). In such an instance, Vendor agrees to:

9.1. Take such action as may be necessary to preserve forensic evidence and eliminate the cause of the risk or breach. As soon as practicable after discovery, but in any event within (30) days of discovery (unless extended by MUSC), Vendor shall undertake a thorough forensic investigation of any compromise or improper use and provide MUSC all information necessary to enable MUSC to fully understand the nature and extent of the compromise or improper use to the extent known;

9.2. Notify MUSC by telephone at (843) 792-9700 and by e-mail at security-incident@musc.edu regarding such an event without undue delay and in any event within two (2) business days of discovery; and

9.3. To the extent that the breach or incident was the fault of Vendor, assume the cost of informing all such individuals in accordance with applicable law. For the avoidance of doubt, such costs shall include, but not be limited to (i) mailing notices to affected individuals, (ii) establishing and operating call center(s), and (iii) providing credit monitoring and/or identity restoration services to affected individuals. At MUSC’s request, Vendor shall provide the notice to affected individuals and others, as may be required by applicable law. Such notification shall be approved by MUSC prior to distribution or notification.

10. Security Incident Investigations. Vendor agrees to cooperate with MUSC in investigating a Security Incident and provide the name and contact information of at least two (2) security contacts who will respond to MUSC in a timely manner, dependent on criticality, in the event that MUSC must investigate such Security Incident. Those contacts are:

Contact Name

[CONACT 1]

[CONACT 2]

Phone Number

[PHONE NUMBER 1]

[PHONE NUMBER 2]

Email Address

[EMAIL 1]

[EMAIL 2]

11. Compliance with Applicable Standards, State and Federal Law. Vendor shall comply with all applicable standards, federal, state, and local laws concerning data protection, breach notification, and privacy regarding the handling of MUSC Data.

12. Enforcing Compliance. Vendor shall enforce and be responsible for compliance by all its personnel and contractors with the provisions of this ISA and all other confidentiality obligations owed to MUSC.

13. Right to Assess Compliance. MUSC reserves the right to make reasonable requests of Vendor to assess Vendor’s compliance with the terms of this ISA and Vendor shall promptly comply with any such requests.

14. Indemnification. Notwithstanding any disclaimer or limitation of liability contained in an Agreement, which shall not apply with respect to breaches of this ISA, and in addition to any indemnity obligation(s) of Vendor set forth in an Agreement, Vendor agrees to indemnify, defend and hold harmless MUSC, including MUSC’s respective employees, directors, officers, subcontractors, agents or other members of its workforce (collectively, “Indemnitees”), against all losses, liabilities, fines, penalties, costs or expenses (including reasonable attorneys’ fees and expenses) suffered by MUSC (collectively, “Losses”) and all direct liability(ies) to third parties arising from or in connection with a breach of this ISA by Vendor, including its employees, directors, officers, subcontractors, agents or other members of its workforce. Accordingly, on demand, Vendor shall reimburse MUSC for any and all Losses and direct liability(ies) to third parties which may for any reason be incurred by MUSC or other Indemnitees resulting from Vendor’s breach hereunder. Vendor’s obligation to indemnify Indemnities shall survive the expiration or termination of this ISA for any reason.

15. Vendor Liability Insurance. Vendor shall procure and maintain for the duration of the applicable Agreement insurance against claims and damages which may arise from or are in connection with privacy or data breaches of MUSC Data. Coverage shall have limits of no less than $5,000,000.00 per occurrence and $10,000,000.00 aggregate.

16. Term and Termination; Termination of Underlying Agreement. The term of this ISA commences on the Effective Date and will remain in effect until the termination of all Agreements between MUSC and Vendor. In the event Vendor materially breaches this ISA, experiences a Security Incident that materially impacts MUSC (including, but not limited to, a Vendor’s inability to provide MUSC with assurances that it has fully remediated a Security Vulnerability which required notification under Section 9), MUSC shall have the option to terminate the applicable Agreement without penalty on 30 days’ notice to Vendor with termination effective as of the date set forth in such notice. These termination rights are in addition to, and do not limit, MUSC’s rights to terminate under the Agreement.

17. Miscellaneous.

17.1. Applicability. Vendor’s obligations and requirements under this ISA apply to all Products and Services provided by Vendor to MUSC (which, for clarity, includes Affiliates) both before, on, and after the Effective Date hereof.

17.2. Governing Law; Severability. This ISA shall be governed by and construed in accordance with the laws of the State of South Carolina, without regard to its conflict of laws principles. In the event that any provision of this ISA violates any applicable statute, ordinance or rule of law in any jurisdiction that governs this ISA, such provision shall be ineffective to the extent of such violation without invalidating any other provision of this ISA.

17.3. Amendment. This ISA may not be amended, altered or modified except by written agreement signed by Vendor and MUSC Entity.

17.4. Survival; Order of Precedence. The provisions of this ISA, which by their nature extend beyond the termination of an Agreement, shall survive expiration or termination of such Agreement. The terms of this ISA shall govern over any conflicts with provisions in an Agreement; provided, that the applicable Agreement will control to the extent it expressly provides greater protections for MUSC and/or MUSC Data than those contained in this ISA. In the event of a conflict between the terms of an applicable HIPAA Business Associate Agreement (“BAA”) between MUSC and Vendor and this ISA, the terms of the applicable BAA will control to the extent it expressly provides greater protections for MUSC and/or MUSC Data than those contained in this ISA.

17.5. Waiver. No provision of this ISA may be waived except by an agreement in writing signed by the waiving party. A waiver of any term or provision shall not be construed as a waiver of any other term or provision. Nothing in this ISA shall be deemed a waiver of any legally-recognized claim of privilege available to Vendor. An Affiliate’s acceptance of a Product or Service that is inconsistent with the obligations and requirements hereunder will not constitute a waiver by MUSC Entity or Affiliate of any of right or obligation under this ISA.

17.6. Entire Agreement. This ISA contains the entire understanding of the Parties with respect to the subject matter hereof and supersedes all prior agreements, oral or written, and all other communications between the Parties relating to such subject matter.

[signature page follows]

ACCEPTED, ACKNOWLEDGED AND AGREED TO:

Vendor: Address for Notices:

[Vendor Name]

By: ___________________

Its:

Date:

MUSC Entity:

Medical University of South Carolina Address for Notices:

MUSC

Attn: General Counsel

22 WestEdge St. Suite 300

Charleston, SC 29403

By:

Its:

Date:

image1.png image3.emf

Software Table.pdf

Name of Software Product Name of Software Product’s Licensor Contractor licenses or sublicenses Software Product directly to State

Contractor "resells" or distributes Software Product

[09-9035-1] image1.jpeg

File details come from the government source that posted it. Updated .