Three Questions That Make Cybersecurity a Real Board Conversation

For nonprofit leaders who want their board to engage on security but don't know where to start.

I've been in a handful of nonprofit board meetings where cybersecurity came up. The shape is usually the same: a bullet on the risk register, a brief mention, a nod, and on to the next agenda item.

Sometimes there's a flurry of concern triggered by something in the news. Sometimes there's a question or two. Then the topic recedes for another six months.

That's not anyone's fault. Most nonprofit boards aren't built to have a substantive cybersecurity conversation. Members come from fundraising, program, finance, legal, and sector backgrounds. The technical vocabulary is unfamiliar. The risks sound abstract until something specific goes wrong. And the executive director, who carries it the rest of the year, often doesn't have an obvious way to invite the board in without making everyone feel out of their depth.

This is a post about the version of the conversation that works — and the three questions that, in my experience, get a board engaged without requiring anyone to become a security expert.

Why most board cybersecurity conversations stall

The standard format is the risk register. Cybersecurity appears as a row, often with a generic description ("ransomware risk," "data breach risk"), a static rating ("medium"), and no real ownership. The board reviews it once a year, asks a few questions if anyone has them, and moves on.

The problem isn't with the risk register itself; it's with the format, which doesn't generate decisions. A board can't actually do anything with "ransomware risk: medium." There's no concrete thing to allocate resources toward, no specific question to debate, no clear next step.

Most boards sense this. They just don't have a different framework to reach for. So the conversation defaults to the format that exists, even when everyone in the room can tell it isn't producing value.

A more useful conversation: three questions

Here are the three questions I've seen produce better conversations.

1. What data and systems, if compromised, would materially harm our mission, our beneficiaries, or our ability to operate?

This is a mission-first question, not a tech question. The board doesn't need to know what a server is to engage with it. They need to think about consequences in terms they already understand.

For most nonprofits, the answers cluster around a few categories:

• Donor data, especially if major donors would be embarrassed by exposure

• Beneficiary records, often the most sensitive data the organization holds — particularly for orgs serving vulnerable populations

• Financial systems: payments, payroll, grants management

• Program delivery infrastructure: if it goes down, services stop

• Reputation within the communities you serve: some breaches are more reputation-damaging than financially damaging, and the impact is harder to quantify

  
  

The first time a board works through this list, they almost always learn something. Often it's that the things they assumed were most critical aren't, and the things that would cause the most pain are different than expected.

2. What's actually in place to protect those specific things?

This is where the conversation tends to drift into jargon. Resist it. The board doesn't need a deep dive on EDR (endpoint detection and response) versus antivirus, or the differences between SAML and OAuth. They need a plain-language answer for each item identified in Question 1: what's protecting it today?

For many nonprofits, the accurate answer for at least some items will be "not much, formally." That's not a failure. The point of this exercise is to know what you have and what you don't, not to have everything already in place.

What this section produces, when done well, is a clear picture of where the gaps are. Not a list of recommended tools. Not a vendor pitch. A picture.

3. Who would we call if something went wrong — and do they know we'd be calling?

This is the question that catches the most organizations flat-footed.

Many nonprofits assume their IT vendor or managed services provider would lead the response if something serious happened. Many of those vendors don't have incident response capability and don't expect to play that role. The misalignment tends to surface only at the worst possible moment.

A useful answer to Question 3 covers four categories:

• Technical first responder. Who handles immediate forensic and containment work? Is it your IT vendor? Do they have incident response experience? Have they been briefed on what would trigger their involvement?

• Cyber insurance. Where's the policy? Who notifies the carrier? What's the claim process? Carriers often have preferred incident response firms on retainer — knowing this in advance changes who you call first.

• Legal counsel. Does your attorney handle breach notification requirements? If not, who? Notification laws vary by state and by what data was involved.

• Communications. Who decides what to say to donors, beneficiaries, board, staff, and press? What gets said, and when?

A board that can't get satisfying answers to Question 3 has just identified an action item — without anyone having to wave the flag of "cyber risk is medium."

What to do if your board hasn't engaged here yet

If you're reading this and recognizing the pattern (the topic comes up once a year, you carry it alone in between, the board defers to you, you defer to the IT vendor, the vendor defers to "best practices"), that's not unusual. It's the shape most nonprofits arrive in.

The first move is to draft your own answers to the three questions, not to educate the board on cybersecurity. They don't need to become experts. "I don't know" is a valid answer for individual items. The point is to get a written picture of where the organization actually stands.

Then pre-circulate your draft to two board members you trust — ideally one with finance, audit, or risk background, and one who knows your program work deeply. Ask: "Does this make sense? What's missing? What would you want to discuss with the full board?"

When it reaches the full board, frame it as a 20-minute conversation, not a vote item. "I'd like to walk through where we are on cybersecurity and what I need help thinking through." Plan a second discussion 90 days out. Don't try to resolve everything in one meeting.

What this approach does, that the risk-register approach doesn't, is give the board something concrete to engage with. It also takes the burden off you to be the security expert in the room.

The bigger picture

When boards engage on cybersecurity well, three things become possible.

Resource allocation starts to track actual priorities. Money goes to the things that would hurt most, not the things that sounded most important last time someone read an industry article.

Decisions get made and stick. The same questions stop getting revisited every quarter because they've actually been answered.

And the executive director stops carrying it alone. The burden is shared, not transferred — which is what good governance looks like in any other domain, and there's no reason cybersecurity should be the exception.

The three-question framework isn't the only path to a better board conversation on security. Other frameworks exist. What matters is having some framework — not the absence of one.

A practical starting point

If you're an ED who wants to bring this to your next board, here's a useful order of operations:

1. Block 90 minutes this week to draft your answers to the three questions. "I don't know" is a valid answer.

2. Pre-circulate the draft to two trusted board members. Ask for reactions.

3. Add it to your next board agenda as a 20-minute discussion, not a decision item.

4. Plan a follow-up discussion 90 days out, with a narrower scope — pick one of the three questions to go deeper on.

5. 
   

That sequence won't resolve every cybersecurity question your organization faces. It will start a different kind of conversation — one that produces decisions instead of summaries.

If you're carrying the security question alone and want to think through your draft answers with someone before you bring them to the board, that's the kind of conversation LockFort is built to have.