By Bob Hayes, Managing Director, Security Executive Council
I've always made a habit of finding the smartest people in the room and learning from them, in any situation. That was one of the driving ideas behind the SEC when it started 15 years ago – to gather knowledge from the smart folks – successful security leaders – and their programs, document that knowledge, and build on it.
But back when I was a CSO, starting and running five different programs, I made probably every mistake you can make. There are so many things I have learned since that I wish I had known at that time.
That's the focus of this new series of conversations: I Wish I Had Known … We hope to offer you insights from other security professionals, but I wanted to start with my own thoughts about what would have made my journey to successful security leadership less bumpy.
The things I'll talk about require meaningful conversation between you, your leadership, constituents or customers.
I wish I'd understood the position, company, strategy and organizational philosophy before I took the job.
When you're interviewing for a position, you're so busy getting the job that you don't ask the right questions about what the job actually is. My expectations more often than not were beyond the reality of what I was about to walk into. Here are the questions I wish I had asked up front.
- What's your definition of security?
Every organization defines the security function differently. Investigations may be part of Human Resources or Legal. Physical Security may reside in Real Estate. How does the function that I'm envisioning as my job in this organization match up with the function as the organization defines it? If it doesn't match up, can I shift my expectations? Does my skill set still prepare me adequately to run security in this organization?
- What do you think your most significant risks are?
Note that the question isn't "What does the security function or I, the prospective security leader, think the risks are?" but "What do you, the executive leadership team, think they are?" If there are differences between the organization's idea of its risk and a security-focused understanding of it, do they represent security gaps that need to be closed? Or do executives and security need to come to a shared understanding of risk appetite?
- How will the security organization mitigate risk?
How has management defined security's service delivery model? Will you run a traditional department staffed with FTEs? Are individual sites in charge of their own security? Are you a one-person security function tasked with strategy and planning, with all operations to be carried out by contractors? There are no right or wrong service delivery models, but different skill sets and experience is required for each. Do you have the expertise to run things as management expects them to be run?
- Who owns the security risk?
You probably know the answer to this question, but it's important to ask it to executive leadership, because they often don't know. Many of my early bosses didn't, and I didn't know how to explain to them that the answer is not Security. Corporate executives are the individuals with the decision-making authority and the resources to mitigate risk, and it is important that they understand that.
It further helps them to understand that Security doesn't prevent all risk. There are layers of mitigation and residual risk, the risk they choose to accept in order to further their business. My executives early on didn't really know about that.
- What are the mitigation strategies most valuable to the company?
Some believe they need an executive protection program, for instance, because they believe it is a non-negotiable element of a "good" security program. But if there is little to no risk of executive kidnap, is that program necessary, or could resources be redirected? All mitigation strategies should align with identified risks.
I wish I'd known how to run security like a business.
In every situation, my new bosses expected me to be a businessperson who was an expert in security, and at the beginning I didn't know how to be that. I looked at security as my primary concern, while they wanted me to look at the success of the business as primary and security as a function of that.
I needed to ask myself more questions: Is every function my business customer? What's my role? What's the cost of our service? Our scalability? Our capacity? What's the value? What does my regulatory baseline look like?
One very important question I wish I'd asked myself: Do I have a process? There's no silver bullet answer to security-related questions. Every organization needs something unique to itself. I wish I'd realized that I had to go through a process to come up with the right answers for my given situation rather than relying on just benchmarking or just tradition or just demand. The abbreviated process chart shown here will give you an idea of what I mean.
The SEC Web site is full of information about each of these topics, as well as research behind them and ways to engage with us. Specifically, check out our articles on the state of comparison research in security
, the value of benchmarks as tools
, and our collaborative consulting options
You can download a PDF of this page below: