Service Level Agreements

Version: 2020-05-27

Overview

This Service Level Agreement (SLA) document is provided for customers as referenced in the governing end user terms. Any capitalized terms not defined herein shall have the same meanings assigned in the that agreement.

Service Level Agreements

Uptime Service Availability Commitment SLA

During the term of an Order Form, the Deepwatch infrastructure and software platform will be available no less than 99.9% of the total number of minutes within each calendar month.

Initial Response and Update SLA

Impact	Service Request*	Operations Incident*	Threat Event	Validated Security Incident	SLA
Critical	N/A	1 Hour	N/A	1 Hour	95%
High	1 Business Day	1 Business Day	N/A	2 Hours	95%
Medium	3 Business Days	3 Business Days	N/A	8 Hours	95%
Low	5 Business Days	5 Business Days	N/A	24 Hours	95%
Informational	N/A	N/A	N/A	N/A	N/A

* Applicable to Service Requests and Operations Incidents for standard and normal changes

Deepwatch applies the Initial Response and Update SLA to validated incidents. Deepwatch only provides measurements and reporting on the handling of threat events and unvalidated incidents. The Initial Response and Update SLAs also does not apply during the initial sixty (60) days of onboarding or adding any additional division or business unit.

Resolution SLA

Customer agrees that this SLA does not apply to the resolution of any incident but only to the provision of initial response and updates.

Carve-Outs and Credits

SLA Credits

Any request for a credit must be in writing and received by Deepwatch within fifteen (15) days following the last day of the month of Deepwatch’s failure to meet any of its SLA commitments in a calendar month. Upon receipt such written request and verification by Deepwatch, Deepwatch will issue a credit of 1/30th of the monthly subscription fee for the affected Service for the month of the failure. If a written request is not received within fifteen (15) days following the last day of the month of the failure, Customer’s right to receive a service credit with respect to the month in which Deepwatch failed to meet its SLA commitment shall be waived.

Customer Requirements

In order for the SLAs to apply, Customer must submit the case through the customer portal.

Reproducing Errors

Deepwatch must be able to reproduce errors with an unmodified version of the Services being accessed in order to resolve them. Customer agrees to cooperate and work closely with Deepwatch to reproduce errors, including conducting diagnostic or troubleshooting activities as reasonably requested.

Exclusions

In determining whether Deepwatch has met its SLA commitments, the following exclusions shall apply with respect to Deepwatch’s obligation to provide support under the specific care plan which Customer selected and if Customer might be eligible for a service credit: (i) if Customer breaches any of its obligations with Deepwatch, including payment obligations; (ii) any Deepwatch scheduled maintenance; (iii) any Service unavailability due to any force majeure event or any other factor outside of Deepwatch’s reasonable control including but not limited to telecommunications or internet problems, power failures, and/or service provider failures outside of Deepwatch’s data center; (iv) any problem resulting from any hardware, software, infrastructure and/or platforms not provided by Deepwatch or any third party’s acts, errors or omissions ; (v) any interruption or unavailability resulting from Customer’s use of the Services in an unauthorized or unlawful manner or any interruption resulting from the misuse or improper use of the Services; (vi) any Service Requests and/or Operational Incidents, as defined below, related to non-standard changes; (vii) any interruption resulting from disconnection or suspension of the Services for Customer’s non-payment in a timely manner of any Deepwatch invoice; and (ix) any industry wide security threat (e.g., WannaCry). The service credit remedy set forth in this SLA is the Customer's sole and exclusive remedy for the unavailability of any applicable Services in the Order Form. Under no circumstance, shall Deepwatch’s failure to meet an SLA commitment be deemed a default or breach under the end user agreement. All SLAs for Cases will be delayed while Deepwatch is waiting on Customer or third-party vendor’s action or information while the Case status is in a “waiting on the customer,” “waiting on a third party” or “pending other prerequisites” status. Uptime SLAs do not apply for planned maintenance including unexpected outages resulting from planned maintenance where the Customer has not invested in high availability.

Additional Conditions

Deepwatch makes no guarantee that breaches, compromises or unauthorized activity will not occur across a customer’s network or IT environment.

Key Terms

Where practicable, Deepwatch bases key terms in NIST and ITIL definitions.

Case Types

Operations Incident - An unplanned interruption to service or reduction in the quality of service. An unrealized but imminent threat to interrupt or reduce the quality of service is also an Operations Incident. Operations Incidents may be linked to a change record as part of resolving the incident.
Service Request - A formal request from a Customer for something to be provided. Service requests may be linked to a change record as part of fulfilling the request.
Threat Event - An event or situation that has the potential for causing undesirable consequences or impact.
Security Incident - A threat event that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
Change - An adjustment to a system that may arise reactively in response to an Operations Incident, proactively from a Service Request, or from service enhancement initiatives.

Change Management

Change Management - A set of standard operating procedures for changes to include change review and approval requirements and change windows for the varying types of changes.
Standard Change - A pre-authorized change that is lower risk, relatively common and follows a defined procedure. Standard changes do not adhere to change management and they are logged and tracked using the Service Request or Incident driving the need for the change.
Normal Change - A change that is higher risk, relatively common and follows a defined procedure. Normal changes adhere to change management and are logged and tracked in a change record separate from the Service Request or Incident driving the need for the change.
Emergency Change - A change required to resolve a critical Operations Incident. If a normal or non-standard change, the change will adhere to change management immediately following the change but not to impede resolving the incident.
Non-standard Change - A change that has unknown risk because it is not common and does not follow a predefined procedure. Non-standard changes adhere to change management.

Change Examples

Change Type	Service Request	Operations Incident
Standard	Initial deployment of or enhancement to a SIEM log source or use case pre-built by Deepwatch or SIEM vendor and is CIM compliant Integration between a Deepwatch platform and the same platform within the customer environment Creation, modification, or deletion of a firewall rule Creation, modification, or deletion of a vulnerability report	An inoperable or malfunctioning SIEM log source or use case pre-built by Deepwatch or SIEM vendor and is CIM compliant An inoperable or malfunctioning integration between a Deepwatch platform and the same platform within the customer environment A down or inoperable platform managed by Deepwatch
Normal	A planned upgrade of a platform to the latest patch or release certified by Deepwatch Decommissioning of a platform managed by Deepwatch	Applying a platform patch or new release certified by Deepwatch to resolve a non-critical Operations Incident
Emergency	N/A	Any standard or normal change required to resolve a critical Operations or Security Incident
Non-standard	Initial deployment or enhancement to a SIEM log source or use case, not pre-built by Deepwatch or SIEM vendor and is not CIM compliant	An inoperable or malfunctioning SIEM log source or use case, not pre-built by Deepwatch or SIEM vendor and is not CIM compliant An inoperable or malfunctioning integration between a Deepwatch platform and a different platform within the customer environment
Out of Scope	Cases not driven by cybersecurity value or not achievable within the platform Deepwatch manages

Prioritization

Priority - A classification used to identify the relative importance of a case. Priority is based on impact and urgency relative to the Deepwatch service.
Impact - A measure of how service levels will be affected as a result of the case. The impact may be the result of fulfilling the case or a result of not fulfilling the case.
Urgency - A measure of how long until the case has an impact on the service level.
Business Urgency - A measure of how long until the case has an impact on the customer’s business operations. Deepwatch will make reasonable attempts to expedite cases based on customer business urgency but business urgency does not influence case prioritization or the SLA.

Prioritization Examples

Prioritization	Service Request	Operations Incident	Security Incident
Critical	N/A	Correcting a SIEM log source and use case from the Deepwatch maturity model that collectively are not parsing or producing threat events as intended Restoring a platform that is unavailable or inoperable Creation or modification of a firewall rule as needed to mitigate a critical security incident Creation, modification, or execution of a vulnerability scan and report as needed to manage a critical threat event	An unauthorized actor (human or automated) is present in the environment Leakage or exposure of sensitive information The platform is unavailable or inoperable to provide the intended security function SIEM log source from Deepwatch maturity model is not reporting in or not parsing correctly and is associated with an active use case from the Deepwatch maturity model.
High	A planned upgrade of a platform to the latest patch or release certified by Deepwatch Initial deployment of a log source and associated use cases from within the Deepwatch Maturity Model	Applying a platform patch or new release certified by Deepwatch to resolve a non-critical Operations Incident Platform performance is degraded but the intended security function remains operable Creation, modification, or execution of a vulnerability scan and report as needed to manage a high-security incident Creation or modification of a firewall rule as needed to mitigate a high-security incident	Sudden decrease or increase in data ingested from log source within Deepwatch”s maturity model Suspicious activity potentially indicative of an unauthorized actor (human or automated) being present in the environment or possible leakage or exposure of sensitive information
Medium	Initial deployment of a log source and associated use cases provided by the SIEM vendor and CIM compliant Malicious IP event [host scanning] Vulnerability report creation or modification FW rule creation, modification, or deletion	Correcting a SIEM log source or use case provided by the SIEM vendor that is CIM compliant and not parsing or producing threat events as intended Creation, modification, or execution of a vulnerability scan or report as needed to manage a medium security incident. Creation or modification of a firewall rule as needed to mitigate a medium security incident	Reconnaissance activity such as port scanning, excessive failed logins, or outbound traffic to known bad actors
Low	Initial deployment of a log source and associated use cases requiring customized development	Correcting a SIEM log source or use case customized for an individual customer by Deepwatch that is not parsing or producing threat events as intended Creation, modification, or execution of a vulnerability scan or report as needed to manage a low-security incident Creation or modification of a firewall rule as needed to mitigate a low-security incident	Threat activity that is mitigated such as via a firewall block but requires reporting for regulatory compliance or other reasons
Informational	Request for documentation related to how Deepwatch operates	N/A	Threat event reports as required for regulatory compliance or other need to review high volumes of threat events Initial threat hunt before the hunt reveals a security incident

Deepwatch tailors prioritization of threat events for each Customer’s risk tolerance and regulatory requirements and therefore threat events are not represented in the above table. Deepwatch bases SLAs on impact as defined in this document and Deepwatch retains the right to reclassify the impact and resulting SLA on a case per the definitions above.

Deepwatch may change any of the SLAs from time to time in Deepwatch’s sole discretion and any such changes will apply only on a prospective basis from the effective date of such change. Deepwatch may also update the toll-free telephone number and/or trouble ticket contacts or procedures by providing Customer with written notice.