Interview with a CISO:
Jack Leidecker, CISO at Gong
Matt Gordon, Intaso, speaks with Jack Leidecker, CISO at Gong, about building a security programme from the ground up, supporting hyper-growth, aligning security with go-to-market, and what aspiring CISOs need to know before stepping into the role.
About the Interviewer:
Matt Gordon
Matt is a Chicago-based cybersecurity talent and advisory partner who works closely with CISOs to help them design, scale, and mature high-impact security and infrastructure teams. He partners with security leaders navigating growth, transformation, and increased regulatory or investor scrutiny, supporting everything from early team design to executive-level hiring.
As a Principal Consultant at Intaso, Matt is part of a global cybersecurity practice with 30+ years of combined experience supporting security leaders and organizations. Intaso’s work is grounded in deep industry knowledge, long-term relationships, and a highly tailored approach to helping security leaders build teams that actually move the business forward.
Jack Leideker
Jack is an accomplished, results-driven, senior security executive with significant domestic and international experience in both public sector and corporate roles. He motivates and develops high-performing teams resulting in a proven track record of success applying an enterprise risk strategy and implementing enterprise-wide technology solutions and services that align to business and customer goals.
As a security leader, he’s built multiple world-class information security and risk management functions within diverse industries.
Jack, thanks for joining us. To start, can you give us a short introduction to your role at Gong and how the security function has evolved since you joined?
JL: Absolutely. I joined Gong as its first CISO, with the remit to build out the security team and programme. At the time, there were no full-time security people in place, so it was a greenfield environment.
Over the past few years, we have built out the core security functions you would expect: product security, security operations and GRC. We also added a go-to-market support function, which we call the Office of the CISO, because of the volume and importance of customer-facing security work at Gong. That team supports customer interactions, audits and security-related sales activity.
In addition, we have built out red team and architecture capabilities, so the function has grown from nothing into a much broader security organization.
When you joined as Gong’s first CISO, what already existed and how did you begin to identify what needed to be implemented?
JL: A lot of it comes down to general philosophy. I have built, or rebuilt, security teams a number of times, and the one consistent theme is that no two environments are the same.
What worked at one company is not necessarily what will work somewhere else. So the first step is understanding where the organization is today. What controls already exist? What security activity is already happening inside other teams?
Even if there are no dedicated security people, there are usually security-related functions taking place somewhere. Someone may be looking at logs. Engineers may already be doing code reviews. Different teams may be handling parts of the security picture, but those activities may not be centralised, joined up or fully understood.
For me, the first 30 to 60 days were about understanding the lay of the land. What is Gong already doing? How does it work? Where are the risks? Where does security need to integrate? From there, we could start to build a roadmap for where we wanted to go.
When I first put that programme together, the response was essentially: “This looks great… but how can we do it ten times faster?” That led us to hire more quickly than I had originally expected, so we could scale across the different areas we needed to build.
Did you face any challenges in understanding what was happening already versus what needed to happen next, especially in a hyper-growth environment?
JL: That proximity was useful. When you are trying to make significant change in an area, working side by side with that team helps you understand how they operate. You can then build security in a way that supports their goals, rather than slowing them down unnecessarily.
There is always an element of people saying, “We are doing okay, don’t worry about it.” But Gong was going through a major growth stage, moving from a few hundred people to more than a thousand in a relatively short period of time. The company understood that some things needed to scale.
One thing that helped was that I was initially brought in under R&D. I was meeting with engineering leaders weekly, sometimes daily, which gave me a strong understanding of their priorities and the pressures they were under.
The goal was not simply to add security controls. It was to understand what the company was trying to achieve, how engineering needed to scale, and how security could integrate into those processes while maintaining, or even improving, velocity where possible.
For example, automation in the CI/CD pipeline, automated testing and better approaches to authentication can make life easier for engineers while improving security. Not everything works that way, sometimes security does create additional work, but the more you understand the business and the teams you work with, the better you can design a programme that fits.
Given Gong’s environment and the type of data the business handles, compliance must have been a major priority. How did you balance compliance with the broader security programme?
JL: Compliance is always important, but my view is that if you have good security, good IT practices and good development practices, compliance becomes much easier.
Rather than starting with, “We need to do this for SOC 2” or “We need to do this for ISO 27001,” I prefer to focus on the underlying practices. What are we doing for monitoring and logging? How do we handle vulnerability management? How do we understand what is happening across the environment?
If those things are done well, the compliance work becomes far more manageable.
One of the things I am proud of is that, as the programme matured, audits became less disruptive. Early on, audit work was a major event. More recently, when I have asked engineering leaders how impactful an audit was, the answer has been, “I hardly noticed it.”
For me, that is the goal. We have the processes and controls in place. We may still need to work together on evidence, but the audit itself should not feel like a major disruption.
The mistake some companies make is building only for a specific framework. For example, if you focus purely on PCI requirements, you may pass PCI but still leave significant security gaps. I would rather build a risk-based programme that addresses the right risks first, and then map that back to the relevant compliance requirements.
You also built a red team function relatively early. Why was that important?
JL: When you are putting new controls, processes and detections in place, you need to validate that they work as expected.
Some organizations wait a long time before building a red team capability, but for me it was important to do it early. If we introduced a control and it did not actually address the risk we thought it would, we needed to know that and adjust.
That red team and purple team activity helped us validate the programme. It allowed us to ask: are our detections working? Are we addressing the right risks? Do we feel more confident about the environment?
It is not just about finding issues. It is about improving the programme and making sure the basics are effective before expanding into other areas.
You mentioned the Office of the CISO earlier. What drove the creation of that go-to-market-facing security function?
JL: Part of it was driven by the nature of Gong’s business. Security and privacy are important to our customers. We are dealing with sensitive business data, so customers quite rightly want to understand how we protect it.
Gong also had ambitious plans to work with large enterprise customers, and we knew that would bring a high volume of customer security reviews, audits and detailed questions.
The Office of the CISO helped us support those conversations properly. It works with sales, understands what customers need, helps respond to audits and builds trust with customer security teams.
Security professionals often want to speak with other security professionals. Even if a sales engineer knows many of the answers, customers may still want to engage with someone who owns the security programme. Having that function in place helps us support the sales process in a credible way.
How did you demonstrate the business impact of that function?
JL: One of the advantages at Gong is that the company is very data-driven. We were able to track the impact of security involvement in the sales process.
For example, we could see that without security involvement, enterprise win rates were much lower. When security was involved in those opportunities, win rates increased significantly. On one level, that is not surprising, large companies are unlikely to buy without going through security review, but having the data made it much easier to articulate the impact.
We could also track how often customers asked about security and privacy, how often those topics came up in introductory calls, and how much customer-facing work the security team was doing.
That kind of data makes the value of security more tangible. It is not just a cost centre conversation.>It shows how security supports revenue, customer trust and enterprise readiness.
Was the external-facing team only effective once the internal foundations were in place?
JL: Exactly. The external team is only useful if the internal foundation exists.
You cannot talk credibly to customers about controls, processes or maturity that are not actually in place. Companies will go deep during audits and reviews. They want to understand what is happening, and you cannot pretend something exists if it does not.
The Office of the CISO can articulate the programme externally, but it is only successful because of the work happening across security, R&D, IT and the wider business.
A good starting point is to look at what the company has already committed to customers. What security requirements exist in contracts or security appendices? Are we doing what we said we would do? If not, we either need to implement those controls or have a difficult conversation with the customer.
That takes away some of the debate. If the business has committed to something, security needs to ensure the organization can deliver it.
Before the Office of the CISO was created, sales engineers were involved in responding to security questionnaires. Did the new function also help them focus more effectively?
JL: Yes, although perhaps indirectly. Before we built the dedicated function, sales engineers were spending time on security questionnaires. In many cases, their answers were broadly right, but even being 10 or 15 percent wrong can have a material impact.
Those answers can make their way into contracts, and then you may need to explain later that something was not quite accurate. That is not a good position to be in. We explored whether we could simply train sales engineers to handle more of that work. I put together an outline and said, “Here is the 20 to 40 hours of training someone would need to be reasonably prepared.”
The response was that they were hoping for something closer to two hours. That would not have been enough to understand the nuance.
Looking back over the past five years, is there anything you would do differently if you were starting again tomorrow?
JL: There is always room for improvement. Some of our approaches, such as vulnerability management, could probably have been simpler.
But I also think every company and every point in time is different. Technology has changed a lot over the past five years. For example, containerisation and more ephemeral infrastructure change how you approach certain risks. In some cases, you can reduce risk by not having to manage traditional operating systems in the same way.
That is why I do not believe in copying and pasting the same security programme from one company to another. The environment, technology, people and business goals are different. You should always be learning and adjusting your approach.
Gong has moved through a significant maturity curve. How did you think about the shift from growth mode into a more mature operating model?
JL: In some ways, it never really changes. You should always be asking: how are we growing, where are we improving, and how are we addressing risk?
There were times when I could probably have grown the team faster from a headcount perspective, but I was careful not to grow too quickly. I did not want people to be underutilised or for the team to scale faster than the work justified.
The key is understanding the value each team provides and how each function addresses risk. That data is useful in any environment, but it becomes especially important as the company’s growth rate changes or priorities shift.
You also need to think about scale. If a company grows from 1,700 people to 5,000 people, the security team should not necessarily triple in size. The question is: how do we scale more efficiently? How do we use automation, better processes and tooling to support growth without simply adding people at the same rate?
Another important point is being clear about what you are not doing. Security teams can always do more with more resources, but it is important to explain what risks are not being addressed because of current priorities, capacity or budget.
That creates a more productive conversation. If the business wants to move faster on a particular framework, customer requirement or capability, you can explain what it would take in terms of people, cost and operational change.
Does risk tolerance change as a company grows and revenue scales?
JL: It changes, and it is active. The metrics that matter at one stage may become less useful later. Early on, the focus may be on maturity. Then it might shift to customer acquisition. Later, it may become more about scale.
The important thing is to ask whether the metrics you are reporting are relevant to the business and whether they resonate with the audience. Sometimes security teams report on things like vulnerability counts because that is what they have always reported, but the question is whether it is driving the right engagement.
You need to make sure people understand the risks you are taking, the risks you are addressing, and the risks you are not addressing. The way you communicate that will depend on the company, the leadership team and the stage of the business.
The important thing is to ask whether the metrics you are reporting are relevant to the business and whether they resonate with the audience.
Automation and AI are major topics across security right now. Which workflows have you seen benefit most?
JL: The first thing is making sure the right guardrails are in place. Before using these tools broadly, you need the right controls and the right enterprise licences so you can use them safely.
One interesting example is contract summarisation. Our legal team uses summarisation to identify areas they need to review, and security works closely with them because exceptions often come to our team. That does not mean AI is making the decision, but it helps people find the right areas faster.
That distinction is important. AI can be very useful for analysing data, identifying areas of interest, creating tickets automatically and accelerating certain workflows. It can also help with content creation, as long as the output is properly reviewed and validated.
Where it works less well is when you remove the guardrails or rely on it to make decisions without validation. You do not want tools going off on their own and taking actions you did not expect.
There are now so many AI security tools being added to existing platforms. How do you avoid tool sprawl while still advancing the team?
JL: The first question is whether the tool provides the value it claims to provide.
A lot of vendors, not just in security, have added some form of AI so they can say they have it. So you need to understand what the tool is actually doing. Is it just a simple wrapper around an LLM? If so, you may be better off using the LLM directly.
Some tools do much more than that. They may be fine-tuned, integrated into workflows or genuinely adding value. But you need to validate that.
The next question is whether it makes the team efficient enough to justify the cost and implementation effort. I remember a team wanting a tool to automate a task, which sounded good in principle. But when we looked at it, the task took around two hours per quarter. The implementation effort and cost did not justify the saving.
Automation for its own sake is not always useful. If something takes two hours now but will become ten or twenty hours as the company scales, then it may make sense to get ahead of it. But if it is a small, occasional task, the ROI may not be there.
The goal is not to automate because it is interesting. The goal is to solve a real problem in a way that makes sense for your specific environment.
A lot of security leaders are aiming to become CISOs. What advice would you give to managers, directors or VPs who want to make that transition?
JL: The first thing is making sure the right guardrails are in place. Before using these tools broadly, you need the right controls and the right enterprise licences so you can use them safely.
One interesting example is contract summarisation. Our legal team uses summarisation to identify areas they need to review, and security works closely with them because exceptions often come to our team. That does not mean AI is making the decision, but it helps people find the right areas faster.
That distinction is important. AI can be very useful for analysing data, identifying areas of interest, creating tickets automatically and accelerating certain workflows. It can also help with content creation, as long as the output is properly reviewed and validated.
Where it works less well is when you remove the guardrails or rely on it to make decisions without validation. You do not want tools going off on their own and taking actions you did not expect.
Used in the right way, automation can be a strong accelerator. But it still needs oversight.
How did you build that business and cross-functional muscle before becoming a CISO?
JL: Earlier in my career, I noticed that security teams were often saying the right things, but people were not listening. That made me realise we were not always speaking the same language as the business.
For me, one step was getting an MBA, which helped me better understand strategy, business impact and how to articulate risk in commercial terms. That will not be the right path for everyone, but the principle is important.
You need to understand the business you are in. At Digital Realty, I had to learn about real estate and data centres. At Gong, I had to understand the sales process because Gong sells to sales teams. That changed how I thought about when security should engage in the sales cycle and how we could support the business.
Not everyone has time to pursue formal education, but everyone can start by learning their own business more deeply. How does the company make money? Where are the blockers? Where can security create positive impact? Which teams are under pressure, and how can you help?
Most leaders are open to those conversations. Asking where teams are running into challenges and how security can support them makes you a better leader and helps you identify impact you may not have seen before.
Closing thoughts
For Jack, the role of the modern CISO is not simply to build controls or respond to audits. It is to understand the business, communicate risk in a way that resonates, and build a security programme that supports growth, customer trust and long-term resilience.
At Gong, that meant building the security function from the ground up, creating a dedicated Office of the CISO, using data to show security’s commercial impact, and continually adapting the programme as the company matured.
As security becomes increasingly connected to revenue, trust and customer confidence, the ability to translate technical risk into business value is becoming one of the most important skills a CISO can develop.