How to gain the trust of the board

Answering that magic question: "What do you need from the board?"

question man
Thinkstock

Last time, in my post, “How to present security to the board", I mentioned 10 factors relevant to preparing that all-important briefing. One of those factors had to do with ensuring the CSO’s objectives and strategic plans are in alignment with the CEO and other executive officers. One common complaint often shared by CEOs has to do with the C-suite not aligning their risk management priorities to a common set of business objectives.

In her report in Security Info Watch, “Balancing Board-level Risk,” Marleah Blades writes: “it is incumbent on security leaders to ensure that the significant risks under their purview are being clearly communicated up the chain to inform the board’s decision on risk management priorities and resources.” One of the keys that can make a good CSO presentation a great one is by ensuring the data being reported actually has relevance on specific business risks the organization is most likely to encounter (rather than assembling a cross-section of common risks that may or may not be relevant).

So when/if the magic question is posed, here are three points of posture to consider:

  1. Thank them for their offer but decline any further intervention. While board members want to be somewhat engaged in the operational direction of the business, they may not be aware of the details behind the decision-making on a day-to-day basis. Boards “should hold management accountable for results,” writes Jeremy Barlow of Board Effect, “Without directly micromanaging specific matters.”
  2. Having already anticipated a response by your CEO, defer to him/her for follow-up. According to a 2015 New York Stock Exchange Governance Services survey, co-developed with Veracode, two-thirds of board members asked said they were less than confident in the level of security within their companies’ respective IT infrastructures. As a consequence of this potential, CSOs that maintain a strong dialog between the C-suite members will reduce any potential for doubt or misconceptions.
  3. If you are prepared to ask for something, be sure it’s urgent, necessary and relevant. While the temptation is often present for board members to want to offer their assistance, your best approach is to assure them your team and the extended resources provided through the executive staff, are achieving the security objectives you have set forth. That said, however, there are times in which board members might make you an offer you can’t refuse. If the CSO and CEO (and probably the CFO), are in-sync ahead of the meeting, “resources” usually translates into funding for more staff positions, rather than for more technology. Go ahead and ask (with justification).

Part 2: “Where are we (vs where we want to [should] be)?”

Tell them what they need to know

The board is looking for a basic indicator of where you and your team are (in general terms), where you think you should be, and how long it will take to get there.

In recent years, with reports on the Sony hacks, and the myriad of reports on stolen passwords, etc., in every case, some form of compliance mandate was implemented, but as shown in a recent Ponemon Institute survey, data breaches continue to be a major burden to boards and company operations.

Several years ago I was working with a global corporation with a strong presence in Southeast Asia. My team met with the leaders on both sides of the Pacific to discuss how to best approach the board’s request for an update on how the organization’s security policy could be better tailored from its current 350-page set of GRC-driven requirements.

Imagine the shock when we walked into the boardroom and told the chairman, “This policy is useless.”

We spent 30 minutes explaining that being “compliant” doesn’t equate to being secure, and that a better approach would be to target key operational objectives that align with the board’s business drivers, and then shift the broader security team’s focus to basic housekeeping.

That approach did two things; first, it showed the board that the people the CEO had in place to look after security were in-tune with what the company needed, rather than painting broad-brush strokes to meet a set of artificial standards. Second, by pinpointing exactly what the organization needed on a day-to-day basis, the team was able to target their resources at issues specific to the business. The revised security plan, came in at about 40 pages, and was rolled into an ISMS-type structure.

Here’s an example of how to tackle the issue of Where are we and where should we be:

“Last year/quarter, we had [x] hacks/attacks, and this data helped us improve our security posture in the following controlled areas [list them]. The mean-time for us to detect and contain incidents [has been/will be] reduced from three days to one day, based on our revised Incident Response mitigation plan.”

“Cause & Effect” (in basic terms)

No matter how many vendors try to pitch their wares, “security” for any organization comes down to two basic factors: assets and access. Measuring “risk” is often based on the level of threat exposure an organization is willing to take based on the access factor, which brings to reference two more important points of consideration: Risk appetite and risk tolerance.

“Risk appetite,” according to the Institute of Risk Management, “Can be defined as ‘the amount and type of risk that an organization is willing to take in order to meet their strategic objectives.”  

“How much loss can be tolerated before some threshold of damage is breached?” writes George Campbell in his Security Info Watch article, “Aligning Incident Impact with Acceptable Risk.” What is an “acceptable” risk in your world of exposure to security risk management?” When meeting with the board, CSOs might find it impactful to define the differences between “appetite” (which tends to be more about accessibility and availability), and “tolerance” (which evaluates the ramifications of compromise to those assets).

Compartmentalizing “risk” is a way of keeping disparate groups on an even keel, and explaining how your team is implementing pragmatic steps to address varying levels of risks, based on the degree of exposure individuals within the organization may have, is a good way in demonstrating operational “need to know.” Here’s an example from a report our team provided in a recent board briefing:

“Based on roles and privileges, and degree of accessibility, our policies and operational controls are configured to match our levels of exposure, thereby providing a higher degree of confidence in our alerting and mitigation processes relating to potential breaches.”

Knowing when you’ve said enough

The board reads USA Today and watches the news outlets too. Providing regurgitated news reels and summarized media reports about security breaches is the fast track to a CSO snapping back to becoming a Tier-1 help desk responder. When CSOs are called up to the board, there are usually two common factors to consider playing in the background: 1. The board needs to be assured their investments are being safely assessed and protected; 2. They want to feel confident in their executives.

A couple of final thoughts that tend to be useful in preparing your board briefing:

  • Don’t scare anybody with complicated terminology.
  • Keep the statistics relevant to the business.
  • Budgets should already be worked out with the Executive Team and approved by your CFO.
  • Provide information in a way in which board members can internalize/personalize the data.
  • Be sure you don’t stick the CEO’s neck out during your remarks!

Finally, remember that the average presentation in front of a formal board meeting by a senior staff member is between 15 and 20 minutes. Providing senior executives and investors with a level of confidence may take longer, but showing them you’re on the right course is a good start at gaining their trust and building confidence.

This article is published as part of the IDG Contributor Network. Want to Join?

NEW! Download the Fall 2018 issue of Security Smart