3.1
– most of us are inclined to support some sort of chargeback for negligence – but what would happen if the incident resulted from a state actor or advanced persistent threat? To encourage reporting of all real or potential incidents – which is ultimately what we all want – maybe investigations and remediation could be considered core-services?

What we want to avoid are internal punitive repercussions that will limit reporting – things that customers fear like massive investigation costs and removal or takeover of their resources. On the other hand, perhaps this SLA can show in detail the external factors that customers should perceive as risks – regulatory and accreditation bodies, credit reporting coverage for breached accounts, etc.? Basically, make it clear to data users that internally, UNM IT will help them, that the investigation is about discovery, not punishment. But that there are serious consequences external to UNM – in those cases, they cannot dodge responsibility for negligence.

This SLA could reassure customers that UNM IT will shepherd them through a process that may not have been their fault; otherwise, their fear of internal repercussions and costs may prevent them from reporting suspected issues. Which could allow an APT to thrive on the network. There is a time and place for cost recovery, but I fear implementing it within the Security Incidents SLA will undermine the larger goal, identifying and removing bad actors from the UNM network.

• This reply was modified 8 years, 8 months ago by ccovey01.

2.1.2
– bullet 6 – what is the predefined set of criteria for escalation?
– Suggested criteria:
· Within 1 business day of ticket submission, requestor must receive notification identifying the assigned department (ticket owner)
· The following cycle applies to customer tickets/emails at initiation and at any point after a customer response
-After 3 business days of no response from ticket owner, Help Desk contacts owner for update
-After 3 additional business days of no response, director of owning department contacted by Help Desk for update
-After 6 days of no response, owner and director receive daily reminders from Help Desk to respond to the ticket
-After 7 business days with no response, Incident declared:
— Service Owner contacts ticket owner and owning department director for written response
— Report filed with IT SAC

· Whether by policy or thru the interface, ticket owners must put response at the top of their email (we often receive Help.UNM emails with the request for information at the bottom of a very long thread of Help.UNM responses).
· All responses – ‘Holds,’ ‘Waiting for Response, ‘Fulfilled,’ ‘Closed due to Resolution’ etc., must provide details explaining the status change for the ticket.
6.3 – if customer requests a certain priority, initial ticket response must note actual priority designated, and reason for change from customer request
8 – Billing – is this applicable? If it isn’t, does it need to be included in the SLA?

• This reply was modified 8 years, 8 months ago by ccovey01.

Item 2 – a direct link to the service catalog item for Master Hardware would be useful, that could then link to the Dell B2B site – and via that users would see what Dell provides, discounts, etc.

2.1.1 – so that users, Purchasing, and Auditing could see it, might be useful to link in the Service catalog to exclusions already in place. E.g.,, the HP MP9s that are allowed for digital signage. Having these exclusions listed would save a lot of back and forth email between units and Purchasing and Auditing.
Not related to the SLA – could we get line breaks/basic editing added to this interface? The interface currently only allows unbroken text entry.

Jeff and Tuan,

One trend I see forming is the need for all SLAs to link to

• the specific service catalog/cost statement(s) that they invoke
• as well as all dependent documents, like the Incident Response document

That will help us all consider the full implications of the SLAs.

Again, thanks for your replies to the various discussions.

Chad

Tuan,

My thanks as well for taking the time to reply to all of these responses, in detail, and for being receptive to the suggestions made – Chad

2.1.2 – Request to add-  “Staff initiating long distance code requests can also see the LCD issued to the end user” – in some cases, the LCD issued is incorrect or users lose the email, this will save repeated Help.UNM requests if initiating staff can maintain their users’ LCDs and test them.

• What is time to completion for LCD creation?
• What is time to completion for phone line move/addition?
• What is time to completion for break/fix of active phone line?

3.1 What are department’s options in terms of cost recovery for loss of services?

6 –  Incident

• Does the department have the ability to declare an incident?  Within this SLA, does an interruption in the normal functioning of a service or system include the department’s services or systems?
• If the department experiences incidents, what are the department’s options in terms of escalation and revision of the SLA?

6.3 can a department communicate to UNM IT phone systems it considers critical?  For example, the receptionist phone line for most departments is critical to the public being able to call that department – if its service is lost, can it be treated as a P1?
9.1 Performance and Reporting

• If Targeted uptime is 99.9, shouldn’t there be a reporting interface for customers to see?

9.2 who are the primary stakeholders? In terms of the review facilitation, that’s a bit unclear.  Would it be useful to do annual reviews of the SLA with the customers?

General SLA concern – in most of the current SLAs and Service Catalog, UNM Enterprise services are offered by a single entity, there is no competitive marketplace.  Given that, shouldn’t UNM customers (departments) have an equal stake in the writing and re-writing of the SLAs?  And should this revision process be set annually for all SLAs and services where UNM departments are the customer?
SLA’s between customers and vendors typically feature the ability for either side to terminate the SLA – what is the escalation/termination process for UNM SLA’s between Central IT and departments?  What if customers are gravely unhappy with service delivery?  What if the service owner is unhappy with the customer? Is there an arbitrating body to make determinations when the service owner and departments disagree about the SLA or service delivery?

Understandably, many Enterprise services now appear to have cost recovery components. Between the service catalogs and the SLAs, funds appear to flow unilaterally from the customer to the service owner.  With no cost downside, there’s little incentive for the service owner to be timely or accountable. What mechanisms are in place to ensure accountability by the service owner?

• Inclusion of a 1,2, 3 strikes escalation series might be appropriate accountability mechanism – 1 to 2 incidents lead to remediation meetings and revision of SLA.  3rd incident leads to SLA termination.
• A return to the customer of the full amount or part of the fees for the service might be a necessary baseline for most SLAs and statements of work.
• In the case of a mis-routed ticket, as an example, where the customer followed the appropriate protocol, but the ticket was mis-routed, what can customers expect as compensation in terms of lost time, productivity, or funding?

• What happens if a grant is affected or lost due to an Incident?

Help.UNM appears to be the default mechanism for reporting issues and incidents, per the SLA.  It does not presently allow customers to see to whom the ticket is routed, who owns it, etc.,

• To protect both the service owner and customers, perhaps Help ticket responses could by default include the routing and owner of the ticket?  Mis-routed tickets do happen, and a mis-routed ticket could become very expensive to either the customer or service owner.

There seems to be a general concern about the number of SLAs appearing weekly, and little time for discussion.  Given their importance, and the likely volume of comments forthcoming, would it be better to put them into some sort of document management system, like SharePoint?

• 2.1 – Will these assessments occur at the department’s request only?
• If they are UNM IT originated, what SLAs, processes, and costs apply?
• 2.1 – Where is the MOU (link) mentioned?
• 2.1  – Are any of the scans/reports cloud-based?
• 2.1 – What process will be followed if the service identifies some issue that is less critical than an unauthorized PII or SPI disclosure?

  For example, if a department’s service has been interrupted due to UNM IT Security request to Networking to shut off network access to a scanned system or service, and the department then fixes the issue and reports the fix to UNM IT, how many business days does UNM IT have to complete a remediation scan and provide results to customer?

• What is resolution process if vendor or customer disagrees with the assessment as to the severity of a vulnerability?
• If service interruption was in error, what will be the cost if any to the customer?
• 2.1  Request for change- “comply with directions”   “Utilize directions from” …..
• 3.1 – Could we get an example statement of work?
• 4.1 – Will departments be given the time the scans takes place, to prepare their users for potential loss of service?
• 4.1 –  Vulnerability scanning tools can take servers, web sites, printers, and systems offline – what is the process to pause or cease scan(s) if service break occurs due to scans/assessment?
• It may be useful for the customer to be able to select between passive and aggressive assessments, where the customer understands the aggressive assessment will more than likely take their services offline.  Given that choice, a loss of service could not be declared an Incident by the customer.

  4.3 Escalation –

• Request to Add – “Customer can after 1  Incident request meeting on-site with Service Owner and Service Manager”
• Request to Add – “Customer can after 2  Incidents request review and redraft of SLA”
• Request to Add – “Customer can after 3  Incidents request termination of SLA”
• 4.3 – Will the phone number of the lead assessment technician or service owner be provided in the SoW?
• 5.2 – Will customers be able to determine who has been assigned the request?

6 –  Incident

• Does the department have the ability to declare an incident?
• Within this SLA, does an interruption in the normal functioning of a service or system include the department’s services or systems that are being assessed/scanned, or is an incident restricted to only the Assessment service itself?
• Request to Add – “If the customer experiences a service interruption due to an IT Security Assessment, and the Assessment is not paused or canceled within 2 business hours after customer notifies Service Owner, an Incident has occurred.”
• Request to Add – “If the customer experiences a service interruption as a result of an IT Security Assessment, where service is removed, and the customer requests a remediation assessment, and the remediation assessment is not completed within 2 business days, an Incident has occurred.”
• If the department experiences incidents, what are the department’s options in terms of escalation and revision of the SLA?
• 9.2 who are the primary stakeholders? Is that the ‘customer’ and UNM IT?