For CFOs: Seven Questions to Ask About Cyber Risk
Most CFOs are not short on security information. They get vendor pitches, insurance questionnaires, audit findings, and IT reports full of acronyms. What they are short on is a way to tell whether the business is actually in good shape.
This guide is for CFOs and controllers who want to ask better questions without becoming technical. It is the first in a series of plain-language guides for owners, CFOs, COOs, and CIOs.
Why this is a finance question
Cyber risk ends up on the CFO's desk whether anyone planned it that way or not. Fraudulent payments come out of your accounts. Downtime stops billing and collections. Insurance applications ask you to attest to controls. Regulators and customers ask for evidence. And when an incident happens, someone has to make fast decisions about money.
The NIST Cybersecurity Framework 2.0 made this explicit. It added a sixth function, Govern, alongside Identify, Protect, Detect, Respond, and Recover. Govern covers how the organization sets its risk strategy, assigns roles and responsibilities, oversees the program, and manages supplier risk. Those are leadership questions, and finance has a seat at that table. You can read the framework itself at nist.gov/cyberframework.
Seven questions to ask
1. How does money leave this company, and what would stop a fraudulent payment?
Map every way funds can move: ACH, wires, checks, card payments, payroll changes. For each, ask who can initiate, who approves, and how a change to a vendor's bank details is verified. The answer you want is a callback to a known phone number, not a reply to the email that requested the change. Payment fraud through compromised or spoofed email is one of the most common and direct ways cyber risk becomes a financial loss.
2. If our main systems went down tomorrow, how long until we can bill and get paid?
Ask IT for the expected recovery time for the systems that drive revenue: the ERP, the practice management system, the DMS, whatever yours is. Then ask when that recovery was last tested. A backup that has never been restored is an assumption, not a plan. If the answer is "we think a few days," ask what that estimate is based on.
3. What did we tell our insurer, and is it still true?
Cyber insurance applications ask detailed questions: Is MFA enabled for remote access and email? Are backups kept offline or immutable? Do you have an incident response plan? Those answers are representations. If they were wrong when you signed, or became wrong since, coverage questions can follow. Pull last year's application, sit down with IT, and confirm each answer before renewal.
4. Which vendors could hurt us most, and how do we know they are secure?
Every business depends on vendors that hold its data or have access to its systems: payroll, accounting software, IT providers, cloud platforms, billing services. Ask for a short list ranked by impact. For the top of that list, ask what you have on file: a security questionnaire, a third-party report, a contract clause, a business associate agreement if you are in healthcare. NIST CSF 2.0 treats supplier risk as part of governance, not an IT side project.
5. Who is accountable for security, and who do they report to?
Someone should own the program by name. For dealerships under the FTC Safeguards Rule, that is the Qualified Individual. For healthcare, it is the security official HIPAA requires. Elsewhere, it may be an IT director or an outside provider. Ask who it is, how often they report to leadership, and when you last saw a written report. If nobody can answer, that is your first finding.
6. What are our top risks right now, and what are we doing about each?
A good answer is a short list: the top five or so risks, the current status of each, the owner, and the next step. A bad answer is a dashboard of green lights with no explanation. You do not need technical detail. You need to know that someone has ranked the risks and is working down the list.
7. What would we do in the first hour of an incident?
Ask whether there is a written incident response plan, who is on the call list, and whether the plan includes your insurer's breach hotline and outside counsel. Ask who has authority to approve emergency spending and to take systems offline. Many of the costliest mistakes happen in the first hours, when people improvise. Our post on building an incident response plan you will actually use goes deeper.
What good answers sound like
You are not looking for perfection. You are looking for specific answers with evidence behind them. "MFA is on for all email and remote access, here is the report" is a good answer. "I think so" is not. "We restored the ERP in a test last quarter and it took most of a day" is a good answer, even if you want it faster, because now you know.
When answers are vague, ask for the evidence. When the evidence does not exist, that becomes the work.
Tie spending to risk
Once you have answers, budget conversations get easier. Every security line item should point to a risk it reduces: MFA reduces account takeover, tested backups reduce downtime, payment verification reduces fraud. If a proposed purchase cannot be tied to a risk on the list, ask why it is a priority.
Frameworks help, but they are not the goal
Your business may answer to HIPAA, the FTC Safeguards Rule, NIST SP 800-171, or customer requirements. Ohio businesses also have a reason to care about framework alignment: under Ohio Revised Code 1354.02, a covered business with a written cybersecurity program that reasonably conforms to a recognized framework, such as the NIST CSF or the CIS Controls, can assert an affirmative defense to certain tort claims after a data breach. That is a reason to document the program, not a guarantee of any outcome. Talk to your counsel about how it applies to you.
How we help
TRNSFRM works with CFOs and owners across Cleveland and Columbus to turn security into answers they can act on. Start with the free compliance checklist, read about our approach to cybersecurity, or book a free 45-minute Compliance Gap Audit to walk through these seven questions with a senior engineer.