SOX _and_amp; Change Control _and_amp; SDLC 381

  • Does the SDLC documentation process have to be changed to reflect the SOX 404 requirements and if so which step in the process does this occur? Also, how about Change Control? I am relatively new to this and I am looking for any advice on these topics. Thank you.

  • This post is deleted!

  • This post is deleted!

  • This post is deleted!

  • This post is deleted!

  • No, but you should have a documented SDLC process and effective controls within it. If can’t prove that the controls you have within the process are effective, then you may have to change something.
    You also should have a look at the ‘IT Control Objectives for Sarbanes Oxley’ doc. at the isaca homepage.

  • Your SDLC process documentation MAY have to change to satisfy SOX. Look at the document Holger refers to and this will tell you the control objectives that are pertinent to SDLC, it may be that you do have to formalise your docuementation of various aspects of the process - in fact based on other projects I’ve worked on I would go so far as to say it is likely.

  • Hi:
    As part of Application Controls within General IT Control’s framework- there are significant controls that are embedded within a company’s Software Development Methodology.
    As far as Sarbanes is concerned, IT General Controls are usual target of an auditor. If the your company has a large development environment, or if your key (home grown/ if you have access to the source code) applications are contributing to the Company’s financial reporting systems then you have a bigger burden to gear towards the SOX 404 testing.
    From IT Audit stand point the first place for software life cycle testing is company’s SDLC methodology. In my experience, some of our clients had no SDLC methodology, some had good ones and some had proudly wanted to adopt the best methodologies from the web etc,.
    However the most important thing is, SDLC could be a just methodology or a guideline. It may not substitute a well-defined policy and procedure for developing and maintaining the software applications within a company. Auditor would like to request policy and procedures as typically these would have inherent controls built in them. Auditors can test the design effectiveness of these procedures and then move on testing the operational effectiveness of these procedures.
    In case if the company does not have separate policy and procedures, but have adopted a SDLC methodology, auditors will evaluate the same and come up with controls that are mentioned within your SDLC and then when they audit your applications - they expect that all the processes within your application cycle are strictly adhere to your SDLC.
    In my experience, some companies have adopted best of the SDLC methodologies- however the development teams have not followed such methodology. This could lead to a potential control breakdown and failure in audit testing.
    The general SDLC controls within Sarbanes perspective include

    1. Documented policy and procedures
    2. Developers/ IT managers are trained on the procedures
    3. Standard controls such as business owners approve the design,
    4. Development is carried over as per standards, functional specifications
    5. Separate test environment for development/ test/ production / test plans
    6. Segregation of duties ( The developer who created and cannot pass his own test, cannot promote the code to production etc)
    7. Business owner’s testing and approval before changes/ app goes into production
    8. Good Version Control Program to ensure that older versions are kept available
    9. Source Code is properly secured
    10. Built in user access controls for authentication and prevention of fraud.
      I hope the above information is useful to you. If you have any questions, please refer them in this forum, or drop me an email.
      Madhav Vedula CISA
      Sr.Internal Audit Consultant

  • If an SDLC policy/process document fails on Design Effectiveness, can that lead to a significant deficiency ?
    How would the auditors test on whether the developers/IT managers have been trained on the procedures ?
    For example, if an organization has a policy/procedure document, which was been formally sent out to a selected group of IT people (primarily managers), BUT not posted /available at a place whether all other IT personnel can view it, would it be considered as failing this test ?

  • Good Question …
    While reviewing the design effectiveness of controls - auditors would look for existence of good policy and procedures as part of their audit.
    In an ideal control environment within SDLC:

    1. Management has identified and designed best practices within SDLC - to satisfy Change Mgmt and IT Security controls that are embedded within the SDLC
    2. P and P are distributed to all IT Personnel and related business entities
    3. Specific training is provided to all programming staff to follow and implement the SDLC procedures as identified in the document
    4. Managers will ensure that the controls embedded within SDLC are generally followed and evidence/audit trail is created.
    5. Periodic review process is in place to ensure that the programming staff is following the SDLC Procedures.
      ----------- Needless to say auditors do not have a specific test step for all the controls that are mentioned above. However, please do remember that Auditors interview managers and may interview the programming staff as well. The outcome of these discussions can be used as a material for forming the audit opinion.
      Sample Scenario: Let us assume that XYZ Company has hired a good consultant to write a great P and P doc on SDLC that depicts the controls that I mentioned above.
      Scenario -1 - If the P-and-P doc does not have minimum controls as mentioned above - that situation may be qualified as a design gap
      Scenario 2 - If we take a scenario - where in the above mention controls are written within the P -and-P - it may pass a design effectiveness test.
      Scenario - 3 - If the client passes Scenario -3 , however Auditor through his/her observation and inquiry - noted that the programmers do not have the P -and-P, never trained on it - or weven worse - these controls are not often followed. In this case - this is an operational deficiency - based on what systems, to what extent, are compromised- given the poor control environment- this could lead to a significant deficiency - or even a material weakness.
      If you have any questions, please feel free to contact me at
      Madhav Vedula CISA
      Sr.Internal Auditor

  • Something to consider and evaluate:
    If your client has to update their SDLC for SOX compliance then it is likely that they won’t have enough evidence or cycles to prove they are operating effectively with the revised SDLC policy/procedure. I’ve seen companies rush to slam something in and the fail the test of operating effectiveness because no one is following the revised SDLC.
    I think to put this in perspective a bit, it may be helpful to understand the categories of projects currently underway (new dev, packaged impl, maintenence, bug/fix-emergency change, etc.) and the number in each category.
    If you find they don’t have a lot of big projects or new development going on then you may want to consider putting together a remediation plan for fixing the SDLC. It is important to consider the types of projects and their size as well as complexity in terms of what the requried deliverables and sign offs are for SDLC. Most SDLC have a small, medium, large flavor to them as well as a path for maintenance and packaged implemenations. For example, a new report program may not require integration testing like an online and batch program would. You may implement part of your remediation plan this year (assuming you have a good chance to prove it working and the part you fix maps really well to the types of projects you are currently doing) and some next year. Its a balancing act.
    If I know for sure that I’ll fail on test on operating effectiveness, then why not take a step back and design the process, policy, and procedure correctly in the first place rather than pretend it should be working.

Log in to reply