This is documented in Omegabit Disaster Recovery Handbook, Section 1.1 to 1.4 and Section 2.3 ref: Omegabit Disaster Recovery Plan TOC

We consider any intrusion to be a "Severity I" class event.  Which, per our SLA requires a response time of <2hrs.  In reality, our 24x7 operations staff will respond to any Severity I event the instant it is detected.  I've attached  boiler-plate/generic copy of our SLA and am happy to produce a named/completed version for a given stack if of benefit (this one calls out "sticker" and a la carte pricing and is OK to share as-is).  

In the event of any detected incident, including known breach or ongoing security intrusion, performance degradation, major change in performance profile, etc., notice is provided to the customer as soon as practical. Typically, within minutes provided we are not actively triaging and providing emergency responding to the issue.  We consider the ownership of security related issues to be a joint-responsibility along with the application sponsor.  Because, in many cases the risk may be specific to the customer's implementation of the portal, and we must be in communication with the owner to permanently resolve the issue if not to triage and block it, temporarily.  A 24hr point of contact with the customer is preferred for emergency incident notification, which can include email and telephone contact depending on severity and customer preference.

Yes, for specific audit log event analysis we use a combination of tools including but not limited to Splunk and Dynatrace SaaS; additional software subscription and fees apply for a dedicated implementation of reporting facilities for Client use and self-reporting.