Every week, Sprocket Security's CEO Casey Cammilleri interviews an expert leading the charge on empowering security experts and practitioners with the knowledge and insights needed to excel in the future of cybersecurity.

We recently spoke with Cody Florek, Director of Information Security Operations at Sentry. Here are the top takeaways from the interview.

#1: Treat InfoSec as an Internal Customer Service Function

“So it's a lot of coordination. As an InfoSec area, I'm glad that I came from a customer service background when I was at Rapid7, because everything you do is for the organization. So you're trying to provide a service and ensure that you have good customer satisfaction. So is your internal CSAT, is it going up or is it going down with outside entities? Now, yes, you have specific requirements to maintain in terms of security, but making sure that you are lockstep with different parts of the organization so that when they need something, you're delivering something useful and when you need something from them, there can be some reciprocation there.

“So a lot of time is spent trying to make sure that we've got our eyes on the right projects, that we know what some of the upcoming work is going to be or where we need to inject ourselves at the right time. That's more at an organizational level. From a internal to InfoSec area, it's do we have the right training to perform our work? Are we measuring things appropriately so we're self-aware enough of when we're struggling? Or do we have blockers that we now need to think about and refactor? Is our design choices appropriate?

“So there's a lot of external analysis, internal analysis that goes on there. And then at times you're brought in to talk about the risk of a certain thing and what's our risk appetite and should we take action, should we find a mitigation? So there's, do we need more data? There's a variety of things happening in that space.”

Actionable Takeaway: Build your security team with a customer service mindset to ensure organizational alignment. Measure internal satisfaction metrics alongside security requirements, creating reciprocal relationships with other departments. This approach helps identify the right projects to focus on, determines when to inject security expertise, and maintains appropriate internal training and measurement systems to identify blockers before they become critical issues.

#2: Adapt Your Risk Communication Strategy to Different Scenarios

“There's a variety of nuances there based on the category that you're looking at. So are you talking about what risk is there in this new business process that maybe there's not the most clean way to secure? There's risk inherently in doing business of this type — or maybe not in this type, but in this way. And there's no good answer to go around it. Those are conversations that you're having with the business unit and then you raise that up through your group. Sometimes it's a meeting to talk a little bit more. Other times it's you have to form an exception if it's flying in the face of policy directly.

“So you need to register that. Now, there's other risk elements that you can measure and that would be more from vulnerability management and AppSec metrics. So how much risk do you have baked into the things that you own and how are you driving that down? Month-over-month metrics are useful, but calling that out is, in a specific way, useful. Otherwise if it's a new hot button vulnerability right out the door, well, let's get people on the phone.

“You go from operational tracking and movement on vulnerability management to incident response mode when you hit a certain severity level and then all those metrics go out the door and it's getting people on the phone and making sure that you're blocking and tackling and getting the right people on online to mitigate, stop or whatever in those particular moments. So that's when you go over to the IR side of the house. So lots of silos on raising risk.”

Actionable Takeaway: Recognize that risk communication varies dramatically across security contexts. Business process risks might require exception documentation, while vulnerability metrics demand month-over-month tracking with specific callouts. When high-severity issues emerge, be prepared to shift immediately from operational tracking to incident response mode. The transition requires different communication approaches and stakeholder engagement strategies depending on the security domain.

#3: Prioritize Vulnerabilities Based on Context, Not Just CVSS Scores

“There's the basics of CVSS says this, ‘Okay, what's the buzz in the news? Is there anything happening there? Is it exploitable? Is there any proven examples of somebody exploiting that?’ Those are some of the components of let's raise those to the top right away. I think the context in which it lives also makes a lot of sense. So if this is a client-side vulnerability versus a server-side vulnerability, if that's a batch server that no one ever logs into, you probably don't need to hit the big red button to have somebody chase that down right this second. But if it's something that, yeah, it's that batch server and every other server. Okay, well that changes it.

“Talking about context is really important. There's times at which, given the context, we might say we're reasonably sure that this wouldn't be exploitable, but let's test it. Can we try to attack ourselves and figure that one out? And if so, all right, well, now we need to activate teams a little bit faster. Otherwise, here is the list of things that you need to cover this month. A lot of things will get covered through your typical patching cycles. We're going to measure to that and understand that and how that goes. But if there's anything that's big and glaring and missing, we need to talk about that because you still have a lot of risk in that environment and we need to drive that down a little bit.”


Actionable Takeaway: Look beyond basic CVSS scores when prioritizing vulnerabilities. Consider news buzz, exploitation evidence, and — critically — the context in which vulnerabilities exist. A client-side vulnerability on an isolated batch server requires different urgency than server-side issues affecting your entire infrastructure. When uncertain about exploitability, test it yourself before activating teams and potentially creating unnecessary downtime for your organization.