The Board's Cyber Handbook

Before you start

What this is. The NACD/ISA handbook is the best-known board guide to cyber oversight, and it earned that. It is also written the way governance documents get written: careful, committee-shaped, and pitched at a Fortune 500 audit committee that already has a full-time CISO and outside counsel on retainer. This version says the same six things in a different register, and adds the part we think is missing — what any of it looks like when the company has 200 employees instead of 20,000, and when the "cybersecurity department" is one internal IT manager and a provider like us.

How it's built. Six chapters on what a board owes the company, then fifteen short tools you can pull off the shelf when a specific thing lands on the agenda. Each chapter has a lead author and a short note from the other one, because we disagree in useful places and hiding that would make this less honest, not more.

• David Levin, CEO. He runs the business, buys the technology, signs the invoices, and has watched a lot of owners get sold things they didn't need.
• Daniel Ramos, CISO. He runs the security practice, reads the advisories, and gets the call at 11 p.m. when something is actually wrong.

A note on the numbers. Where we cite a statistic that came out of the NACD/ISA handbook's own research, we say so, because we did not re-run their surveys. Where we cite an incident or a rule — Change Healthcare, MOVEit, the SEC's four-day clock, NIS2's penalty ceiling — those are matters of public record and we've stated them as we understand them. Where a number is a forecast dressed up as a fact, we say that too. See the source note at the end.

A note on copyright. This is our own writing and our own argument, not a copy. The original handbook is copyrighted by NACD and ISA, it is free to obtain, and any director serious about this subject should read it alongside this one. We think ours is more useful for a mid-market board. We do not think ours replaces theirs.

PART ONE — WHY ANY OF THIS LANDS ON YOUR DESK

1. Dear fellow board member

David Levin

I'm not here to scare you. If you want to be scared, there is an entire industry standing by, and it bills hourly.

Here's the plain version of what's changed. For most of the last twenty years, cybersecurity sat with IT, IT sat with operations, and the board heard about it once a year in a slide deck with a padlock icon on it. That arrangement worked because the downside was mostly embarrassment and some cleanup cost. It doesn't work now, for one unglamorous reason: the technology stopped being the plumbing and started being the building.

Think about what your company actually runs on. Your revenue moves through software. Your customer relationships live in a database that a vendor hosts. Your people work from four locations and a kitchen table. Your last three growth initiatives were technology projects wearing a business costume. The NACD's own 2026 survey found 72 percent of directors expect to pursue technology investment as a growth initiative this year, ahead of new products, ahead of acquisitions, ahead of hiring. That tracks with what I see. Nobody I talk to is planning growth that doesn't route through a system.

So when a board says "cybersecurity is an IT matter," what it's really saying is "the thing our strategy depends on is somebody else's problem." That's the part that doesn't survive contact with a bad week.

Here's the analogy I keep coming back to. You own the building. You do not personally inspect the sprinkler system, and nobody expects you to. But you do decide whether the building has a sprinkler system, whether it's tested, what it cost, and whether the answer to "is it working?" comes from the person who installed it or from somebody independent. You don't need to be a fire engineer for any of that. You need to know which questions have real answers and which ones have comfortable ones.

That's this whole book, honestly. You're not being asked to become technical. You're being asked to stop accepting comfortable answers.

The three things that actually changed:

Your technology decisions are now strategy decisions. Artificial intelligence is the loudest current example. The NACD reports 62 percent of public company boards now have AI as a routine agenda item, more than double 2023, and 76 percent of directors expect AI investment to factor into growth. Both things are true at once: the technology can genuinely save real hours, and the same technology hands attackers better tools and hands your company new ways to leak. You cannot govern the upside and delegate the downside. They are the same decision.

Somebody wrote your name into the rules. I'll let Daniel handle the specifics, because that's his end of the table. The short version for owners and directors: regulators stopped asking whether the company had security and started asking what the board did about it. That's a change in who's exposed, not just what's required.

The failure is no longer contained to you. A ransomware attack that came in through a supplier cost one large international retailer roughly a third of its annual profit, according to the handbook's reporting. A carmaker halted production across multiple plants and dragged thousands of suppliers along with it. Neither of those companies had bad security by the standards of their industry. They had partners.

What I'd tell a fellow owner over coffee. You are not going to buy your way out of this, and you are not going to hire one person who makes it go away. What you can do is treat it like every other material risk you already know how to govern: know what it could cost you in dollars, know who owns it by name, know how you'd find out if it were going badly, and check that the answer you're getting is the real one. That's four things. They're all things a board already does for credit risk, and none of them require you to know what a firewall is.

One more thing before I hand over. The most expensive cyber problem I see in mid-market companies is not an attack. It's deferred maintenance — systems nobody replaced because replacing them was a capital request with no obvious return, so it lost every budget cycle for six years running. The federal government's cyber agency has taken to calling legacy systems ticking time bombs, and while I usually flinch at that kind of language, the underlying point is fair. Old systems are cheap right up until the week they aren't.

If your board does one thing after reading this chapter, make it this: ask what's running in the business that the vendor no longer supports, what it would cost to replace, and what happens if it fails on a Tuesday. You will not enjoy the answer. You will be glad you have it.

Daniel's note. David is being generous about the industry that bills hourly, and I'd know, because I'm in it. Let me be blunt about the sales dynamic he's dancing around: fear sells product, and a board that is frightened buys badly. It buys the thing in the demo instead of the thing that closes the gap. The boards I respect most are the calm ones, because calm boards ask second questions.

2. What actually changed, minus the theatre

Daniel Ramos

Let me start by taking a number away from you.

You will read that global cyber losses are heading toward $20 trillion a year. You'll see it in vendor decks. It's in the handbook I'm rewriting. It is not a measurement — it's a projection built on other projections, and if you tried to audit it you would find fog. I'm not repeating it as fact, because the fastest way for a security leader to lose a board is to hand them a number they later discover was marketing.

Here is what I will stand behind, and it's quite enough.

The attackers got organized, and then they got automated. Ransomware is no longer a person with a script; it's a business with a support desk, an affiliate program, and negotiators who know your revenue before the call starts. On top of that, attacks have moved from AI-assisted to AI-generated. The practical translation: the phishing email that used to give itself away with bad grammar now doesn't. The fake voice on the phone asking your controller to move money now sounds like your CFO, because sixty seconds of his voice from a conference panel is enough to clone it. Neither of those requires a sophisticated adversary anymore. They require a subscription.

Nation-state actors are sitting inside infrastructure, not stealing from it. The Chinese state-linked activity tracked as Volt Typhoon is the clearest public example. The pattern that matters to a director is the technique: rather than deploying obvious malware, the intruders use the tools already present on the system — the same administrative utilities your own IT team uses — so their activity looks like routine work. It's called "living off the land," and it's why some of these intrusions went undetected in U.S. energy, water, and telecom networks for more than two years. If your mental model of a breach is an alarm going off, replace it. The realistic model is a quiet guest who has been in the house long enough to know your schedule.

Your suppliers became your attack surface. Verizon's 2025 Data Breach Investigations Report found the share of breaches involving a third party doubled year over year, from 15 percent to 30 percent. That is the single most important trend line in this book. Nearly a third of the time, the failure wasn't yours. It was someone you bought from, integrated with, or granted access to and forgot about.

And the regulators moved the target from the company to the boardroom. The U.S. Securities and Exchange Commission's 2023 disclosure rules require public companies to report material cyber incidents within four business days of determining materiality, and to describe annually how the board oversees cyber risk. The European Union's NIS2 directive goes further and puts obligations directly on management bodies, with penalties reaching €10 million or 2 percent of global turnover. Nineteen U.S. states now have their own privacy regimes, each with its own definitions and clocks. State attorneys general have started coordinating — the multistate Blackbaud settlement was $49.5 million and, notably, mandated enhanced board reporting as part of the remedy. And Delaware courts have been expanding the theory that a mission-critical risk left unmonitored is a board failure, not just a management one.

Now the honest severity read, because I owe you one of those in every chapter.

None of this means your company is about to be destroyed. Most organizations, most years, absorb a couple of contained incidents and move on. The tail risk is what changed, not the average day. What a board is actually governing here is the difference between "we had a bad week and told people about it properly" and "we had a bad quarter, discovered it late, disclosed it wrong, and are now explaining ourselves to a regulator and a plaintiffs' firm at the same time."

That difference is almost never about buying better security products. It is about four unglamorous things: knowing what you have, knowing who's responsible, having practiced the bad day before it arrived, and being able to prove any of that afterward.

What we tell our clients. Assume compromise is possible on any given day and build so that it stays boring. Boring means: it's detected in hours rather than months, it's contained to one part of the business rather than all of it, you can restore from backups the attacker couldn't reach, and you can tell your regulator, your insurer, and your customers a clear and accurate story about what happened. A company that can do those four things has a bad Tuesday. A company that can't has an event that shows up in its valuation.

David's note. Daniel just talked you out of a $20 trillion number, and I want you to notice that, because it tells you something about who to trust in this field. The people worth listening to subtract claims. The ones to watch out for only ever add them.

PART TWO — THE SIX THINGS A BOARD OWES THE COMPANY

The original handbook calls these principles. I'd call them the six places a board can actually change the outcome, which is the same idea with less ceremony. — DL

Principle One: Treat it as a business risk, and price it

Lead: David Levin

Every board on earth already knows how to govern a risk it can price. You do it with credit, with currency, with key-person, with supply. Somebody puts a number and a probability in front of you, you argue about the assumptions, and you decide how much of it you're willing to carry.

Cyber has been the exception, and the reason is silly: the reporting has historically been in a language that can't be priced. "We blocked 4.2 million threats this quarter" is not a risk statement. It's an activity statement, and worse, it's an activity statement designed to make you feel good. Four million blocked attacks tells you nothing about the one that gets through.

What treating it as a business risk actually means. It means the same conversation you have about any material exposure:

What would it cost us? Not "a lot." A range, in dollars, for the two or three scenarios that could genuinely hurt. Ransomware that takes out the systems the business runs on. A breach of the customer data you hold. A critical vendor going dark for two weeks. For each: direct costs — response, legal, notification, possibly ransom — and indirect ones, which are usually bigger. Lost revenue while you're down. Customers who don't renew. The deal that dies in diligence.

How likely is it? Honestly stated, with the reasoning shown. Anyone who gives you a precise probability with a decimal point is selling. A defensible range with the drivers named is real work.

What are we spending, and against which of those scenarios? This is where most boards find something uncomfortable. Security budgets tend to accrete by product, not by risk. You end up with three tools that overlap on the thing you were already good at and nothing on the thing that would actually take you down.

How much of this are we choosing to accept? Some of it, always. The goal was never zero. The goal is a number you chose on purpose instead of a number you ended up with.

On the AI question specifically, since it's on every agenda. Boards keep asking me whether they should be investing in AI. Wrong question, or at least the wrong first one. The better question is: what does this specific use of it do to our exposure? Because a company adopting AI tooling is usually doing three things at once — creating real productivity, handing employees a new way to send company data somewhere it shouldn't go, and adding a system whose failure modes nobody in the building fully understands yet. All three are true. Govern all three. The one that catches most mid-market companies is the middle one, and it doesn't come from the AI project. It comes from the staff who signed up for tools on their own because the approved thing was slow.

What good looks like from the board's chair:

• Cyber shows up in the strategy discussion, not only in the risk report. When you approve a transformation project, an acquisition, or a new product line, someone has already asked what it does to the exposure — at inception, not at launch.
• The CEO can talk about it without turning to the technical person. Not in detail. But if your chief executive cannot describe the company's top two cyber exposures in business terms, the risk is not owned at the top, whatever the org chart says.
• Budget moves are tied to a specific risk being reduced, and somebody comes back later and reports whether it was.
• The company can use its security posture commercially — in contract negotiations, in enterprise sales, in diligence. That's the tell that it's finally being managed rather than endured.

Questions I'd actually ask in the meeting:

1. If we lost our core operating systems for ten business days, what does that cost us? Show me the math, not the adjective.
2. Which three of our systems, if they went down, would stop us from taking revenue? What's protecting those specifically?
3. What's still running that the manufacturer no longer patches? What's the replacement cost, and why hasn't it won a budget cycle?
4. Where did our last million dollars of security spending go, and which of those scenarios did it reduce?
5. Where does our security posture win or lose us business? Has anyone asked the sales team?

Daniel's note. One correction to David's framing, and it matters. He says put a dollar figure on it, and he's right, but be careful whose model produces it. If the quantification comes from the vendor selling the remedy, the number will always be large enough to justify the remedy. Use a recognized method — the FAIR model is the common one, and the point of it is that the assumptions are visible and arguable. If you can't see the assumptions, you're not looking at a risk estimate. You're looking at a quote.

Principle Two: Know what you owe, and know when the clock starts

Lead: Daniel Ramos

This is the chapter where a board's personal exposure lives, so I'll be direct.

Under the SEC's 2023 rules, a public company must disclose a material cyber incident within four business days — and the clock starts when the company determines materiality, not when the incident is neatly understood. That distinction is the whole game. Nobody fails this rule because they didn't know it existed. They fail it because on day one, in the fog, nobody could say who was authorized to make the materiality call, and by the time that got resolved the clock had been running for a while and the record looked bad.

The same rules require an annual description of how the board oversees cyber risk. Read that sentence like a lawyer would: it presumes there is a process, that it existed before the incident, and that it can be described. If a board is inventing its oversight process while drafting the disclosure that describes it, that's the finding.

What the rest of the map looks like, plainly:

• NIS2 in the European Union puts duties on management bodies directly, with penalties up to €10 million or 2 percent of global turnover. If you sell into Europe or have an entity there, this reaches you.
• DORA covers financial entities operating in the EU and is prescriptive about operational resilience and third-party oversight.
• CIRCIA in the U.S. brings critical-infrastructure incident reporting on its own timeline.
• Nineteen U.S. states have privacy laws with differing definitions of a breach and differing notification windows. A single incident routinely triggers several at once, with different clocks.
• HIPAA, PCI DSS, and sector rules sit on top of all of the above if you're in healthcare or take card payments.

None of that applies uniformly, which is exactly the problem. The obligation isn't to memorize it. It's to have a current register of what applies to this company, with the trigger and the deadline for each, maintained by someone whose name you know.

And private companies should stop reading this as somebody else's chapter. The SEC rules bind public filers. But the standard of care they establish gets borrowed — by your enterprise customers' procurement teams, by your insurer at renewal, by an acquirer in diligence, and by a plaintiff's lawyer looking for the reasonable-practice benchmark. In Delaware, the courts have been signalling that cybersecurity may qualify as a mission-critical risk, which raises the bar on what "we were monitoring it" has to mean. Board minutes that show a briefing was received are weaker than minutes that show a decision was deliberated. That's not a technicality; in litigation it's most of the record.

What the board actually does here:

Assign it, in writing. One named committee owns cyber oversight — audit, risk, or technology, the choice matters less than the clarity. Put it in the charter. Overlapping ownership produces the same result as no ownership.

Rehearse the disclosure decision, not just the incident. Most tabletop exercises stop at containment, which is the technical team's favorite part and the least relevant to you. Run one that starts at hour thirty-six, when the facts are still partial, and forces the question: is this material, who decides, who's drafting, and what do we file? Do it with counsel in the room. The first time you have that argument should not be the real time.

Insist that reporting reaches you unfiltered. Direct line from whoever owns security and from the general counsel, to the committee. Not routed through the person whose budget or performance is implicated by the bad news. This is the single most common structural weakness I see, and it is invisible until the week it matters.

Make the minutes show deliberation. Not "the committee received an update on cybersecurity." What was asked, what was challenged, what direction was given, what management committed to do by when. That's your defensible record, and it costs nothing but discipline in the drafting.

Check the insurance against the actual exposure. Annually, and read the exclusions rather than the summary. Two failure patterns recur: a policy that excludes the exact scenario the company is most exposed to, and a directors-and-officers policy whose interaction with the cyber policy nobody has mapped. Ask your broker to walk a real claim scenario through both, end to end.

Severity read. For a mid-market private company, this chapter is "aware and organized," not "emergency." For any public filer, or anyone selling into Europe, or anyone in healthcare or payments, the registry and the rehearsed disclosure decision are overdue if you don't have them. The cost of both is measured in meeting hours. The cost of not having them is measured differently.

Questions to put to management:

1. Who, by name and by title, decides that an incident is material? What happens if that person is unreachable at 2 a.m.?
2. Show me the compliance register — every reporting obligation that applies to us, with its trigger and its deadline.
3. When did we last rehearse a disclosure decision, as opposed to a technical response? What broke?
4. Does the board hear from the security lead and from counsel directly, or through someone else?
5. Walk me through what our insurance pays and refuses in the ransomware scenario we say is our worst case.

David's note. The part of this that owners underrate is the register. It sounds bureaucratic. It is bureaucratic. But I've watched a deal stall for six weeks because nobody could produce a straight answer on which notification rules applied to a company operating in four states, and the buyer's read wasn't "these people have a documentation gap." It was "these people don't know their own business." That's an expensive impression to leave.

Principle Three: Build the seat, not just the skill

Lead: David Levin

There's a shortcut going around: put a cyber person on the board and you've handled cyber governance. I understand the appeal. I think it's mostly wrong, and where it's right, it's right for a narrower reason than people assume.

Start with the honest numbers. Per the NACD's 2025 survey work, 34 percent of public company directors say improving the board's cybersecurity expertise is very or extremely important, and 40 percent say the same about clarifying which committee actually owns it. Among private company directors both figures run higher — 45 and 49 percent. Two things stand out there. First, structure scores as high as expertise, and structure is the cheaper fix. Second, private boards know they're further behind, which is at least encouraging, because it means the awareness gap isn't the problem.

Why one expert doesn't solve it. A board is a deliberating body. Knowledge parked in one seat doesn't become oversight; it becomes deference. I've sat in rooms where the presence of the technical director made everyone else quieter, and the quality of challenge went down. The board didn't gain a capability. It outsourced one, to a colleague, in the room.

There's a second problem. "Cyber expert" is not a defined role. Someone who ran security operations at a large bank, someone who built products, someone who did policy, and someone who audited compliance are four different people with four different blind spots. If you're going to recruit for it, define what you're recruiting for first, against your actual strategy and risk. Otherwise you've hired a credential.

That said — the EY analysis cited in the handbook found 86 percent of Fortune 100 companies now disclose cybersecurity as an expertise sought on the board or cited in a director's biography, up from 53 percent in 2019. Investors are looking for it. Fine. Just don't confuse the disclosure with the capability.

What I'd do instead, in order of value per dollar:

One. Fix the charter. Write down which committee owns cyber oversight, what it reviews, how often, and what goes to the full board. An afternoon of work. Removes the most common failure, which is everyone assuming audit has it while audit assumes technology has it.

Two. Put a floor under every director, not a ceiling on one. Two sessions a year, both of them substantive. Not vendor presentations — those are sales calls with a governance costume on. What does the company actually run on, what's the realistic bad day, and what changed since last time. Every director. Including the ones who think they don't need it, who are usually the reason it's needed.

Three. Buy independent verification. This is the one I'd fight for. Management grades its own homework everywhere in a company, and the board's normal answer is an independent audit. Cyber shouldn't be exempt. An outside assessment against a recognized framework, annually, reporting to the committee rather than to the CIO. It's not expensive at mid-market scale, and it changes the character of every subsequent conversation, because now the internal report has something to be compared against.

Four. Then, maybe, recruit. If your strategy is genuinely technology-dependent and your risk is genuinely high and the first three haven't closed the gap, add the seat. With a defined profile. And when you do, make it explicit to the whole board that everybody else's floor didn't just get lower.

On the skills matrix, since every governance committee has one. Update the cyber row to reflect what's actually coming: cloud concentration, AI governance, quantum readiness, third-party dependency. A matrix that still says "IT experience" is telling you about 2014.

What good looks like: the charter is specific; cyber is a standing item with real time on it rather than the last ten minutes; the board's questions have gotten sharper year over year, which you can literally read in the minutes; new directors meet the security lead during onboarding; and somebody independent validates the picture at least annually.

Questions for the board to ask itself:

1. Which committee owns this, and does its charter actually say so?
2. If our security lead told us everything was fine, how would we know whether that's true?
3. What's the cyber literacy floor for this board, and are we all above it, honestly?
4. Are we recruiting for a defined capability, or for a line in the proxy?
5. When did an outside party last assess this company, and did their report come to us or to management?

Daniel's note. The independent-verification point is the one I'd underline twice, and I say that against my own commercial interest, because sometimes the independent party is checking my work. That's the point. Any security provider who resists being audited by someone else is telling you something. And on the added director: the good ones make the board more demanding, because they know which answers are soft. If your new cyber director has made the room quieter, you recruited the wrong one.

Principle Four: Run it on a framework, and decide how much risk you'll accept

Lead: Daniel Ramos

Two words in that heading do the work. Framework, because ad hoc security is unmeasurable and therefore ungovernable. Accept, because you will be accepting risk whether or not you do it deliberately, and deliberately is cheaper.

On frameworks, briefly and without religion. A framework is a checklist of things competent organizations do, written down so you can tell what you've done and what you haven't. The common ones are the NIST Cybersecurity Framework 2.0, the CIS Critical Security Controls, and ISO/IEC 27001. In regulated corners you'll also meet PCI DSS for card payments, HIPAA in healthcare, and CMMC if you serve the defense industrial base. They overlap heavily. Which one you pick matters far less than picking one and being honest about your score against it. A board should ask for the framework, the current maturity rating, the target, and the date — and should be suspicious of a rating that only ever improves.

On risk appetite, which is the part most companies skip. Your appetite is the amount and type of risk you'll accept in pursuit of your objectives, and it should be stated in business terms, ideally with numbers. Something like: we will not accept a scenario with a plausible loss above $X without executive sign-off; we will not accept unpatched internet-facing critical vulnerabilities beyond N days; we will not accept vendors with access to regulated data who lack current independent attestation.

Write it down, because a written appetite converts a hundred technical arguments into one governance decision. Without it, every remediation debate is relitigated on instinct, and instinct loses to whoever spoke last.

The division of labor, stated cleanly. The board sets tone, approves appetite, and verifies. Management runs the program — translating appetite into actual controls, assessing continuously, reporting in business language, integrating security into finance and legal and HR and operations, and testing response. Directors who cross that line into running the program stop being able to oversee it. Directors who never test the line get managed.

What I'd have the board insist on:

Tone, set once and visibly. Cyber sits at the same table as credit, legal, market and operational risk. The chair reinforces it. It's a standing agenda item. That costs nothing and changes behavior throughout the organization, because everyone below you watches what gets asked about.

An appetite statement you actually approve. Quantitative where it can be. Reviewed when the business changes, not on a calendar out of habit.

Resilience testing that includes you. Management tests incident response, crisis management, and business continuity; the board reviews the results and, at least annually, sits in on a scenario exercise. Not as observers. As participants who have to make a decision under pressure with incomplete facts, which is the actual job during an incident. Track the metrics that come out of it — time to detect, time to contain, time to recover — and track them over time rather than as a snapshot.

Cross-functional ownership. If security lives entirely in IT, three things break: legal finds out late, finance can't quantify anything, and HR isn't managing the human risk that causes most incidents. Some organizations formalize this with a cyber risk committee at management level. The mechanism matters less than the outcome, which is that business leaders share accountability rather than delegating it downward.

An annual look at the governance itself. Charters, reporting cadence, escalation thresholds, independence of assurance. Governance structures decay quietly. Nobody notices until the thing they were supposed to catch goes uncaught.

A caution on maturity ratings. They're useful and they're gameable. A program can improve its score meaningfully while leaving the one control that would have stopped your realistic worst case exactly where it was. Ask which specific scenario each improvement reduces. If the answer is a general improvement in posture, you've been given a scoreboard rather than an answer.

Questions to put to management:

1. Which framework, what's our current maturity, what's the target, and by when?
2. What's our stated risk appetite in numbers, and where are we currently outside it?
3. What did the last tabletop exercise get wrong, and what changed as a result?
4. Which business leaders — outside IT — carry accountability for a cyber mitigation this year?
5. Of everything we improved last year, which improvement reduced our top scenario, and by how much?

David's note. The appetite statement is the piece I'd steal for the rest of the business. Most companies have never written down how much of any risk they'll accept, which is why every risk argument is an argument about temperament rather than about policy. Doing it once for cyber tends to expose how loose the rest of the risk register is. Consider that a feature.

Principle Five: Demand reporting you can actually use

Lead: David Levin

The NACD found 43 percent of public company directors and 57 percent of private ones want management's cyber reporting to improve this year. Having read a lot of these reports, I'd say those numbers are polite.

Here's the pattern. The deck has twelve slides. Slides one through nine are activity — threats blocked, tickets closed, training completed, patches applied. Slide ten is a maturity score that went up. Slide eleven is a budget request. Slide twelve is questions, and there are none, because nobody in the room has been given anything to have an opinion about.

That's not a communication failure. It's a translation failure, and it's fixable, because the underlying information exists. Somebody has to require it in a different form.

What I'd want on the page instead. Six things, and it fits on two:

Where we stand. Top three to five risk scenarios, in business terms, with an estimated financial exposure and a direction of travel. Not a heat map with colored squares. A short list a director can argue with.

What moved. Since last quarter: what got better, what got worse, what's new. Trend lines, not snapshots. One quarter of data tells you nothing; four quarters tells you whether the program is working.

What happened. Incidents above an agreed threshold. What occurred, what it cost, whether it's closed, what changed as a result. Include the near-misses. A report with no incidents in it is not a clean quarter; it's an under-reporting problem, and I'd say that out loud in the meeting.

Where we're exposed outside our walls. Third parties, cloud concentration, the systems too old to defend properly. This is the section most often missing and most often the actual answer.

Where we stand legally. Compliance status, open audit findings, remediation plans with dates.

What we want money for, and against which risk. Tied to a specific exposure and a specific expected reduction, with someone coming back next year to report whether it worked.

On metrics. The handbook offers a set worth borrowing, and I like it because each one is a question a non-technical director can follow. What percentage of critical systems require more than a password to access, with a target above 98 percent. How long it takes to detect an incident and how long to recover. What share of critical vulnerabilities are more than 30 days old, targeting under 5 percent. What proportion of vendors have contractual security requirements and current independent attestation, targeting above 90 percent. What percentage of staff click the test phishing email, targeting under 2 percent. What share of sensitive data is classified and inventoried, targeting above 95 percent.

Six numbers. Trended quarterly. Any director can hold a real conversation with that, and no one needs a technical background to notice when a line is going the wrong way for three quarters running.

The trap I'd warn about, since I've walked into it. Metrics get managed. If the phishing click rate is the number the board watches, the click rate will improve — possibly because the training worked, possibly because the tests got easier. Ask how the number is produced roughly once a year. Not accusingly. Just often enough that everyone knows you might.

On cadence. Quarterly for the standing report. Immediately for anything material — the handbook suggests within 24 hours of a materiality determination, which aligns with the four-day disclosure clock and gives you room to actually govern rather than ratify. A half-hour deep dive each quarter on one theme, rotating: ransomware, artificial intelligence, cloud, suppliers. That last one is where directors learn enough to ask better questions the following quarter.

Questions I'd ask about the reporting itself:

1. Can I explain our top cyber exposure to another director using only this report? If not, it's the wrong report.
2. Are we seeing trends, or a snapshot that resets every quarter?
3. Does the report include what's going badly, or only what's going well?
4. Who produces these numbers, and would we hear about it if one of them were flattering?
5. Is management asking for money against a named risk, and does anyone come back to report whether it worked?

Daniel's note. From the other side of that table: the reason security teams hand boards activity metrics is usually not evasion. It's that activity is what their tools measure by default, and translating it into loss exposure is genuinely hard work that nobody asked for. When a board asks for it explicitly, most teams can do it within two quarters. And they should — the one detail I'd add to David's list is near-misses, because in my experience the near-miss log is the most predictive document in the company. It's the incidents you didn't have yet.

Principle Six: You can't be secure alone

Lead: Daniel Ramos

The single most important number in this book, again: a third of breaches now involve a third party, double the prior year, per Verizon's 2025 report. Your security is a function of your suppliers' security, and their suppliers' security, and it goes further down than anybody's map does.

Look at how the well-known failures actually worked. In the Snowflake campaign of 2024, the cloud platform itself wasn't breached — attackers used stolen credentials against customer accounts that hadn't turned on multi-factor authentication, meaning a password alone was enough. The vendor was fine; the customers' configuration of the vendor was not. MOVEit was the opposite shape: one flaw in one widely used file-transfer product, exploited by a ransomware group, cascading into thousands of organizations that had never heard of the software because it sat inside a service they bought. Kaseya in 2021 showed concentration risk plainly, with roughly 1,500 downstream businesses disrupted through a single IT management product. And the XZ Utils backdoor in 2024 showed the newest shape: an attacker who spent two years being a helpful open-source contributor in order to get code into a component that nearly everything depends on.

Four incidents, four different failure modes, one lesson: the boundary of your risk is not the boundary of your company.

What this means for oversight. The board's field of view has to extend past the perimeter, and the specific things worth asking for are:

A dependency map, not a vendor list. Procurement has a vendor list, sorted by spend. What you need is different: which third parties, if they went dark for a week, would stop us from operating or expose regulated data. Those are rarely the biggest contracts. The critical dependency is often a small vendor with deep access — the billing integration, the remote-support tool, the specialist processor.

Fourth parties, at least for the critical few. Your critical vendor's critical vendor. You can't map the whole tree, so don't try. Map it for the handful of relationships where you couldn't operate without them.

Contracts that mean something in an incident. Security requirements are common in contracts and frequently unenforceable in practice. What matters: notification obligations with actual deadlines, audit rights, defined liability, and cooperation clauses that require joint response. The handbook's benchmark is above 90 percent of vendors with cybersecurity requirements and current SOC 2 Type 2 attestation. That's a reasonable target and most mid-market companies are nowhere near it.

Concentration risk, named as such. If a single provider hosts everything you run, that is a strategic decision with a resilience cost, and it should be made consciously rather than by drift. I'm not arguing against consolidation — the security benefits of a well-run single platform are real and multi-cloud has its own costs. I'm arguing that "what happens if this provider has a bad week" should be an answered question rather than an unasked one.

Membership in the sharing networks. Information Sharing and Analysis Centers — ISACs — are sector-specific bodies where member organizations share threat intelligence. Most industries have one. InfraGard is the FBI's equivalent partnership program and is open broadly. These are cheap, and the value is asymmetric: you see the attack that hit a peer three weeks before it reaches you. A board can reasonably ask whether the company participates, what intelligence it has acted on, and what it has contributed. Organizations that only take tend to get less over time.

A relationship with law enforcement before you need one. Covered properly in Tool O. The short version: the time to meet your local FBI field office is on a calm day.

On tabletop exercises with your partners in the room. Rare, and worth the trouble. Most crisis plans assume the partners will cooperate promptly. Most partners have their own crisis, their own counsel, and their own disclosure clock. Running one joint exercise with a critical vendor surfaces more than three internal ones will.

Severity read. Third-party risk is the area where most mid-market companies have the largest gap between their perceived and actual exposure. It's also the one with the highest return on unglamorous work: a dependency map and enforceable contract language for your top twenty vendors will move your real risk more than most tooling purchases of the same cost.

Questions to put to management:

1. Which five third parties could stop this business, and what happens if one goes dark for a week?
2. Do our contracts with those five require notification, permit audit, and define liability? Has anyone read them since signing?
3. Who is our biggest concentration risk, and was that a decision or an accident?
4. Do we participate in our sector's information-sharing body, and what has it told us that we acted on?
5. Have we ever run a crisis exercise with a critical vendor in the room?

David's note. Every board I've watched approach this starts by trying to assess all their vendors and stalls in month two under the weight of questionnaires nobody reads. Do the top twenty properly. Sort by damage-if-they-fail, not by invoice size. Twenty done well beats three hundred done as paperwork, and the paperwork version gives you a false sense of coverage, which is worse than knowing you haven't started.

PART THREE — THE TOOLKIT

Short, practical, pull one off the shelf when it's on the agenda. Each is written by whichever of us owns the subject.

Tool A — Ransomware

Daniel Ramos

Why this is the board's problem. Ransomware isn't a data-theft story anymore, it's an operational-shutdown story with a data-theft chaser. The attackers encrypt what you need to operate, steal a copy first, and threaten to publish. That gives them two levers, which is why "we have backups" stopped being a complete answer around 2019.

The Change Healthcare attack of February 2024 is the case study I'd put in front of any board. The ALPHV/BlackCat group hit claims and payment processing that served roughly one in three U.S. patients. Every hospital in the country felt it, 74 percent reported direct disruption to patient care, and recovery ran for months. One company's bad day became a national one.

The governance questions that actually matter, in order:

Who decides whether to pay? Not a hypothetical. Establish it now: what threshold escalates to the board, who has authority below that, and what the standing policy is. Most well-run companies hold a strong presumption against payment, consistent with law-enforcement guidance, with a narrow carve-out for human safety or existential business risk that requires board notification and legal review. The legal review isn't optional — U.S. sanctions rules administered by the Treasury's Office of Foreign Assets Control can make payment to certain groups unlawful regardless of circumstance.

Can we operate without paying? This is the question the payment decision actually depends on. It comes down to recovery point and recovery time objectives for critical systems — how much data you'd lose and how long you'd be down. And to backups the attacker can't reach: offline or immutable, tested by actually restoring, not by confirming the job completed. Backup jobs that ran successfully for two years and cannot be restored from are common enough that I'd call them the default state until proven otherwise.

Have we pre-arranged the help? During an incident you want retainers already signed: digital forensics, breach counsel, communications, and — if it ever comes to it — a negotiator. Procuring these mid-incident costs you two days you don't have and puts you in the weakest negotiating position of your life.

What does it cost us per day? If nobody has modeled downtime cost per day, every response decision will be made on vibes.

What I'd want reported to the board: backup restore-test results with dates, recovery objectives for the systems that carry revenue, retainer status, results of the most recent ransomware-specific tabletop, and whether the payment decision framework has been reviewed by counsel this year.

Honest read. Ransomware remains the most likely severe event for a mid-market company. It's also the most preventable-to-survivable: multi-factor authentication everywhere, tested offline backups, network segmentation so one infection can't reach everything, and a rehearsed plan. That's not exotic. It's just work nobody gets credit for until the week it saves the company.

Tool B — Incident response

Daniel Ramos

Four phases. The board's role differs in each, and confusing them is how directors end up unhelpfully in the way.

Preparedness — where you have all the leverage. Scenario-specific playbooks, not one generic document: ransomware, cloud account compromise, insider misuse, third-party breach, and now AI-enabled fraud. A current inventory of where sensitive data lives, because you cannot contain what you cannot locate. Pre-drafted holding statements and a named spokesperson. Retainers in place. And exercises run against your realistic threats rather than a movie plot. Board reviews the plan annually and after any material change.

Response — where you mostly stay out of the way. Management triages, contains, coordinates with counsel to preserve privilege, notifies insurers within the window their policy requires, and engages the cloud and software providers whose shared-responsibility duties are now live. The board's job is to receive accurate updates, make the decisions reserved to it, and resist the temptation to direct the technical work. One thing to brace for: what is known during an incident changes hour by hour, and early facts are frequently wrong. A board that punishes revision will get certainty instead of accuracy, which is a genuinely dangerous trade.

Notification — where the deadlines bite. Regulators on their various clocks. Law enforcement. Insurers, usually immediately. Cloud and technology providers. Affected customers, often within 72 hours depending on regime. Investors, with an 8-K within four business days of a materiality determination for U.S. public filers. Media, through one designated voice. The plan should already contain a template and a named contact for each group.

Recovery — where the value is. Restore what the business needs first, not what's easiest to rebuild. Then root cause, honestly. Then update the playbooks, the training, and where warranted the architecture. Boards should track post-incident actions to closure the same way they track audit findings, because the most reliable predictor of a second incident is an unclosed action from the first.

Questions with answers worth having: Who owns the program, and does a steering group meet regularly? When was the last realistic exercise and what failed in it? What's our average time to detect, and how do we know? What thresholds trigger a board briefing? Are backups isolated and restore-tested? Can we quantify the business impact of our top scenarios in dollars?

Tool C — Emerging technology

David Levin

Every board gets asked to approve technology whose risks are not yet well understood. Here's the frame I use, and it's older than any of the technologies it's applied to.

First, decide what kind of adopter you are. Early, with the market, or deliberately late. All three are legitimate strategies; what kills companies is holding one position in the strategy document and a different one in practice. Early adoption buys advantage and buys immature security. Late adoption buys stability and buys the risk that your competitor learned something you didn't. Pick, say why, revisit annually.

Second, understand that the vendor's security is a schedule casualty. When a technology market is racing, security in the product loses to features and ship dates, every time. That's not cynicism; it's how product roadmaps work under competitive pressure. So the question to management is never "is this product secure" — it's "what did we do to verify that, and what do we assume the vendor has not done?"

Third, ask what it lets us retire. The most underrated question in technology governance. If the new thing lets you shut down two old things, you may have improved your risk position and your cost base at once. If it just adds a layer, you've added dependency, integration, and a new failure mode. Both can be worth it. They're different decisions.

Fourth, ask what it costs to not adopt. Symmetry matters here. Boards are trained to interrogate the risk of action and to accept inaction as the safe default. In technology, inaction accrues quietly and presents its bill all at once.

The questions I'd put to management: How are you scanning for what's coming, and where does that intelligence come from? What are competitors doing and what has it done for them? Has this been independently tested — an actual penetration test by an outside party, with results we can see? What third-party risk comes attached? Does this let us retire anything? And what's our roadmap if it works?

And one for the board about itself: do we have enough independent information to judge management's answers, or are we grading a paper written by the person who wants the budget? If it's the latter, that's what an outside advisor is for.

Tool D — Quantum

Daniel Ramos

I'll keep this proportionate, because quantum is where board conversations most often lose their grip on time horizons.

The mechanism, plainly. Nearly all the encryption protecting data in transit today relies on math that's easy in one direction and impractical in reverse. A sufficiently capable quantum computer makes the reverse direction practical, which breaks the widely used systems — RSA and elliptic-curve cryptography — at once. The day that becomes real gets called Q-Day. Most credible forecasts put it in the 2030s. Nobody knows.

Why it's not purely a future problem. "Harvest now, decrypt later." An adversary who captures encrypted traffic today can store it and open it when the capability arrives. So the practical question is: how long does your data need to stay secret? For a retailer's transaction logs, probably not long enough to matter. For pharmaceutical research, defense work, long-term contracts, health records, or anything with a twenty-year confidentiality requirement, the exposure started already.

What's actually actionable now. The U.S. National Institute of Standards and Technology has published approved post-quantum cryptography standards and selected the algorithms. That's the important development, because it means no organization needs to invent anything — this is a migration project, not a research project. The work is: find every place cryptography is used in your environment (harder than it sounds, and this discovery phase is where the cost sits), prioritize by how long the data must stay confidential, and migrate on a schedule.

The constraint nobody plans for is people. Multiple studies cited in the handbook — ISACA putting only 4 percent of organizations with a defined quantum strategy, the Trusted Computing Group finding 91 percent without a roadmap, Bain estimating 90 percent unprepared — all point the same direction, and the workforce implication is the sharp end. The number of people who can execute a cryptographic migration is small today. After Q-Day it will be small and fully booked. Organizations that transition early will do it with available talent at normal prices.

Severity read for a mid-market board: aware and scheduled, not urgent. Concretely, this year: ask whether anyone has inventoried where cryptography is used, ask how long our most sensitive data must remain confidential, and put a date on the roadmap. If your business is in defense, pharma, finance, or long-horizon intellectual property, move that up. If you handle short-lived transactional data, you have room — but the inventory is still worth doing, because you'll need it eventually and it's cheaper calm.

One thing to refuse. Anyone selling you a proprietary "quantum-safe" encryption product of their own invention. NIST ran a multi-year public competition specifically so that nobody has to trust a vendor's homemade math. Use the standards.

Tool E — Artificial intelligence

David Levin

Boards keep asking me for an AI policy. Most of the time what they need first is an AI inventory, because the policy will be theoretical and the inventory will be alarming.

Start with what's already in the building. Shadow AI — staff using tools nobody approved — is the live exposure at nearly every company I look at, and it happens for a sympathetic reason: the sanctioned option was slow or didn't exist, and people had work to do. The risk isn't that they're careless. It's that customer data, contracts, and source code end up in systems your agreements don't cover and your legal team has never seen. Find out what's in use before writing rules about what should be.

Then sort your AI questions into three piles, because they get muddled constantly:

Does it work? Does this application actually save time or money, measurably? Most claimed AI savings evaporate under measurement. Some are real and large. Require the measurement.

What does it expose? Where does the data go, who can see it, what does the contract say about training on your inputs, and what happens if the provider has a breach?

What happens when it's wrong? Every AI system is wrong sometimes. The governance question is whether a wrong output can reach a customer, a regulator, or a payment without a human noticing. That's a process question, not a technology one, and it's the one boards are best equipped to ask.

The two AI risks I'd raise unprompted at the next meeting:

Impersonation. Convincing fake audio and video are cheap now. The attack is old — someone senior urgently asks someone junior to move money or hand over access — but the credibility is new. The control is also old and boring: a verification step for payment and access changes that does not depend on recognizing a voice or a face. A callback to a known number. A second approver. Tell your finance team that a request that discourages verification is itself the warning sign, whoever it appears to be from.

Agents with permissions. As AI systems start taking actions rather than producing text, they need access to systems, and that access tends to get granted generously because narrowing it is work. An AI agent with broad standing permissions is a privileged user that never sleeps and can be talked into things. Ask who owns the identity, what exactly it can reach, and who reviews that.

What I'd want in front of the board: an inventory of AI in use including the unsanctioned, the two or three uses that are actually material to the business, a plain statement of what data goes where, the human-in-the-loop points, and whether the insurance responds if an AI system causes harm. That last one surprises people. Ask the broker directly.

Tool F — Cloud

David Levin

Cloud adoption is mainstream, mature, and generally a security improvement over the average company-run server room. The governance issues aren't about whether to use it. They're about dependency and about a division of labor most customers misunderstand.

Shared responsibility, in plain terms. The provider secures the building. You secure your apartment. Amazon, Microsoft and Google run the infrastructure to a standard almost no individual company could match. What they do not do is configure your access controls, decide who can log in, turn on multi-factor authentication, or manage your data. That line is documented in every contract and misread in a large share of incidents. The Snowflake campaign in 2024 is the clean example: the platform held, the customers who hadn't required more than a password did not.

The four questions I'd ask:

What does an outage actually cost us, per day? Cloud providers are highly reliable and they are not perfectly reliable. Somebody should have modeled it.

Could we leave? Not "will we." Could we. Where's the data, in what format, what would migration cost, and has anyone tested moving anything? Answering this is worth the effort even if you never move, because it tells you your real negotiating position at renewal.

Who's watching the bill? Not a security question, but it belongs on the same page. Cloud spending grows quietly through defaults and forgotten resources. The tell is a bill that rises faster than usage.

Do we have the expertise in-house to read the contract? IBM's 2024 breach-cost research, cited in the handbook, found 40 percent of breaches involved data spread across multiple environments — the complexity of hybrid and multi-cloud is itself a risk factor. If nobody internally can evaluate the terms and the architecture, you're relying entirely on a vendor's account team, which is a fine relationship and a poor control.

On multi-cloud, since it comes up as a resilience answer. Running across two providers reduces one dependency and adds complexity, cost, and a second set of configurations to get wrong. For most mid-market companies, one well-run platform plus a genuinely independent backup is the better trade. Make it deliberately, either way.

Tool G — Insiders and human risk

Daniel Ramos

Most incidents involve a person doing something ordinary. That's the whole of it, and the reason this tool exists is that boards persistently allocate their attention to the exotic version of the problem.

The categories, in order of how often I see them. Careless or rushed employees, by a wide margin — someone clicks, someone reuses a password, someone emails a spreadsheet home to finish over the weekend. Then people working around a control that made their job harder, which is usually a design failure rather than a discipline failure. Then departing employees taking material they think of as theirs. Then, rarely, genuinely malicious insiders. And increasingly, contractors and partners with privileged access that nobody reviewed after the project ended.

Why insiders are harder to catch. External intrusion leaves traces because the attacker has to get in. An insider is already in. Their activity looks like their job, because it mostly is their job, with an anomaly inside it.

What actually reduces this, in order of effect:

Access that matches the role, reviewed on a schedule. Access accumulates. People change roles and keep the old permissions, and after six years a mid-career employee can reach half the company. Periodic review is dull and it's the highest-value control here.

Departure handled as a process. Access revoked immediately across every system including the ones IT doesn't manage, with heightened monitoring in the notice period. Most intellectual property loss happens in the last two weeks.

Controls designed for how people actually work. If the secure path is slow, staff will route around it and you'll have an unmonitored shadow process. When you find a workaround, treat it as a design bug first.

Training measured by behavior, not completion. Completion rates measure attendance. Simulated phishing click rates measure whether anything changed. Track the trend, and treat repeat clickers as a coaching matter rather than a disciplinary one, unless it's persistent.

A reporting culture without fear. People notice things — an odd request, a colleague behaving unusually, a mistake they made themselves. Whether they tell you is entirely determined by what happened to the last person who did. If reporting a mistake gets someone punished, you have bought silence, and silence extends dwell time.

And a caution on behavioral indicators. The handbook lists warning signs — poor performance reviews, financial distress, unusual hours, disagreements with colleagues. Some correlation exists, and I'd handle that list carefully. Run a program that treats ordinary human difficulty as suspicion and you'll damage trust across the whole company to catch approximately nobody. Anything in this space belongs jointly with HR and legal, with clear boundaries, disclosed to employees.

What I'd ask management: How often is access reviewed and what did the last review remove? What's our offboarding time to full revocation, measured? What's the phishing click trend over four quarters? Are we tracking near-misses and self-reports, and is that number going up — which is good?

Tool H — Third parties and supply chain

Daniel Ramos

The full argument is in Principle Six. This is the working checklist.

Classify by damage, not by spend. Three tiers: could stop the business or expose regulated data; would hurt; replaceable. Most vendor programs sort by contract value and therefore scrutinize the office supplier more closely than the remote-access tool.

For tier one, know the fourth parties. Who does your critical vendor depend on. Ask them. A vendor who can't answer is telling you about their own program.

Get the contract terms right at signature, because you will not get them at renewal and certainly not during an incident. Breach notification with a stated deadline. Audit or attestation rights. Defined liability and indemnity. Cooperation in joint incident response. Data portability and return on exit.

Verify rather than survey. A completed questionnaire is a claim. A current SOC 2 Type 2 report or ISO 27001 certificate is a claim someone independent tested. For tier one, require the latter and actually read the exceptions section, which is where the interesting material is.

Watch continuously for tier one. Annual reassessment means you learn about a vendor's deterioration up to twelve months late.

Include a vendor in an exercise once a year. Pick a critical one. The gaps you find will be coordination gaps — whose incident is it, who tells the customers, who talks to the regulator — and those are exactly the ones that cost days during a real event.

Board-level metrics worth seeing: percentage of tier-one vendors with current independent attestation, percentage with enforceable notification terms, count of concentration points where one vendor is irreplaceable, and time to identify affected systems when a vendor discloses a vulnerability. That last one is the sharpest measure of whether the program is real.

Tool I — Mergers and acquisitions

David Levin

Cyber risk in a transaction shows up in four places, and the expensive mistakes are made in the first one.

Diligence. You are buying their vulnerabilities, their unpatched systems, their compliance gaps, and any breach they haven't discovered yet. Document review alone won't find it — the target's own security team may not know. Technical testing during diligence costs a fraction of a percent of most deals and routinely finds material issues. And get the remediation cost into the purchase price, because a funding request from IT six months after close is a much harder conversation than a line item in the model.

The transaction itself is a target. The FBI has warned that ransomware actors deliberately time attacks around mergers and acquisitions, using the deal as leverage — including threatening to release non-public information to affect valuation. Deal periods concentrate attention, urgency, and pressure to move quickly. Assume adversaries read the same announcements your investors do.

Integration. This is where the risk is highest and governance is loosest, because the pressure is to connect systems fast and the security team is downstream of that decision. Two failures recur: connecting networks before either side understands the other's hygiene, and an incident landing on two teams who have never worked together and have no shared plan. Security needs a seat at the integration table from day one, and connectivity should be staged rather than opened.

Divestitures. The mirror problem. Splitting a security team creates two weaker ones. The retained business usually has to provide security services to the separated one under a transition services agreement, which needs to be specific about scope and duration, and exited as soon as practical. Long-running transition arrangements have a way of becoming permanent and unowned.

And if you're the seller. Cyber problems found in diligence become price reductions. Cheap preparation pays for itself several times: remediate the known vulnerabilities, refresh the insurance, rehearse the incident story. Buyers do not expect a spotless history — they expect awareness, a realistic plan, and evidence you learned something. A seller who volunteers a past incident with the lessons attached reads as competent. One who gets caught omitting it reads as a different kind of risk entirely.

Tool J — The board and the security lead

David Levin and Daniel Ramos

We wrote this one together because it's a two-sided relationship and we've each been on our own side of it.

David: The failure mode I see most is a board that meets the security lead twice a year, both times in a formal presentation, and concludes that the relationship is fine. It isn't a relationship. It's a performance, and the person delivering it has correctly worked out that the safe move is to bring good news.

Daniel: From my side, that's exactly right, and I'd add the mechanism. If a security leader's only board exposure is a scheduled presentation, they will optimize it — polish the metrics, lead with wins, keep the bad news in the appendix. Not out of dishonesty. Out of a rational read of the incentives. Fix the incentives and the reporting changes without anyone having a difficult conversation about candor.

David: So the practical asks are unglamorous. Standing agenda item, real time on it. A deep dive each quarter with room for the discussion to go where it goes. Occasional contact outside the formal meeting — a call from the committee chair, not an interrogation, just contact. And the committee chair should have at least one conversation a year with the security lead that management doesn't sit in on.

Daniel: That last one matters more than it sounds. If the security lead reports through the CIO, and the CIO owns the systems being criticized, the escalation path runs straight through a conflict of interest. It's not that CIOs suppress bad news as a rule. It's that a structure requiring them not to is a poor structure. A direct line to the committee, used occasionally so it isn't remarkable when it's used, fixes it.

David: Say something about what makes a good one, since boards ask me how to evaluate a CISO.

Daniel: Three things. First, they tell you what they don't know. Anyone with a complete picture of their own environment is describing an ambition. Second, they can translate — if every answer requires you to already understand the answer, they're either not able to translate or not willing to, and both are disqualifying at this level. Third, they escalate early and are proven right about half the time. A security leader whose warnings are always vindicated is under-reporting; one whose warnings never are is crying wolf. Half is about right.

David: And a board's obligation in return — resources, air cover, and not shooting the messenger. If the honest report gets a hostile reception, you'll get the polished one forever after, and you'll have done it to yourself.

Questions worth asking: How often does the security lead brief the board, and is it strategic or technical? Is their reporting filtered through anyone? Do they have the resources they've asked for, and if not, what specifically was declined? How does the board evaluate their performance, and what's the succession plan? Does the board have enough literacy to interpret what they're told?

Tool K — Metrics that mean something

Daniel Ramos

Five categories. If your board pack answers these five, it's doing its job.

One: what's coming at us. Top threats facing our sector, how many incidents we had this period, what happened to peers, and whether our threat intelligence is telling us anything we act on.

Two: what it could cost. Our crown-jewel assets and the risk they carry. Top scenarios in probable frequency and financial impact. Which quantification model, and whether it's been independently validated. Which loss types we count — productivity, response cost, fines, reputational. Our stated appetite in financial terms and where we sit against it.

Three: how good the program is. Independently assessed maturity. Performance against a recognized framework — NIST CSF, CIS Controls, CMMC where applicable. Control effectiveness against industry norms. External vulnerability rating and peer comparison. Recent penetration test findings, including the ones not yet fixed.

Four: supply chain. Which vendors carry the most risk, estimated likelihood and impact of a breach through them, our resilience to a third-party incident, and any single-vendor concentration.

Five: are we spending well. Estimated exposure attached to major business initiatives. Which controls deliver the most risk reduction per dollar, and which are underperforming or redundant — a question almost nobody asks, and one that usually finds money. How much cyber insurance we carry and what it actually covers. Return on the program overall.

Two cautions. Metrics are directional, not precise; a board that treats a maturity score as a measurement will over-trust it. And any metric that becomes the metric will improve, sometimes for the wrong reason. Rotate what you scrutinize.

Tool L — What the board pack should look like

David Levin

Concrete format, borrowed from the handbook's structure and trimmed to what a mid-market board can sustain.

Every meeting — the standing brief. Two pages plus a dashboard. Trend analysis, current exposure, resource needs. Two pages is a discipline, not a limit; it forces someone to decide what matters.

Within 24 hours of a materiality determination — the incident update. One page: facts, impact, containment status, disclosure steps, followed by a call. Written first so there's a record, then the conversation.

Quarterly — the deep dive. Thirty minutes on one theme. Strategy, an emerging threat, or a budget question. Rotate.

What goes on the dashboard. Top five risks with likelihood and impact, mapped to business objectives and quantified where possible. The six trended metrics from Principle Five. Significant events since last report, with cause and lessons. Compliance status and open audit findings. And the forward plan — priority initiatives for the next two quarters with budget tied to quantified risk reduction.

What I'd delete from most packs I've seen: threat-blocked counts, tool inventories, vendor logos, anything with a world map and moving dots on it, and the maturity score presented without the underlying gaps. If a slide can't change a decision, it's taking up the time that would have been spent on one that could.

Tool M — Disclosure

Daniel Ramos

What you say publicly about board cyber oversight is now itself a governed artifact. EY's analysis of large-cap proxy statements shows how fast the norm moved: in 2025, 96 percent disclosed that a board committee owns cyber oversight, up from 81 percent in 2019; 86 percent cited cyber expertise on the board, up from 53 percent; 99 percent disclosed using an external independent advisor, up from 14 percent; and 73 percent disclosed alignment with an external framework, up from 4 percent.

That last one is the most telling. In six years, framework alignment went from a rarity to a norm. A company that can't name its framework is now visibly outside the pack.

The questions to work through before drafting:

What do our major investors and largest customers actually care about here? Which committee owns it, and how do we describe the full board's role? Is cyber in our skills matrix, and if we name a director as an expert, by what criteria? Do we describe the education directors receive? How do we describe the flow of information from management to the board, and its frequency? How does the specificity of our risk factors compare to our internal assessment — a gap between the two is a finding waiting to happen. Do we describe the actual practices: policies, response planning, exercises, training, information sharing, external advisors? How do our disclosures compare to peers? And the balancing act: enough detail to demonstrate rigor, not enough to hand an attacker a map.

The trap. Do not disclose an oversight practice you don't perform. That sounds obvious. It happens anyway, usually because the disclosure describes the intended process rather than the operating one. In an enforcement action or a securities claim, the disclosure becomes the standard you're measured against, and the gap between the described practice and the actual one is the case.

Tool N — Directors' personal security

Daniel Ramos

You are a target personally, and not because anyone dislikes you. You have access to material information, authority that others defer to, a public profile that makes you easy to research, and — statistically — weaker personal security than the company provides at the office. Adapted from the U.S. Secret Service guidance in the original handbook, with my ordering.

The attacks aimed at you specifically: highly personalized phishing built from your public speaking, bios, and social media; impersonation of you or a fellow director to authorize a payment or an access change, now with convincing synthetic audio; targeting of your phone, which holds both board material and personal life; and your home network, which protects your board portal with whatever came in the box from the internet provider.

What actually moves the needle, in order:

1. A password manager, with a unique password everywhere. One reused password on a breached site is the most common path into everything else.
2. Phishing-resistant multi-factor authentication. A hardware key or a device-based passkey. Where you can, turn off text-message and email codes, which are interceptable — and check the account recovery options too, since attackers go around the front door rather than through it.
3. An out-of-band verification habit for anything financial or access-related. If you get a call or a message that sounds like a fellow director or an executive asking for money or credentials, you hang up and call back on a number you already had. Agree this convention with your board colleagues explicitly, so nobody is offended when it's used. The voice will sound right. That's the point.
4. Separate personal and board accounts and devices where you can.
5. Lock down the phone: a real passcode rather than four digits, biometrics on, remote wipe enabled, apps only from the official store. If you're a plausible high-value target, Apple's Lockdown Mode or Google's Advanced Protection are worth the inconvenience.
6. Automatic updates on everything, including the home router and the smart devices nobody thinks of as computers.
7. Back up personal data on the 3-2-1 rule: three copies, two types of media, one held somewhere else.
8. Know your public footprint. Take a look at what a stranger can assemble about you in an hour. That's the raw material for the message that will eventually fool you.

None of this is exotic and all of it is under your control. If it helps: directors set the tone here in the most literal way available. Staff notice whether the board follows the rules it approves.

Tool O — Working with the FBI

Daniel Ramos

Two things boards get wrong about law enforcement. They think reporting invites regulatory trouble, and they think it happens after the response. Both are backwards.

What the FBI can do that you can't. They can act against the attacker's infrastructure under legal authority no private company has. Through the Internet Crime Complaint Center's Recovery Asset Team they can freeze fraudulent transfers — a 66 percent success rate in 2024, per the handbook's figures, covering $469 million domestically and $92 million internationally. They can connect your incident to others they're already investigating and tell you things about the adversary you have no way to learn. They have cyber squads in all 56 field offices and legal attachés abroad. And under many federal and state laws, they can request a temporary delay of otherwise mandatory breach notification when there's an investigative reason.

What they won't do. The FBI is not a regulator. They are not assessing whether your defenses were adequate. They don't publicly confirm investigations, and they work to avoid disclosing information that would harm you. They want technical detail — malware samples, logs, indicators — not your privileged communications, and they'll coordinate with your counsel on the boundary.

Why it can help with regulators. The Federal Trade Commission has stated it looks more favorably on a company that reported and cooperated than one that didn't. If the incident becomes public, cooperation strengthens your position with shareholders, insurers, and the press.

Timing. Report as soon as the incident is verified. Attribution depends heavily on speed, and electronic evidence degrades. Preserve the original evidence — logs from critical servers, network devices, and security monitoring systems, malware samples, and disk and memory images taken before remediation. Coordinate the report through counsel to keep it consistent with your other obligations.

The part that's a board action. Build the relationship on a calm day. Your local field office will give you a named point of contact. InfraGard membership is free and gives you a standing channel. Companies that already have the contact spend hour one of an incident responding rather than searching a website for a phone number.

Where to start: the local FBI field office directory at fbi.gov, the Internet Crime Complaint Center at ic3.gov, or 1-800-CALL-FBI.

CLOSING

David: If you take one thing from all of this, take the second question. Whatever management tells you about the state of the company's security, there's a second question, and it's almost always the same one: how do we know that's true? Not asked with suspicion. Asked the way you'd ask it about a revenue forecast or a debt covenant. Boards that ask it routinely get better information over time, because the organization adjusts to what gets examined. Boards that don't get slide decks with padlocks on them, right up until the week they need something better and it isn't there.

Daniel: And take the fact that none of this required you to become technical. Reread the six chapters. Every one of them asks for something a competent board already knows how to do — price a risk, know your obligations, structure your oversight, choose how much you'll accept, insist on usable reporting, and understand your dependencies. The subject matter is unfamiliar. The governance work is not. That should be encouraging, and it's the honest position: this is a domain where boards are far more capable than they've been told, and where the main thing standing between the current state and a good one is a handful of specific questions, asked consistently, by people who don't accept the first answer.

Source note

What this is derived from. The National Association of Corporate Directors and Internet Security Alliance, Director's Handbook on Cyber-Risk Oversight, Fifth Edition (2026), prepared by Larry Clinton with contributions from the security leaders and directors credited in that volume. This rewrite reorganizes and re-argues that material in original language; it reproduces no text from it. The original is copyright NACD and ISA.

Where our version differs on substance, not just voice:

• We decline the "$20 trillion in annual losses" projection. It's a forecast built on forecasts and it doesn't belong in a document that asks boards to demand rigor.
• We rank independent verification above adding a cyber director. The original treats the expert-director question as open; we think structure and outside assurance beat a single seat for most mid-market boards, and we say why.
• We front-load third-party risk. The Verizon 15-to-30-percent shift is, in our read, the most consequential number in the source material, and it deserves more weight than a single tool.
• We're more explicit about the incentive problem in board reporting — that polished reporting is a rational response to how most boards receive bad news.
• We've written throughout for a company with hundreds of employees rather than tens of thousands.

Facts we carried across but did not independently re-verify: NACD's 2025 and 2026 survey percentages on director sentiment and board practice; EY's Fortune 100 proxy disclosure analysis; the Bain, ISACA, and Trusted Computing Group figures on quantum preparedness; the FBI Recovery Asset Team recovery figures; and the hospital-impact figures from the Change Healthcare incident. These are attributed to the source handbook and its cited research.

Matters of public record stated on our own reading: the SEC's 2023 cybersecurity disclosure rules and their four-business-day requirement; NIS2's penalty ceiling of €10 million or 2 percent of global turnover; the $49.5 million multistate Blackbaud settlement; Verizon's 2025 DBIR third-party finding; the Change Healthcare, MOVEit, Kaseya, Snowflake, and XZ Utils incidents; and NIST's publication of post-quantum cryptography standards.

Prepared by Intelligent Automation, LLC — August 2026. Not legal advice. If you need legal or accounting counsel on any of the obligations described here, retain someone qualified to give it.