Medium Priority Incident Failure Credit Sample Clauses

Medium Priority Incident Failure Credit. Any failure of Provider to meet the Response Times or Resolution Times in connection with the resolution of any Medium or Low Priority Incidents shall constitute a Default for the purposes of this Schedule 4.1; provided, however, that if Provider has used its commercially reasonable efforts to provide a Resolution to a Medium or Low Priority Incident within the applicable Resolution Time, such Default shall not constitute a breach of this Agreement. With respect to each Recipient Party, if Provider fails to provide a Resolution within the Resolution Times set forth in Table 4.4 for more than twenty (20) Medium Priority Incidents during such Measurement Period reported by such Recipient Party to the Service Desk during any Measurement Period (the “Medium Priority Incidents Service Level”), Provider shall credit the applicable Recipient Party an amount equal to one percent (1%) of the Payment Processing Fee owed by such Recipient Party to Provider for the applicable Measurement Period in the next Invoice issued pursuant to Section 7.2 (“Medium Priority Incidents Failure Credit”). Notwithstanding the foregoing, if Provider’s failure to resolve any Medium Priority Incident is due to a Force Majeure Event or any other deficiency or outage in the Services, Platform or Provider’s Systems such that Provider is already bound to award the applicable Recipient Party an Availability Credit or Performance Event Credit as a result of such Incident under the terms of this Schedule 4.1, then the Recipient Party shall not be entitled to an Medium Priority Incidents Failure Credit pursuant to this Section 4.7.2.
AutoNDA by SimpleDocs

Related to Medium Priority Incident Failure Credit

  • Security Incident Notification The Transfer Agent shall promptly notify the Trust but in no event later than 72 hours following discovery of any Security Incident(s). Such notification shall include the extent and nature of such intrusion, disclosure, or unauthorized access, the identity of the compromised Customer Confidential Information (to the extent it can be ascertained), how the Transfer Agent was affected by the Security Incident, and its response to such Security Incident. The Transfer Agent shall use continuous and diligent efforts to remedy the cause and the effects of such Security Incident in an expeditious manner and deliver to the Trust a root cause analysis and future incident Mitigation plan with regard to any such incident. The Transfer Agent shall reasonably cooperate with the Trust’s investigation and response to each Security Incident. If the Trust determines in its sole discretion that it may need or be required to notify any individual(s) as a result of a Security Incident, the Trust shall have the right to control all such notifications and the Transfer Agent shall bear all direct costs associated with the notification, to the extent the notification and corresponding actions are required by U.S. law, and subject to the limitation of liability set forth in the Agreement. Without limiting the foregoing, unless otherwise required by U.S. law, no such notifications shall be made by the Transfer Agent without the Trust’s prior written consent and the Trust shall, together with the Transfer Agent, determine the content and delivery of all such notifications. For the avoidance of doubt, the Transfer Agent shall be solely responsible for all costs and expenses, subject to the limitations of liability under the Agreement that the Trust and/or the Transfer Agent may incur to the extent that they are attributable to or arise from the Transfer Agent’s breach of its confidentiality obligations under the Agreement.

  • Security Incident Reporting A security incident occurs when CDA information assets are or reasonably believed to have been accessed, modified, destroyed, or disclosed without proper authorization, or are lost, or stolen. Subrecipient must comply with CDA’s security incident reporting procedures located at xxxxx://xxx.xxxxx.xx.xxx/ProgramsProviders/#Resources.

  • Security Incident “Security Incident” means the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.

  • Security Incidents 11.1 Includes identification, managing and agreed reporting procedures for actual or suspected security breaches.

  • Security Incident Response Upon becoming aware of a Security Incident, MailChimp shall notify Customer without undue delay and shall provide timely information relating to the Security Incident as it becomes known or as is reasonably requested by Customer.

  • Secured Party Control Bank, Secured Party, Servicer and Company each agree that Bank will comply with instructions given to Bank by Secured Party directing disposition of funds in the Collateral Accounts (“Disposition Instructions”) without further consent by Company or Servicer. Except as otherwise required by law, Bank will not agree with any third party to comply with instructions for disposition of funds in the Collateral Accounts originated by such third party.

  • Breaches and Security Incidents During the term of the Agreement, CONTRACTOR 27 agrees to implement reasonable systems for the discovery of any Breach of unsecured DHCS PI and PII 28 or security incident. CONTRACTOR agrees to give notification of any beach of unsecured DHCS PI 29 and PII or security incident in accordance with subparagraph F, of the Business Associate Contract, 30 Exhibit B to the Agreement.

  • Priority Hiring If the Contract Amount is over $200,000 and this Agreement is for services (other than Consulting Services), this section is applicable. Contractor shall give priority consideration in filling vacancies in positions funded by this Agreement to qualified recipients of aid under Welfare and Institutions Code section 11200 in accordance with PCC 10353.

  • Reporting Incidents The Interconnection Parties shall report to each other in writing as soon as practical all accidents or occurrences resulting in injuries to any person, including death, and any property damage arising out of the Interconnection Service Agreement.

  • Name Collision Occurrence Assessment 6.2.1 Registry Operator shall not activate any names in the DNS zone for the Registry TLD except in compliance with a Name Collision Occurrence Assessment provided by ICANN regarding the Registry TLD. Registry Operator will either (A) implement the mitigation measures described in its Name Collision Occurrence Assessment before activating any second-­‐level domain name, or (B) block those second-­‐level domain names for which the mitigation measures as described in the Name Collision Occurrence Assessment have not been implemented and proceed with activating names that are not listed in the Assessment. 6.2.2 Notwithstanding subsection 6.2.1, Registry Operator may proceed with activation of names in the DNS zone without implementation of the measures set forth in Section 6.2.1 only if (A) ICANN determines that the Registry TLD is eligible for this alternative path to activation of names; and (B) Registry Operator blocks all second-­‐level domain names identified by ICANN and set forth at <xxxx://xxxxxxxx.xxxxx.xxx/en/announcements-­‐and-­‐ media/announcement-­‐2-­‐17nov13-­‐en> as such list may be modified by ICANN from time to time. Registry Operator may activate names pursuant to this subsection and later activate names pursuant to subsection 6.2.1. 6.2.3 The sets of names subject to mitigation or blocking pursuant to Sections 6.2.1 and 6.2.2 will be based on ICANN analysis of DNS information including "Day in the Life of the Internet" data maintained by the DNS Operations, Analysis, and Research Center (DNS-­‐OARC) <xxxxx://xxx.xxx-­‐xxxx.xxx/xxxx/xxxx/xxxx>. 6.2.4 Registry Operator may participate in the development by the ICANN community of a process for determining whether and how these blocked names may be released. 6.2.5 If ICANN determines that the TLD is ineligible for the alternative path to activation of names, ICANN may elect not to delegate the TLD pending completion of the final Name Collision Occurrence Assessment for the TLD, and Registry Operator’s completion of all required mitigation measures. Registry Operator understands that the mitigation measures required by ICANN as a condition to activation of names in the DNS zone for the TLD may include, without limitation, mitigation measures such as those described in Section 3.2 of the New gTLD Name Collision Occurrence Management Plan approved by the ICANN Board New gTLD Program Committee (NGPC) on 7 October 2013 as found at <xxxx://xxx.xxxxx.xxx/en/groups/board/documents/resolutions-­‐ new-­‐gtld-­‐annex-­‐1-­‐07oct13-­‐en.pdf>.

Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!