5-Service Level Agreement.pdf

ATTACHMENT K: SERVICE-LEVEL AGREEMENT

RFO 701-26-013, Federal Fiscal and Program Monitoring Management System

Contractors are required to review and comply with the Service Level Agreement (SLA) requirements provided in Attachment K and address their ability to meet those requirements in their proposal.

General Principles

• Contractor Responsibility: Contractor must meet or exceed all specified Service Levels.

The Contractor is fully responsible for any costs—including time, effort, and financial expenses—needed for remediation or rework to achieve these Service Levels.

• Burden of Proof: Contractor shall be accountable for any failure to meet a Service Level. If Contractor believes a failure was proximately and solely caused by TEA, a TEA-controlled system, or a Force Majure event, Contractor bears the burden of providing sufficient, detailed evidence to substantiate this claim within three (3) business days of the event.

The sufficiency of such evidence shall be reasonably determined by TEA. Failure to provide such evidence renders Contractor fully accountable.

• Measurement & Reporting: Contractor shall, at its own expense, implement and maintain monitoring tools (subject to TEA's approval) to comprehensively measure performance against all Service Levels. Contractor shall provide TEA with a monthly SLA Performance Report ("SLA Report") detailing the performance for the preceding month and any Service Credits incurred. Reports are due by the fifth (5th) business day of the following month.

• SLA Report Disputes: If TEA disputes the accuracy of the SLA Report, TEA shall provide written notice to Contractor detailing the basis of the dispute. TEA's good-faith monitoring data shall be considered. The parties shall cooperate to resolve the dispute within ten (10) business days. If unresolved, the dispute shall be escalated pursuant to the Contract's dispute resolution procedure.

• No Cure Periods for SLA Failures: The Service Credits specified herein are automatic and shall apply immediately for the month in which the Service Level failure occurred. These remedies are not subject to any "cure period," as the damage (e.g., downtime, a security lapse) has already been incurred by TEA.

• Reasonable Opportunity to Apply: Contractor acknowledges that application availability during grant opening and closing periods is essential to ensuring grantees have a reasonable opportunity to apply for TEA-administered grants. A system shall be considered unavailable for SLA purposes if Contractor-controlled issues prevent or materially impair grantees from completing the intended grant application or submission process, regardless of whether the system remains partially accessible or technically online.

• Root Cause Analysis: For any failure to meet a Service Level, Contractor shall provide TEA with a formal, written analysis identifying the root cause of the failure to meet the Service Level(s) and a corrective action plan within five (5) business days of the failure. This obligation is separate from and does not delay the application or payment of any Service Credits.

• Audit and Verification: Contractor shall provide TEA and its designated auditors (including the Texas State Auditor's Office) with direct, read-only access to all systems, tools, and raw data logs used and/or reasonably necessary or useful to monitor and measure performance against the Service Levels herein. This access shall be provided at no cost to TEA and its designated auditors and is for the sole purpose of auditing and verifying Contractor's compliance with this SLA and the Contract, or for any other reason as required or allowed by law.

• Examples outlined in the SLAs are illustrative and non-exhaustive and are provided solely for clarity.

2. Definitions

• "95th Percentile": A statistical measure of performance where at least 95% of all measured transactions (e.g., page loads) during the measurement period must be equal to or faster than the target time.

• "Acceptance" / "Accepted": The formal, written approval by TEA that a deliverable meets all requirements specified in the Contract. TEA shall have a review period of ten (10) business days to review any submitted deliverables. Failure by TEA to complete its review or provide written acceptance or rejection within such period shall not constitute Acceptance, deemed acceptance, or a waiver of any rights or remedies under the Contract, including but not limited to the assessment of Service Credits, enforcement of Service Levels, or pursuit of corrective actions. If TEA rejects the deliverable, the deliverable is not "Accepted," and the Contractor's resubmission must still meet the original Target Date unless otherwise approved in writing by TEA.

• "Acknowledgement / Response": Confirmation from a qualified Contractor technician (not an automated reply) that the reported issue has been received, logged, and assigned to a severity level.

• "API Response Time": The time elapsed, measured at the application's server-side load balancer, from the moment an API request is received to the moment the first byte of the response is sent back.

• "Availability": The percentage of time the production application is available, calculated as: ( (Total Minutes in Month) - (Downtime) ) / (Total Minutes in Month) * 100.

• "Business Hours": 8:00 AM to 5:00 PM Central Time, Monday through Friday, excluding TEA-recognized holidays aligned with State of Texas agency holiday schedules. TEA holiday observance follows the Texas Education Agency Holiday Schedule and can be provided upon request.

• “Change Request Impact Assessment”: A documented analysis prepared by the Contractor that evaluates the anticipated effects of a proposed Change Request on the solution, project delivery, and TEA operations before the Change Request is approved or implemented.

• “Core Business Function”: A primary operational activity of the application that is essential to TEA’s ability to carry out its authorized statutory, regulatory, or programmatic responsibilities.

• “Critical Component”: Any application module, service, interface, infrastructure element, or dependency that is essential to the availability, security, performance, or operation of one or more core business functions of the Production Environment.

• “Critical Feature”: A specific user-facing or system functionality of the application that is essential to the execution of one or more Core Business Functions in the Production Environment.

• “Critical Software Patching”: The identification, testing, and deployment to the application environments (includes development, testing, and production level environments) of software, operating system, firmware, or dependency updates that remediate vulnerabilities rated as Critical or equivalent severity based on industry-recognized risk ratings (e.g., severity assigned by the vendor, Common Vulnerability Scoring System (CVSS), or other comparable scoring), or that TEA reasonably determines present a significant security risk to the confidentiality, integrity, or availability of the system or TEA Data.

• "Data Return Request": A formal written request from TEA for Contractor to provide a complete and secure copy of all TEA Data in a standard, non-proprietary, and usable format determined by TEA.

• “Defect Resolution”: The permanent correction of a confirmed defect such that the affected functionality operates in accordance with the Contract, approved requirements, and Acceptance Criteria.

• “Disaster Recovery Test”: A planned and documented exercise conducted by the Contractor to simulate a disruptive event and to validate that systems, applications, data, and recovery procedures can be restored in accordance with the Contract’s Recovery Time Objective (RTO) and Recovery Point Objective (RPO). A Disaster Recover Test includes execution of recovery processes and verification of outcomes and is intended to demonstrate operational readiness, not merely the existence of recovery plans or backups.

• "Downtime": The total number of minutes the production application is unavailable to users. Downtime begins when Contractor's monitoring tools detect an outage or when TEA notifies Contractor of an outage (whichever is earlier) and ends when the application is fully restored.

o Exclusions: Downtime does not include unavailability due to:

Scheduled Maintenance.

Failures that are proximately and solely caused by TEA's network, hardware, or personnel (as substantiated by Contractor and agreed by

TEA).

A declared and substantiated Force Majeure event.

• "Escaped Defect": Any defect of Medium, High, or Highest severity found by TEA in a user acceptance testing (UAT) or production environment, which was not previously identified and logged by Contractor in its own internal quality assurance (QA) test results.

• "Key Pages": A list of high-traffic or critical-function user paths (e.g., Homepage, Grant Application Form, Search Results Page, User Login) to be mutually agreed upon and documented in writing.

• “Major Release”: A planned deployment to the Production Environment that introduces significant new functionality (materially changes to Core Business Functions or Critical Features, architectural changes, security-relevant changes, or data model modifications that materially affect system behavior, integrations, performance, or risk profile.

• "Mandatory Training": The TEA-approved cybersecurity training that all Contractor personnel must complete before being granted any access to TEA systems or data.

• "Milestone Payment (MP)": The total amount being invoiced by Contractor to TEA for services rendered for each milestone reached with formally accepted deliverables from TEA, excluding pass-through costs.

• “Non-Critical Feature”: A user-facing or system functionality of the application that is not essential to the execution of a Core Business Function in the Production Environment and whose unavailability, degradation, or incorrect operation does not materially impair TEA’s ability to perform requires business processes.

• "Page Load Time": The client-side time, as measured by industry-standard tools (e.g., browser-based performance monitoring), for a "Key Page" to be fully rendered and interactive for the user (specifically, the "Largest Contentful Paint" or "Document Object Model (DOM) Complete" event).

• "Penetration Testing": A formal, authorized, and simulated cyberattack against the production application (or a production-identical environment) to evaluate its security, conducted by a qualified and TEA-approved third-party security Contractor.

• “Protected Window”: The period beginning 48 hours before and ending 24 hours after any TEA-published opening date, closing deadline, renewal deadline, amendment deadline, or other submission deadline, unless TEA designates a longer period in writing. During a Protected Window, Core Business Functions are deemed mission-critical.

• "Recovery Point Objective (RPO)": The maximum acceptable age of data that may be lost following a declared disaster. An RPO of "1 hour" means that upon restoration of the application, the data used to restore the system must be no more than 1 hour old (effectively requiring backups be continuous or, at minimum, hourly). “Remediate Security Vulnerabilities”: The actions necessary to fully address and eliminate identified security vulnerabilities in the application environments in a manner that reduces the associated risk to an acceptable level, as reasonably determined by TEA.

• "Recovery Time Objective (RTO)": The maximum acceptable duration of time for the production application to be unavailable following a declared disaster. The clock starts now of the declared disaster and stops only when the application's critical business functions are fully restored and available to TEA users.

• "Resolution": The permanent correction of a defect, verified by TEA, and deployed to the production environment. Providing a temporary workaround does not constitute Resolution.

• "Scheduled Maintenance": Maintenance, patching, or upgrades performed by Contractor.

To be excluded from Downtime, Scheduled Maintenance must be (a) conducted between 10:00 PM and 4:00 AM Central Time, and (b) approved in writing by TEA at least five (5) business days in advance. Emergency maintenance outside this window will be classified as Downtime.

• "Security Breach Containment": The moment when Contractor successfully isolates all compromised systems, components, and data to prevent any further unauthorized access, data exfiltration, or lateral movement by the attacker.

• "Security Breach Detection": The moment a security incident or breach is first identified by any party, including but not limited to Contractor's internal monitoring tools, a TEA notification, or any other third-party report (whichever is earliest).

• "Security Breach Resolution": The moment when Contractor has completed all actions necessary to: (a) eradicate the root cause of the breach, (b) securely restore all affected systems and data, and (c) verify that the vulnerability has been remediated and the system is safe for production use.

• "Service Credit": A deduction, calculated as a percentage of the MP, applied to the next MP invoice following a Service Level failure.

• Severity Level Definitions (Application Defects):

o "Highest" (Severity 1 - Critical): A defect that renders the entire production application, a critical component, or a core business function completely or practically unusable. This includes, but is not limited to:

The production system is down or unavailable.

Widespread data corruption or data loss.

A critical security breach.

Any issue that halts essential business operations for a significant number of users, as determined by TEA, with no workaround available.

For purposes of this Contract, a Core Business Function shall be deemed

“completely unusable” if users are unable to complete the intended business process in the Production Environment without a reasonable workaround, regardless of whether the system or feature remains technically accessible.

o "High" (Severity 2 - Urgent): A defect that causes a core business function or feature to fail, severely degrades system performance, or impacts a significant number of users, as determined by TEA. This includes, but is not limited to:

A critical feature is non-functional or produces incorrect results.

Significant performance degradation impacts user productivity.

The issue impacts essential operations, but a difficult or inefficient workaround exists.

For purposes of this Contract, a Core Business Function or Feature shall be deemed “failing” if users are able to complete the intended business process in the Production Environment only with material errors, significant degradation, or reliance on a workaround, such as the function does not operate as required, even though the process is not wholly blocked.

o "Medium" (Severity 3 - Standard): A defect that causes a non-critical feature to fail, impacts a limited number of users as determined by TEA, or presents a cosmetic or usability issue. This includes, but is not limited to:

A non-essential feature is non-functional or produces incorrect results.

Minor performance issues that do not halt business operations.

An issue that has a reasonable and readily available workaround.

For purposes of this Contract, a page, feature, or function shall be considered essential if it is required to complete a Core Business Function, and non-essential if its unavailability does not materially impair completion of required business processes.

o "Low" (Severity 4 - Informational): A minor defect that has little to no impact on business operations or system functionality. This includes, but is not limited to:

Includes cosmetic issues (e.g., typos, alignment errors).

Errors or omissions in documentation.

Usability issues or minor inconveniences that do not affect functionality.

• Severity Level Definitions (Technical Support):

o "Highest" (Severity 1 - Critical): A production system outage or a halt to critical business operations. This applies to any issue where the entire application is unavailable, or a core business function (e.g., submitting and application, processing an award) is completely non-functional for all users. This includes, but is not limited to:

The production system is down or unavailable.

Users cannot log in.

Important data is inaccessible.

For purposes of this Contract, a Core Business Function shall be deemed

“completely unusable” if users are unable to complete the intended business process in the Production Environment without a reasonable workaround, regardless of whether the system or feature remains technically accessible.

o "High" (Severity 2 - Urgent): A core business function is severely degraded or unusable for a significant number of users, and no reasonable or convenient workaround exists. The system is still operational, but its primary purpose is critically impaired. This includes, but is not limited to:

A required form necessary to complete business operations fails to submit successfully, even when the user has completed all fields correctly and followed the expected submission steps.

A key integration is failing.

For purposes of this Contract, a Core Business Function or Feature shall be deemed “failing” if users are able to complete the intended business process in the Production Environment only with material errors, significant degradation, or reliance on a workaround, such as the function does not operate as required, even though the process is not wholly blocked.

Performance is slow, preventing business operations from completing within Service Level Agreements.

o "Medium" (Severity 3 - Standard): Either (1) a non-critical application feature is impaired, or (2) a core feature is impaired for a limited number of users as determined by TEA, but a reasonable and convenient workaround exists. This also includes general “how-to” questions that, if left unanswered, are blocking a non-critical business process. This includes, but is not limited to:

A report is generating incorrect data.

A user’s permissions are incorrect.

A button is not working on a non-essential page.

For purposes of this Contract, a page, feature, or function shall be considered essential if it is required to complete a Core Business Function, and non-essential if its unavailability does not materially impair completion of required business processes.

o "Low" (Severity 4 - Informational): A minor cosmetic issue, a general “how-to” question that is not time-sensitive, or any request that has no immediate impact on business operations. This includes, but is not limited to:

A user asks for clarification on a feature.

A typo is found on a page.

A request for new documentation.

• Security Vulnerability Severity Level Definitions:

o "Highest" (Critical): A vulnerability that, if exploited, could lead to a full compromise of the system, remote code execution, or unauthorized access, modification, or loss of all sensitive data. This includes, but is not limited to:

Failure to properly validate or sanitize input allowing unauthorized access to backend systems or data; inadequate execution controls allowing untrusted code to run; improper authorization controls permitting elevation of privileges beyond those explicitly granted.

o "High": A vulnerability that, if exploited, could reasonably be expected to result in unauthorized access to, modification of, or loss of sensitive data, or cause significant degradation of system availability or performance, but not a full system compromise. This includes, but is not limited to:

Improper input handling or output encoding allowing malicious content to be processed in a user session; insufficient access controls allowing users to access data beyond their authorized scope; inadequate request validation allowing internal services or resources to be accessed in an unintended manner.

o "Medium": A vulnerability that, if exploited, could reasonably be expected to result in limited unauthorized actions, exposure of non-sensitive information, or partial degradation of system performance, but does not materially impair Core Business Functions or system security. This includes, but is not limited to:

Inadequate request validation allowing unauthorized actions on non-critical functionality; configuration or error-handling weaknesses that expose non-sensitive system information; resource management deficiencies that may cause localized or intermittent performance degradation without system-wide impact.

o "Low": A vulnerability that , if exploited, represents a minor security weakness with minimal risk to the confidentiality, integrity, or availability of the system or

TEA Data, and that does not materially affect system operation or business outcomes. This includes, but is not limited to:

Minor configuration or best-practice deficiencies, such as missing or misconfigured non-critical security headers; informational messages that reveal non-sensitive data without enabling authorized actions; or other low-risk weaknesses with negligible operational or security impact.

• "SLA Report": A consolidated written report, submitted by Contractor in accordance with the Contract, that accurately reflects performance for the entire preceding calendar month and includes all information required for TEA to evaluate compliance with project schedule, risks, constraints, assumptions, dependencies, decisions, outstanding items, support needs, contractual, service level, and corrective action obligations.

• “Target Date”: The calendar date specified in the Contract, project plan, delivery schedule, or other TEA-approved documentation by which a deliverable, milestone, corrective action, or obligation is required to be completed and submitted to TEA for review or Acceptance.

• "TEA Data": All data, information, records, files, and content, in any format, that are (a) provided by TEA to Contractor, (b) created, processed, or stored by Contractor on behalf of TEA as a result of or in furtherance of the Contract, or (c) generated by the application.

• "Unapproved Software": Any third-party, open-source, or licensed software, library, or dependency that was not explicitly disclosed by Contractor and approved in writing by TEA's Technology Review Committee (TRC) prior to its use in any deliverable or environment.

• “Usability Issue”: A defect or deficiency related to the user interface, interaction design, or user experience that affects ease of use, clarity, consistency, or efficiency, but does not prevent completion of a Core Business Function, does not cause incorrect processing of data, and does not result in a Service Level failure.

• “Vulnerability”: A weakness, flaw, misconfiguration, or deficiency in the application, infrastructure, code, controls, processes, or dependencies that could be exploited to compromise the confidentiality, integrity, or availability of the system, TEA Data, or related services.

3. Liquidated Damages

The Parties agree that damages for breach of the associated requirements below are difficult or impossible to calculate and that liquidated damages, which shall be assessed as Service Credits, are appropriate. The Contractor further agrees: (1) that all liquidated damage formulas set forth in this document (a) are fair and acceptable methods to calculate damages and (b) are not penalties, and (2) that the liquidated damages can be assessed by TEA in the event of a specified Contract breach by Contractor as outlined herein.

Contractor agrees that the liquidated damages provided for herein are not intended to be exclusive and shall not waive, limit, or preclude any other rights, remedies, or causes of action that may be available at law, in equity, or under this Contract, all of which shall be cumulative.

Service Credits are non-cumulative; only the highest applicable Service Credit for a single, distinct incident shall apply. The total Service Credits shall not exceed thirty percent (30%) of the Milestone Payment except for a final invoice when the Contract is terminated or expires.

Accrual and Carry-Forward of Credits: In any calendar month where a Service Level failure occurs but no Milestone Payment is invoiced, the applicable Service Credits shall accrue and be "carried forward." These accumulated credits shall be applied as a direct reduction to the next Milestone Payment invoice submitted by the Contractor. T+ he 30% cap applies to the Milestone Payment inv Contract Effect of Termination on Credits: Upon termination or expiration of the Contract for any reason, any accrued but unapplied Service Credits shall be applied against Contractor's final invoice. If the total value of such credits exceeds the amount of the final invoice, Contractor shall pay the remaining balance to TEA as a direct cash payment within thirty (30) days of the termination date. Such direct payment not paid by the Contractor within thirty (30) days of the termination date shall accrue interest at a rate equal to the lesser of (i) the then-prevailing prime rate as published by a nationally recognized financial institution or (ii) the maximum rate permitted under applicable Texas law, if such law sets a maximum rate.

Prerequisite for Invoicing: Contractor's submission of a "SLA Report," as defined in Section 2, is expressly required as part of any relevant invoice, with any document that purports to be an invoice without including an applicable “SLA Report” being void such that it does not trigger an obligation to pay under Chapter 2251 of the Texas Government Code. TEA shall have the right to reject any invoice submitted for a period in which all reports have not been provided and Accepted by TEA.

4. Service Level & Remedies Table

Category Metric Target Measurement Period / Frequency

Liquidated Damages

Application Availability & Performance

Application Uptime (Production)

99.9% Per Calendar Month

Service Credit equal to percentage of MP:

99.5% – 99.89%: 7.5%

99.0% – 99.49%: 15%

< 99.0%: 25% Page Load Time (Key Pages, Desktop)

< 4 seconds (95th percentile)

Per Calendar Month

Service Credit equal to percentage of MP:

4.1 – 5.0 sec: 5%

> 5.0 sec: 10% Page Load Time (Key Pages, Mobile)

< 3 seconds (95th percentile)

Per Calendar Month

Service Credit equal to percentage of MP:

3.1 – 4.0 sec: 5%

> 4.0 sec: 10% Security & Compliance

Security Breach Detection

24 hours from initial compromise

Per 24-hour period

$10,000 Service Credit

Capped at $30,000 per incident

Security Breach Containment

Isolate breach within 8 hours of Security Breach Detection

Per Incident $20,000 Service Credit for failure to contain within the required timeframe

$10,000 per additional 8-hour period until containment

Capped at $60,000 per incident

Security Breach Resolution

Full remediation & restoration within 72 hours of Security Breach Containment

Per Incident $25,000 Service Credit for failure to resolve within required timeframe

$150,000 per 24-hour period until resolution

Capped at $75,000 per incident

Critical Software Patching

Deployed to production within 48 hours of patch release

Per Incident $3,500 Service Credit per day (per patch)

Remediate Security Vulnerabilities

Highest: 24 hours

High: 72 hours

Medium: 5 business days

Low: 10 business days

Per Incident Service Credit per vulnerability, per day past deadline:

Highest: $3,000 per vulnerability per day capped at $30,000

High: $1,500 per vulnerability per day capped at $15,000

Medium: $750 per vulnerability per day capped at $10,000

Low: $350 per vulnerability per day capped at $7,500

Penetration Testing Conducted per Contract and Project Plan

Annually and, in addition, post-major release

Per Year $15,000 Service Credit for failure to conduct

$5,000 per 30-day period until completed

Capped at $30,000

Mandatory Training Compliance

No Contractor personnel accessing TEA systems without having first completed Mandatory Training.

Continuous $10,000 Service Credit per untrained individual, per incident.

Defect & Support Response (Post- Production)

Technical Support Response (Acknowledgement of receipt of the support request to

TEA)

Highest: 1 hour

High: 4 business hours

Medium: 24 business hours

Per Support Request

Service Credit per incident:

Highest: $1,500

High: $750

Medium: $350

Post-Production Defect Resolution

Highest: 24 hours

High: 2

Medium: 5

Low: 10

Per Escaped Defect

Service Credit per defect, per day past deadline:

Highest: $3,500

High: $1,500

Medium: $750

Low: Warning for first five (5) in any given calendar month;

beginning with the sixth (6th) Low defect in the same calendar month $250 per defect, per day past deadline

Quality Assurance

Escaped Defects Found by TEA

0 Highest Escaped Defects

0 High Escaped Defects

< 5 Medium Escaped Defects

Per Calendar Month

Service Credit per escaped defect:

Highest: $5,000

High: $2,500

Medium: $500 (Penalty applies starting with the 5th Medium defect)

Low: Warning Project Management

On-Time Delivery of Key Milestones

All deliverables listed in the Contract, including all items in the

"PROJECT

DELIVERABLES

AND

MILESTONES"

section, are fully "Accepted" by TEA by their specified Target Date.

Continuous

$2,500 Service Credit per business day that a deliverable is late for Acceptance.

No Use of Unapproved Software

No use of Unapproved Software.

$25,000 Service Credit per incident.

The Contractor must immediately remove and replace the Unapproved Software with an approved alternative at no cost to TEA and is solely responsible for all schedule delays and rework.

SLA Report Delivered

An SLA Report is delivered by the 5th business day of the month, each month.

$2,000 Service Credit.

Weekly Status Reports Delivered

Delivered by Friday 12:00 PM

CT.

$750 Service Credit per occurrence (late or incomplete).

Risk Management Plans Updated (Identification & Mitigation Plans)

Updated weekly per agreed process.

$3,500 Service Credit per instance of non-compliance.

Root Cause Analysis & Corrective Action Plan

Completed within five (5) business days

Per SLA Failure

$5,000 per non-compliance.

Training & Knowledge Transfer

Train-the-Trainer Certification Required for All Designated Participants

90% of TEA's designated participants must demonstrate sufficient understanding of the training content by passing a TEA-approved knowledge assessment within five (5) business days of training completion.

Per Training Event

Contractor shall re-perform all training and update materials at no cost to TEA for each failed attempt. $5,000 Service Credit if 90% pass rate is not achieved after the second attempt.

Perez, Gabriel Is this desired?

Perez, Gabriel Needed?

Perez, Gabriel Needed?

Perez, Gabriel Will need to be updated based on training desired

Data, Compliance & Business Continuity

Data Portability and Return

Contractor must provide a complete copy of all TEA Data, which is the sole property of the State of Texas, within 10 business days of (1) a Data Return Request at any time or

(2) upon contract termination.

Continuous $50,000 Service Credit.

$1,500 per business day that the complete data set is not made available after the Target

Recovery Time Objective (RTO)

4 hours Continuous $15,000 Service Credit for first hour past RTO; $7,500 for each additional hour.

Recovery Point Objective (RPO)

1 hour up to 4 hours

Continuous $30,000 Service Credit for any data loss exceeding 1 hour.

$10,000 Each additional 4-hour increment (or portion thereof)

Data Backups Daily Backups Created

Continuous $1,500 Service Credit per missed daily backup.

Disaster Recovery Test Conducted and Report Delivered

Annually (Full Test)

Continuous $20,000 Service Credit for failure to conduct the test and provide report.

Perez, Gabriel Needed?