Questions

How to handle "Unauthorized Changes" in ITIL

Tags:
+
0 Votes
Locked

How to handle "Unauthorized Changes" in ITIL

kennyt18
I'm just curious as to how other organizations handle "unauthorized changes" in their IT environment. In my work environment, when we detect an "unauthorized change", we just inform the employee that it was unauthorized and we ask for an explanation as to why he implemented the change without following standard ITIL procedures. We don't have any penalties for committing unauthorized changes. In rare cases, we ask the employee to reverse the change that he made.

How does your organization deal with "unauthorized changes"?
  • +
    0 Votes
    robo_dev

    First of all, is it possible for employees to make unauthorized changes? Seriously? You have no IT controls over changes? (I assume your business has no SOX or other regulatory requirements)

    Typically, things like software libraries, batch schedulers, or code repositories require admin-only rights to modify them.

    Typically, too, there is a change-management system of some sort, and manager and/or director-level approval is required before any change is performed. (and there must be a test plan and backout procedures)

    In every IT organization I have worked for, making unauthorized changes would earn you an escort to your car with your desk contents in a big box.

    +
    0 Votes

    SOX

    neilb@uk

    Doesn't actually get beyond your borders. The OP is Canadian.

    ITIL started in the UK so maybe it has got over to Canada. The guy isasking about what to do about unauthorized change in an ITIL environment and the answer is simple. Apply ITIL principles. Reverse the change immediately and then apply sanctions. If there aren't any sanctions then there is no control.

    +
    0 Votes
    JamesRL

    If a Canadian business is owned by a US company, than SOX is applied in Canada so that the parent company in the US is fully compliant. I know this from painful person experience.

    ITIL has been around in Canada for well over a decade, I used to get invites to conferences at a previous employer prior to Y2K. For a time it was the "flavour of the year", but I think its less enthusiaticallyy embraced as the cure all for all IT operational ills than it had been. Like anything else its a tool, one that can be used well or poorly.

    +
    0 Votes
    robo_dev

    there needs to be somebody actually making sure that the controls are working.

    Every organization is different, but the ones I have worked for have very strong controls regarding change management.

    +
    0 Votes
    neilb@uk

    that the OP's only chance is to make sure that - under whatever framework they apply for Change Management - the unauthorized changer gets his arse (or ***) thoroughly kicked.

    +
    0 Votes
    robo_dev

    Posterior Impact Management

    +
    0 Votes
    JamesRL

    ...pre ITIL btw, was a place that had all changes to the environment be reviewed at a weekly meeting. There being a defined amount of time that changes could be made during the week, everyone got together to agree on what changes should be made, when and in what order, with the goal of reducing risk and maximizing the amount of changes that could "safely" be made. So common sense things, like no system patches to the server the same week as a major application change, were brought to the fore.

    +
    0 Votes
    gevander

    I work in Change Management at a company that does ONLY what you have described your company doing - notify the person performing the change that they were wrong. That was only because we (Change Management) insisted. Recenty, we expanded that notification to the Change Owner and their manager. Now our Audit department has requested that we notify the Director as well.

    Previously, I worked at companies where the first mistake like that would get you a warning, the second would get you a reprimand in your permanent record (and possibly a loss of annual bonus) and the third unauthorized change would get you escorted out. That is, of course, if the change did not cause any Incidents or only a minor Incident. If the change caused a Major Incident or a Problem, you were done.

    Part of the problem for those of us in Change Management is our authority is derived from our management - we need their support to implement "punitive" enforcement measures. At my current company, that support is not there. One statistic we used to start getting more management buy-in is "80% of unplanned outages are due to ill-planned changes (operator/application errors) ??? Study by Stephen Elliott, IDC; quoted in Visible Ops, p 10". Unauthorized changes were our primary example of ill-planned work.

    Hope that helps.

  • +
    0 Votes
    robo_dev

    First of all, is it possible for employees to make unauthorized changes? Seriously? You have no IT controls over changes? (I assume your business has no SOX or other regulatory requirements)

    Typically, things like software libraries, batch schedulers, or code repositories require admin-only rights to modify them.

    Typically, too, there is a change-management system of some sort, and manager and/or director-level approval is required before any change is performed. (and there must be a test plan and backout procedures)

    In every IT organization I have worked for, making unauthorized changes would earn you an escort to your car with your desk contents in a big box.

    +
    0 Votes

    SOX

    neilb@uk

    Doesn't actually get beyond your borders. The OP is Canadian.

    ITIL started in the UK so maybe it has got over to Canada. The guy isasking about what to do about unauthorized change in an ITIL environment and the answer is simple. Apply ITIL principles. Reverse the change immediately and then apply sanctions. If there aren't any sanctions then there is no control.

    +
    0 Votes
    JamesRL

    If a Canadian business is owned by a US company, than SOX is applied in Canada so that the parent company in the US is fully compliant. I know this from painful person experience.

    ITIL has been around in Canada for well over a decade, I used to get invites to conferences at a previous employer prior to Y2K. For a time it was the "flavour of the year", but I think its less enthusiaticallyy embraced as the cure all for all IT operational ills than it had been. Like anything else its a tool, one that can be used well or poorly.

    +
    0 Votes
    robo_dev

    there needs to be somebody actually making sure that the controls are working.

    Every organization is different, but the ones I have worked for have very strong controls regarding change management.

    +
    0 Votes
    neilb@uk

    that the OP's only chance is to make sure that - under whatever framework they apply for Change Management - the unauthorized changer gets his arse (or ***) thoroughly kicked.

    +
    0 Votes
    robo_dev

    Posterior Impact Management

    +
    0 Votes
    JamesRL

    ...pre ITIL btw, was a place that had all changes to the environment be reviewed at a weekly meeting. There being a defined amount of time that changes could be made during the week, everyone got together to agree on what changes should be made, when and in what order, with the goal of reducing risk and maximizing the amount of changes that could "safely" be made. So common sense things, like no system patches to the server the same week as a major application change, were brought to the fore.

    +
    0 Votes
    gevander

    I work in Change Management at a company that does ONLY what you have described your company doing - notify the person performing the change that they were wrong. That was only because we (Change Management) insisted. Recenty, we expanded that notification to the Change Owner and their manager. Now our Audit department has requested that we notify the Director as well.

    Previously, I worked at companies where the first mistake like that would get you a warning, the second would get you a reprimand in your permanent record (and possibly a loss of annual bonus) and the third unauthorized change would get you escorted out. That is, of course, if the change did not cause any Incidents or only a minor Incident. If the change caused a Major Incident or a Problem, you were done.

    Part of the problem for those of us in Change Management is our authority is derived from our management - we need their support to implement "punitive" enforcement measures. At my current company, that support is not there. One statistic we used to start getting more management buy-in is "80% of unplanned outages are due to ill-planned changes (operator/application errors) ??? Study by Stephen Elliott, IDC; quoted in Visible Ops, p 10". Unauthorized changes were our primary example of ill-planned work.

    Hope that helps.