Free Downloads

ISO 20000: 2011
ITIL 2011 MMap

Request for Change (RFC) Template

Major Incident Report Template

ISO 20000/ITIL Timeline poster


Sponsored Links



Dec 30, 2011

What is Password Reset: Service Request, Incident or Change?

I browsed through a few social networks lately discussing basic Service Support activities like password reset. Interesting to see how even experienced IT professionals have different points of view on elementary procedures like this one.

One of discussions goes on and on about what is a Password Reset procedure: is it a Service Request, Incident or Change?
We can take for granted that these portals consider the simplest case of Password Reset event: the user forgot hers/his password. In a consolidated service desk of 2000s this was the most frequent event, making 50-80% of all calls.

Is it an Incident?
So, could it be an Incident? Obviously NOT. Incident definition requires a service downtime or probability of downtime. No service downtime here, only end user can't log in, by his own fault.
Why then a plenty of Service organizations treat these events as Incidents? Because of the Service Desk TOOL they (miss)use. They have a nice little tool which is ITIL approved by some elephant. It can do all the process, you name it. But implementation of additional modules costs money and time. They already have Incident Management. Their implementer sucks, their ITSM consultant could do better, and they are often the same person. So they created a category "Password reset" in Incident Management module and they treat password reset as an incident. That's why it has to be an incident. If the only tool you have is a hammer, every problem is a nail. Let's move further.

Is it a Service Request?
Is password reset request a Service Request? Of course it is, there it is in the ITIL definition of a Service Request:
  • A request from a User for information or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service requests are usually handled by a Service Desk, and do not require an RFC to be submitted.
So it's a small preapproved standard Change which is processed thru Request Fulfillment process.
Yes, it is a Change, but no need for Change Manager and CAB to get involved since it happens frequently and can be dealt with on the 1st level. And thank you God for technology you provided so that lately any end user password can be reset via a simple self-help portal. User just answers a secret question, puts in his employee ID and receives the new password via text message or such.
What other special flavors of password reset are there?
  • Simple web application user passwords are a mild example of the above described case.
  • Enterprise domain user password is closer to what first comes to our mind when we think about password reset. Now, we said it is a Service Request. In which cases it escalates to a Change Request? Well, if you have a strong security policy, implemented SOX or ISO/IEC 27001 and influential security officer, then it's possible that they require formalized approval cycle and implemented operational Standard Change procedure.
  • VPN account passwords which enable user to connect from the outside of the company to internal network are a very sensitive security case, so all concerns regarding domain user accounts apply to them, and then some. A special case is a VPN account given to a 3rd party employee. Usually such a request has to have defined start and end of usage and approval from a high position (chief security, IT manager or CEO).
  • Application Administrator account passwords enable the user to create a significant amount of damage to a company according to the importance of the application to the business. Examples: Intranet applications, CRM, ERP. Which one contains the most sensitive data for your company? Probably the ERP application.
  • System Administrator Account presents the highest possible level of trust to an employee. Only security officer , Operations or IT Manager should approve these account creations and their password reset requests.
  • Service Accounts under which different IT services are executed. These have to be taken care by the security officers, their catalogue has to point to services they enable (1:M relation) and access to their passwords has to be restricted only to most confidential people. Usually these accounts have broad authorization and they are set to rarely or never expire, so they should be maintained with utmost care, especially in organizations with frequent employee fluctuation. Best practice is to deposit them in a safe box by a single person.
Note: there are significant changes lately in best practices and recommendations with large vendors and consulting companies about the password lockout policy.
Until recently, the recommendation was to lock the user account after three to five unsuccessful attempts. What changed? Implementation of security standards and best practices introduced higher password complexity and more frequent user password changes. Majority of users have some kind of mobile device for connecting to an enterprise mail system. These devices cache user credentials and often lock-out user's accounts after password change. Virtualization also contributed to simplification of lockout policy since various user credentials can be cached on different physical and virtual machines.
Brute force attacks are measured in hundreds if not thousands of attempts in a short period of time, so it is now advised to lift the lockout attempt number to 60-100, or to turn the policy off completely and survey security logs with adequate tools.

Let me just finish here in a nicer tone. ITIL is not too prescriptive in telling you how exactly to do things.
In the above example, if you process Service Requests as a special category Incidents, you are still in the green. Customers get their service, all needed reports can be generated as agreed, KPIs are there, you are good!

We are in business of keeping the customer business going. In the spirit of current holidays, I wish you the very best of luck with it. Because you are going to need it :)

For further reading I recommend 4.2 Incident Management, 4.3 Request Fulfilment and 4.5 Access Management chapters in ITIL Service Operation book.
Also, have a look at articles:


Ruby Claire said...

I hope you are talking about Tools too. Sometime Service Desk request takes long time..Why is it so?

Satisfaction questionnaire

doctor said...

Hi Ruby.

Yes it does, everything depends on what is agreed with the business. If the SLA addresses the issue properly, then all processes should take care to be performed in the agreed parameters.

Happy New Year to you!

doctor said...

A comment from LinkedIn:
"Many Service Requests may come in via the Service Desk and may be initially handled through the Incident Management process. Some organizations may choose that all requests are handled via this route..."

Service Requests can be handled in SD tool via Incident Management module thru a separate branch in category tree. Everything will be in place: management, KPIs, SLA, Reporting.

But WE should keep in mind that it is not an (ordinary) incident.

Anonymous said...

very interesting article! I will follow your themes.
Can I subscribe to your posts on Twitter or on your Facebook profile?

doctor said...

yes, dear friend, you can see me on FB as ITSM Doc and i am ITSMdoc @ twitter

David said...

Hi, A very basic question that came up recently was "Why do we log Incidents as Service Requests initially". I am sure that I have seen in ITIL documentation that this is "best practice". I cannot find anything to back this up now, which leaves me questioning whether in fact a Service Request does have to be raised before turning it into an Incident ?

Event Management Companies in Chennai said...

such a nice post…I liked it.. We are Event management companies in chennai and Event organizing companies in chennai. All the best for your future post..

Anonymous said...

ITIL іs absolutelу beсoming
a lot more νital in today's IT businesses around the world. I understand that, in my encounter, it does not constantly go 100 % to strategy - however thats the reason why Itil is only a framework I suspect.

Feel free to surf to my web blog :: itil training

Anonymous said...

Hi, i rеad youг blog from timᥱ to time and i own a similar one and i was just
wondering if you get а lot of spam reѕponses?
If so hοw do you prevent it, ɑny plugin or anything you can suggest?
I get so much ⅼately it's driving me cгaᴢy so any
assistance is very much appгeciated.

Alsߋ visit my homepaɡe - best running shoes for supination 2015