In Part 1 of this two-part series, I argued that the moat is dry. When NotPetya hit Merck in 2017, it didn’t climb a wall. It came in through trusted vendor software, the routine traffic every perimeter is built to admit, and Merck put the damage at more than $1.4 billion. Its insurers then tried not to pay, and after that fight, underwriters started asking much harder questions.

AI has since made attacks like that cheaper and faster. In IBM’s 2026 Cost of a Data Breach report, one in four malicious breaches was AI-enabled, and breaches that took more than 200 days to find and contain cost about $1.3 million more than those that didn’t. Deepfaked executives, software that can be talked into things and AI agents holding credentials are attacks on trust first and technology second.

Yet the people we hold responsible are set up to lose. Some 64% of CISOs still report into IT leadership, only 10% influence financial decisions, and only a quarter say board discussions of cyber risk run longer than 30 minutes. They are accountable for the breach without budget authority, and they check the work of the people they report to.

The organizations that feel safest about the next two years are not the ones with the most tools. They are the ones where leadership understands AI risk, someone clearly owns it, and the security team has the authority to act. That is a governance problem, and it has a governance fix.

A roadmap for reconstruction

1. Take security out of IT, and do it before the breach

No company lets the finance department audit its own books. That is why internal audit reports to the board’s audit committee rather than to the CFO. Security deserves the same independence for the same reason: the people who build and run the systems should not vouch for them. The CISO’s job is not to run technology. It is to govern how people, partners and machines behave around the things the organization cannot afford to lose, and to tell leadership the truth about that risk.

That does not make the job less technical. A CISO who can’t read an architecture diagram, question an engineer or spot a vendor’s overstatement will be steamrolled in the first meeting. The role needs an engineer’s depth. It is just bigger than engineering, the way a general counsel needs to know the law but is hired for judgment.

In practice, that means a direct line to the CEO and a board committee. Equifax did this after its 2017 breach. Its new CISO, Jamil Farshchi, called the direct line to the CEO and board the key to the turnaround, and noted that it costs nothing. Vertex Pharmaceuticals took a different route: its CISO reports to the Chief Scientific Officer, which puts security next to what the company actually protects, its research. Choose a model deliberately. Most organizations never choose; they inherit one.

2. Hand the CISO the AI governance pen

Only 19% of organizations report coordination between their AI governance and security teams. Every AI tool the business adopts is a security design decision, and it needs one accountable owner. Otherwise, you have a committee that approves tools and a security team that finds out later. But accountable doesn’t mean alone, which brings us to the most important step.

3. Give everyone a voice

A CISO knows security. A CISO does not know research, or claims processing, or the manufacturing line. Elevating the CISO works only if decisions get made with the people who live with them: research leaders, business owners, legal, finance and the CIO. Build a standing risk council where those voices shape controls before they’re imposed, and where a scientist can say “this will break my work” and be taken seriously. The point of elevating the CISO isn’t to put one person in charge of everyone else’s work. It’s to make sure the person who owns the risk is in the room, and that everyone affected by the decision is in the room too.

Security decisions made in isolation get worked around. Decisions made together get followed.

4. Define “ready,” then hire and develop to it

New York’s cybersecurity regulation for financial firms calls the CISO “a qualified individual” but never says what qualified means. Here’s a working definition, in the form of two tests a board can give. The first is technical, and it is not optional:

• Can you tell us what we own, who can reach it, and how fast we can recover, and when did we last test that?
• Have you personally used the AI tools our employees use? Can you explain prompt injection and agent permissions to us in plain English?
• Where does your threat knowledge come from besides vendors: peer networks, industry information-sharing groups, red-team results?

The second test is about judgment and behavior. It is the one most security leaders are never given:

• What do our people actually do when a request seems urgent and comes from someone senior?
• Which risks have you advised us to accept, and why? A CISO who never recommends accepting a risk is a gatekeeper, not a risk officer.
• Can you translate a risk into dollars and days of downtime?
• Which research and business leaders do you consult before a control changes how they work?

And one question for the board itself: Have we given this person authority that matches their accountability?

👉 Click here to download a sample CISO job description👈

5. Make sure AI agents are governed like employees

The CISO doesn’t provision these accounts; the CISO makes sure someone is accountable for every one of them. Every non-human identity needs an owner, the least privilege it needs, monitoring, and a kill switch. Among organizations that had an AI-related incident, 92% lacked proper AI access controls.

6. Hold everyone to the clock, not the checklist

Ask every part of the organization for time to detect, time to contain and time to recover, using tested numbers rather than estimates, and report them to the board. The 200-day line in IBM’s data is worth more than a million dollars per breach.

7. Make sure the boring things get done

Encryption, multi-factor authentication, asset inventory and network segmentation are not glamorous, but they are exactly what insurers began requiring after the Merck case. Doing this work belongs to the technology teams. The CISO’s job is to verify that it’s done and to tell the board plainly when it isn’t. If your underwriter is asking for these controls, your board should be too.

8. Give the board more than 30 minutes

Make cyber a budget conversation rather than a status update. If the CISO’s board time is spent on regulatory trends instead of business trade-offs, the board is being briefed, not governed.

A word to CIOs

I know how this reads to a CIO: someone telling you to give up a direct report. But a CISO who reports to the CIO is grading the boss’s homework. The CIO is measured on availability and speed of delivery. The CISO is measured on risk. That tension is healthy only between peers. Elevating the CISO doesn’t diminish the CIO; it frees the CIO to build without also serving as auditor of what they built. The two roles aren’t a senior and a junior version of the same job. One builds and runs the organization’s technology. The other is responsible for whether the organization, its people included, can be trusted.

A good CIO should lean on the CISO and also be a little afraid of the CISO, the way a good CFO relies on the auditor and is a little afraid of what the auditor will find. That fear is not hostility; it is the reason the books stay clean. Pair it with the partnership described above, and the CIO gets something no direct report can offer: someone with the standing to say “no, not like that” before the board has to hear it from an attacker.

The CIO’s seat at the table appeared when technology became the business. The CISO’s is appearing because trust has become the business, and AI has made that impossible to ignore. Some organizations are already moving. In IBM’s follow-on research, 85% said they plan to increase security spending after learning what frontier AI models can do to their systems, compared with 64% who planned to spend more after suffering a breach. Learning from the threat is far cheaper than learning from the post-mortem, and the organizations that get there first will be the ones where security, research and the business decide together.

The moat is dry. Stop dredging it, and give the person defending the castle a seat at the table.

In June 2017, a piece of malware called NotPetya got into Merck & Co. without climbing a single wall. It arrived through a backdoor in accounting software supplied by a Ukrainian vendor, the kind of trusted, routine traffic every perimeter is built to let through. It spread to some 40,000 of the drugmaker’s computers, and Merck put the damage at more than $1.4 billion.

Then several of Merck’s insurers argued they owed nothing, because the attack was attributed to Russian military intelligence and their policies excluded acts of war. The fight ended in a confidential settlement in January 2024.

Two lessons sit in that story. The moat didn’t matter, because the threat came in with the traffic the moat was designed to admit. And the people who price risk for a living were the first to notice and the first to send the bill.

That was 2017, when attackers still needed humans at the keyboard. Increasingly, they don’t.

Here is the argument of this two-part series in two sentences. Security stopped being a technology problem with business consequences; it is now a business risk with a technology component. Most organizations are still organized the other way around, and the person they hold responsible for that risk sits inside the IT department, reporting to the people whose work they are supposed to check.

What AI actually changed

IBM’s 2026 Cost of a Data Breach Report, based on 602 breached organizations, found that one in four malicious breaches was AI-enabled, a 56% jump in a single year. Those breaches averaged $6 million, about $1 million above the global average of $4.99 million. In the U.S., the average breach now costs $11.5 million.

You don’t need a computer science degree to understand what changed. Three things matter:

• The con got a better voice. Deepfake impersonation was the most common AI-driven attack in IBM’s data, at 45%. The oldest scam in business, the urgent wire transfer, now arrives in the CFO’s actual voice on a video call.
• Your software can be talked into things. “Prompt injection” means hiding instructions inside an email, document or web page that an AI assistant reads and then obeys. It is social engineering aimed at the software instead of the employee, and no amount of annual phishing training protects against it.
• You’ve hired employees with no background check. Every AI agent holding credentials is, in effect, a new hire with keys to your systems, no manager and no HR file.

Notice what those three have in common. Each one is an attack on trust, on whom we believe, what we obey and whom we let in, and only then on technology. That distinction matters for everything that follows.

Meanwhile, employees aren’t waiting for permission. Shadow AI, meaning tools staff use without sanction, showed up in 43% of breached organizations this year, up from 20% the year before. Breaches involving AI systems themselves rose to 21% of all incidents, and the most common way in wasn’t the model at all. It was the plumbing around it: compromised APIs and plug-ins, and misconfigured cloud workloads.

Why the moat is dry

Moat security is easy to recognize. There’s a perimeter, a couple of expensive appliances, an annual training module, and a binder of procedures nobody reads until the auditor visits. It assumes the enemy is outside.

Today, much of the risk has been invited in the assistant reading the email, the agent holding the credentials, the vendor pushing the update. When Johnson Controls was hit by ransomware in 2023, the attackers first got into the company’s Asia offices and spread from there across the network. The company confirmed data theft and more than $27 million in costs, net of insurance. One breach in a distant office, and the moat was irrelevant.

Moat organizations measure activity. Attackers measure time. IBM found the average time to identify and contain a breach rose to 247 days, the first increase in five years. Breaches contained in under 200 days cost $4.32 million; those that ran longer cost $5.65 million. And 53% of breached organizations hadn’t encrypted sensitive data at rest and in transit. The basics still aren’t done.

My email signature reads “Process is the evil twin of progress.” Moat security is process mistaken for protection.

Prepared versus old school: the numbers

In fairness, IBM sells security tools, and I’m aware of the irony of citing a vendor in a piece that warns against learning from vendors. The fieldwork is done by the Ponemon Institute, though, and the pattern matches what independent CISO surveys show. The gap between prepared and unprepared organizations is not subtle:

Sources: IBM/Ponemon, Cost of a Data Breach 2026; IANS/Artico Search, CISO Perspectives on AI Risk 2026.

The most revealing finding comes from the IANS survey of 113 CISOs. Mature AI security programs explained why some security chiefs feel safer today. But confidence about the next two years tracked something else: whether leadership understood AI risk, whether someone clearly owned AI governance, and whether the security team had budget authority and enough staff. In other words, the factor that matters most is governance, not technology.

The CISO problem: under-trained and under-armed

Under-trained. Many of today’s security leaders learned the job defending against people, not software that behaves like people, and much of what they know about AI came from the companies selling the cure. When IANS released its research this year, one of its partners pointed out that most AI risk data comes from vendors and so reflects the supply side. If your threat briefings, your training and your tools all come from the same sales channel, you’ll end up with a well-funded blind spot. Only 53% of CISOs in a LevelBlue survey said they felt prepared to defend against AI-enabled adversaries.

This is not about age. A veteran who keeps learning beats a newly certified buyer of AI-branded appliances every time. What matters is whether someone is still learning now, not when they first learned.

Under-armed. The IANS 2026 board engagement study found that 95% of CISOs brief their boards regularly, but only 10% influence financial decisions. Only a quarter say board discussions of cyber risk run longer than 30 minutes. And 64% of CISOs still report into IT leadership. That leaves the CISO accountable for the breach without authority over the budget.

The lab is not the accounting department

Everything above gets harder in a research organization. Research runs on unpredictable workflows, tools adopted the week they appear, enormous data transfers and outside collaborators. A control that slows a scientist doesn’t stop the work. It moves the work somewhere security can’t see.

The stakes are rising at the same time. Google’s threat intelligence group reported that in the second quarter of this year it investigated extortion cases involving stolen AI research, including one in which a healthcare organization lost drug research and an AI model. It also tracked a China-linked group targeting academic, medical and military research institutions in North America.

R&D doesn’t need an exemption. It needs a different deal: wide freedom in how the work gets done, in exchange for a short list of fixed rules around the assets that matter most. In practice, that means protecting around the lab rather than inside it:

• Make the safe path the fast path. Offer pre-approved sandboxes, compute environments and AI tools that are quicker to use than the workarounds. Researchers don’t resist security; they resist friction.
• Watch instead of block. Monitor what leaves the lab and how, rather than putting a checkpoint in front of every action. Unusual data movement and odd access patterns are how theft gets caught without slowing discovery.
• Classify by value, not by department. Open science, pre-publication results and proprietary or controlled work need different protection. Lock down the crown jewels, not the whole lab.
• Borrow from the research networks. The research and education networking community solved a version of this years ago with the Science DMZ, a design that moves high-performance research traffic outside the enterprise firewall and secures it with targeted controls and monitoring instead.

Some rules don’t bend: federal research-security requirements, defense contracting standards, export controls. But that list should be short, explicit and explained, not a binder of procedures nobody in the lab can name.

We regulate security by tax status, not consequence

Public companies must describe board oversight of cyber risk to the SEC, though the final rule dropped a proposal to disclose whether they even have a CISO. New York’s financial regulator requires the CISO to report to the board in writing every year, and the board must understand and fund the program, public or private. Hospitals still operate under a HIPAA Security Rule written in 2003; its overhaul has slipped to July 2027. A privately held research firm can fail as badly as any public company, and the rules barely notice. Don’t wait for a regulator to tell you what your risk already has.

That is the diagnosis. In Part 2, the prescription: an eight-step roadmap for rebuilding, starting with the reporting line that most organizations never chose and simply inherited.

With a career built at companies like Visa, Ellie May, and Blackhawk, Selim Aissi, a 2026 CSO hall of fame inductee, understands how boards and executives demand a clear justification for cyber security investment, especially considering today’s difficult economic climate.But getting security leaders to communicate tech debt, operational fragility, and long-term cyber risk in business terms the board can actually act on isn’t always straightforward.

A lot of organizations add tools, and more platforms and controls in response to new threats. Yet that doesn’t necessarily address underlying complexities. Security investment can actually increase operational and strategic risk.

“I think there’s a tipping point once a reasonable depth of defense is in place,” he says. “When there’s a reasonable level of automation of security controls and cross integration of security tools, anything beyond that could potentially be overspend and could potentially add risk to the entire organization.”

So the challenge is to know when an environment exists and functions without the need for a sudden budget spike.

“All of the KRIs and KPIs in place should be able to indicate the level of resiliency,” he adds, “in addition to other controls such as making sure there are processes that would allow for detection of, let’s say, API abuse, cloud-level abuse, and, increasingly these days, AI as it adds yet another threat vector.”

Understanding risk also lies in recognizing the distinction between organizations that are genuinely resilient, and those that appear mature on paper, focused on fine-tuning policies, compliance, governance, and frameworks.

“These are all important but they shouldn’t be the main focus,” he says. “The first step is knowing where the data is and once in transit, how it needs to be protected with the most updated protocols.”

Aissi expands on how organizations unintentionally create risk through tool sprawl and operational complexity, how boards should think about long-term cyber resilience, and why AI and cloud expansion are accelerating security debt faster than many enterprises can manage. Watch the full video below for more insights, and be sure to subscribe to the monthly Center Stage newsletter by clicking here.

On resiliency: A security organization that’s mature — and I’ve seen many and have built several — is one that’s architecturally designed to be resilient. But resiliency means different things to different people. To me it means that recoverability is tested often, making sure that in case of an event or breach case of lateral movement, the company can react according to a very clear playbook that’s been thoroughly tested. I also think a resilient organization is one that has the right controls of the right places, and one that also has metrics around them that indicate if there’s an event, and how well the tools work.

An area which I’m really passionate about is data protection. But how do you know the data is protected? A resilient organization doesn’t look at whether the data is encrypted at rest or not. It looks at the entire lifecycle of that PII. Meaning the organization has a very clear discovery mechanism to know exactly where the data is. It could be on laptops, servers, or in a public cloud. It could be in many different places, and it can be structured or unstructured.

On organizational risk: My definition of security debt is the accumulation of risk because of investment in areas where complexity is added, where a lack of automation is exaggerated, and where there’s overcompensation for some controls that aren’t needed. So if an organization spends money without effectively simplifying security controls, and automating more than what needs to be automated, that is tech debt.

Most commonly, tech debt in security is defined as the accumulation of vulnerabilities that aren’t patched, the over complexity of identity exposure management (IEM), and a lack of understanding of where data is. So most significant organizations, especially in fintech, have a huge volume and velocity of PII, and in health tech, PHI and security debt is not knowing where all the data is, or that it’s potentially not protected in some areas. So in addition to the data itself, IEM, and lack of automation and overlaying security tools are other forms of tech debt.

On managing board expectations: The board really wants to understand the risk of cyber security investment, and anything else could potentially be perceived as noise. I see many CISOs taking metrics upon metrics, and dashboards upon dashboards of all sorts of variations of vulnerability management. But what the board really cares about is what the risk is to the business if the most critical systems aren’t patched. Anything else could be perceived as not a concern or a business risk.

CISOs should speak in terms of impact of any real or perceived threat on the business, and be specific. So going back to vulnerability management, let’s say there’s a zero day that was patched or maybe multiple ones that were patched. How do you explain that to the board? You say we patched five zero day vulnerabilities. And honestly, the reaction is probably, who cares. The story should sound like these five vulnerabilities if unpatched, could have put certain systems down for three days, or it would’ve been much easier for an adversary to attack this revenue generating system. That’s what the board cares about, the impact on the revenue. And that’s how CISOs need to speak to them.

On AI: Security didn’t get a seat from the beginning when it comes to AI. So how do we explain to the board that developers might start sharing the company’s source code with Claude and it could potentially leak? This is something we’re all trying to figure out. But we should start speaking from a business perspective about the benefit of AI to the security organization, to the security tooling, to security operations, how it could be more efficient and effective, and at the same time, highlighting some of the risks to the organization — not theoretical risks, but risk related to the organization. If it’s a financial institution and AI agents are deployed in some transactional application, I think the CISO should speak to the board about the business risk of not deploying the necessary security tools to ensure that those AI agents don’t go rogue, that the LLMs are protected. So those are the business terms we need to be speaking about.

Several months ago, I was invited to an event for CTOs. Just looking around the room, I could see someone had made an assumption about my title. I am a chief transformation officer, not a chief technology officer.

I stayed anyway to see how the other type of CTO thinks about AI. When a CISO got onstage and said, “This is our time,” my immediate reaction was cringe.

I remember thinking, AI is going to change jobs, workflows, skills and how people experience work. Tools and controls alone will not produce transformation. The real challenge is redesigning how work gets done.

I knew from the beginning that AI would require partnership across technology, security, legal, finance and the business. But I saw people and operating-model change as the center of the work, with technical and governance teams enabling it. After working to operationalize AI across a company, I can see what I missed.

Why I started with people and operating models

My original assumption was based on my own experience managing through change. Technology creates possibility; operating models create value. Access is not adoption.

A team can run an impressive pilot that never becomes part of how the function operates. Experimentation means very little if leaders have not defined the business outcome, how the workflow will change or how the team will sustain it once the pilot ends.

People leaders understand job design, learning, manager behavior and the emotional reality of change. People resist initiatives that feel disconnected from the work they are accountable for every day.

Organizations also tend to budget for technology and not for transformation, treating licenses, APIs and model usage as the whole investment. The real cost includes the time people need to learn and build fluency, and the clarity managers need about what good use looks like. 

A technically strong AI program can fail because the organization never changes around it. AI raises the floor, but transformation raises the ceiling. The larger value comes from what happens around the technology, including where human judgment is still required and what the company can now do differently.

Research supports the importance of that organizational layer. McKinsey’s 2025 State of AI report found that redesigning workflows was the factor most associated with reported bottom-line impact of generative AI. 

Operationalizing AI shaped my answer

The more I moved into execution, the more obvious it became that any single function can’t own AI transformation. Technology, data and security could not sit alongside the people transformation as support functions. Leaders across the business have to help design it.

At Branch, I am the executive accountable for AI across the company, including our enterprise strategy and the work of connecting governance, technology, priority use cases and organizational change. Once I started leading that work, I kept running into decisions my team could not make. We needed technology and data leaders to determine whether the architecture was ready and how models would connect to our systems. Security and legal had to establish the boundaries. Finance needed visibility into consumption. The business still had to decide which workflows deserved investment and own the result.

Every practical decision exposed another dependency. We needed an operating model that made routine decisions clear and gave higher-risk work the right review. Good governance should work like a freeway, with lanes, offramps and rules everyone understands, not a roadblock that stops progress. 

Operationalizing AI taught me that no one function can own execution because the work happens across workflows rather than within the boundaries of the org chart.

After eight months of doing this work, I believe someone has to own the transformational work within the organization, but technology, security, legal, finance and people leaders each carry critical parts of the execution. Then, individual functions own their use cases and results.

What a chief AI officer should actually own

Every company needs to know which executive is accountable. Whether that person needs the title of chief AI officer depends on the company.

A dedicated role can be valuable when AI activity is fragmented and the company needs to move from pilots to an enterprise operating model, but it can’t substitute for shared ownership across the leadership team.

That distinction is showing up in the role itself. CIO’s examination of the chief AI officer’s evolution describes a shift away from a central leader owning every AI activity and toward a model where the AI executive establishes strategy, standards and common capabilities while enabling the business to execute. In my experience, that is much closer to what the work requires.

The accountable executive should decide where the company will focus and make sure governance produces decisions quickly enough for teams to act. They need alignment from the leadership team on which risks the company is prepared to accept and how it will know the work is paying off. They also own how the organization changes around the technology. That includes how people learn, what managers expect, how workflows get redesigned and where the company reinvests the time AI creates.

They should not become an AI island. They can’t be the technical concierge for every tool request or the gatekeeper every function waits on. That structure gives the rest of the executive team permission to outsource responsibility for a transformation that affects all of them.

Finding someone who fits that profile is its own challenge. I would look for a transformation leader with real technical fluency. They need to work credibly with architecture, data and security leaders. Their job is to connect those decisions to workflow redesign and bring the organization with them.

In some companies, that person will be the CIO. The 2026 State of the CIO research describes CIOs increasingly acting as AI orchestrators and change management champions. In other companies, the accountable executive may be a chief transformation officer, a chief operating officer or a dedicated CAIO. The title matters less than the mandate, authority and ability to lead across boundaries.

When I think back to that CTO event, I understand why the CISO said, “This is our time.” AI has expanded the mandate of security and made its partnership with the business more important. I also understand why I reacted so strongly. People are the transformation. Ultimate accountability still sits with the CEO. Functional leaders own outcomes in their areas. The board needs visibility into strategy, material risks and oversight. The AI leader keeps those layers connected.