Strategic alignment

On the ISO27k Forum this morning, a member from a financial services company asked for some advice on aligning IT and Security with overall corporate/business strategies.  He said, in part: 

"Organizational level strategic plan, covering its core business, has been derived. And it includes what is expected form Technology and Security departments,  I.E. to keep customers, shareholders happy and to provide safe and secure technology services.   

[I need] to prepare a strategic plan decoded from organization's strategy, specifically for Technology and Security department, with goals, objectives, principles etc.  So for achieving this, my approach is to understand each business strategy and determine the possible ways that Technology and Security team can help it. 

Business strategy -> Technology strategy -> Security Strategy"

I strongly support the idea of explicitly linking 'our stuff' with corporate/business strategies (plus initiatives, projects and policies) but 'our stuff' is more than just technology security, or IT security, or cybersecurity, or data security .... I encourage everyone to refer to information risk, defined as 'risk pertaining to information', an all-encompassing term for what we are managing and doing. Especially in the strategic context, we should all be thinking beyond securing bits and bytes.  

[The mere fact that they have a department, team or whatever named "Security" that he and presumably others consider a part of, if not very closely tied to, "Technology", strongly suggests a very IT-centric view in the organization. To me, there's the merest whiff of a governance issue there: treating this as 'IT's problem', with the emphasis on security (as in controls, restrictions and prohibitions, as much as protection and safety) is a common but, in my view, sadly misguided and outdated approach - a widespread cultural issue in fact.]

Identifying information risk aspects of the corporate strategies is a creative risk assessment activity. In stark contrast to financial risks, information risks tend to be largely unstated, if not unrecognized, at that level but can generally be teased out from the assumptions (both explicit and implicit). For instance, if a business strategy talks about "Expanding into a new market", consider what that actually means and how it will be achieved, then examine each of those proposed activities for the associated information risks - including for instance the information risk that the 'new market' opportunity has been misunderstood or misstated (often by whoever is eagerly promoting the approach, an obvious bias that experienced managers are adept at discounting in others, yet curiously reluctant to admit in themselves!). If it goes ahead, management are making significant assumptions that the market exists and is profitably exploitable using the proposed strategic approach but what if they are wrong? What if the projections are unrealistic (overly optimistic or pessimistic: remember risk cuts both ways)? What if the assumptions turn out to be unfounded? What if 'something else happens'? These are just some of the information risks concerning a proposal that is being used as the basis for strategic business decisions - a high-stakes situation for sure. In addition, there are the more obvious implications on Security of going ahead with the strategy (e.g. finding the information risk and security specialists needed to support and guide the new market activity) plus other more subtle effects (e.g. diverting attention and resources from more mundane but potentially just as risky stuff).

Doing that kind of risk assessment properly and thoroughly is a lot of work - a major and potentially difficult and costly undertaking, involving business managers plus specialists from Security, Risk Management, IT, HR, Compliance, Business Continuity, Audit etc. It's a team effort, supporting and enabling each other and negotiating for the best overall outcome for the business as a whole. If that's not feasible given the current circumstances, maturity level and resources, then I recommend at least focusing on and clearly prioritizing risk associated with the organization's most valuable and/or vulnerable information assets. In financial services, customer financial data is undeniably worth protecting, so there should be little argument if the strategy lays out whatever that involves. Other things may dangle from that handy hook, within reason, but still it's better to be able to show that every single item in the strategy or plan relates to something that the business has identified as a driver, goal, objective etc. [OK, some of those relationships might be tenuous in practice, but still it's hard for managers to resist or block activities that relate to strategic goals - potentially career-limiting in fact.]

Especially if we are able to do this properly, a significant advantage is that the business drivers for information risk and security form an excellent basis for security metrics: if our metrics measure those things, we can reasonably expect management to take notice and use them. If not, why are we wasting their time with irrelevancies? In other words, we can squeeze extra mileage out of the strategy development process by picking out the associated metrics that will help achieve the strategy. It's a win-win.

Don't forget that strategy is relatively long-term big-picture stuff. This is our big chance to plan the foundations for the future development and maturity of information risk and security management in the organization: it's not just about tagging dutifully along behind whatever the business is doing, but also setting things up so the business has more, better options going forward. It's part of 'business enablement'. If, for example, I would love (for sound business and professional reasons, you understand) to set up a superb Security Operations Centre but have so far been denied the opportunity, are there things we can do over the next year or so to set things up and get the process running so that, maybe in a few years time, the SOC is more likely then to be approved? The strategy development process is like a chess game: we need to think several moves ahead, and consider what the other players are doing and how they will respond to our moves. It's also a competitive team game: as much give as take. Call it back-scratching or horse-trading if that helps.