← All Blogs

Your Monthly Security Report: What It Should Say, and What Padding Looks Like

By Best IT MSP Editorial Team - Updated October 22, 2026 - 10 min read

The Best IT MSP editorial team maintains this directory's provider data across the US and Canada. We rank providers on verified rating and firmographic data, label paid placement, and do not sell IT services.

What should a monthly security report tell you?

A monthly security report should tell you whether you were defended last month. Four answers do that. What was watched, what was not, what happened, and what changed because of it. Everything else in the pack is decoration.

Google's engineering handbook sets the bar for any monitoring output in one sentence. A monitoring system should address two questions: what's broken, and why? A 20-page report that answers neither has not failed at being brief. It has failed at being a report.

Your provider's dashboard already shows the present, and a live screen beats a document for anything happening right now. That is why the one-page service review asks for screens instead of paperwork. The monthly report earns its place on the one thing a screen cannot give you, which is a dated series. Coverage last month, beside coverage this month. That comparison is the product you are buying.

Does any standard say what a security report must contain?

Not one that reaches you. No standard obliges a provider to send a private business a monthly security report or sets what goes in it, so the format is a contract term and you decide it. But there is a published model worth stealing. FedRAMP's Continuous Monitoring Playbook, which governs cloud providers seeking federal authorization, recommends uploading the monthly ConMon deliverables (summary report, vulnerability scan files, updated POA&M and Inventory, DRs, SCRs) on the same day each month and then holding a monthly, one-hour recurring Collaborative ConMon meeting a week later, so the recipients have time to read before anyone talks. That is a named deliverable set, a fixed date and a separation of reading from presenting, published free by the buyer side of a federal programme. None of it binds your provider. All of it can go in your agreement.

CISA's performance goals come closest and still stop short. The goal for identifying adverse events asks an organization to have defined clear criteria and processes for adverse events and, where one is suspected, to follow the protocol outlined in the incident response plan to escalate the situation. It names no recipient and sets no cadence. The oversight goal supplies one interval, that policies for managing the cybersecurity program are reviewed at least annually.

One regulator does prescribe a written security report, and it is annual. New York's cybersecurity rules require that the CISO of each covered entity shall report in writing at least annually to the senior governing body, covering, to the extent applicable, material cybersecurity events involving the covered entity during the time period addressed by the report and plans for remediating material inadequacies. Between those reports the officer must timely report to the senior governing body or senior officer(s) on material cybersecurity issues.

Read what the regulator asked for. The events in the period, and the plans to fix what is inadequate. It did not ask for a threat intelligence summary. The rule binds New York financial firms, so treat it as a model rather than your obligation, and notice that the two things it demands are usually the two things missing from your monthly pack.

The test that separates substance from volume

Apply one test to every line in the report. Could you prove it wrong? A number you have no way to check is not a measurement, it is a claim, and the padded sections are always the uncheckable ones.

Start with the biggest number in the pack. Events ingested, or logs collected, usually printed in millions on page one. In Microsoft's own security platform that figure is the invoice. Pricing is based on the tier that the data is ingested into, the default model is pay-as-you-go based on the actual data volume stored, data volume is measured in GB, and ingestion and analysis are billed on a daily basis. So the headline tells you what the service cost to run last month. It does not tell you what the service caught.

Google's handbook applies the same scepticism to collected data. Signals that are collected, but not exposed in any prebaked dashboard nor used by any alert, are candidates for removal. Your report prints those signals as an achievement. The engineers who wrote the discipline treat them as housekeeping.

Alert triage counts have the same problem in a smarter suit. Your provider's sensors produced the alerts and your provider's staff decided how many deserved attention, so both halves of the number come from inside the service you are grading. Falling ticket volume works that trap through in full, and the short version for a security pack is that a count your provider generates cannot show you what it missed.

Three lines pass the test, because each one is keyed to a list you already hold.

• Monitored devices against your own count. How many endpoints and servers reported in the last 24 hours, printed next to the number in your asset inventory. Two figures, and one of them is yours.
• Connected log sources, each with the time it last sent data. A name and a timestamp per row. Nothing in that table is arguable.
• Detections tested, with the date each one was last validated. Configured is a setting. Tested is an event, and an event has a date.

Coverage is the section most monthly reports leave out

Coverage means two concrete lists. Which of your assets are monitored, and which log sources are connected and still sending. Both belong in the report every month, with last month's figures beside them, because the useful fact is the movement.

A silent log source is the specific failure this section exists to catch. A disk fills, an agent stops after an update, a firewall forwarder breaks, and the dashboard stays green because green is only the absence of alerts. Microsoft treats this as routine operational hygiene, listing is the data connector receiving data? among the health questions a security team should ask, alongside whether an analytics rule ran when it was supposed to, and did it generate results.

Cost is not the obstacle. Microsoft states that its health table isn't billable and incurs no charges for ingesting health data, although somebody has to enable health and audit monitoring in settings first. So there are two honest answers to why your report carries no coverage section. Nobody switched the feature on, or nobody ever asked for it.

Federal practice shows how fresh these numbers can be. A 2022 CISA directive tells agencies to initiate automated ingestion of vulnerability enumeration results (i.e., detected vulnerabilities) into the CDM Agency Dashboard within 72 hours of discovery completion. A monthly pack that lands in mid-October and describes September is reporting a world six weeks old. Ask for the date the data was pulled, printed on the page, and verify it against your own change log.

The scope gap worth naming yourself is cloud software. That same directive excludes ephemeral assets, such as containers and third-party-managed software as a service (SaaS) solutions from its own coverage requirement, so no public template covers your Microsoft 365 tenant or your accounting platform. List those systems and ask who monitors each one. Our detection and logging audit sets out the seven checks behind this section, and the IT asset register you can demand covers the list it all gets scored against.

Configured is not tested

To tell a tested detection from a configured one, ask for the date it last fired in a test. Detection coverage says which systems are watched. Detection quality says whether the watching works, and a rule nobody has deliberately triggered is a hypothesis.

The two agencies that do this for a living are blunt about the gap. Insufficient internal network monitoring is one of the ten most common misconfigurations named in a 2023 joint advisory drawn from NSA and CISA Red and Blue team assessments, sitting beside poor patch management and weak multifactor authentication. Their example is specific. An assessment team observed an organization with host-based monitoring, but no network monitoring. Both products had been bought. One layer saw nothing.

Their remedy is a testing programme rather than a purchase. NSA and CISA recommend exercising, testing, and validating your organization's security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework, and recommend continually testing your security program, at scale, in a production environment. Continually, and in production. Your monthly report is the natural place for that evidence to land, and a proactive security operations center already produces it.

Four lines carry the whole of it.

• Detections added, retired, or tuned this month, each with a one-line reason.
• False positive volume by rule, so the noisiest rule becomes visible and gets fixed instead of muted.
• Detections validated, naming the behaviour tested and the date of the test.
• Rules that fired zero times in 90 days, which is either a quiet month or a broken rule, and nobody can tell which without testing.

Noise is why this matters more than it sounds. Google records that when alerts come too often, employees second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a 'real' page that's masked by the noise, and holds that every page response should require intelligence. An unmanaged false positive rate does not only waste an analyst's hour. It trains the desk to look away.

What the report should say about incidents that happened

Four facts per incident, and four is enough. How it was found, when each stage happened, what it turned out to be, and what changed afterwards. A severity label with no incident timeline behind it is a sticker.

The clearest published model is a national authority reporting on itself. In the year to August 2025 the UK's cyber agency received 1,727 incident tips, which were triaged into 429 incidents requiring support. Of those, nationally significant incidents represent 48% (204) of all incidents, a significant increase from last year (89). Among this year's incidents, 4% (18) were categorised as highly significant.

Count what that disclosure does. It publishes the whole funnel rather than the top of it, names where the work came from as a combination of our own information flows and reports from partners and victims, and states last year's figure so a reader can see the direction. Three habits, none of them expensive, and all three missing from the average monthly pack. The hours between an alert and your phone ringing are a separate question, covered in the alert fired at 2:14am.

Six tells that a monthly security report is padding

Six tells mark a padded report, and five of them survive a 60-second flick through the pack.

• A threat intelligence section you could have had free. Paste one sentence into a search engine. CISA publishes its own advisories at no charge, so a reprint is not a deliverable.
• Volume as the headline. Events, signals or logs in the millions, on page one, with no denominator anywhere near them.
• Charts with no list behind them. A pie of alert categories shows how your provider sorted its own output, and nothing about your business.
• No section for what is out of scope. Every environment has unmonitored corners. A report that names none of yours has not gone looking.
• Green every month. A monthly report with no bad news in it is a brochure printed on your data.
• Prose that never changes. Only the counts moved, and the counts came from the same tool that wrote the paragraph.

Then run the test almost nobody runs. Put three consecutive months side by side and read the same page in each one. Count the sentences that changed. A report built from your environment changes every month, because your environment does. A template changes in the number cells and nowhere else, and that one comparison settles an argument adjectives cannot.

A report that cannot be wrong cannot be useful. If every line would read the same whatever happened last month, you are not being reported to.

The monthly security report to ask for, in nine lines

Ask for nine lines on one page, each showing last month's figure beside this month's. Send the list once and it becomes the standing format, because a provider that has to assemble it twice by hand will automate it.

Then add two sentences to the service level agreement. The report arrives by the fifth working day, and every figure in it names the system it came from. Those two commitments do more for the quality of the pack than any argument about charts, and they make it measurable by somebody who is not technical.

Judge the first one on specifics rather than adjectives. Good reads as 58 of 61 endpoints reporting, 2 log sources silent since the 14th, 3 detections validated, 1 incident with a four-stage timeline, and 2 things we got wrong. Weak reads as all systems monitored and no issues detected. None of this buys perfect security, and no honest provider offers that. It buys a verifiable document, which is what you thought you were already getting.

FAQ

What should be in a monthly security report from an MSP?

Four sections. Coverage, meaning how many of your assets and log sources reported. Detection work, meaning rules added, tuned and tested. Incidents, each with a timeline. And what changed. New York's rules ask a security officer to report material cybersecurity events involving the covered entity during the time period addressed by the report and plans for remediating material inadequacies.

Is events ingested a useful security metric?

No. It measures volume, and in Microsoft's own platform it measures cost. Pricing is based on the tier that the data is ingested into and ingestion and analysis are billed on a daily basis. Ask instead how many of your known log sources are connected, and when each one last sent data.

How can I tell whether my security report is padded?

Read three consecutive months together and count the sentences that changed, then check whether any line is keyed to a list you hold. Google's own rule is that signals that are collected, but not exposed in any prebaked dashboard nor used by any alert, are candidates for removal, rather than printed as a result.

What is a silent log source?

A silent log source is a system that has stopped sending logs while the dashboard still looks healthy. Microsoft lists is the data connector receiving data? as a basic health question, and says its health table isn't billable, so cost is no reason for your report to leave this out.

Does my MSP have to send a monthly security report?

Only if your contract says so. No standard sets the cadence or the contents. CISA's goal for adverse events asks only for defined clear criteria and processes for adverse events and names no recipient, so specify the format, the deadline and the nine lines yourself in the service level agreement.

← All Blogs