NDMA Home Page
Index of topics on this NDMA website
Search this NDMA website on Google
© 2024 N. Dean Meyer and Associates Inc.
Excerpt from www.NDMA.COM, © 2024 N. Dean Meyer and Associates Inc.

Book: How Organizations Should Work

Role Analysis: Chief Compliance Officer, Chief Information Security Officer

some simple guidelines make the difference between a Chief Compliance Officer and a Chief Scapegoat

by N. Dean Meyer

Whether you're in charge of Regulatory Compliance or Information Security, the challenges are the same. How do you get everybody in the enterprise to do the right things?

Book: How Organizations Should Work

Consider the (true) story of a Chief Compliance Officer who tried a conventional approach to that challenge....

Allison was recently appointed Chief Compliance Officer in the IT department of a huge financial services company, and was set up to fail from day one.

The set-up was pretty obvious to an outsider, but not to her. She enthusiastically told me of the importance of regulatory compliance in their industry, and hence the stature of her position as the one person accountable for the compliance of the entire IT function.

"The regulators require a single point of contact," she explained. "We need to ensure consistent processes and metrics throughout the organization. And our CIO gave me the authority to make it happen."

I was reminded of past discussions with Chief Security Officers, Quality managers in the pharmaceuticals industry, and Business Continuity managers. All these people had been made accountable for other people's compliance, and believed they had the authority to control other people's behaviors.

Sigh. I hated to burst Allison's bubble. But time and again, history has proven that this approach doesn't work. Here's why:

Others have businesses to run, and they're not going to let a compliance officer tell them how to do it. Sure, they'll comply when it's easy or when they really have to -- with the big, visible initiatives. But on a day-to-day basis, Allison has three factors going against her:

One, others are not being held accountable for their own compliance -- she is. Why should they put effort into something that's outside their own personal performance objectives?

Two, others are being held accountable for business results, and they aren't going to let Allison cause them to fail at that. They're not going to take time away from their missions to worry about compliance, and they're certainly not going to change their processes or disrupt their operations to help Allison with her objectives.

The third factor is the killer. Others don't need to worry about compliance. Remember, Allison is accountable, not the rest of them. So if others mess up and bad things happen, she'll take the fall. Allison may as well have been given the title, "Chief Scapegoat."

The Path of Accountability

The organizational principle that applies in this situation is straightforward: Accountability and authority must flow down through the solid lines of the reporting hierarchy.

Accountability and authority must never flow sideways. One person must never be given accountability or authority for peers' behaviors.

Everybody in the organization must be accountable for their own behaviors, including for their own compliance (whether that means obeying laws and regulations, ensuring security, planning for disasters, etc.).

This means that everybody must balance operational objectives with compliance objectives. The degree to which operational objectives must be compromised to ensure compliance (or vice versa) is a decision that should be made by each manager for his or her own group (of course subject to review by his or her boss).

Idealist will claim that compliance helps achieve business results. That may or may not be true in the long run; but realists know that, at least in the near term, there's often a trade-off.

To illustrate this trade-off, consider the extreme cases. If implementing compliance means shutting down production, a manager may choose to take the risks inherent in waiting to implement the compliance measure and pray that nothing bad happens in the meantime. Conversely, if the risks of non-compliance are huge, the manager may choose to shut down production to implement the change.

There's no one right answer for everybody. It's a trade-off made in the context of specific business imperatives. Each manager is in the best position to make these decisions for his or her own group, and must answer to the consequences of those his or her decisions.

Organizational Risks

After explaining this to Allison, she objected, "But what if one guy takes a risk and something bad happens. Then the whole organization suffers the consequences."

"Allison, would you advocate zero risk?" I asked.

"In public, I'd have to say yes. But I know that would be unrealistic. Zero risk would force us to shut down the business, at least for a while. We can't do that. And the costs would be astronomical."

"Right. So if you take a risk and something bad happens, the whole organization suffers the consequences, the same as if one of the managers had taken the risk. Whoever has the power to decide, the organization as a whole is at risk. The only question is who should make the decision on those trade-offs -- you, or the managers running the business."

Allison honestly felt she was in the best position to make those decisions. "They always sacrifice compliance for near-term business results. I represent the compliance perspective, so I have to make it a priority. I'd take far less risk than they would."

"Even if they're all accountable for their own compliance?" I replied.

She had to grant that making them accountable for compliance would swing the balance somewhat. But she still wasn't satisfied that they'd make the right decisions.

"You know there's a good chance you'll make the wrong decision too, Allison. Given your position, you'll opt for more compliance than they would, and in doing so you might sacrifice critical business results -- maybe without even knowing it since you're not in the trenches delivering IT services."

We agreed that the trade-off between compliance and business objectives had to be made with a full understanding of both points of view. Either she could study the business and make the decision, or she could teach others the risks and let them decide.

I reminded her of the Golden Rule of organizational design: Authority and accountability must match. If she's to make the decision, then she has to be held accountable not just for compliance but for everybody's business results. Otherwise, what's to stop her from deciding in favor of absolute compliance, sacrificing business results, and letting them take the blame when critical projects and services fail?

"I can't be held accountable for everything going on in IT!" she cried.

"Exactly," I said. "Therefore, you can't be the one making these decisions."

Practicalities of Change

"Okay," Allison sighed, "I'll grant that if everybody accepted their accountability for compliance, we could let them decide when and how much to change. But how do we get them to take that accountability seriously?"

"Let's look at their incentives," I replied. "Sure, if something bad happens, the whole organization suffers. But whose job is it to fix the mess; or in the worst case, who gets fired? It doesn't do any good to fire you when the managers running the business make poor decisions and cause a serious problem. In fact, using you as a scapegoat only reduces others' incentives for real compliance."

She eagerly agreed. "Scapegoat" does not look good on a resume!

I reminded her that, in reality, getting changes to happen is far more likely if everybody is accountable and hence willingly implementing compliance initiatives to protect their own hides. On the other hand, the odds of successful change are far lower if she's forcing the change on the organization. Thus, overall, the success rates of compliance initiatives are higher, not lower, when the decision is left to each manager for his or her own group.

Compliance as a Service

"But remember," Allison said, "the regulators require a single point of contact. And even if it weren't required, process changes cut across organizational boundaries. Someone has to look after the big picture."

This was a perfect segue into discussing how she could achieve the critically important objectives of compliance without accountability for others' behaviors or authority over how others run their groups.

I suggested that Allison think of her job as a "coordinator" who sells services to her peers (figuratively, though money doesn't change hands) to help them with their accountability for compliance.

One of those services is to bring others together and help them agree on changes that cross organizational boundaries. She can then help them implement the change in their respective groups, not as the project manager accountable for results but rather as a project facilitator and coordinator.

In a similar vein, if people outside the IT organization (like regulators) ask for information or impose an audit, she can coordinate the organization's response. But every manager must be held accountable for his or her own piece of that response.

She also can coordinate planning. At one level, she can teach individual managers how to put together their own plans. Beyond that, her coordinating services include consolidating all their plans into an organizational plan, and bringing people together to work out the integration of their various pieces. Again, this is a service. Everybody must be accountable for planning, and Allison is there to help them satisfy this requirement.

The same roles apply to testing the plan, as in the case of business continuity. Allison can coordinate the test, while everybody remains accountable for their own groups' responses.

Throughout this service-oriented role, Allison can teach her peers the regulatory requirements, the risks of non-compliance, and the kinds of changes required to mitigate those risks. Educating others puts them in a position to decide the trade-offs. In the spirit of education, Allison may offer a risk assessment service, if her peers are willing to "buy" it from her.

"One final concern," Allison said. "What if they just don't do anything about compliance? Who's to catch them? Their bosses may not know enough about the regulations to know that they've got a problem."

There may be a need for auditing, I granted. But here too, a service approach works best.

"Remember," I replied, "the real auditors are outside the organization -- the regulators, hackers (in the case of security), or Mother Nature (in the case of business continuity). If you are seen as an auditor, doors will close as you approach and you won't be able to implement meaningful change. But you can sell "compliance assessment studies" to managers which help them get ready for the real, external audit."

The difference between an audit and an assessment is this: An audit is imposed, and the results are reported to others than those being inspected. An assessment is voluntary (if not requested by the manager, then by his or her boss). And the results are reported back to those who were inspected.

"Describing it this way keeps the accountability where it belongs, and keeps you on their side of the table -- there to help them, not judge them. You've got to maintain good relationships to implement meaningful change."

"Information security leaders (CISOs), [Meyer's work] is the key to transforming your group into a service organization that extends accountability for information security to everyone, empowering you to exit the command-and-control style that makes you a scapegoat for others' mistakes and ultimately is unsuccessful."
Jonathan Maurer, CISO

Stay On the Line

Allison could have stubbornly insisted that someone needs to be in charge or it won't happen. But fortunately for her, she saw the light. "I've got to go back to my boss and renegotiate this position," she said.

"Absolutely right!" I said. It's the responsibility of the CIO to get accountabilities sorted out properly, and never to put one manager at odds with peers or set someone up to fail.

The trap of the scapegoat occurs in many situations beyond compliance. It may be that ITIL "process owners" are tasked with implementing changes in the way the rest of the IT organization works. It may be that IT is asked to implement ERP and takes responsibility for changing clients' business processes. It may be that someone is tasked with chairing a committee of decentralized IT leaders and is expected to change the way all its members work.

In whatever form, the same fundamental organizational principle applies: Accountability and authority must follow lines of reporting. Everybody must be held accountable for their own behaviors.

Compliance, security, business continuity, and other change agents must limit their accountability to providing a highly effective coordination service. And C-level executives must step up to the plate and demand accountability in all the right places.


Free library


Speech abstracts

NDMA coaching/consulting services