Red Flags in Cybersecurity Programs

Even when security programs appear functional on the surface, there are often deeper warning signs that something isn’t working as it should. Sometimes they show up as organizational friction, unclear ownership, or decisions made without proper visibility or accountability. Left unchecked, these issues weaken the program over time and increase the odds of a serious incident. Recognizing these warning signs early can help strengthen the security program and address problems before they lead to an incident.

The following red flags are some of the most telling I’ve seen across industries and company sizes.

The CISO Doesn’t Have Visibility or Authority Over Production or OT Environments

In many organizations, the CISO is empowered to secure the corporate IT environment—email, laptops, and internal networks—but lacks authority over many of the key systems that actually run the business. These might include customer-facing applications, cloud platforms, or operational technology (OT) like control systems, and energy infrastructure.

This is a serious failure in governance. If the security team can’t see into those environments, they can’t assess the risk or identify malicious activity. And if the CISO doesn’t have the authority to set security requirements, enforce standards, or block dangerous changes, they can’t reduce cybersecurity risk.

The common rationale is that these environments are too sensitive, or their uptime requirements are too high, to risk adding security tools or controls. In other cases, responsibility is nominally assigned to a product team or operational unit, but there’s no dedicated security leader and no formal security program in place. Sometimes security is allowed to “influence” decisions, but influence without authority means security is optional. And optional security is not good enough in systems that directly impact customers, revenue, or safety.

Questions to ask:

• What environments fall outside the CISO’s authority, and how are cybersecurity decisions made in those areas?
• Can the CISO enforce standards or block high-risk changes in production or OT systems?

Frequent CISO Turnover

While high turnover in the CISO role is common, it often indicates structural issues; e.g, unclear expectations, limited authority,lack of executive support. You can’t build an effective, long-term security strategy if your cybersecurity leadership changes every 12 to 18 months.

CISOs often leave because they’re not given the authority to do the job they were hired to do. They’re brought in to lead cybersecurity but are excluded from critical environments, denied access to the board, or expected to approve risk decisions without meaningful influence or decision-making authority. The organization expects them to own cybersecurity risks, but doesn’t give them the ability to manage them.

Some CISOs are hired after a major security incident and burn out trying to clean up systemic problems under unrealistic timelines. Even when both the CISO and the organization have high expectations for the role, the CISO may find that the role lacks the positioning, budget, or influence needed to deliver meaningful change. When it becomes clear the role isn’t set up for success, they leave

Questions to ask:

• How long did our last CISO stay? Why did they leave?
• What organizational or cultural barriers have made it difficult for security leaders to succeed here?

The CISO Doesn’t Have a Clear Line to the Board or Executive Leadership

Effective oversight requires a direct line between the CISO and board or executive oversight. If everything the board hears about cybersecurity is filtered through the CIO or CTO, important context may be lost or deliberately softened. This isn’t necessarily the result of bad intent, but their goals often conflict with secruity. Security can delay go-live dates, increase costs, or require rework, which can make it tempting to downplay risk.

When the CISO is isolated, presenting to the board (or executive leadership) only once a year, or not at all, the board may not hear about systemic issues until they become public. A mature program brings the CISO to the table regularly and ensures there’s a clear path to escalate concerns when risks aren’t being properly addressed.

Questions to ask:

• When was the last time the CISO briefed the board or audit committee directly?
• When was the last time they briefed the executive leadership team?
• If the CISO disagrees with IT leadership about a risk decision, how is that resolved?

The Company Doesn’t Maintain a Cybersecurity Risk Register

If your company can’t name its top cybersecurity risks, how is it supposed to manage them? A cybersecurity risk register is a foundational tool. It doesn’t need to capture every minor issue, but it should clearly document the company’s top concerns, who owns each risk, what actions are being taken, and the current status. Ownership is critical. The risk register should identify an accountable business leader for each risk. Cybersecurity risks belong to the business, not the CISO.

The security team and business leaders should review and update the risk register regularly as they close out risks, launch new projects, or confront new and evolving threats. Ideally, the organization will integrate the register into a broader enterprise risk management framework so leaders can evaluate cyber risk alongside financial, legal, and operational risks. Boards should ensure the company maintains a register, that the most significant risks are highlighted in their briefings, and that the organization has effective processes for addressing organizational and cybersecurity risks.

In my experience, organizations that lack risk registers have CISOs who are siloed and lack the authority to manage risk across the enterprise. Without visibility or accountability at the business level, cybersecurity decision-making is often inconsistent, and in many cases mid-level leaders are able to opt out of controls or standards without consequence. Risk registers help create visibility, and visibility is the first step to accountability. Without one, executives may lack the insight they need to brief the board on critical risks and their progress toward reducing them.

Questions to ask:

• Do we have a cybersecurity risk register? Who owns and reviews it?
• Do we have an enterprise risk management program? Who is responsible for it?
• What are the top cybersecurity risks in the risk register right now?

Risk Acceptance Falls on the CISO Instead of the Business

Risk acceptance is an important component of managing cybersecurity. No security program can stop every threat or eliminate every vulnerability. When an organization encounters significant risks that cannot be easily mitigated, it has to decide whether to accept the risk or to expend significant effort or resources to address it. For example, the organization might have to decide whether to accept the risk of running a legacy application that doesn't meet its security standards, or to purchase an an expensive replacement.

In less mature organizations, the CISO (or CIO) is often responsible for accepting risks even though, in most cases, they have little control over the decision. This is foolish as it removes responsibility from the business leaders responsible for the areas where the risks originate, and puts pressure on the CISO to accept risks or grant exceptions to keep projects moving or maintain the status quo. In organizations without a risk register or formal risk management processes, business leaders may also accept risks implicitly without documentation or accountability. This results in the business accepting the risk without executive leadership having any awareness of it.

In mature environments, business leaders own the risks and decide whether to accept them. The CISO will provide input, explain the impact, and offer up alternative possibilities, but they can't accept the risk themselves. If the risk materializes, the lost revenue, legal liability, or reputational harm will impact the company, not just the security team. Some companies have a cybersecurity oversight committee (which may include the CISO) that is responsible for reviewing and accepting risks. Others may require individual business leaders to sign off on risks originating in their areas. In any case, it's important that the leaders accepting the risks have a level of authority commensurate with the risks they are accepting. Put simply, a business "leader" who can't make a $10,000 purchase shouldn't be accepting a $10 million risk.

Questions to ask:

• When cybersecurity risks are accepted, who is accountable for the decision?
• Are business leaders consistently engaged in those decisions, or does it default to the CISO?
• How are accepted risks documented and how often are they reviewed?

No Clear Cybersecurity Strategy or Roadmap

Most security teams stay busy responding to incidents, supporting projects, and addressing vulnerabilities. But without a clear strategy, that work becomes reactive and fragmented. The program may be doing dozens of things, but still not addressing the company’s most important cybersecurity problems. Without a strategy, even well-funded security programs can feel like a collection of disconnected projects. Leaders may highlight activity and spending, but those efforts don’t necessarily add up to meaningful risk reduction.

This often shows up in board briefings that are full of buzzwords (cloud-native, zero trust, AI, unicorns, and rainbows) but lack a coherent story. You may hear about ten initiatives but walk away unsure whether the program is progressing, backsliding, or treading water. Buying products and launching initiatives can look like progress, but without a clear strategy and roadmap, the organization may still miss its most critical risks.

A good cybersecurity strategy should provide high-level guidance for addressing the company’s most critical risks and protecting its most important assets. The roadmap should then translate that strategy into a sequence of projects and initiatives. The strategy sets the direction; the roadmap explains how to get there. The CISO should be able to answer five basic questions:

1. What are we trying to protect?
2. What are our top risks?
3. What is our strategy for reducing those risks over the next 12–24 months?
4. What is our roadmap for implementing that strategy?
5. What are the biggest obstacles that we expect to face?

If the CISO can’t answer these questions clearly, the board should treat it as a warning sign that the program lacks direction.

The Company Doesn't Test it's Incident Response Plan (or doesn't have one)

Incident response is both a technical function and a crisis management function. If your company suffers a breach, ransomware attack, or major outage, you’ll need to coordinate across legal, communications, HR, IT, cybersecurity, compliance, and executive leadership. And you’ll need to move fast.

An effective incident response plan should document roles, decision-makers, escalation paths, and notification protocols. It should also clarify which leaders are accountable for business decisions (e.g., making public statements, activating the company’s cyber insurance policy). Business and security leaders should review the plan at least annually and test it via tabletop exercises that simulate real-world situations. A plan that sits untouched will quickly become outdated, leaving the organization unprepared when an incident occurs.

Tabletop exercises are one of the most effective tools for improving incident readiness. A tabletop exercise simulates a real-world cyber incident and asks participants to make decisions about the situation presented to them. These exercises are designed to test how the company will make decisions during an incident and can be tailored for technical responders, IT and business leaders, or executives. A technical tabletop might simulate a ransomware outbreak and require participants to decide what countermeasures to use to contain the incident. An executive tabletop might focus on determining SEC materiality, making public statements, and working with regulators or law enforcement. To simulate real-world circumstances, tabletop exercises often introduce complications, e.g., the CISO or another key leader is unavailable for part of the exercise (even if they are sitting in the room).

Beyond testing the plan itself, tabletop exercises help leaders understand what’s expected of them, surface blind spots, and clarify assumptions. For example, it’s common to find that participants disagree about who has authority to make a key decision such as activating a cyber insurance policy or incident response retainer. I've also worked with business leaders who assumed the incident would be short-lived and that their IT and security teams would work around the clock ("all hands on deck") until it is resolved. Real incidents, however, can drag on for weeks and planning shifts and coverage is essential. Requiring internal teams to work extremely long hours can burn them out quickly and result in team members quitting mid-incident (it's happened).

Tabletops can also highlight misalignments, showing that leaders may prioritize security or business continuity differently than participants expect. For instance, in one tabletop I facilitated, participants indicated that if the CEO’s account were compromised, they wouldn’t disable it without his permission. The CEO responded that, while he would want to be notified immediately, the security team should disable it right away to contain the threat, prioritizing damage control over his convenience.

Addressing these issues in advance strengthens the company’s ability to respond effectively when a real incident occurs and can help the company avoid painful mistakes. Boards should ask whether tabletop exercises are taking place, who participates in them, and whether they are required by regulation or insurance.

If your company has never done a tabletop exercise, or if no one can remember when the last one happened, that’s a red flag. Boards should hold management accountable for reviewing the plan regularly and testing it with the participation of technical and business leaders. Regular review and realistic testing will help turn the plan into a capability the organization can rely on when it matters most.

Questions to ask:

• When was our incident response plan last reviewed and updated?
• Have executive leaders, legal, and/or communications teams participated in a tabletop exercise?
• How often do we test the plan, and what lessons have we applied from those exercises?
• Who has decision-making authority during a major incident, and is that clearly documented?

Conclusion

Cybersecurity oversight is about ensuring the right structures, strategies, and processes are in place for the cybersecurity program to be successful. The red flags in this chapter point to governance failures that can leave the company exposed, even when day-to-day operations appear to run smoothly. Boards should ensure the CISO has the authority and visibility to succeed, hold management accountable for addressing risks, and create space for ongoing, candid discussions about cyber risk. By recognizing these warning signs early and acting on them, boards can strengthen the company’s security posture and support a more resilient cybersecurity program.