I have spent most of my career on one side of the boardroom table — the side that reports. I build the deck, I take the questions, and I own the answer when something has gone wrong or is about to. From that seat you learn, very quickly, which directors are actually governing and which are receiving a status update and calling it oversight. The difference is not seniority or credential. It is the questions they ask, and whether they can tell the difference between being told a thing is handled and knowing that it is.
Reporting to a board and sitting on one are different jobs. I am clear about which one I do today, and I am equally clear that watching good directors work is the best preparation there is for eventually doing the other. So this is a piece about the second job written from the vantage of the first: what the reporting side has taught me about what real cyber and AI oversight requires, and the questions I would ask if I held the seat.
Most board content on security — including some I have written — is advice to the executive presenting up: how to structure the pre-read, how to translate risk, how to ask for a decision. This is the other direction. This is what the person receiving that pre-read should be doing with it.
Oversight is not management, and the line is the whole job
The first thing the seat requires is discipline about a line the executive side does not have to hold: the line between oversight and management. A director does not run the security program. A director is responsible for knowing whether the program is real, whether it is funded to the risk the company actually carries, and whether the person running it is being honest. That is a narrower job than the operating one, and in some ways a harder one, because you are accountable for an outcome you are not allowed to execute.
Both failure modes live on that line. The director who tries to manage — who wants to debate tooling, redesign the architecture, pick the endpoint vendor — is not adding oversight. They are adding noise, and they are usually crowding out the questions only the board can ask. The director who defers entirely — who accepts "it's handled" because the security lead seems competent and the slide is green — is not governing either. They are spectating. Oversight lives in the narrow band between those two, and holding that band is most of the work.
Here is the tell I would watch for in myself. When management brings a problem, the operating instinct is to help solve it. The oversight instinct is different: is the problem surfaced honestly, is the plan real, is this a risk the board is actually willing to carry, and is there anything management is not saying because they are hoping to fix it before anyone notices? The first is a management reflex. The second is the job.
The SEC made cyber a board decision, not just a CISO one
For public companies, the era where cyber lived entirely with the security team ended when the SEC's cyber-disclosure rules took effect. Under Form 8-K Item 1.05, a company that experiences a cybersecurity incident it determines to be material has roughly four business days to disclose it. Read that sentence again with a director's eye, because the load-bearing word is material, and materiality is not an engineering judgment. It is a board-level judgment about impact on the company and its investors, and it is one directors can be asked to defend after the fact.
This is the part I would least want to be improvising during the incident. The failure I have watched from the reporting side is a board that meets its disclosure obligation the way you meet a fire drill you never rehearsed — assembling the materiality judgment, the disclosure committee, and the legal read in the same forty-eight hours you are also trying to contain the thing. The questions a director should force long before that day are simple, and almost never asked in advance:
- Who decides materiality, and against what? Not "does the security team think this is bad." A defined process, a threshold, and named decision-makers — security, legal, finance, disclosure — who have practiced making the call on a hypothetical before they have to make it on a real one.
- What is our disclosure clock, mechanically? The four-day window starts at the materiality determination, not at first detection, and a company cannot indefinitely delay that determination to stop the clock. A director should understand that distinction and should have seen the runbook that operationalizes it.
- Have we rehearsed this at the board level? Tabletops usually stop at the operating team. The disclosure decision is a board and committee decision, and it deserves its own rehearsal with the actual people who will have to make it.
None of that is management's private business. The disclosure judgment is the board's exposure. A director who first engages with it after the 8-K is already due is doing incident response, not oversight.
Ask to see the control run, not the policy that describes it
The single most useful habit I have seen effective directors bring — and the one I would bring — is refusing to accept the existence of a policy as evidence that a control works. A policy is a description of intent. What a director should ask for is the last time the control actually fired, and what the record of it looks like.
"Do we require MFA everywhere" is a status question, and the answer is always yes. "Show me the exception report — the accounts that are exempt, who approved each one, and when each was last reviewed" is an oversight question, and the answer is where the truth lives. "Do we have an incident response plan" invites a yes. "When did we last run it against a scenario we had not seen before, and what broke" invites the truth. The move is always from the noun to the verb — from the policy to the moment it was exercised.
This is where my operating experience shapes what I would demand. On my own team we built an internal platform for governing automated systems — we call it AgentOS — around a simple conviction: a control that cannot produce its own record is not a control you can be examined on. Every consequential action leaves an audit trail, and the system distinguishes, by design, between an output that can be acted on directly and one that has to be interpreted by a human first. I did not build that because a framework told me to. I built it because I have to answer for those systems, and you cannot answer for what you cannot show. A director should want from the whole company exactly what a serious operator wants from their own platform: not the assurance that a control exists, but the ability to watch it work.
AI oversight is a model-risk question, not a technology-fascination one
The newest thing on the oversight agenda is AI, and the most common mistake I watch boards make with it is treating it as a fascinating novelty to be briefed on rather than a risk to be governed. The right frame is older and more boring than the technology: most of what a board needs to ask about AI is model risk, and regulated finance has governed model risk for years. SR 11-7, the interagency model-risk guidance, already describes the shape of the questions — is the model validated, is it monitored for drift, does someone independent of the people who built it own that validation. AI does not repeal those questions. It raises their stakes and multiplies their number.
What is genuinely new is the pace and the surface area. The US Treasury published a Financial Services AI framework in February with 230 control objectives across seven domains — a signal of how much regulatory structure is arriving, and how fast. The EU AI Act's obligations for general-purpose models carry enforcement powers that activate on August 2, with fines reaching 3 percent of global turnover. California's automated-decision rules land in January 2027. A director does not need to read any of these cover to cover. A director needs to know that management has read them, has mapped the company's AI to them, and can say which systems fall in scope and which do not.
The questions I would put on the agenda are deliberately unglamorous:
- Where does AI touch a decision that affects a customer? Credit, pricing, eligibility, account actions. That inventory is the whole ballgame, and in regulated finance an AI-driven adverse decision inherits explainability obligations that predate AI by decades — the same adverse-action reasoning fair-lending law has always demanded of a human.
- Who owns the AI, and is it the same person who owns protecting it? The governance question and the security question are converging on one control plane, one identity problem, one audit trail. A board should ask whether the org chart reflects that convergence or fights it.
- How many non-human identities are we running, and who governs them? Every agent and automation holds credentials. Industry counts now put machine identities at dozens per human and climbing — in some tallies well past a hundred to one. That is an access-control and accountability question a board can understand without reading a line of code.
- What can our AI do without a human, and how fast can we shrink that set when we are wrong? The oversight question is not "is the AI good." It is "what is the blast radius when it is confident and wrong," because that is the failure mode that actually hurts you.
Notice that none of those questions require a director to be technical. They require a director to be relentless about the same three things governance has always been about: what can hurt us, who is accountable, and can you show me it works.
What the seat actually requires
If I distilled all of it into what I would hold myself to from the director's chair, it comes down to four habits, and none of them require me to run anything.
Separate oversight from management, and stay on the oversight side even when the operating instinct is screaming to help. Treat cyber materiality and the disclosure clock as a board decision you rehearse before the incident, not one you improvise during it. Ask to see controls run, not policies that describe them — move every question from the noun to the verb. And govern AI as model risk with a faster clock, starting with one inventory: where does a model touch a decision that affects a customer, and what can it do without a human in the loop.
Do those four things and you are governing. Skip them and you are receiving a status update in a nicer room.
I am still on the reporting side of this table, and I pay close attention to the directors who make me a better executive — the ones whose questions I cannot answer with a green slide. If you sit on a board, or report to one the way I do, I would genuinely like to know: what is the one question that most reliably separates real oversight from the performance of it? Leave a comment. I read them, and the good ones change how I show up to the next meeting.
