CISO Toolkit: The Metric of No.

Saying “No” and being the “Department of No” are two different things. CISOs can use “No” to justify increased security and resilience while maintaining the pace of innovation that modern businesses demand.?

By Clarke Rodgers , Director of Enterprise Strategy at Amazon Web Services (AWS)

Many CISOs that I meet with globally have a common challenge they’re trying to overcome: to be viewed as business leaders. They want their security programs to drive business value, and reduce/mitigate risk for their respective organizations.?They understand that no modern security organization can afford to be viewed as the “Department of No.” Instead, they want to be viewed as the “Department of Yes, and,” where they are fully leaning in to support business objectives, along with the responsibility of elucidating and mitigating risks related to certain business objectives.

While it may seem counterintuitive, one of the best ways for the CISO to support their initiatives, and to be able to effectively communicate risk, is to track how many times they MUST say “No.” An organization with a strong security culture, an adequately?funded security organization, and executive team that understands cyber risk shouldn’t have to say “No” very often to any legitimate business request. But if you’re in an organization that doesn’t check those boxes, tracking how often you say “No” can be the catalyst to get your organization to that state.

Businesses are rapidly pursuing use cases for and implementing AI as quickly as possible, and security teams are balancing the need to support business innovation while mitigating risk for the organization.

History shows us that if CISOs are not supportive of business objectives, they lose visibility of company activities due to shadow IT and other end-runs around the security apparatus, further exposing the organization to unnecessary risk. At the dawn of cloud experimentation and migration more than a decade ago, some CISOs actively blocked cloud, were circumvented, and ended up having to bolt on security after the fact. Others took a more objective stance, learned about the security benefits of the cloud, and supported their business colleagues along the way to ensure that anything built or deployed in the cloud would meet or exceed their security standards.

Today, we see a similar conundrum: generative artificial intelligence (AI).?Businesses are rapidly pursuing use cases for and implementing AI as quickly as possible, and security teams are balancing the need to support business innovation while mitigating risk for the organization. The lessons CISOs learned from cloud adoption are finding their way into AI adaptation, and that is a great thing. However, for those CISOs who are not able to match the speed of their business, and have not yet earned the trust of their business peers, how can they shift from being viewed as blocker of innovation and instead be seen as a champion of it?

An example: Product delivery velocity.

Line of Business (LOB) owners: “We need to increase the velocity of our code releases to achieve better time to market, and increase revenues to meet the target set by the CEO. Security keeps blocking us right when we’re about to launch because they find security issues in our code and force us to do expensive rework that puts us further behind. We need to remove this burden, launch the release on schedule, and if there are any security issues, we can just put them in later via our backlog.”

CISO: “No. The risk is too high to the organization, we must be able to release code securely and maintain that security throughout the product lifecycle.”?

How that “No” turns into an asset for getting to “Yes”:?

The CISO organization tracks how often this comes up across the various LOBs and what the “No” actually costs in terms of potential lost revenue. Using that data, they can then make the business case to obtain funding and buy-in for: 1/ incubating a security culture program where everyone has a security responsibility, 2/ justifying the cost of a tooling team that builds and maintains CI/CD pipelines with the security checks built in, not bolted on—so developers get security feedback at every stage of the SDLC and focus on features), 3/ building a training program and embeds a “Security Ambassador” in every product team, and 4/ making security objectives clear (we must do X, Y, and Z) yet flexible (Let's explore any options we can).

These strategies result in LOB developers having full control over their release velocity, ownership, and security of their product. Security is built in early with every product, with fewer (perhaps zero) expensive “night of production implementation” security blocks. LOB delivers code securely at the velocity that aligns with business objectives.?

Saying “No” and being “the Department of No” are two very different things. But CISOs have an opportunity to use “No,” in terms of business risk and opportunities, to justify increased security and resilience while maintaining the pace of innovation that modern businesses demand.