Plastic SCM (Software Configuration Management) can facilitate your compliance with the Sarbanes-Oxley Act of 2002. How? Plastic SCM uses automation and auditable change tracking to help eliminate human error and criminal intent within the software development process. It allows you to:
In 2002, President George W. Bush signed the Sarbanes-Oxley Act of 2002, commonly called SOX or Sarbox, into law in response to large-scale financial scandals at companies like Enron. Investors lost billions of dollars over these scandals and therefore lost confidence in the market, causing an economic downturn. To restore investors' confidence, Sarbanes-Oxley was enacted to monitor corporate financial reporting systems and provide an audit trail to ensure accountability.
For those of us in the IT sector, we mostly have to worry about Section 404 of Sarbanes-Oxley, titled Management Assessment of Internal Controls, which stipulates that internal control structures be established, implemented, and assessed on an annual basis. What's an internal control? It's any process that helps a company achieve certain goals. For example, pertinent to Sarbanes-Oxley, code review is a process that helps achieve a stable and secure code base, so it qualifies as an internal control. The act requires that you not only have internal controls in place, it requires that they be auditable. That's where Plastic SCM comes into play.
Plastic SCM changes the way that you manage your application development through branch promotion. How? For every new task that you start in your coding process, you create a new child branch off the parent branch. Just need to fix a typo? Create a branch for that. Need to fix an important issue in the database code? Create a branch for that one, too. Every child branch, before being promoted, is independently reviewed and promoted only when testing has been completed. Incomplete or untested branches do not affect your ability to create a new release. For every changeset you check in to your task branch, and for every promotion you perform, Plastic SCM keeps a permanent record. If there's a problem with the code, Plastic SCM can tell you exactly who broke the code, when, and on what branch. In version 4.1, we've also added an audit trail to the server that logs every change made to other objects in the system. If you create a branch, delete one, or change the owner of an object, for example, those actions are recorded in the new audit trail feature. Also, every file that's added, deleted, moved, or changed as part of a check-in is logged in the trail as well. Plastic SCM forces developers to leave an auditable trail, which is precisely what Sarbanes-Oxley demands.
With Plastic SCM, you can set triggers to enforce company Sarbanes-Oxley compliance policies. For example, every time you execute a merge to promote the code to the main branch, you can have Plastic SCM run a series of custom validation tests on the code. If there were changes made to the financial reporting system, you can have an email automatically sent to the developer's designated manager and the Financial Controller (or whoever you want) alerting them of the exact changes that were made, by who, when, and on what machine. You can also tell Plastic SCM that if changes were made by a new hire, the code must be sent to a senior developer for code review. The possibilities for triggers are endless.
After you complete code reviews and the code passes all of your automated tests, you'll need to build the release. Plastic SCM can utilize build automation, which is key to compliance, to ensure that your build is not tampered with. Plastic SCM works with popular build automation software to build the code. The code is automatically built – a totally hands-off process – so that when auditors ask their questions (Who had access to what? What changes were made? When? Why? Where?) you can answer confidently that there are computer records of all changes and that the final build for your financial reporting software was untouched.
Let's talk more about those questions that the Sarbanes-Oxley auditors will ask. Protocols for developers'
access to the code will be an important part of their investigation. Plastic SCM makes that an easy answer
by allowing you to
In the same vein, Plastic SCM can limit the number of people with permission to promote child branches to the main branch by assigning promotion rights to groups of authorized users. This restricts any unauthorized person, such as junior developers, external personnel, or non-integrators, to making changes only on child branches. Integrators, or more senior developers, can then review all changes before they are merged into the mainline for production. If, for some reason, an unauthorized person had intent to tamper with the financial reporting software, this makes it so he or she wouldn't be allowed to alter the mainline in any way. Their changes would be reviewed by an integrator, and any errors or criminal intent would be discovered before it affected the mainline or the release. This internal control looks great on an auditor's report.
And then there's the grand finale: If, somehow, all of these internal controls fail and bad code gets promoted to the mainline, Plastic SCM allows you to quickly and easily roll back changes to a previous version that's known to be stable and secure.
Sarbanes-Oxley requires that every public company have an auditable system of internal controls to safeguard financial reports and therefore, investors' money. Unfortunately, for most companies, this is the most expensive part of complying with the law. Not for Plastic SCM users .
For one price, you get all of these features and more, which help you effortlessly and inexpensively comply with Sarbanes-Oxley. The bottom line is that Plastic SCM helps your bottom line. Talk with us today about how we can help you save your company time and money while simultaneously increasing compliance with the Sarbanes-Oxley Act of 2002.