Readout 005: An Appetite for Risk
What happens when Security knows the safest answer, but the business chooses another one?
There is something I've told my teams for years: “Document Everything.”
I've actually had members of my team ask me what “C.Y.A.” means. Nothing ages you quite like having to explain an acronym you assumed everyone knew, but while “C.Y.A.” may be showing its age, the principle behind it isn't.
Part of documenting things is protecting yourself and your team. Let's be honest about that. If you've identified a legitimate concern, brought it to the appropriate people and the business decides to go in another direction, there should be a record of that conversation. Documentation, however, is about more than covering yourself.
It's about what you do when you're put in a difficult position, the answer isn't black and white, and you still have a responsibility to protect people and the business. Those situations happen more often than most people realize.
You Can Be Right and Still Not Get Your Way
Security professionals are trained to identify risk, and when we see a vulnerability, our instinct is to fix it. We put standards and controls in place because we've seen, and many times experienced, what can happen when those controls aren't there. There are still going to be times when you recommend something and the answer is no.
It’s not because leadership doesn't understand the risk or because your team didn't explain it well enough. Sometimes the business understands exactly what you're telling them and decides it is willing to accept that risk, and that's a hard reality for security professionals to get comfortable with.
The safest answer may require more people, costing more money. It may slow down an operation or conflict with another priority. Maybe the business has evolved since a standard was put in place. Maybe the financial environment has changed, or maybe leadership simply has a different appetite for risk, and you have to understand that reality.
Our job, hard as we may try, isn't to eliminate every possible risk from the business. If it were, most businesses couldn't operate. Our job is to identify the risk, explain it clearly and make sure the right people understand what they're accepting before they make the decision. We have to be accurate when we do it.
We have to ask all the right questions: Is this illegal? Is there a regulatory requirement? Is it against company policy? Is it an industry best practice? Or is it simply something that introduces more risk than Security would prefer?
Those are very different conversations. You have to know which one you're having before you walk into the room.
So What Do You Do When the Answer Is No?
This is where I think judgment matters. You've identified the issue, made your recommendations and brought them to the appropriate people. You've made sure everyone involved understands the gravity of the situation.
A decision is made. The business is going to accept more risk. Now what?
Do you keep pushing until you've made yourself the problem? You can get frustrated and decide that whatever happens next isn't your responsibility, or you can figure out what you can still do. I've found myself saying some version of this many times throughout my career, and the answer is always the same: I can't do nothing.
If I can't get the control I originally recommended, what can I get? Can we provide training? Can we change the escalation process? Can we make sure people know who to call when something happens? Can we increase communication or monitoring? Can we put something in place that reduces at least part of the exposure?
It may not be the solution I wanted, and it may not reduce the risk as much as I would like, but doing something is better than standing on principle while doing nothing. That's part of being a business partner.
You still advocate for what you believe is right, but you also have to be able to operate in the reality of the business you're supporting.
Risk Has a Price
Businesses make decisions based on risk and reward every day. Security risk isn't exempt from that calculation, and that can be uncomfortable.
Sometimes an organization will knowingly accept additional exposure because the alternative costs more money, requires more resources or interferes with another business objective. That doesn't necessarily mean someone doesn't care about security, although it can be difficult to see it that way when your entire job is to protect the business and its people. It means the organization has made a business decision about how much risk it is willing to carry.
Accepting additional risk doesn't mean nothing will happen. Eventually, something will. As I wrote in The 90th Day, the question isn't whether an organization will face an incident. It's when, and whether we're prepared to respond when it does.
When that day comes, the fact that an accepted risk resulted in a loss doesn't automatically mean the original decision was irrational. You have to go back to what was known at the time. What were the alternatives? What did the organization gain by accepting the additional exposure? What did the incident ultimately cost? A decision that made sense at the time may not make sense anymore.
That's the nature of risk. You make the best decision you can with the information you have, and when the information changes, you reassess. What shouldn't change is the history of how that decision was made.
Once something happens, hindsight has a way of making every risk look obvious and every decision look different than it did at the time. People remember conversations differently. Leaders change, employees leave, organizations restructure, and the context around a decision disappears.
Which brings me back to documentation.
Documentation Isn't an “I Told You So”
There is a difference between documenting a decision and building a case against the people who made it. If I've raised a concern and the business decides to accept the risk, I want a record of the conversation: who was involved, what we understood the risk to be, what decision was made and, most importantly, what we're going to do from there.
Yes, part of that is protecting yourself and your team, and I'm not going to pretend it isn't. It also protects the organization by preserving the context around a decision that may look very different months or years later.
Usually, that doesn't require much. A follow-up email that says, “Per our conversation, here's my understanding of the decision and here's what Security will do to support it,” may be enough. You're not writing it for effect or trying to get the last word. You're making sure everyone leaves the conversation with the same understanding.
If something does happen, pulling out an old email and saying “I told you so” is about the least useful thing a security leader can do. At that point, you have an incident to manage. Deal with the problem in front of you. The documentation will still be there when it's time to understand how you got there, what was known at the time and whether the risk the organization was willing to accept before is still one it's willing to accept now.
That's why I say document everything.
The Part They Don't Put in the Job Description
I've had several people reach out to me over the past few years, asking about careers in corporate security. Some are just getting started, while others are coming from government or law enforcement and trying to understand how their experience translates into the corporate environment.
One of the biggest adjustments is realizing that many of the security rules you assume exist simply don't. Something can be a good security practice, an industry standard or even seem like the obvious thing to do without being legally required and knowing the difference between what the business must do and what Security believes it should do is an important part of this job.
There will be times working in private sector security when you make the strongest recommendation you can and don't get the answer you want. That doesn't mean you failed; It means your responsibility shifts from advocating for the solution you believe is right to solving the problem within the parameters of the decision that's been made.
Someday, the 90th day will come, and when it does, nobody needs the person who can prove they were right six months ago. They need the person who understands what was known, what was decided and why, and can help the organization figure out what happens next.
So ask the right questions, make the recommendation, manage the risk….and document everything.
