Can We Be Sarbanes-Oxley Compliant with Scrum?
by Paul Hodgetts, Agile Logic Founder & CEO
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.