Business Resiliency

Creating Governance You Can Rely On

David Edborg By David Edborg Portfolio Manager, Business Resiliency February 2, 2015

This is the fifth blog in a series supporting EMC’s Business Resiliency eBookUse the menu to the right to explore the rest of the series. 

As a practitioner, I’ve always felt that the best way to help a customer get serious about security has been via the Corporate Governance route.  Here’s why – it establishes who makes decisions, when they make those decisions, and for what reasons.  Tell me I’m wrong, but the only topic that everyone is interested in, after how much you’re paid, is who owns what?  Ownership is always defined by who has the authority to make decisions.

More often than not, I find that Governance is not understood in the way that it should be by most clients.  It tends to be overlooked as the mechanism that helps the organization more efficiently and effectively manage systemic liabilities.  Its mandate and objectives are also commonly commingled with those of compliance and enterprise risk management and, thus, it’s not uncommon to see it hijacked and used as a vehicle that helps advance nefarious objectives..  My point? Governance is usually viewed as a series of not always super important activities that are engaged in by a company fresh off the boat from Insolvency Island.

So how do I get a client to get serious about Governance?  How do I use Governance as consulting Kung Fu to help me use the client’s own weight to address resiliency or just do whatever I want them to do?  Easy, I show them how to make decisions.  Let’s be clear, the days of “because I said so” in corporate America are long gone.  You’ll rarely find a single person making decisions for any company anywhere.  And, rarer still, is the instance of anyone, outside of the CEO, actually in a position that explicitly, unilaterally, universally and singularly is responsible for large commitments.  Catching on now? We need to focus on…

    1. Process – Formalize the series of steps, stakeholders and activities that are a part of any governance program.  Usually broken into some version of (1) issue prioritization; (2) escalation procedures; (3) tolerances and thresholds; (4) roles and responsibilities; (5) compliance and performance requirements; and (5) reporting
    2. Prioritization – Decisions about everything that needs to be managed in the IT function are either a function of (1) help leverage an asset – something that will make the organization faster or cheaper or (2) will help manage a liability – a risk that needs to be managed.  So, naturally, every item on the list of priorities in the organization should be sortable by a set of criteria that provides the basis for relative ranking.  Basically, we need to assign values to the each of the individual items in the big book of corporate to-do’s.  Think simple!  Think size, scale and scope.  Think impact, relevance and urgency.
    3. Escalation and thresholds – use the relative ranking from the prioritization process as the basis for how items move through the escalation process.  Think of thresholds as the trigger that allows for the movement through gates that are cleared, or not cleared, in the steps of the escalation process.  I’m clearly leaving out details associated with the procedures, but those can be gleaned from any process you already have.  Use the thresholds as the forcing function for the decisions that need to be made regarding any issue, risk, or commitment that has to be made.  For example, for an investment decision to be made, it must have cleared the following gates in the investment decision process – the thresholds will remove YOU, personally, from having to own the single decision.
    4. Roles and responsibilities – The only governance function that works well is the one that is plotting against an organization chart and has clear structure to who is responsible for what activity.  Per my earlier points, few single individuals are ever empowered to make decisions.  So don’t fight it… make the roles focus on activities and end product.  The thresholds and the process called for in 1 will force the decisions.  In simple terms, make the different parts of the hierarchy responsible for moving the process along and enforcing structure and updating criteria.  DO NOT make any of the roles a decision-making role.

I’ve done the equivalent of squeezing about 50 pounds of process and support into a 5 pound casing.  Or is it sausage?  What I do know is that every client I’ve ever seen address Governance correctly had several things in common… (1) there was always a clear process to sort the noise of what they needed to focus on; (2) people never made decisions, the process did; (3) roles and responsibilities always had more to do with the activities the individuals engage in than it did the thing they “owned”.

David Edborg

About David Edborg


Portfolio Manager, Business Resiliency

David originally joined EMC (now Dell EMC) in 2005 and is currently the Portfolio Manager for Dell EMC Business Resiliency Services. Over his career at Dell EMC, David has served as a Global Practice Manager for Availability Technologies, as an Availability Services Solutions Principal, and as the Chief Architect for EMC’s Continuous Availability Services Line.

David has over thirty years in the computer security and disaster recovery industries. Out of college David worked as an IBM Assembler coder and wrote operating system mods for ACF2/VM; the first ever security product for IBM’s Virtual Machine OS. He has worked with other vendors and partners in the DR industry, including supporting recoveries from the 9/11 event. David has also worked in the packaged software industry as Director of Development and Support for a computer security product.

Read More

Share this Story
Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

Your email address will not be published. Required fields are marked *