My first point is that what really matters is what the external auditors tell your CIO about the current state and the level of control on your change management process and tool. What we think or would like to think has minimal weight compared to the audit report that gets forwarded to the head of your IT organization.
Auditors do not like enforcement of separation duties to be subjective: they like objectivity, they like the tool enforcing the rules: that is the aim. Case in point: the change manager as defined in the Remedy change mgmt app (and I think the change assignee too) can approve or reject an approval for the change: this is not good from an auditor perspective. We can think whatever we want to think about this, but they don't like the fact that the change manager (as defined in the application) can approve the change, if we wants. The auditor will tell you something like: Why is "Joe" being allowed to approve the change (if he wants to) for financial application "Big Bucks", that already has predefined approvers? The second thing they are going to ask you is proof that good ol' Joe did in fact not approve/reject any changes for the "Big Bucks" app, so now you have to produce reports to the auditor proving that. My second point is that, As said in my previous reply, one of the most important SARBOX rules is that you cannot approve and implement a change for a financial application. Nothing in the OOTB ITSM implements this from either a configuration or application code perspective: OOTB, any person can have all the roles of app: change requester, change assignee, change implementer (or task assignee) and change approver. In the end what matters is what the auditors think, not the Remedy administrator/developers; it may be unfair but it's that simple. Guillaume ________________________________________ From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Marsh, Lee [lee.ma...@usdoj.gov] Sent: Monday, March 29, 2010 11:40 AM To: arslist@ARSLIST.ORG Subject: Re: Change Manager - Change Implementer Can't you still separate roles using Remedy change configuration rules, approval mappings, and AP-administration? The software is not the process nor does it control the process. The organization still has its own processes and rules. ITSM is a way to capture the data for service management purposes. For example, you can implement an organizational policy that says financial changes have to have a particular approval from a particular non-IT, accounting staff member. His signed authorization is a required approval for anyone in IT implementing that change. I don't see where Remedy ITSM is not SARBOX compliant. It supports SARBOX policies and processes which is what you want for an IT Service Management package. You want to have historical record of the changes to all the systems and how they were implemented. The degree and complexity of SOD is up to the organization, its structure, and its business needs. ITSM just records and helps automate the capture and processing of the service and process related data. For example, if your accounting application development team propose a change, Remedy CM is there to record the reviews and approvals by the parties. I would assume it would include your IT technical staff but would also include your accounting staff. The accounting staff may also want an outside auditor to review and approve the change. ITSM CM would capture the process related data. It can organize the related communications in the work information records and capture the dates and times the approvals are processed. A change review board can pull up copies of all the various ITSM CM records related to the change process, review them for approval and risk management. SarbOx is not my area of expertise so maybe I'm missing something. Lee Marsh. ************************************* Lee Marsh Remedy Administrator BAE Systems Office Automation Systems Team Antitrust Division, U.S. Department of Justice Phone: 202-305-9725 Cell: 202-528-1749 Email: lee.ma...@usdoj.gov ************************************* From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Monday, March 29, 2010 10:42 AM To: arslist@ARSLIST.ORG Subject: Re: Change Manager - Change Implementor ** Now, the ironic thing, is that for organizations to be SARBOX compliant, they need to implement a change mgmt process (and tool therefore), which would be ITIL compliant. but OOTB, the ITIL tool is not SARBOX complaint!! so we're coming full circle. Ironic isn't it? _____ From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Guillaume Rheault [guilla...@dcshq.com] Sent: Monday, March 29, 2010 10:41 AM To: arslist@ARSLIST.ORG Subject: Re: Change Manager - Change Implementor ** Financial applications are defined in our environment as Application CIs. These applications run on databases and servers which are also in the CMDB. So here is a very simple scenario: If you follow Sarbanes Oxley rules, you cannot approve and implement changes for financial applications: these two duties (or roles) need to be segregated If you make a change against a database that stores the data for financial applications, same thing. If you make a change for a server that runs financial applications, same thing So issue is not ITIL "proper", it is the regulations that need to be adhered to such as Sarbanes Oxley. Guillaume _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
