Risk Acceptance is a mechanism by which Security teams can partner with their business lines and help support the goals of the organization
A common refrain in the industry is that Security departments are roadblocks and obstacles to accomplishing business objectives. I often hear stories from my Chief Information Security Officer colleagues of hostile or combative working relationships between the business/IT and Security departments. Understandably, Security departments need to act as an effective challenge for the organization can foster that type of environment.
However, this type of relationship adds unnecessary friction to the organization, impairing the needs of the business and creating security risk. Users who are frustrated by combative security policies find alternative means to complete their work, often resulting in them looking to bypass internal controls. This leads to users seeking “shadow IT” solutions, finding ways around problems that their Security teams couldn’t answer. The root cause for these types of situations can often be characterized by misunderstanding or disagreeing with the risk associated with some action.
"Risk Acceptance is a mechanism by which Security teams can partner with their business lines and help support the goals of the organization"
For example, consider a business executive who has been charged with identifying a new product to help market to customers. As part of this effort, the executive may need to navigate numerous security and regulatory challenges to accomplish their goal. At this stage, Security teams are often brought in to help facilitate due diligence and identify any risks associated with the effort. This is where the business/Security relationship often breaks down. Due to the technical nature of the analysis, Security teams are prone to intermingling risk and risk acceptance. They might determine the product has a vulnerability that makes it too risky to use, and simply tell the executive they cannot move forward. While this might be appropriate, it creates frustration among an audience who may be less technical and confused by the outcome.
Over time, this can lead to Security being perceived as an obstacle to business objectives. As a result, the business executive may be more inclined to pick a Software as a Service solution, where sales people readily communicate that their products are “turnkey” or don’t require IT. As most of us have experienced in technology roles, these solutions are seldom as advertised, leading to pain down the road as technical resources are required to solve issues. This result creates both security risk and operations risk.
The key to navigating this challenge and creating a sense of collaboration between teams is to establish good processes for Risk Acceptance. Risk Acceptance is occurring within our organizations today, whether or not it’s acknowledged. In our example above, the business is accepting the risk of using Software as a Service without Security’s involvement or support. Inadvertently, risk is being accepted, leading this approach to fail over time. The objective of a proper Risk Acceptance process is to have a productive and facts-based discussion of risk prior to moving forward.
As I hire and train new staff, a common misconception I hear is that Security’s role is to say “no,” or other more colorful expressions. This approach to security doesn’t support business objectives and alienates our team from the rest of the organization. From the beginning we emphasize that our role is to help measure, quantify, and present risk to the business. It is the business’s responsibility to choose if they have the appetite to accept that risk.
The way we translate Risk Acceptance from a philosophical concept to a practical one is by breaking down risk into digestible pieces. Every assessment completed by the Security team results in a report which is presented to our business stakeholders. This report is written to convey technical concepts with clarity and simplicity.It clearly outlines the
outcome of our review and states the specific risk items for concern. It ends by summarizing that risk and providing a recommendation if the risk is perceived acceptable. What happens next is the critical step.
The creation of the report opens up dialogue with our business lines and is not a finishing point. If our business line wants to move forward and accept that risk, it’s our job to ensure they fully understand the implications of that. Once they do, our role as Security needs to shift, immediately working to fully support the effort. Though we might have felt differently about the risk, as long as it’s understood and explicitly accepted we can comfortably support the desired direction of the organization.
This may seem like a simple or small change to make, but it has a large impact on Security’s role within the organization. The presentation of risk and ability for the business to explicitly accept it ensures there is always a path forward and Security isn’t a position of saying “no.” This establishes your Security team as a partner rather than a barrier to overcome or evade through shadow IT. From a Security perspective, it may not feel ideal to have a significant risk accepted by the business and watch them move forward. But because a stronger partnership has been established through this process, we find we have many more opportunities to mitigate risk as development or implementation of an effort moves forward. Business lines are not afraid to proactively and continuously engage Security, because they understand that risk and risk acceptance is a dialogue between the areas, rather than a strict approval process.
Risk Acceptance is a mechanism by which Security teams can partner with their business lines and help support the goals of the organization. It creates dialogue and trust in the organization, ultimately improving security outcomes and awareness.