After 20+ years across cybersecurity, privacy, compliance, and risk, plus advising organizations from SaaS to manufacturing, what has experience taught you about the difference between a security program that looks mature and one that actually reduces risk?
My career has taught me that maturity is what a security program has, but its effectiveness is what it changes. A security program can have strong policies, frameworks, audits, tools, and metrics, and still fail to meaningfully reduce risk. Identifying risk earlier, improving resilience, and reducing the likelihood or impact of events that matter to the business are what change outcomes. A program’s maturity should give the organization a better understanding of its exposure and help it make better decisions about that risk.
Effective programs also understand the business and engage early instead of becoming a barrier. They help teams find secure ways to accomplish their objectives, with controls that address the risks involved. Security needs to improve resilience while supporting the work the organization is trying to do. Ultimately, maturity matters when it translates into measurable risk reduction. Having a process or control in place is useful only if it works as intended and changes the organization’s exposure.
RapidScale operates across private, public, and hybrid clouds, supporting clients with very different risk profiles. What makes securing that kind of environment different from securing a more contained enterprise?
The biggest difference is that there is no single security perimeter or risk profile for these sorts of environments, and the way these technologies are architected and intersect reshapes how defense is designed and applied. Across private, public, and hybrid clouds, we’re dealing with different technologies and shared-responsibility models that require a clear understanding of what needs protection and who is responsible for securing it. Regulatory requirements and customer risk tolerances also vary and complicate these priorities.
The challenge is creating a consistent security foundation without assuming every environment should look the same. Visibility across a complex environment, supported by strong identity and access controls, secure architecture, and continuous monitoring, is fundamental to understanding the risks of each customer and workload. Security must be both scalable and flexible, providing a strong baseline while enabling customers to operate in the way their business requires.
A breach at a cloud services provider can quickly become someone else’s operational or business crisis. How does that downstream responsibility influence the risks you’re least willing to tolerate at RapidScale?
The responsibility to protect customers from the downstream effects of a breach shapes how we assess risk. As a cloud service provider, an incident doesn’t necessarily stop with us and can affect a customer’s operations and data, damage their reputation, and extend to their own customers. We have to account for those consequences when assessing the risk.
Risks that can create broad or cascading impacts get the most scrutiny. That includes weaknesses in privileged access controls and segmentation, as well as failures to protect customer data. The concern is whether a single compromise could cross boundaries or significantly disrupt customers. Like any business, we may accept certain business risks. The potential for an incident to affect multiple environments raises the level of scrutiny considerably. Our assessment has to reflect how far the impact could extend and the disruption it could cause.
To what extent can security teams actually see what AI is doing across their environments today? Where are the biggest visibility gaps you encounter?
Security teams have some visibility into AI use today, but it remains incomplete. The biggest challenge is shadow AI. Tools are incredibly easy to adopt, allowing employees to use them with corporate data before security and IT even know they exist. That makes it difficult to assess the exposure or determine whether the right controls are in place.
Traditional controls can identify some activity, but understanding what data is being shared and how AI is actually being used remains difficult. Seeing that an employee accessed a tool provides limited insight into the information they submitted or what happens to it afterward. Security teams need that context to evaluate the risk and determine what protections are appropriate. You cannot effectively manage AI risk without knowing where or how AI is being used.
With RapidScale spanning AWS, Azure, Google Cloud, VMware, and hybrid infrastructure, what makes a security solution genuinely operationally viable across that mix, not just technically compatible?
A security solution needs to provide consistent visibility and control across RapidScale’s cloud environments without creating unnecessary complexity for the teams operating it. The team needs to be able to use it consistently across the platforms it supports.
The solution should integrate into existing workflows and, where possible, improve them. It needs to produce actionable information and scale without requiring a different operating model for every platform. The operational effort required to maintain it is part of that evaluation. At RapidScale, that means assessing whether the solution can address the use case across our environments and remain manageable as those environments change. A solution has to work for the people responsible for operating it, with capabilities they can use effectively to reduce risk.
Security vendors increasingly sell “platform consolidation” as an answer to tool sprawl. When does consolidation genuinely simplify security, and when is it simply moving several problems into one larger platform?
Consolidating security tools into a single platform works when it reduces complexity and gives teams better visibility into their environments. Fewer tools can have benefits, but replacing several products with one platform does not automatically solve the operational problems behind tool sprawl. If the platform is difficult to operate, creates new blind spots, or provides weaker capabilities in critical areas, you have simply concentrated the complexity. The goal should not be fewer tools, but a simpler, more effective security operation.
A vendor can demonstrate strong security outcomes, but requires access to sensitive telemetry, identities, or client-environment data. What part of that conversation gets the most scrutiny from you?
When a security vendor requests access to sensitive data or systems, the first question to ask is whether that access is necessary to deliver the security outcome. A strong security capability does not automatically justify unrestricted access to sensitive data or systems. We look closely at what data the vendor can access and the privileges they require. How that access is protected and monitored deserves the same scrutiny as what happens to the data once they have it.
We also consider the potential blast radius if the vendor is compromised. Access that helps a vendor deliver a security capability can also create exposure for us and our customers. That exposure needs to be understood as part of the decision. Ultimately, the access and trust we allow should be proportional to the value the solution provides and how well the vendor can protect the data.
Imagine an existing tool is still “working,” but the environment it was bought for has changed significantly. What would prompt you to reopen that buying decision rather than simply renew?
At RapidScale, we regularly evaluate whether our security tools are still delivering the business and security outcomes they were intended to provide as our environment changes. Renewal is one point in that evaluation, but changes in the environment can warrant revisiting a buying decision earlier.
Taking a FinOps approach to security and asking whether the original use case still exists and whether the tool is being fully utilized are fundamental to minimizing the risk surface. Changes in our environment may create opportunities to expand or adjust that use case. They may also change how much value the tool provides. A tool can continue working exactly as designed while the requirements around it have moved on. If it no longer addresses the risks or operational needs that justified the investment, that is a reason to reconsider it. The decision needs to reflect what the business requires today and whether the tool can continue meeting those requirements.
When RapidScale evaluates a security solution, what does your role look like from problem definition to shortlist, technical validation, business case, and final approval? Where do you have the strongest influence?
As RapidScale’s CISO, my strongest influence on security purchasing decisions is at the beginning of the process, setting the vision and establishing priorities. That means making sure we are solving the right problem with clear security and business outcomes. Those outcomes give the team a basis for assessing potential solutions and determining what needs to be validated.
From there, my team helps build the shortlist and leads the technical validation. My focus stays on strategic fit and whether the investment will deliver meaningful risk reduction and business value. The business case needs to reflect what the team learns during validation, including the operational requirements of the solution. By final approval, we should be able to clearly explain why we need the technology and what outcome we expect from it. That keeps the buying decision connected to the problem we set out to solve.
