There are couple of IT communities, namely architects and systems operators, which have the ability to punch a big hole through almost any IT or business control. They know flaws and potential breaches. Any architect worth their salt can create a material breach. They can also spot one. Practitioner experience should therefore be essential to pretty much any regulatory compliance or corporate governance initiative.
Compliance can’t be outsourced. Outside organizations, such as auditors, can help meet compliance challenges, but responsibilities can’t be transferred, which makes it critical to make the most of internal resources.
As one architect recently told me: “We’re struggling with SarbOx and compliance. What has happened is several consulting firms that have never done any coding now want to make lots of money out of auditing code.” Too much of the work of these people ends up creating “ceremonial” processes.
Architects should be brought in to compliance initiatives as professional skeptics. These folks know how the systems they watch can be compromised. They therefore must be included in any remediation programs. Architects can be a real pain. We know that. Developers certainly do. Architects always go on and on about… architecture, process and discipline. BORING. Well you know what? In compliance and governance boring is good. In fact boring is critical. Boring means less risk.
Meanwhile what do ops folks do? Manage uptime, right. Doh! No they manage data. That’s the stuff you run your business on. Thats the stuff you should be managing properly to protect from (increasingly severe) reputational damage or fines due to regulatory breaches.
The recent Bank Of America leak, in which 1.2m federal employee credit card details went missing, happened because backups were being shipped on tape on commercial airlines. Want to bet that senior folks in the organization had not talked to the back up team about approaches, controls and responsibilities? In fact a friend tells me the Feds *mandate* the use of tapes and sneakerware rather than networked backups. The truth is someone should have pushed back, should have been in a position to pushback against the Feds. That someone would likely be an operations person looking at the intersection of business process and data governance.
This pushback role is critical to compliance triage and cost management, especially when outside auditors are considered. The likes of PwC and BearingPoint provide opinions, not certified best practice guidelines, when they audit for Sarbanes Oxley 404, say. They dont indemnify or take responsibility, and may well give advice that an organization has every right to ignore. Senior architects and operations managers should be used to help parse what actually needs to be done.
Lines of business cut corners. That is what they do. That is why IT needs to be part of the governance dialogue. Some of the things that most annoy business managers about IT are the very same things that could keep them out of jail. Interestingly, this role is somewhat similar to the role architects are increasingly playing in Service Oriented Architecture projects. SOA is not just about funky new software; its primarily about discipline and portfolio management. Its about setting IT standards. SOA is thus at least partly an internal compliance effort, an IT Governance initiative. SOA gives LOBs the freedom to make their own development and application purchases, that comply with centrally determined infrastructure standards.
Chris Byrne points out that people with IT experience do not seem to be part of the compliance conversation.
One narrative that may help IT folks to talk more effectively to the business about SOA and compliance initiatives is Compliance Oriented Architecture.
I am talking about culture of compliance. You need people that won’t run off the cliff with the CEO. I am not talking about whistle-blowing but standing up for what is right. That is something in the architect mind set. It may be annoying, but its critical for compliance. Can your organization learn to love the trouble makers? The lone voices? If not your compliance initiatives are going to be less successful. This is not about ticklists, but doing what’s right.
James McGovern at the Hartford is doing some really solid work around COA – explaining why architects are crucial for compliance and business governance improvements.
Final words though–its no good waiting for the business to ask for your help if you’re in architecture and ops. Show willing. Start thinking about how you can help. Check out ITIL (ops) and Cobit (architecture)h
Cote' says:
April 6, 2005 at 2:22 pm
In general, at least in software, it’s always seemed like the tech-heads need more balls to push back. We have a bad tendency of just saying, “well, the biz people told me the requirements, I wrote to it, and now they get what they asked for…and they don’t get what they forgot to ask for that I knew they needed…oh well!”
That is, the tech folks still feel like they don’t need to concern themselves with the biz side of things. And, worse, the biz people seem to think the same thing: or, at least, act like they do.
And in the mean time, more and more middle-management/process is being layed-off peoplewise, and then process-wise, pushed down to the technical people. More responsiblity/work is pushed down to the tech workers, but equivilent authority isn’t. Or, at best, us tech-workers haven’t learned how to grab that authority. It’s rarely *given* in a company, afterall; it’s usually taken and *then* allowed to have been taken.
Compliance is just one way this more general problem is currently manifesting itself. The next time a “time-sensitive we gotta change our biz process” thing comes along, the same issue will re-surface.
Jaime Cardoso says:
April 6, 2005 at 6:45 pm
I really hope cote’s view on tech isn’t that general. Not so much time ago a diferentiator between the Unix admin and the Windows admin was that business concern we, the Unix folks, grew up having.
Anyway, James, I totally agree with you. but, the disregard for the compliance legislation isn’t that bad. Since forever, Managers disregard the technical input and, it’s the techs that pay for the foolishness. Now, it’s the same problem but, the managers also pay for not listening.
ericr says:
April 7, 2005 at 4:55 am
I’m currently working as an IT Auditor at a big public company. A few months ago, while trying to staff up a bit, the VP of Internal Audit and I discussed the proper qualifications for an IT auditor. I maintained that we need people with a strong sys admin & network background, preferably with security experience. I was told, and told strongly, that CPA’s would be preferred, as anyone can learn IT quickly, but it takes forever to get people trained as auditors. I look forward to testifying at the trials of our executives in the next few years…
RG says:
April 7, 2005 at 6:07 am
I’m also an IT auditor, but I work for one of the Big 4 accounting firms. I totally agree that hands on experience is necessary to truly understand IT controls. I’m a former system/security administrator. My colleagues without technical experience see everything as an administrative process. They have little ability to connect technical controls to administrative controls. In the years prior to SOX, my perspective fell on deaf ears. People are slowly getting it these days.
Regarding Ericr’s comment, I know that attitude all too well. Auditors are a strange breed of consultant, which in the end is a salesman who sells words. To be convicing the salesman must believe his own hot air more vigorously than his clients. From personal experience, IT auditing is dead easy. I learned it in just a few months. Now if you’re talking about how to write up findings without angering your client too much, that’s another story for another day.