The Chicken, the Egg, and Change Management Over the past couple of years, I’ve talked with dozens of data architects and DBAs about how new compliance requirements affect how they do their jobs, design controls, provide documentation, and show proof of compliance. Several themes have emerged. Here’s one:
“Why don’t they get us involved before they make final decisions? Some of the controls they want and the ways they want us to prove compliance are practically impossible!”
Who are the “they” being referred to? Compliance officers, internal and external auditors, and others who are responsible for implementing and monitoring new measures for compliance. I’ve also talked with many of them. It didn’t matter whether they were responsible for Sarbanes-Oxley (SOX), Basel II, HIPAA, The Patriot Act, Access Management, eSecurity, or other types of compliance. Their comments and complaints were consistent. For example:
“Why doesn’t IT speak up sooner? They act like we should know what’s easy and hard for them to do. They wait until our plans are final and there’s no time for new rounds of approval, then they tell us it’s too expensive to do things the way we’ve planned!”
No one has ever really answered the question of which came first, the chicken or the egg. Likewise, I doubt anyone will ever come up with a great answer to the question of how IT and compliance teams should work together.
The truth is that IT and compliance groups rarely understand the nuances of each others’ jobs well enough to understand the impact of different compliance options. If you’re a data architect or DBA, however, you can help change this situation.
Your opportunity involves another of the common compliance themes: change management. Most regulatory compliance initiatives address base requirements along with whatever specific needs prompted the regulation. These base requirements almost always include electronic security and access management controls, data governance to address rule-making and issue resolution, and formal, auditable change management procedures.
DBAs and data architects sit at ground zero when it comes to database changes. Even if you’re not invited to early planning sessions for compliance requirements, you will eventually learn what’s happening. You’ll receive a request for new reference data values, new or changed data fields, new or changed access to data, or new ways to connect sets of information.
These requests are your opportunity to not only do your job, but also to educate your compliance counterparts about what you both need to know if you’re going to work together to manage technology, data, controls, documentation, and proof of compliance.
Here’s an example: You’re in charge of tables that contain sensitive data. You receive a request to change the logical model, the physical model, access to the data, database-level controls, or even the data itself (if it’s reference data or master data).
Did this request go through a formal change control process that included sign-off by all the following functions in your organization: eSecurity, access management, privacy, regulatory compliance, contractual compliance, data architecture, application architecture, controls architecture, controls testing, data quality, tech pubs, and internal audit?
If not, consider sending an FYI e-mail. State the requested change. Say you’re copying all the above roles because you realize a change could have a potential impact in one or more of these areas. Say whether you’re planning to make the change as requested.
Then sit back and watch. Will there be strong reactions to the request? If so, you’ve uncovered a potentially serious disconnect. Will thoughtful dialogues take place between roles that don’t routinely consult with each other? If so, you’ve helped construct a more tightly aligned compliance culture. Will you be informed there’s no need for such FYIs, since everyone involved is already in the loop? If so, you can ask to become a part of that loop, since you, too, are involved.
A caveat: I’m not suggesting you do anything to cause yourself professional or political grief. But if the mere suggestion of such a memo from a data architect or DBA sends your organization’s management team into defensive mode, then that’s telling. Are your company’s communication protocols part of the solution or part of the problem?
If they’re part of the problem, then maybe it’s time for those protocols to face a little change management of their own. If you can provide a test case—one that’s clearly and objectively designed to help your company address risk— then you can become part of the solution.