C2 Corner

C2 Corner: Why Cybersecurity Leadership is an Organizational Problem First

Written by: 
Carl Saiyed
Chris Camacho
Published on: 
Jun 9, 2026
On This Page
Share:
Try abstract today!
Abstract AI Gen. Composable platform diagram showing data sources, security data pipelines, detection fabric, data lakes, and AI SOC components including Hunt, SIEM Console, and Response & SOAR.

Get Abstracted!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Foreword

By Chris Camacho, Co-Founder & COO at Abstract

One of the best parts of C2 Corner is getting to feature practitioners who see cybersecurity through a wider lens than tools, alerts, controls, or compliance.

Carl Saiyed does exactly that.

His piece starts with a simple but important idea: many cybersecurity failures are not purely technical failures. They are organizational failures. Not because people do not care. Not because teams are incompetent. But because decision-making, ownership, incentives, and consequences are often disconnected across the enterprise.

That is a reality every security leader eventually runs into.

A finding is assigned, but the outcome is not owned. A control exists, but no one has tested how it works in the real world. A dashboard says risk is going down, but the business still has exposure where it matters. A detection fires, but the accountability structure around it is not strong enough to drive action.

At Abstract, we spend a lot of time thinking about visibility, signal, data, and detection. But technology is only useful when it helps leaders see what is really happening and act on it. Data should not just create more dashboards. It should help close the loop between risk, ownership, and consequence.

That is why Carl’s perspective matters. He is not arguing against technology. He is arguing that technology works best when it is part of a stronger accountability architecture.

This is a leadership piece, but it is also a practical one. It challenges security leaders to look beyond whether the metric is green and ask a harder question: Is the outcome actually better?

Why Cybersecurity Leadership Is an Organizational Problem First

By Carl Saiyed

When headlines announce the latest breach, we often assume a technical failure: a missing patch, a weakly defended system, or an unknown backdoor. I think the root cause is organizational, a failure of accountability that no technology can address.

And I will tell you why this distinction isn’t some academic theory.

We have spent decades building better tools, better frameworks, better compliance programs. We have more visibility than ever before. We have more data, more alerts, more dashboards, more regulatory guidance. And yet, still we produce the same structural conditions that produce the same failures. Someone was responsible for the risk without being connected to the consequence. Someone owned a finding but not the outcome it represented. Someone followed the process correctly, but produced the wrong result. Nobody was quite sure who was supposed to fix what was right in front of us.

I didn’t mention a single technology, but if you’ve been in this world for a minute you probably instantly recognize the above. That’s the organizational design problem that cybersecurity leaders need to solve.

The Open Loop

I love Donelle Meadow’s Thinking in Systems. Meadows introduces a concept called the Feedback Loop. In a closed loop, the person making the decision feels the outcome. In an open loop, the consequences land elsewhere. An open loop isn’t malicious by nature, and it’s not incompetence. They are structural and predictable outputs when organizations have separated decision making from operational consequences.

Cybersecurity has a lot of open loops.

The team that implements the preventative controls can’t turn them on until the application team approves the changes. The vendor whose product fails in production over and over and keeps “fixing” it. The team that is responsible to implement the control has to justify why the application that can’t run with the control needs to solve the app problem. The application that goes offline when a vulnerability scanner is within 3 octets of the web server.

The people responsible for these failures made rational decisions. They seem irrational from a cyber perspective, because they were not made within a cyber incentive structure. They were made within the incentive structure available to these decision makers. And that is the distinction that matters most: system wide problems without system wide incentives. You cannot train, hire, or buy your way out of misaligned incentives to system problems.

Instead, the loop is closed by changing the structure. Rebuilding the connection between decision and consequence that the organizational complexity severed.

What Closed Loops Actually Look Like

As a technical practitioner, you learn early that technology will tell you the truth if you listen. TCP is my favorite example - flow control, built in error handling, sequencing. You know the data got there and you can prove it with a packet capture. A bad firewall rule means the packets (or datagrams, we don’t judge) don’t get there. That transparency and directness shaped my views on technology and the organization systems it lives in.

In leadership roles, the feedback becomes slower and more diffuse. The consequence of a decision made today may not arrive for months or years. Cause and effect become decoupled, represented by “metrics”. And, within that gap, a new temptation emerges: to manage the appearance of accountability instead of the reality of it. The metrics, acting as the proxy for the outcome, become something separate that we manage until they are no longer the proxy, but their own thing entirely.

I have seen this play out countless times. The risk was reduced, the vendor managed the problem within SLA, and the auditor is happy.  But is the data truly protected? The metric is healthy. Is the outcome?

I had the opportunity to build a cornerstone security program capability under significant pressure and time constraint. Examiners loved the resulting program, and it went on to be very successful. We had great engineers, project managers, and leadership. But the overall achievement came from refusal to conflate the metric with the outcome. Insisting that the controls actually work under real conditions, not just to check the box. Holding that line required discipline at a time when every organizational pressure was toward the easy button. This discipline is what cybersecurity leadership demands.

The Accountability Architecture

3 easy steps to close loops in your security organization.

Step 1 – Traceability from decision to consequence. Every security decision; risk acceptance, vendor selected, control implemented or not, should trace to a named owner who is accountable for that outcome if the risk materializes. We trace a lot of activity, we need to trace the outcomes. The gap between those two is a breeding ground of risk.

Step 2 – Direct experience of what you own. We often call this “eating your own dog food”. You need to experience as the user how your controls actually work. Not an adoption metric, not a dashboard, not a summary or “my EA took care of that”. You. Try. It. Insulation is the enemy of calibration. You can’t calibrate what you can’t understand. You need the real experience of your controls, under normal conditions, regularly.

Step 3 – Incentives that extend time and span the org structure. Often, decisions are made that solve today’s problem and create tomorrow’s risk. How many times have you seen a remediation deferred to the “next release”, or just risk accepted because fixing it is inconvenient. These decisions are rational within a myopic incentive structure and a short timeline. Cybersecurity is neither of those two things. Build incentive structures that connect decision to consequence over time. Force the loops to close as a matter of practice.

The Leadership Question

There is a question I ask in every new engagement: if the tables were turned, would I want this?

Try it for yourself next time you’re implementing something. Would I want to follow this process? Would I want to receive this notification? Could I take action on this alert? Would I want my information protected by this control suite?

If you answer this question honestly, you might produce some uncomfortable answers. That doesn’t mean the people building them don’t care, it means that there’s organizational distance between the decision maker that can change things and the builders is too great. The discomfort is invisible until it isn’t.

If you use this question consistently and honestly, and act on the answers, you will see change from an organization that performs working to one that is actually working. Controls will be adopted and used because they solve more than one problem, and because they make the right way the easy way. They bring more to the table than “for security purposes”. When friction is the point, we can introduce that friction in a way that enhances the process.

Why This Matters Now

All we hear is more, more, more. The threats are more complex, the regulations are more demanding, the attack surface is more broad. 3rd party, 4th party, 5th party. And our response is always the same. More tools, more controls, more compliance, more headcount. What about the structural conditions that undermine your program?

We, as cybersecurity leaders, need to be as adept and sophisticated about organizational design as we are about technical architecture. We need to be clear that a detection model is only as good as the accountability structure that ensures it gets addressed. Compliance is as valuable as the risk it reduces.

Cybersecurity is an organizational problem that technology helps to address and it does that best when designed to close loops revealed by technology.

The next generation of security leadership needs to be as sophisticated about organizational design as it is about technical architecture. It needs to understand that a detection model is only as good as the accountability structure surrounding it. That a compliance program is only as valuable as the actual risk reduction it produces. That a vendor relationship is only as secure as the loop that connects the vendor’s decisions to the organization’s outcomes.

Carl Saiyed is a cybersecurity executive with experience spanning technical engineering, security operations, architecture, and regulatory compliance across major financial institutions. He holds advanced degrees and certifications including CISSP and CISM.

GET
ABSTRACTED

We would love you to be a part of the journey, lets grab a coffee, have a chat, and set up a demo!

Your friends at Abstract AKA one of the most fun teams in cyber ;)

White light beam passing through a black circle with a pink abstract symbol, dispersing into multicolored beams on the right.
Thank you!
Your submission has been received.
Oops! Something went wrong while submitting the form.