I have been to a few customers who have implemented or are implementing Sarbanes-Oxley (SarbOx or SOX) compliance in their development processes using VSTS. Andrew Delin from the VSTS Process team is creating a whitepaper on how to do that with VSTS. In the meantime, here are some reflections based on my personal work with this topic so far.

[The next is a PPT-like intro to the topic. For those who know what SOX, you can skip it].

What is SOX?

  • Federal legislation signed into law in July 2002
  • It requires higher accounting standards, improved trustworthiness in corporate reporting, and greater financial transparency
  • Two key sections of the law that have drawn the most attention
    • Section 302: Requires executives to personally certify the validity of financial statements
    • Section 404: Requires complete documentation of financial controls and auditor attestation to management's evaluation

Section 404

Requires “an internal control report, which shall

1) State the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting;

and

2) Contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.”

[end of introduction]

Ok, given this very brief summary, I can now tell you that the best general guide I have found so far to understand how to implement SOX in an IT environment is "IT Control Objectives for Sarbanes-Oxley, 2nd Edition".

image 

This book explains the rationale for establishing the controls needed from the IT perspective, starting with SEC's own recommendation:

"Historically, assertions on control by an organization have been mostly voluntary and based on a wide variety of internal control frameworks. To improve consistency and quality, the SEC mandated the use of a recognized internal control framework established by a body or group that has followed due-process procedures, including the broad distribution of the framework for public comment. Specifically, the SEC referred to COSO".

and

"For Sarbanes-Oxley compliance efforts, it is important to demonstrate how IT controls support the COSO framework. An organization should have IT control competency in all five of the components COSO identifies as essential for effective internal control. They are:
• Control environment
• Risk assessment
• Control activities
• Information and communication
• Monitoring"

How does that relate to the normal IT framework controls that we are used to, such as ITIL/MOF, and SDLCs such as MSF for CMMI Process Improvement?

Here is a short summary plot:

  • SOX recommends COSO per SEC
  • COSO maps to COBIT (Control Objectives for Information and related Technology) standard
  • portions of COBIT map to relevant parts of CMMI
  • other parts of COBIT map to ITIL and other IT management standards

Said in this way it would seem that by implementing ITIL/MOF, and by using MSF CMMI as the standard SDLC, we would be covered in SOX compliance. This seems like a lot of overhead. However, you don't need all that, as we will see next.

SOX is about financial reporting

This was very eloquently mentioned by Dave Erickson:

“Sarbox is about assessing risk. While risk assessment is an element of ITIL, it isn’t the framework’s primary focus. Furthermore, CIOs who put ITIL or any other IT framework in place solely to comply with Sarbox will have gone overboard, says Erickson. The Sarbanes-Oxley Act requires only that companies establish controls over the systems relating directly to financial reporting. ITIL, Cobit and other frameworks for IT help companies put in place general controls for IT—a good thing to have, but much broader than the narrow scope required by law.”

So one of the first things that needs to be established from an IT perspective is a control that identifies the application being developed as impacting financial reporting. These type of applications will need to follow SOX constraints. Other types of application do not need all the overhead, especially if you are doing Agile development.

Usually SOX compliance teams will keep their own database of such applications. In VSTS it is possible to create a work item to identify those for reporting purposes. That would be the first of several work items that might be needed for SOX compliance.

So given that part of what is needed in already in the MSF CMMI template, it is clear that a few items need improvement. Remember that this just a sample of what might be needed, not a comprehensive list:

  • Strategic planning alignment
  • Risk management process
    • We need to add risk reports per project and across portfolio (slice risk management by financial management applications)
  • Traceability
    • We need to implement reports that show traceability of work items that impact financial reporting. This will be easier to do with
      • Adding new fields to work items (such as a task work item with a tag “SOX regulation” )
      • Adding work items that have have more workflow steps to deal with regulations
  • SCM (as part of change management)
    • Add work items that correspond to checkpoints for branching (see article by John Jacob et alii on branching guidance)
  • Audit trails
    • Have additional reportable fields, pivoted with the SOX attribute, and provide more reports for auditors
  • Security
    • Existing process guidance already handles part of this, but it is not enacted in tooling
    • We need to implement Secure Development Lifecycle with work items as checkpoints, and corresponding work products and reports

As mentioned above, another big part of SOX compliance is covered by ITIL/MOF. I won't go into the infrastructure topics per se (see the book above for that), but there is one clear common implementation point with VSTS/TFS/MSF CMMI in security groups. Segregation of duties is mandated by SOX. However the currently default process template security groups are loosely defined, allowing persons without the proper authority to review/modify documents.

  • The full implementation of security model described in MSDN documentation is a solution.
  • Reporting needs enhancement to provide evidence of compliance showing that groups are separated in their duties.

Finally, part of SOX compliance is covered by IT Portfolio Management. Therefore, reporting needs enhancement to provide evidence of compliance using, for instance, a portfolio view of a dashboard showing compliance status. This view could used departments as pivots.

So as I mentioned above, these are just initial thoughts in a very complex topic. Andrew Delin and the VSTS Process team are working on getting more comprehensive guidance on how to tackle this subject.