Dealing With Compliance Overreactions

I enjoy and highly recommend Dave Nicolette's blog on Agile software development.  In a recent post, Dave takes a stand on software development practices with respect to financial/corporate transparency laws such as Sarbanes-Oxley (SOX):

"When we have mentioned the idea of collapsing an organization to bring Business Analysts, Software Developers, and QA Testers together to facilitate the agile working style, one of the arguments raised by opponents is that Sarbanes-Oxley requires separation of duties. Following up on this a bit I found various explanations of "separation of duties" such as the excerpt above. Clearly, the intent is to reduce the chance of fraud by ensuring more than one person is involved in any work that has to do with financial transactions or financial data management. This is definitely not the same concept as separating work on a software development project along the lines of work functions, such as "analysis" vs "coding" vs "testing". There is nothing in Sarbanes-Oxley that would preclude the establishment of cross-disciplinary agile teams for software development projects, or the elimination of the batch-and-queue or "waterfall" approach to requirements elaboration, software design and construction, and testing. On the merits, Sarbanes-Oxley does not support this sort of argument against changing the organizational structure to improve the effectiveness of IT."

What Dave is referring to here is what I define as Compliance Overreaction.  When dealing with SOX (or its US federal  government analogue OMB Circular A-123) compliance,  we oftentimes find that someone or some entity (usually in the business) is making demands for radical shifts in  development processes, procedures, or techniques in the name of "compliance.' After analysis, the situation in fact is that as long as satisfactory IT production standards are followed (e.g. developers cannot access the production instance directly or through 'back-doors'), little if anything in development procedures or environments must be changed to achieve or maintain regulatory compliance.

Buying-in to compliance overreactions has value only to the requestor's position or piece-of-mind. The downsides to the organization and its people are many: convoluted development and production processes; increased costs and time to develop, deliver, and maintain systems; and little real benefit from any perspective to the business and its compliance functions.

Compliance overreactions are oftentimes implemented because of the potential consequences of non-compliance, particularly those such as criminal convictions, prison sentences, and heavy fines to the organization or individuals. I've seen such potential outcomes used as a blunt object to advance someone's position on system requirements and delivery/production issues. Analysts and other IT folks oftentimes don't know any better, and take the request on good faith that the requester is an expert on such matters and knows what they're doing and talking about.

In the requirements phase of projects supporting or subject-to compliance mandates, it's important to discern requirements that are reasonable with respect to satisfying mandates and when, uttered in the name of 'compliance,' the requirement is simply pushing someone's agenda, misinterpretations, or fear of the unknown.

Admittedly, this is difficult to do in practice without becoming a regulatory expert, but in organizations subject to regulation, someone in the IT function should be as up-to-speed as possible on compliance issues as they directly affect IT. When there are requirements and issues that can potentially be termed an overreaction, it's dealt with in a manner that gives the best benefit to the organization and maintain real compliance with law and regulations.

When I delved into these issues sometime ago for a government client, I developed a two-pronged approach to these issues that is very similar to some of the attributes that Dave mentions in his post:

1. A 'real' regulatory or compliance requirement affects the workings and data of a production system used to run the matters within the business of direct concern to regulators and auditors. For example, it's reasonable to expect that live and archived data subject to compliance has specific audit-related attributes, such as logging who entered, changed, read, or deleted specific data and when they did it.
2. A perceived requirement that could lead to an overreaction of little benefit extends such practices to almost everything, including procedures and systems that are outside of the scope of regulatory and compliance functions. SOX and A-123 deal with financial reporting systems, but I've witnessed arguments that systems involved with producing revenue should also be subjected. My rule-of-thumb here is that if the system doesn't directly hit the general ledger or balance sheet, with no intermediaries, the requirement needs further investigation and analysis to guard against the costs of overreaction. Obviously, there are exceptions to this, but they're too detailed to discuss in a blog post.

Finally, as if SOX and A-123 weren't enough for IT to digest, another compliance elephant entered the room last month when the Federal Rules of Evidence were changed to expand the scope of what is 'discoverable' in civil cases that come before the federal court system in the United States. It used to be only e-mail and paper documents, but the latest changes extend that to instant messages, data on mobile devices such as cell phones and PDAs, and basically any electronic device used in corporate settings. I'll have more specific commentary on this later, as it presents a whole slew of new issues and problems for IT.