Security programs that struggle share a common trait: they operate in isolation from the business. The ones that thrive are deeply embedded in business strategy, viewed not as gatekeepers but as partners who help organizations grow securely.
We spoke with Andy Welch, a seasoned cybersecurity executive and fractional CISO, on the Scale to Zero podcast. Andy has led security, GRC, and risk strategy at Yahoo, IBM, Goldman Sachs, and KPMG, bringing a pragmatic executive-level lens to building secure, compliant, and resilient organizations across Fortune 500 firms and emerging tech companies.
You can read the complete transcript of the episode here >
How should you think about security versus compliance?
Andy reframes the debate entirely: security and compliance should not be at odds. He views compliance broadly — covering both external requirements (regulations, contracts, court mandates) and internal obligations (security policies, control standards).
When compliance mandates are clear, specific, and traceable, they become great inputs to the security roadmap rather than blockers. They function as a form of security requirements that can be prioritized alongside any other set of requirements.
The practical approach:
- Treat compliance obligations as requirements. Good compliance mandates focus on what needs to be done, not how — making them directly translatable to actionable security work.
- Weave them into the existing program roadmap. Do not treat compliance as a separate workstream that competes with security initiatives.
- Have the frank conversation early. Ask stakeholders how they think about requirements. Once they internalize that compliance is just another input, integration becomes natural.
How do you align security strategy with business goals?
Andy considers this the single biggest differentiator between security programs that succeed and those that struggle. The only reason security exists is to protect the enterprise — its people, partners, customers, and brand. That foundational linkage must drive everything.
The biggest hurdle: gaining persistent, regular access to the right business stakeholders to understand where the organization is headed. His approach:
- Identify the people driving business forward and become relevant to their conversations.
- Provide value first. Understand their motivators and demonstrate how security helps them achieve their goals.
- Keep the dialogue open and regular. One-time alignment meetings are insufficient — the relationship needs continuous refreshing.
- Build security champions on the business side who see security as a trust-builder with end customers, not a blocker.
Andy shares a powerful example: during a penetration testing engagement, a hesitant IT leader — burned by past consultants who dropped tool-based findings with no context — became a close partner once Andy invited him to participate directly. The result was faster access to systems, better risk context, and a dramatically improved deliverable.
How do you build a security culture of positive friction?
Andy actively asks his teams to critique him. He calls it “positive friction” — creating an environment where respectful disagreement is not just tolerated but encouraged when the goal is better outcomes.
His practical advice for leaders getting started:
- Start with your direct reports. Do not try to transform the entire organization at once. Test the approach in one-on-one conversations with trusted people.
- Ask specific questions. “Do you see a way we could accomplish this better?” or “Have you seen this work differently elsewhere?”
- Welcome ideas from any level. When someone brings an insight nobody else has considered, that is a golden opportunity to elevate the entire program’s output.
- Reinforce that security must be value-driven. When the team understands their job is to help others succeed in building secure things, it completely changes the energy of relationships.
This approach carries beyond internal teams. The same principle of inviting participation and welcoming input applies to business partners, engineering teams, and executive stakeholders.
What is the current state of GRC maturity in enterprises?
Andy is candid: in many organizations, GRC maturity is low. GRC is often seen as “the assessments team” — a group that shows up after development, runs a checklist, drops a list of problems on someone’s desk, and walks away. In that mode, GRC becomes quickly marginalized.
The shift happens when GRC moves upstream and becomes a valued partner in the process:
- Embed into development and operations directly. Understand their workflows and help them make smarter security decisions as decisions are being made.
- Define a clear vision, scope, and value proposition. Everything the team does should tie back to these, making it easy to communicate value to stakeholders.
- Structure teams by internal vs. external focus rather than by governance, risk, and compliance silos. The internal team handles policies, control standards, and risk oversight. The external team manages regulatory engagement, third-party risk, M&A, and customer assurance. This aligns naturally with how businesses are actually structured.
At Yahoo, Andy built the GRC program using this structure, and it transformed how the organization perceived the team — from a checkbox function to a strategic partner.
How do you fight vendor and tool sprawl?
When Andy sees organizations struggling with multiple overlapping tools, he identifies a root cause: they never had a cohesive security architecture or long-term plan. They built capabilities reactively, picking the best tool for each issue at the moment it arose.
The fix is strategic, not tactical:
- Recognize it is not a tooling issue — it is a strategy issue. Ad hoc tool selection always leads to overlapping capabilities, integration gaps, and bloated costs.
- Map out your future state architecture. Define what your security ecosystem should look like holistically.
- Build a reasonable roadmap to get there. This requires investment, negotiation, and coordination across teams.
- Evaluate tools against the architecture, not in isolation. The best tool for a specific problem may be the wrong tool for your ecosystem.
The payoff: a leaner, more effective, and more affordable program with better outcomes and less complexity. Andy compares it to an all-Apple household — introducing one Android device for a single feature creates friction that compounds with every additional mismatched tool.
What does security leadership look like in high-stakes situations?
Andy shares a formative experience from early in his career: leading a breach response for a major healthcare organization where attackers had root access and full lateral movement. During containment, an operations lead revealed that one compromised system controlled an MRI scanner’s cooling functions.
If tampered with, it could trigger a rapid quench — an uncontrolled depressurization of liquid helium that behaves like an explosion. The team had to immediately reprioritize, take the machine offline, restore from backups (which had not been recently tested), and get it back in service for patient care.
The lesson: security is not always about protecting data. Sometimes it is about protecting people. And the only reason the team could respond quickly was because they had already built trust with operations, the backup team, the recovery team, and the network team. That trust — built through the same partnership principles Andy advocates — enabled rapid, coordinated action when it mattered most.