The InfoSec Control Room

In EP018 of The InfoSec Control Room, I challenge one of those governance statements that sounds obvious until someone actually has to make a decision: “The business owns the data.”

But who exactly is “the business”? And what does ownership actually mean?

This episode looks at the difference between owning information and simply administering the systems that store it. I explore who should make decisions about access, classification, sharing, retention and deletion, and why Security, IT, Legal and Privacy can advise and implement controls without replacing genuine business ownership.

I also look at forgotten data, third-party sharing, unnecessary retention, cloud services and AI tools — all areas where unclear ownership quickly turns into unclear accountability.

A useful test is simple: choose one sensitive dataset and ask its supposed owner why the organization has it, who should access it, how long it should be kept, who it can be shared with, and what would happen if it were exposed.

If the answer is “ask IT,” you may not have a data owner at all.

In EP017 of The InfoSec Control Room, I examine one of cybersecurity’s most persistent reporting problems: measuring what is easy instead of what is meaningful. Security teams track vulnerabilities closed, incidents counted, alerts handled, training completion, supplier assessments, audit findings, and dozens of other indicators. But a metric can improve while the underlying security outcome stays exactly the same. This episode looks at how KPIs can unintentionally drive the wrong behavior, why activity should not be confused with outcome, how percentages can create false confidence, and why every security metric should ultimately support a real decision. One question captures the episode: If this number improves, does security actually improve with it? If the answer is ‘not necessarily,’ the KPI may be measuring the wrong thing.

In EP016 of The InfoSec Control Room, I challenge a common assumption in security operations: that a busy SOC must be an effective SOC.

Thousands of alerts, hundreds of investigations, fast ticket closure, large volumes of telemetry, and constantly moving dashboards can make a security operation look productive. But activity is not the same as outcome. The real question is whether the SOC is detecting the things that matter early enough to change what happens next.

This episode looks at alert fatigue, false positives, detection quality, visibility gaps, business context, escalation, analyst workload, automation, feedback loops, and why collecting more data does not automatically produce better detection.

I also discuss why repeated alerts should eventually lead to improvements outside the SOC, why detection rules need to evolve, and why organizations should understand not only what their SOC can see, but also what it knows it might miss.

One of the main ideas from EP016 is simple: the purpose of a SOC is not to look busy. It is to notice meaningful threats early enough for the organization to do something useful about them.

A useful challenge for any SOC is to take its busiest alert category and ask: if this alert disappeared tomorrow, would we actually become less secure?

If the answer is no, perhaps the team does not need to become better at processing it. Perhaps it should stop receiving it.

In EP015 of The InfoSec Control Room, I look at how the CISO role is changing as cybersecurity becomes increasingly connected to customers, products, suppliers, cloud services, artificial intelligence, privacy, regulation, resilience, reputation, and business growth.

The traditional view of the CISO as the person responsible for security tools, policies, incidents, vulnerabilities, and audits is becoming too narrow. Modern organizations increasingly depend on security leaders to help answer a much broader question: can customers, partners, regulators, employees, and leadership trust the way this organization operates digitally?

This episode explores what it means for a CISO to become a trust leader rather than simply a security manager. I discuss why CISOs need to understand how the business actually works, how security can enable innovation rather than simply approve or reject it, and why technical knowledge has to be translated into consequences that executives, customers, and product teams can use.

I also look at the growing overlap between cybersecurity, privacy, legal, resilience, AI governance, supplier management, customer assurance, product development, and reputation. The CISO does not need to own all of these areas, but increasingly needs to connect them when digital risk crosses organizational boundaries.

The episode also explores why honest uncertainty creates more credibility than false confidence, how security can become a commercial advantage, why customer trust can take much longer to recover than technology after an incident, and why relationships across engineering, sales, leadership, legal, and operations are becoming essential to effective security leadership.

One of the central ideas from EP015 is simple: the strongest CISO is not simply the person who knows how to protect systems. It is the person who helps the organization become worthy of trust.

The future CISO needs enough technical depth to understand reality, enough business understanding to make that reality relevant, enough judgment to separate meaningful risk from noise, and enough credibility to influence decisions they do not personally control.

In EP014 of The InfoSec Control Room, I challenge one of the most common habits in cybersecurity governance: treating the risk register as if it were risk management itself.

A register can be detailed, perfectly formatted, fully scored, assigned, reviewed, and still have very little impact on the organization. The real question is not whether the risk exists in Excel or in a GRC platform. The real question is: what decision did the organization make because it understood that risk better?

This episode looks at the difference between recording risk and actually managing it. I talk about risks that remain open for years, treatment plans that keep slipping, owners who do not know they own anything, scores that create false precision, acceptance decisions that are never revisited, and registers that slowly become repositories for every problem the organization does not know where else to put.

I also explore why incidents, audits, supplier problems, control failures, vulnerability assessments, business changes, and operational evidence should continuously influence the risk picture. A useful risk process should move as reality changes. If the evidence changes, the decision should be reconsidered.

The episode also examines real risk ownership, the difference between a risk and an issue, why enormous registers can destroy prioritization, and why risk management should help the business move forward intelligently rather than simply document everything that could go wrong.

One of the central ideas from EP014 is simple: the risk register is a tool, a memory, and a map. It is not the journey.

Cybersecurity risk management is not about making red boxes turn yellow. It is about improving the quality of decisions the organization makes when dealing with uncertainty, trade-offs, exposure, priorities, and business consequences.

In EP013 of The InfoSec Control Room, I look at one of the most common misconceptions in modern cybersecurity and business operations: the idea that outsourcing a service also outsources the risk.

Organizations rely on cloud providers, SaaS platforms, MSSPs, payroll processors, payment providers, telecom operators, external developers, consultants, and many other partners. That is normal. The problem begins when the organization starts treating the supplier’s responsibility as if it removed its own accountability.

This episode explores what really changes when a service is outsourced and what does not. I talk about supplier dependency, shared responsibility, third-party access, contractual obligations, incident notification, concentration risk, subcontractors, exit planning, offboarding, data handling, recovery, and the need to maintain enough internal capability to challenge and govern a provider effectively.

I also look at why third-party risk cannot be reduced to questionnaires and certificates. A supplier may have strong controls and still create major exposure if your business becomes heavily dependent on it. The real question is not only whether the provider is secure. It is what that provider means to your organization if something goes wrong.

One of the core ideas from EP013 is simple: you can outsource the service, but you do not outsource the consequences.

Customers still call you. Regulators still call you. The board still calls you. Your business still absorbs the disruption. Outsourcing can transfer operational responsibility, but it does not make accountability disappear.

In EP012 of The InfoSec Control Room, I explore what happens when prevention is no longer enough.

Security programs spend enormous effort trying to stop incidents, outages, compromises, and failures before they happen. That work matters. But no control is perfect, no environment is static, and eventually something will get through, break, fail, or become unavailable.

The real question then becomes: can the organization still function?

This episode looks at cyber resilience as more than backups, disaster recovery, incident response, or business continuity. It is about the organization’s ability to absorb disruption, keep essential services running, adapt under pressure, recover deliberately, and improve afterward instead of simply rebuilding the same weaknesses.

I discuss critical services, hidden dependencies, realistic recovery expectations, graceful degradation, manual workarounds, supplier dependency, recovery sequencing, people as part of resilience, and why the business should test services rather than simply servers.

The episode also explores why “returning to normal” is not always the right objective. Sometimes normal was the problem. A serious disruption should create an opportunity to change architecture, remove weak dependencies, improve access, replace poor suppliers, and strengthen the way the organization operates.

One of the main ideas from EP012 is this: resilience is not invulnerability. It is the ability to take a hit without losing the organization’s ability to function.

Strong organizations are not the ones that never experience disruption. They are the ones that know what matters, understand what they depend on, keep essential operations moving, recover with intention, and learn enough from disruption to come back stronger.

In EP011 of The InfoSec Control Room, I look at what happens after an organization earns its ISO/IEC 27001 certificate.

Certification can be valuable. It can bring structure, discipline, credibility, and a much clearer way to manage information security. But problems begin when the certificate becomes the objective instead of the result of a functioning management system.

This episode explores the difference between maintaining an ISMS because an audit is approaching and actually using it throughout the year. I discuss risk ownership that exists only in spreadsheets, Statements of Applicability that stop reflecting reality, internal audits treated as rehearsals for certification, corrective actions that close tickets without fixing problems, and management reviews where everybody says “noted” but no real decision is made.

I also look at the role of consultants, auditors, control owners, risk owners, and senior management in making ISO 27001 useful rather than ceremonial. A good ISMS should survive the consultant, adapt when the business changes, learn from incidents and findings, challenge old assumptions, and help people make better security decisions even when no auditor is watching.

One of the main ideas from EP011 is simple: there is a huge difference between an organization that documents how it manages information security and one that manages documents about information security.

The certificate matters, but the real value is underneath it: the decisions, ownership, corrections, useful findings, changing risks, and improvements that happen between audits.

In EP010 of The InfoSec Control Room, I look at a problem that appears in almost every cybersecurity program: organizations produce more security data than ever, yet leadership still struggles to understand what actually matters.

Boards are shown vulnerabilities, alerts, patch percentages, phishing results, incidents, audit findings, risk scores, trend lines, heat maps, and plenty of red, amber, and green boxes. But more information does not automatically mean better decisions.

This episode explores the difference between operational security reporting and executive decision support. A board does not need to know everything the security team knows. It needs a clear view of what changed, where the business is genuinely exposed, which weaknesses matter most, what uncertainty remains, and where leadership needs to make a decision.

I discuss why totals and averages can hide serious risk, why a “green” metric may still conceal an unacceptable exposure, why repeatedly presenting red issues without action makes dashboards meaningless, and why cybersecurity reporting should connect technical weaknesses to business consequences rather than simply presenting activity.

We also look at why board reporting should focus more on movement than status, why security leaders should be comfortable saying “we do not know” when assurance is incomplete, and how to turn reporting into a conversation about priorities, trade-offs, investment, risk acceptance, and accountability.

One of the central ideas from EP010 is simple: the purpose of board reporting is not to demonstrate how busy cybersecurity has been. It is to help leadership make better decisions.

The board does not need another dashboard. It needs clarity about what matters, what changed, what could hurt the business, and what leadership needs to do next.

In EP009 of The InfoSec Control Room, I look beyond the simple statement, “We have a CSIRT,” and ask the question that actually matters: what can that team really do when something serious happens?

A CSIRT can exist on the organization chart, have assigned staff, procedures, tooling, and even a dedicated mailbox, while still being poorly prepared for a real incident. Readiness comes from much more practical things: knowing exactly what the team is responsible for, who it serves, how people reach it, what happens outside business hours, what access responders already have, how cases are handed over, how other departments work with the team, and where outside help is needed.

This episode looks at the difference between a CSIRT that exists and one that can actually function under pressure. I discuss service boundaries, availability, access to systems and logs, case management, practical exercises, relationships with legal and business teams, communication during uncertain situations, team skills, external support, incident closure, lessons learned, and the danger of depending too heavily on a few individuals who hold everything together.

I also explore why a CSIRT should not simply process incidents and move on. A strong response team notices patterns, exposes recurring weaknesses, feeds lessons back into the organization, and helps improve the environment that keeps producing those incidents.

One of the main ideas from EP009 is simple: a CSIRT is not ready because management created one. It is ready when people know how to use it, when the team knows what it owns, when it can reach the right systems and people, and when it can work effectively under pressure.

If you work in CSIRT, SOC, DFIR, SecOps, cybersecurity leadership, IT operations, GRC, risk, audit, business continuity, or incident management, this episode is designed to challenge the difference between having a team and having a real response capability.