How Can a CISO Lead Security Without a Team?

TL;DR

A CISO can build an effective security program without direct reports by distributing security responsibilities across the organization instead of creating a centralized empire. The approach starts with established risk and security frameworks, adapts their controls to the company, and involves business functions directly so that ownership, engagement, and business understanding do not remain isolated within a security team.

Transcript

Welcome. I, uh, appreciate you, uh, dealing probably with a couple things this morning, the wind, the rain, the eight o'clock hour and, and potentially, uh, some jet lag. So I, I know these eight o'clock sessions are a little rough, so really appreciate you being here. I'll try to make this as valuable as I can. Um, what I'm gonna talk about today ... Read More

Key Insights

• Centralized security organizations can create an ivory tower dynamic in which the business treats security as a separate group's responsibility. This separation weakens ownership and engagement because employees assume that security specialists will handle every relevant issue for them.
• Security ownership remained difficult across every organizational model the speaker experienced, including centralized teams, central business partners, liaisons embedded in business units, duplicated satellite teams, and business-unit security teams without a central function. Structural variation alone did not resolve the engagement gap.
• A CISO with little staff or budget can begin by recruiting contributors from across the organization instead of immediately building a large centralized department. This army-of-one or army-of-a-few approach is intended to diffuse responsibility and participation more broadly.
• Business-driven security requires the business to understand security and the security function to understand the business. Separate organizations can prevent that mutual understanding, contributing to finger-pointing, an us-versus-them attitude, and continued reliance on a central security group.
• Established frameworks provide a practical starting point for program design because organizations do not need to invent security requirements, risk methods, or control collections from scratch. The speaker recommends selecting relevant industry practices, adopting useful elements, and customizing them for the organization.
• Risk analysis at AvidXchange was driven from the top down through the board's interest in the COSO model and its seventeen principles. ISO 31000 and 800-30 were placed underneath COSO to provide additional structure for the company's risk framework.
• The risk framework was applied across business units and functions, including security, to create a risk model, a heat map, and a ranked list of risks. This positioned the security program within a broader analysis of organizational risk rather than treating it as isolated.
• The Critical Security Controls and the Cybersecurity Framework were used to organize the security side of the program. More specific controls were placed underneath them, reflecting the broader principle that frameworks should be adapted rather than used unchanged or created entirely from scratch.

Questions & Answers

Q: How can a CISO lead security without direct reports?

A CISO can lead without direct reports by treating security as a responsibility distributed across the organization rather than as work owned exclusively by a centralized department. When starting with no staff, essentially no budget, and an ad hoc set of controls, the CISO can gather contributors from multiple functions, use established frameworks, identify risks, and engage business units directly in the program.

Q: Why can centralized security teams weaken business ownership?

Centralized teams can signal that security belongs to a separate group of specialists. Business employees may then assume that the security team will take care of relevant problems, allowing responsibility to be abdicated to that function. The resulting separation can produce poor mutual understanding, limited engagement, finger-pointing, an us-versus-them attitude, and what the speaker calls ivory tower syndrome.

Q: What security organization models did the speaker encounter?

The speaker encountered a centralized core security team, a core team with centrally employed business partners, and a core team with partners who reported within business units. Other models included a corporate team with satellite security teams that duplicated functions such as identity and access management, as well as large business-unit security teams operating without a centralized security function.

Q: Do security business partners solve the engagement problem?

Security business partners did not consistently solve the problem in the speaker's experience. Partners employed by the centralized team could still be perceived by business units as members of a separate group. Even when a partner was located within and reported through a business unit, a substantial gap remained. The case therefore suggests that adding liaisons alone does not guarantee ownership or engagement.

Q: How should a company choose security controls and frameworks?

A company should first identify its relevant requirements and recognized industry practices, then adopt the parts that make sense and customize them to fit the organization. The speaker argues that teams do not need to invent controls, models, or frameworks from scratch. At AvidXchange, the selected resources included COSO, ISO 31000, 800-30, the Critical Security Controls, and the Cybersecurity Framework.

Q: How was risk management structured at AvidXchange?

Risk management was driven from the top down, beginning with the board's interest in the COSO model and its seventeen principles. ISO 31000 and 800-30 were placed beneath COSO to provide a risk framework. That framework was used to analyze business units and functions, including security, and to produce a risk model, heat map, and ranked list of risks.

Q: Can this distributed security approach improve an existing program?

The approach is not limited to a new company or a security program being created from scratch. The speaker says its ideas can also be used to reassess or rethink an existing program, including how functions and responsibilities have been allocated. An established organization can examine whether centralized ownership has reduced engagement and consider distributing participation more broadly across business functions.

Q: What problems is business-driven security intended to address?

Business-driven security is intended to address the disconnect created when the business does not understand security and the security function does not understand the business. According to the speaker, this separation contributes to finger-pointing, us-versus-them behavior, and ivory tower syndrome. Distributing involvement across the organization is meant to increase engagement and prevent the business from simply handing all security responsibility to specialists.

Summary & Key Takeaways

• Centralized security teams can unintentionally encourage employees and business units to abdicate responsibility. Across companies of different sizes, structures, and geographic footprints, the speaker repeatedly observed weak ownership, poor engagement, finger-pointing, and an ivory tower dynamic, even when organizations added security liaisons or separate business-unit security teams.

• At AvidXchange, the speaker began an experiment in leading the security program with no direct reports and essentially no initial staff or budget. Instead of immediately hiring a large central team, the plan was to gather participants from across the organization and make security responsibilities more broadly distributed throughout the business.

• The program used existing models instead of inventing requirements and controls from scratch. COSO's seventeen principles, ISO 31000, and 800-30 supported risk analysis, while the Critical Security Controls and Cybersecurity Framework guided security work. These resources were customized to the organization and used to rank risks across major functions.