.Net Application Deployments and SOX 1695



  • I am an Ops Manager for a Software Dev department. I come from 13 years infrastructure experience and some of what these auditors want to see is very odd to me. Here is where I need help:
    The auditors want to see seperation of duties. That makes sense to me. On my team I have 2 engineers and during any regular or emergency deployments they take the code, compile it, enter it into QA and if passed by QA deploy it into production. These engineers do not write code but because they have ‘access’ to the development system the auditors don’t like it. Has anyone had to deal with something like this and if so what have you done to remedy the situation?
    The other thing they want to see is every file deployed being tied into a problem ticket or documented project. So if I deploy the new app.dll file I need an audit trail of that file (among others) back to a valid ticket or project. I havent the slightest idea how to trace back something like that. Any help would be greatly appreciated.
    Does SOX apply to every application that you write or just those applications that relate to financial data? Some of the applications and deployments that our auditors look at puzzle me since they don’t seem to have anything to do with how the company reports earnings. Is there a rule of thumb here?
    As you can tell Im a bit of a novice so any help you guys could give would be greatly appreciated. Thanks in advance…
    djc



  • Is it necessary for your engineers to have access to the development system? If not, it’s easier to remove it than to argue with the auditors (believe me, I’ve tried).
    If yes, and you don’t manage to convince the auditors, you need to come up with some other mitigating controls.
    Is this QA a system or a function performed by another individual? If it’s just a system, then I can see the auditors issue, however, if this is a second pair of fresh eyes testing it, then I would argue that this is a review and acceptance control.
    I don’t think they’re looking for something hard coded into the system when you create a .dll - I would imagine they’re looking for some evidence of all the steps that would lead to the final file being deployed.
    At our company we have a software request database, that takes us through all the steps from request via business case, use case, development, testing, etc. This would be our ‘audit trail’ in your case.
    Financial Applications are the only applications they should be considering, yes. Our auditors started with a scope of 150 applications… it’s now 18 🙂



  • My knowledge of the requirements for segregation of duties would only apply where there was a risk to the accuracy of financial reports.
    COSO (www.COSO.org) have recently issued guidance for internal controls for financial reporting in smaller companies, and have stated that where segregation of duties cannot be fully implemented due to small staff numbers, the risk can be compensated by detailed reviews of reports, transactions, and reconciliations by Management. I’m not sure how this can be applied to your systems, but if it can, it may be worth suggesting such an approach to your auditors and asking for feedback.
    I would agree that it should only be systems effecting financial reporting that are key to sox. Our auditors have suggested implemenation of operating controls as key controls, but have accepted our comments that as they do not affect financial reporting, they are not applicable to Sox.



  • Is it necessary for your engineers to have access to the development system? If not, it’s easier to remove it than to argue with the auditors (believe me, I’ve tried).
    If yes, and you don’t manage to convince the auditors, you need to come up with some other mitigating controls.
    Is this QA a system or a function performed by another individual? If it’s just a system, then I can see the auditors issue, however, if this is a second pair of fresh eyes testing it, then I would argue that this is a review and acceptance control.
    I don’t think they’re looking for something hard coded into the system when you create a .dll - I would imagine they’re looking for some evidence of all the steps that would lead to the final file being deployed.
    At our company we have a software request database, that takes us through all the steps from request via business case, use case, development, testing, etc. This would be our ‘audit trail’ in your case.
    Financial Applications are the only applications they should be considering, yes. Our auditors started with a scope of 150 applications… it’s now 18 🙂
    The original purpose of these engineers was to take the code from developers, compile it and deploy it. They don’t develope code but they are the gatekeepers of it. Upon submitting to QA, they are actually sending to a separate set of people who handle this function. After it passes QA, the QA team will give the files back to the engineers who will then deploy into production.
    We have an object access report that shows files accessed or modified in production on a weekly basis. The auditors want to see 2 things: 1 everytime something in production is accessed that there is a legit ticket or project for it and the correct person is making the modification and then they want to make sure that the file is the correct one to address the ticket or project. So if my ticket requires an update to app1.dll they want to make sure I’m not updating app2.dll and some sort of audit trail for that. This is the oddest request yet and I haven’t the slightest idea how to implement something like that.
    Thank you very much for the help.



  • Hi DJC and welcome to the forums 🙂 Below are a few ideas:
    The auditors want to see seperation of duties. That makes sense to me. On my team I have 2 engineers and during any regular or emergency deployments they take the code, compile it, enter it into QA and if passed by QA deploy it into production. These engineers do not write code but because they have ‘access’ to the development system the auditors don’t like it. Has anyone had to deal with something like this and if so what have you done to remedy the situation?
    As a compromise, I wonder if the Auditors would be satisfied with read-only access or logged full QA access. Hopefully, you shouldn’t have to hire more folks. Also, the use of tools like Visual Source Safe or other source management products might help set up a promotional system where you can promote source code from development to QA to PROD in a manner that satisfies audit.
    The other thing they want to see is every file deployed being tied into a problem ticket or documented project. So if I deploy the new app.dll file I need an audit trail of that file (among others) back to a valid ticket or project. I havent the slightest idea how to trace back something like that. Any help would be greatly appreciated.
    On a DLL level that might be too detailed and the source management system might help better track these changes rather than keying it into a ticket or change management system manually. Certainly the change management process is needed to formally denote application changes to affected parties, but I see this at a macro level.
    Does SOX apply to every application that you write or just those applications that relate to financial data? Some of the applications and deployments that our auditors look at puzzle me since they don’t seem to have anything to do with how the company reports earnings. Is there a rule of thumb here?
    While they apply to Financial systems, you’re best served having one standard set of procedures and not multiples – where you can. For example, you want the best levels of security controls to protect everything. If financials can’t be broken into but other apps can, then the bad guys might be able to hop over into the financial systems through other this ‘open door’ in security controls.
    Finally, you also want a single documentation, production release, and chanagement system for folks to follow also, rather than one for SOX and one for non-SOX. Multiple standards would create confusion and inefficiencies.



  • The other thing they want to see is every file deployed being tied into a problem ticket or documented project. So if I deploy the new app.dll file I need an audit trail of that file (among others) back to a valid ticket or project. I havent the slightest idea how to trace back something like that.
    djc
    Just raise a ticket for every deployment. Document the project or enhancement ID along with the approval for deployment in the worklog of the ticket.

    Does SOX apply to every application that you write or just those applications that relate to financial data?
    djc
    That depends upon which applications you have considered in scope for SOX.


Log in to reply