How to present an IT security report to non-technical leadership

The most common security report in a small business is a forwarded email with an attachment. The attachment is a vulnerability scan, or an assessment a vendor produced during a sales process, or an export from whatever security tooling the business already pays for. It runs to forty pages, it contains between two hundred and two thousand findings, and it is completely accurate. It is sent to the owner or the CFO with a note that says something like “we should talk about this.” Then nothing happens, for months, and the person who sent it concludes that leadership does not take security seriously.

That conclusion is usually wrong, and it is worth being precise about why. Leadership did not decline the report. They could not act on it, because it was not shaped like anything a person can act on. It contained no decision, no cost, no ranking they could trust, and no way to tell whether the business was in better or worse shape than it was six months ago. Forwarding a scan is not reporting. It is handing someone else your unfinished work and hoping the volume does the arguing.

This article is about the finished version: what actually goes in a security report for people who do not work in IT, how to find something to anchor it to when security has no equivalent of a downtime number, how to describe posture in a way that survives being read four quarters in a row, how to make an ask specific enough to approve when what you are asking for is a program rather than a product, and how a vCIO does this on a client’s behalf. It is written for whoever has to walk into that room, which in most small businesses is an internal IT generalist, an operations director, or the provider.

Short answer

Stop sending the scan. The scan is an input to the report, not the report. What goes to leadership is one to two pages with four things on it: where the business stands now on a small fixed set of measures, the top three risks ranked by what they would cost this business rather than by severity score, what closing each one costs, and what has changed since the last review. Then an ask that names a specific amount, a specific decision, and a date. The mechanics of pricing options and getting a spending decision made are identical to the ones in presenting a disaster recovery plan to leadership, so use those. What is different about security is the anchoring: there is no single number like cost per hour of downtime, posture keeps moving whether or not anyone funds anything, and the thing you are asking for is usually an ongoing program rather than a purchase. Those three differences are what most security reports get wrong, and they are the whole subject of the sections below.

What leadership is actually asking, at a glance

Question	Short version
Why do security reports get ignored?	They arrive as evidence rather than as a decision, and there is nothing in them to approve.
Is a vulnerability scan a security report?	No. It is raw material. A report ranks, prices, and recommends.
How long should the leadership document be?	One to two pages, the same four blocks every quarter.
What anchors it, if not downtime cost?	Two or three named scenarios with their own arithmetic, not an industry average.
How many risks should you present?	Three. More than three is a list, and a list does not get prioritized.
How do you rank them?	By what the event would cost this business, not by severity score.
What makes a security ask approvable?	A named amount, a named decision, and a date. Programs need year one and steady state priced separately.
What should never appear?	A tool inventory, severity scores, vendor names, and the scan itself.
How often should it run?	Quarterly, in the same format, plus immediately when something material changes.
What makes the whole thing credible?	Saying what is not in the top three, and reporting honestly on what you promised last time and did not do.

Why security reporting fails harder than any other IT reporting

Budget requests, roadmaps, and recovery plans all struggle to get approved. Security reporting fails for reasons the others do not have, and there are four of them.

It arrives as evidence rather than as a decision. A scan, an assessment, a questionnaire response, a penetration test summary. Each of these is a record of a state of affairs. None of them contains a proposal. The implicit request is “you read this and tell me what you want to do,” which inverts the roles in the room: the person with no technical background is being asked to do the technical prioritization. They will not, and the reasonable response to being handed that job is to put it down.

There is no single number to convert into. This is the structural difference from every other IT conversation, and it deserves its own section below. Downtime has a clean anchor. A license renewal has a price. Security has a probability distribution over a set of very different events, and the honest version of the answer is a range with a wide spread on a thing that may never happen.

It never ends, so it reads as an unbounded commitment. A server replacement finishes. A cloud migration finishes. A security program does not, and leadership can tell. The unspoken fear in the room is not that this quarter’s number is too high. It is that approving it establishes a line item that grows forever with no definition of done. If your report does not address that directly, the objection stays unspoken and the answer stays no.

The category has been oversold, and the room is pre-discounted. Every small business owner has sat through a vendor presentation built on a national breach statistic and a countdown timer. By the time an internal person brings a real finding, the format itself is suspect. This is the cost of a decade of fear-based selling in this market, and it is paid by the honest reporter. The only working response is to be visibly unwilling to overstate, which means occasionally reporting that something is fine.

The three things that make security different from every other funding case

The mechanics of getting money approved are the same across IT. Present options rather than a single price, put a number on doing nothing, give ranges instead of points, concede the true part of an objection before answering it. All of that is set out with worked examples in the article on funding a disaster recovery plan, and none of it changes here. Do not rebuild it. Reuse it.

What changes is three things underneath the mechanics.

There is no single anchor number. Downtime reduces to one defensible figure: revenue plus idle labor, divided by business hours. Every argument about recovery spending resolves against it. Security has no equivalent, because the events are not the same event. Wire fraud from a compromised mailbox, ransomware across the file server, a client’s data exposed through a misconfigured share, and a departing employee walking out with the customer list are four different financial shapes. Averaging them produces a number that describes nothing. The replacement for one anchor is a small set of specific scenarios, each with its own arithmetic, covered below.

Posture is a trend, not an event. A recovery capability is built once and then tested. A security posture degrades continuously without anyone doing anything wrong: staff join and leave, software ages out of support, a vendor changes a default, someone adds an integration. This means the report cannot be a one-time case. It has to be a recurring artifact whose most valuable section is the comparison against last quarter, which is why 63885’s observation that leadership wants to know what has changed since the last review is not a nice-to-have. It is the section that makes the other three mean anything.

The ask is usually a program, not a purchase. You are rarely asking for one product at one price. You are asking for a capability that runs continuously, plus staff time that belongs to other departments, plus a behavior change that leadership has to visibly back. A purchase is approved once. A program has to be approved, resourced, and then defended internally when it inconveniences someone in week three. If the report does not name the non-financial parts of the ask, they do not happen, and the money gets spent on tooling that nobody adopts.

Why the scan is not the report

A vulnerability scan tells you what is technically present. It does not tell you what matters, and the gap between those is where most security reporting goes wrong.

A scan will return hundreds of findings on a network of forty devices. Most will be informational. Many will be duplicates of the same underlying issue counted once per host. A sizeable share will be findings on systems that are not reachable from anywhere an attacker would be, or that are compensated for by a control the scanner cannot see. And the ones rated critical by the scoring system are frequently not the ones that would actually hurt this business, because severity scores are computed against a generic environment rather than yours.

The practical consequence is that the two things people do with a scan in front of leadership both fail. Presenting the finding count creates a number that goes up when you add monitoring coverage, which means doing more work makes the metric worse and you will eventually stop reporting it. Presenting the critical findings first substitutes the scanner’s judgment for yours, which is the judgment you are being paid for.

What a scan is genuinely good for is finding things nobody knew were there, and supporting a statement in the report with a fact. “Nine machines are running an operating system that stopped receiving security updates in October, including the one the practice management software runs on” is a sentence that belongs in a report. It came from a scan. The scan did not.

The same holds for the other common inputs. A network assessment and a Microsoft 365 security audit are both useful and both produce findings lists that need the same treatment: read, rank against what this business would actually lose, and compress. If your report and the tool’s output have the same number of items in the same order, you have not done the work.

What to anchor on when there is no downtime number

The honest position is that nobody can tell a small business owner the probability that they will be breached next year. Anyone who offers a precise figure is selling something. But the absence of a probability does not mean the absence of arithmetic, and there are three anchors that hold up under pressure.

Name two or three scenarios that fit this business specifically. Not categories, scenarios: a sentence describing something that could plausibly happen here, to these systems, with these people. Then do the arithmetic on each one separately. The scenarios are more persuasive than any statistic because they are recognizable, and doing them separately is what preserves the honesty of each number.

Here is the shape it takes for a professional services firm of around fifty people.

Scenario	What it would cost this business	Current ability to prevent or detect it
A compromised mailbox used to redirect a client payment	Average invoice $28,000, no callback verification process, insurer excludes social engineering without one	MFA on 41 of 58 accounts, no mailbox rule alerting
Ransomware across the file server and one workstation	Downtime at roughly $2,400 per hour, last measured restore 19 hours, plus forensics and notification	Endpoint protection present, no monitored detection outside business hours
A client’s data exposed through an over-shared folder	Two contracts require notification within 72 hours, one names an audit right	Nobody has reviewed external sharing in 18 months

Three rows. Each one is checkable, each one is specific to this firm, and none of them needs a national average to land.

Reuse the downtime number where it genuinely applies. Ransomware is a downtime event, and if the business has already calculated the cost of an hour offline for its recovery planning, that arithmetic transfers directly and should be cited rather than recalculated. It also connects the two conversations, which is useful: leadership has already accepted that figure once. How long recovery actually takes after a ransomware attack is the reference that keeps the estimate from drifting optimistic.

Anchor on what is already being carried. The most effective single framing in security reporting is the same one that works for recovery: this is not a new cost, it is an exposure the business currently holds for free. Where published figures help is in establishing order of magnitude, and what a data breach actually costs a small business exists for exactly that. Use it to set the scale of the scenarios, not as the argument itself. A number from a report is something to debate. A number from your own invoice ledger is not.

One discipline applies to all three. Say which parts are estimated and invite the correction. If the CFO adjusts your average invoice value downward, use their figure. A number leadership edited is a number leadership will repeat.

Posture in four numbers leadership can hold

The instinct when building the posture section is to show everything that is measured, because everything that is measured took work. Resist it. A dashboard with thirty tiles communicates less than four numbers that mean something, and it communicates nothing at all by the third quarter, when the reader has learned that the tiles never change.

Pick four to six measures. Keep them identical every quarter. Give each one a current value, a target, and a direction of travel. The point is not the absolute number. It is whether it is moving.

Measure	What it tells leadership	The trap
Percentage of accounts on phishing-resistant MFA	Whether the single highest-value control is actually deployed, not just enabled	Counting accounts that have MFA available rather than enforced. MFA alone is not the finish line
Percentage of endpoints patched within 30 days	Whether the routine work is being done, not whether tooling exists	Excluding the machines that are hardest to patch, which are the ones that matter
Number of accounts with administrative rights	The blast radius of any single compromised user	Counting named admins and missing service accounts and legacy integrations
Date of last tested restore, and the measured result	Whether the recovery you are relying on has been proven recently	Reporting the backup job’s success rate, which is not the same thing at all
Median time to detect, or coverage hours if unmeasured	Whether anyone is watching outside office hours	Reporting tool coverage as if it were monitored coverage
Accounts belonging to departed staff still active	Whether offboarding is actually closing, a measure that is cheap and embarrassing	Checking only the directory and not the SaaS applications

Two notes on measures that look attractive and behave badly.

Phishing simulation click rates are the most requested and least useful metric in small business security reporting. The number is easy to manipulate in both directions, it varies more with the difficulty of the template than with staff behavior, and a very low rate usually means the simulations are too easy rather than that the staff are well trained. If leadership wants it, report it with the caveat attached, and never report an improvement without saying whether the difficulty was held constant.

Training completion percentage measures compliance with a task, not capability. It belongs in the report if a regulator or insurer asks for it, and that is the honest framing to give it: this number exists because we are asked for it, not because it predicts anything.

The top three risks, and why it is exactly three

Three is not an arbitrary round number. It is the number of things a person who does not work in IT can hold, rank, and repeat to someone else after the meeting. A list of nine risks is not a prioritization, and handing it over transfers the prioritizing back to the reader, which is the original failure.

Rank by what the event would cost this business, multiplied by a rough and openly stated sense of how likely it is here. Not by severity score. A critical-rated vulnerability on an isolated test machine ranks below an unremarkable configuration gap on the mailbox that receives client payment instructions, and if your ranking does not reflect that, the ranking is the scanner’s rather than yours.

Each risk gets four lines and no more:

• What it is, in a sentence with no acronym. “Seventeen staff accounts can be accessed with a password alone” rather than “incomplete MFA enforcement across the tenant.”
• What happens if it is exploited, with the number from the scenario table.
• What closing it costs, as a range, and how long it takes.
• What it would require from people outside IT, if anything.

That last line is the one that gets left out and the one that determines whether the work actually completes. If closing a risk means every member of staff re-enrolls a device, or the sales team loses the shared login they have used for four years, leadership needs to approve that friction explicitly. Approval of money is not approval of disruption, and discovering the difference in week two is how security projects stall at seventy percent, which is a state that costs full price and delivers very little.

Then name what did not make the top three, and why. Two lines. “We also found X and Y. Both are real, neither would cost the business much if exploited, and I would rather spend the quarter on the three above.” This is the single most credibility-building paragraph available to you. It demonstrates that a ranking happened, it proves you are not presenting everything as urgent, and it quietly establishes that when you do say something is urgent, it is.

What has changed since the last review

This is the section a disaster recovery proposal does not need and a security report cannot work without, because posture moves on its own. It has three parts and it should fit on a third of a page.

What closed. What was in last quarter’s top three, what was done about it, and what the measure reads now. Closing a risk is the only evidence you have that funding this work produces results, so report it specifically: not “MFA rollout progressing” but “MFA enforcement went from 41 of 58 accounts to 58 of 58, completed March 14.”

What is new. Things that became true since the last report without anyone making a decision. A system reached end of support. Headcount grew and with it the number of accounts. A new application was connected to the company data. A vendor had an incident. This part is where the continuous nature of the problem becomes visible rather than abstract, and it is the honest answer to “why does this keep coming back.”

What did not get done, and why. Including the items you said you would do and did not. This is uncomfortable and it is the part that makes the rest believable. If last quarter’s report promised a sharing review and it did not happen because the person who was going to do it spent six weeks on an office move, say exactly that. A report that only ever contains progress is a report nobody checks against reality, and eventually nobody reads.

One formatting discipline holds this section together: keep the measures in the same order and the same units every single time. A reader who can put two quarters side by side and see four numbers move is being given something no amount of narrative provides. A reader who has to work out whether this quarter’s chart is comparable to last quarter’s is being given work.

Making the ask specific enough to approve when it is a program

Present three priced options, price the do-nothing row, give ranges rather than points, and recommend one. That structure is unchanged from the recovery funding article and it works the same way here.

Four things are genuinely different when the ask is a program.

Separate year one from steady state. The first year contains setup, remediation of the existing backlog, and often a burst of labor. The years after it do not. Presenting a single blended annual figure either overstates the ongoing commitment or understates the first year, and both cost you credibility at the point where it matters. Two columns. “Year one, $34,000. Each year after, $19,000.” That structure also answers the unspoken fear about an unbounded line item, because it shows the shape flattening.

Name the internal cost in hours. A security program spends other people’s time. Device enrollment, password manager rollout, a permissions review that needs a department head to confirm who should have access to what, a policy everyone has to read and sign. Put an hours estimate on it, by department, and put it in the ask. Hiding it does not make it go away, it just moves the argument to a month when you have already spent the money. Rolling out a password manager across a business is the clearest example of this: the license cost is trivial and the adoption work is the entire project.

Separate the decisions that cost nothing. Some of what you need is not money. Removing local administrator rights. Mandating MFA with no exceptions for executives. Approving a security policy with consequences attached. Requiring callback verification on payment changes. These are free and they are harder to get than the budget, because they create friction for people with influence. List them separately as decisions rather than burying them in a scope description, and ask for each one explicitly. An executive MFA exemption granted quietly six months after the program is approved undoes a meaningful part of what was bought.

Define what done looks like, even though the program does not end. You cannot promise that security work finishes. You can define the state you are trying to reach and say what maintaining it costs, which is a different and answerable question. “The goal is every account on phishing-resistant MFA, every endpoint patched within thirty days, monitored detection around the clock, and a tested restore every quarter. Getting there takes about nine months. Holding it is the steady state number.” That converts an open-ended commitment into a destination plus a maintenance cost, which is a shape leadership already understands from every other part of the business.

What a board-level security summary looks like

One to two pages, four blocks plus the ask, in this order. Leadership wants current posture, the top three risks, what closing them costs, and what has changed since the last review. It does not want a tool inventory.

1. Current posture. The four to six measures, with current value, target, and direction. A short paragraph underneath giving the one-sentence read. “Two of the four measures improved this quarter, one is unchanged, and monitoring coverage outside business hours remains the weakest point.”

2. The top three risks. Ranked, four lines each, with the cost of the event drawn from the scenario arithmetic. Followed by the two lines naming what did not make the list.

3. What closing them costs. Three options with prices, including doing nothing priced at the exposure it carries, and a recommendation with a reason. Year one and steady state shown separately. The non-financial asks listed as their own short block.

4. What has changed since the last review. Closed, new, and not done. Same order every time.

5. The ask. An amount, a decision, and a date. “Approval of $31,000 for year one, a decision on removing local admin rights, and both by the April meeting so the work starts before the summer.”

What to leave out is as specific as what to include. No tool inventory, which is the single most common filler in these documents and tells the reader nothing about whether they are safe. No severity scores or CVE numbers. No vendor or product names, because naming one turns a risk decision into a procurement conversation before the risk decision has been made. No network diagram. No acronym you would have to define, which in practice means writing “a second form of sign-in that cannot be phished” rather than a product feature name. And no appendix, though having the full findings in the room and saying where they live is worth a sentence.

Put the ask on page one. A summary that builds to its request at the bottom of page two gets read to the middle of page two.

The column nobody fills in: what we have already attested to

Security reporting has an obligation dimension that recovery planning only touches in passing, and it is frequently the fastest route to a decision because it converts an abstract risk into a commitment already made.

Most small businesses have told someone, in writing, that certain controls are in place. The cyber insurance application asked whether MFA is enforced on email and remote access. A client’s vendor security questionnaire asked about access reviews and encryption. A HIPAA-regulated business has documented a risk analysis, or has said it has. A contract contains a security clause someone signed.

Pull those answers and compare them against what is actually true. Where they match, that is worth a line in the report, because maintained compliance is a result. Where they do not, that is not a technical finding. It is a business exposure of a different kind: an insurer can decline a claim where a warranted control was absent, and a client can treat a questionnaire answer as a contractual representation. Present the mismatch plainly, without drama, as a row with three columns: what we said, what is true, what it takes to make them agree.

Two cautions. Do not use this as leverage, because leadership will hear the implied threat and the conversation ends. State it once, factually, and move on. And be aware that a written record of a known unremediated gap is discoverable, which is an argument for closing gaps rather than for not writing them down, but it is a reason to write carefully. Describe the gap and the plan in the same document, with dates, so the record shows a business managing a risk rather than one sitting on it.

How often, and why the format should be boring

Quarterly for the standing report. That cadence matches the rhythm of a quarterly business review and is frequent enough that the change section has content without being frequent enough to become noise.

Outside that, one thing warrants an immediate report: a material change to the risk picture. An active incident, obviously, but also a vendor breach that touches your data, a newly exploited vulnerability in something the business depends on, or a departure that leaves a meaningful access gap. Keep those to half a page with the same structure, and use them sparingly. A person who sends an urgent security note four times a year is read every time. One who sends them monthly is filtered.

The format itself should be unchanging to the point of dullness. Same headings, same measures, same order, same units. There is a temptation to improve the deck each quarter, and it costs more than it gains: a reader who has to relearn the layout cannot compare against last time, and comparison is the entire value of a recurring report. Save the redesign energy for making the four numbers more accurate.

Deliver it live where possible, in fifteen minutes, with the document sent afterwards rather than in advance. Sending first means the room has skimmed it and formed a position before you speak. Reading the four measures aloud, naming the three risks, and asking for the decision takes eight minutes and leaves room for the questions, which are the part that tells you what leadership is actually worried about.

What leadership will push back on

The pattern for answering an objection is the same one used throughout this series and set out with examples in the recovery funding article: concede the accurate part first, then add the specific fact it does not account for. Arguing with the premise makes the other person defend it, and a person defending a position does not approve a budget.

These are the objections that are specific to security and do not come up in a recovery conversation.

The objection	The answer
“We are too small to be a target.”	Mostly true for targeted attacks, and not how this works. The common cases are automated and untargeted, and the way ransomware actually reaches small networks has nothing to do with being interesting.
“We have never had an incident.”	Correct, as far as we know. We currently have no way to detect a quiet one, which is the second item on the list. Nobody knowing is not the same as nothing happening.
“Isn’t this what we pay the provider for?”	Partly, and they do that part well. The agreement covers monitoring and patching. It does not commit them to enforcing MFA on accounts or reviewing who has access, so those sit with us by default.
“We spent money on this last year.”	We did, on endpoint protection, and it is working. This is the next layer, not a replacement for it. If it were replacing something I would be recommending we cancel that.
“Can’t we just buy insurance?”	We should have it, and we do. The policy asks whether specific controls are in place, and two of our answers would not currently hold up. Insurance prices the risk, it does not remove it.
“Will this stop us getting breached?”	No, and I would not present it as if it would. It reduces how often, how far it gets, and how long before we notice. Those three are what the cost difference comes from.
“Everything is on the list. What is actually urgent?”	Item one. If we only do one thing this quarter, do that, and I would rather have it done than all three started.

That last row is worth having an answer ready for, because it is a test. A person who cannot reduce their own three-item list to one item under pressure has not ranked it.

A worked example

A 60-person engineering consultancy. The internal IT lead had been sending a monthly security summary for over a year. It was thorough: patch compliance charts, blocked threat counts from the endpoint console, firewall traffic summaries, a section on new vulnerabilities. Nobody had ever responded to it. When she asked for budget to add monitored detection, the answer was that things seemed to be under control based on her own reports.

That is the specific failure worth naming. Her reports had been accidentally arguing the opposite case. Blocked threat counts read as “the existing tools are working.” Patch compliance at 94 percent read as fine, because no target had been stated that would make 94 percent inadequate. She had been publishing reassurance for a year and then asking for money to fix a problem she had never described.

The rewrite was one page. Four measures with targets: MFA enforcement at 44 of 63 accounts against a target of all; patching within 30 days at 94 percent with the note that the remaining 6 percent was the six oldest machines including the license server; monitored detection coverage at 45 hours a week against 168; and last tested restore, 14 months ago, result unknown.

The fourth measure was what changed the meeting. It had never appeared in any prior report because backups were not considered a security topic. “We have not verified in 14 months that we could recover from ransomware” was the sentence the managing partner repeated back.

The top three risks came from scenario arithmetic done against their own numbers rather than from the vulnerability report, which had 312 findings. Nineteen accounts reachable with a password alone, against a business that invoices an average of $41,000 per project and has no callback verification. No detection outside business hours, against a 19-hour unverified restore. Two former contractors still holding active access to the project file share, found during the account review rather than by any tool.

The change section was two lines long, because it was the first report in the new format, and it said so.

The ask was $28,000 in year one and $17,000 annually after, in three options, with the middle one recommended. The non-financial asks were listed separately: MFA for everyone including the two partners who had been exempted, and an access review each quarter that department heads would have to spend an hour on. The partners approved the middle option and the MFA mandate. The access review took two more quarters to actually happen, which appeared in the “not done” section of the next two reports, and appearing there twice is what eventually got it scheduled.

The measure that moved first was the restore test, which cost nothing and was completed within three weeks. It came back at 22 hours against an assumed six, which made the following quarter’s report considerably easier to write.

Common mistakes

1. Forwarding the scan and calling it a report. The volume is not the argument. An unranked findings list transfers your job to someone who cannot do it.

2. Leading with a national statistic. A breach average from a published report is background, not evidence. Leadership has heard it from three vendors and discounted it. Your own invoice values have not been discounted.

3. Reporting activity instead of posture. Threats blocked, tickets closed, patches applied. These describe effort, and worse, they read as reassurance. Report the state of the business, not the volume of the work.

4. Changing the metrics every quarter. Usually done to show the best available numbers, and it destroys comparability, which is the only thing that makes a recurring report worth reading.

5. Presenting more than three risks. A list of nine is not a priority order. It is the prioritization handed back to the reader unprocessed.

6. Ranking by severity score. The scanner does not know what your business does. A high-severity finding on a machine nobody can reach ranks below a boring one on the mailbox that receives payment instructions.

7. Omitting the human cost of the ask. Money is the easy part. Device enrollment, new sign-in friction, and a permissions review that costs department heads their time all need approving explicitly, or the project stalls after the invoice is paid.

8. Never reporting that something is fine. If every report is an emergency, the reports stop being read. Occasionally saying a measure hit target and needs nothing is what buys attention for the quarter when it matters.

9. Leaving out what you failed to do. A report containing only progress is a report nobody checks against reality. Naming the unfinished item and the reason is what makes the finished ones believable.

10. Using fear as the closing argument. It works once. The second time, the room has already priced it in, and you have spent the credibility you need for the finding that genuinely is serious.

How a vCIO produces and presents this for a client

This is one of the clearest examples of what the vCIO function is for, and the reason is structural rather than technical.

The person who runs security operations is not well positioned to present the security funding case, because they are proposing their own budget. Everyone in the room knows it, and the argument gets discounted regardless of merit. That discount applies to an internal IT lead and it applies to a provider, which is why an MSP recommending more MSP services is a weaker argument than the same recommendation from someone whose fee does not change with the answer. Where that separation is not available, the substitute is to make the conflict explicit and price an option that involves buying less.

The work itself is: collect from the tooling but do not report from it; run the scenario arithmetic against the company’s own financials rather than published averages; pull the insurance application and the client questionnaires and compare them to reality; rank three risks by business cost and be prepared to defend what was left out; price three options with year one and steady state separated; write one page; present it in fifteen minutes; and then produce the same page in the same format next quarter with the change section filled in. That last part is what converts a one-time approval into a standing line item that stops being argued about.

There is also a role in the room that is hard to fill from inside. When a partner asks to be exempted from MFA, the person who reports to that partner is not well placed to say no. An external advisor is, and saying it is part of the job.

One question worth asking of anyone doing this for you, including us: ask when they last told a client that a control was adequate and recommended spending nothing. Security recommendations are unusually easy to inflate, because nobody wants to be the person who argued for less protection and was wrong. Someone who can point to a specific case where they said the current setup was fine is someone whose recommendation to spend actually carries information.

How this fits the rest of your IT

Security reporting sits on top of work covered elsewhere in this series, and it is only as good as what feeds it. The underlying capability is the subject of managed cybersecurity services for small business, and the detection question specifically is covered in managed detection and response and, for businesses considering log aggregation, whether a SIEM is warranted at all. The posture measures themselves come from ordinary operational work: endpoint protection, password hygiene you can actually audit, and a tested restore, which belongs in a security report even though it is usually filed under backup.

On the strategy side, a security program is an instance of the general pattern in aligning IT strategy with business goals, and it lands far better when it appears on the IT roadmap a year before it needs funding rather than arriving as a surprise. Where it sits in the annual numbers is a question for the technology budget cycle, and whether the total is reasonable for a business your size is answered separately in how much you should spend on IT.

Two connections are less obvious. What your provider has actually committed to, as opposed to what you assume they handle, is a contract question covered in what should be in a managed IT services agreement, and the gap between those two is a recurring source of risks that nobody owns. And in businesses with an internal IT person, the split between running the controls and making the case for them is exactly the division described in co-managed IT and in vCIO versus IT manager. Operating a security program is one job. Getting it funded and defended is a different one, and it tends to go undone where nobody holds it.

What is next in this series

The next article moves from reporting on your own technology to assessing someone else’s: technology due diligence, or what to check when acquiring a small business. What the review actually covers across infrastructure, license compliance, security posture, technical debt, vendor contracts and their exit provisions, and data governance. The red flags that should change the valuation or the terms rather than just the integration plan, how to scope the engagement so it finishes before the deal does, and how a vCIO supports both sides of the transaction.

How Sequentur can help

If you are the person who has to present security to leadership and it has not been landing, the useful first step is turning whatever you already have into one page with four numbers and a ranked three. Schedule a call.