I did a little bit of investigating (brainstorming really) recently for a client on Sarbanes-Oxley (SOX) issues with Scrum. I didn't get to see it through to an audit, and I'm hardly an expert on Sox compliance. But, in case it helps, here's some results of that thinking...

At it's core, SOX requires that an organization maintains adequate controls over financial data and its access across the organization. The infamous section 404, requires that CEOs and CFOs sign off on that, with severe penalties if they are wrong. There's nothing like a scared CEO to make the development organization scramble in their wake.

There are a lot of things about SOX compliance that I don't think affect the Scrum development team directly, like making sure we have backups of data, and security controls, etc.—more IT operations kind of things. If these things spawn off requirements for the systems we build, then of course the team has to build to those requirements (see below).

One area of SOX compliance is making sure the financial info that a company uses is consistent and correct. For software, this is more an issue with what systems are in place, and how these system store and access financial data. These types of requirements would of course feed things into Scrum backlogs, perhaps affecting the Product Owner's work, but has less to do with the development process itself.

A second area is making sure the systems, once we have the proper requirements figured out, actually function correctly when working with the financial data. Scrum does not specify testing practices, but the spirit of Scrum asks us to provide a measure of completeness for backlog items, which of course implies testing. If we use agile acceptance testing practices to build a solid, automated testing safety net around our backlog items, it makes proving the correctness of financial systems a whole lot easier, and auditing for correctness pretty straightforward. But IMHO, we have to raise our level of acceptance testing to a pretty high level (we have to raise our level of testing to a high level no matter what process, IMHO).

A third area is controlling changes to the financial software systems, so that we can prove that we're not altering the functionality or correctness of them without some level of control over those changes. Fortunately, Scrum (and most all agile processes) already provide a pretty good level of scope control via the product backlog and sprint backlog. I think we'd have to provide some more ceremony around backlog change, like sign offs or something, to provide the auditor with the evidence that changes are not being made without controls. It would put some extra hoops in place for developers when they want to refactor code—I would guess we'd need someone on the technical team to sign off on refactorings. Maybe pairing with such an authorized person would help?

I think these general approaches also help in thinking about how to comply with other regulated environments, like FDA or HIPAA. As with those environments, many people interpret the SOX regulations as requiring a particular type of development process, but from talking with a couple of knowledgeable folks, it seems it does not—it only asks for certain levels of controls and auditing. The problem is that a scared CEO/CFO may go overboard to protect their interests, and may end up buying into one of the expensive, heavyweight compliance solutions that dictate process things they don't need to.

As I mentioned, I didn't get to see if our investigations resulted in a SOX-compliant Scrum-like process or not. But the talks with some more knowledgeable SOX folks were promising, so I think we were headed in the right direction and it would be very possible and not too painful to pass a SOX audit with a process based on Scrum with some added formality and ceremony. Maybe we'd be a bit less agile, but it shouldn't hurt the core agile values and strategies.