On Tue, Nov 18, 2008 at 12:36 PM, <[EMAIL PROTECTED]> wrote: > my security team is currently recieving ~500 change tickets a month (not > counting patching, upgrades, etc) with a 2 business day SLA to complete > them. we are getting a lot of people screaming that we should be more > responsive and implement the changes faster. > > I'd like to hear from other folks as to what sort of change rate and > schedule is considered reasonable for large orginizations. I'm especially > interested in hearing from anyone in the financial sector.
Can the tickets be categorized into 5-15 different "types" so that you can assign different SLAs to different requests types? Is there any way to make the process more self-service? For example, could the customers be given a dashboard that lets them control the more simple requests (add/change a single machine)? If the requests currently come in via email, could they instead use a web-form that would sanity check the request, possibly run it through a regression test suite, then just simply ask for a human to approve it? Could you delegate some of the control? For example, if these requests come from all over the company, maybe each division could have an "approver" that is able to aprove the common requests, leaving you to only have to deal with the special cases? Is there a class of request that the helpdesk could be empowered to handle on their own? For example, if some of these requests are password resets, you could permit helpdesk people to follow a very spelled-out procedure to do resets for, say, accounts of non-managers and non-executives. These are just the thoughts that come to mind without understanding who the customers are or what constitutes a "security request". If you are allowed to be more specific (I understand if you can't) please do. Tom _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
