Use a cybersecurity scorecard template to show what you checked, what remains unresolved, and who must act. I'd leave out the overall security grade. A reassuring average is a poor answer when a particular control has a gap the client needs to decide about.
Keep the client page short, with the working evidence behind it. Give each row a status, a scope, a date, and a next action. If you haven't established the result, write Unknown. Don't turn missing evidence green because the tool is installed.
Decide What the Page Promises
The MSP model puts endpoint protection, MFA, awareness training, and email protection in the baseline for every plan. Use those as the first checks. Add recovery readiness as a separate check where backup and recovery work is in your agreed service scope.
That recovery row is a reporting recommendation, not an additional claim about what the model's baseline includes. Define what your agreement covers before making the page. List systems outside your responsibility so the client can see where another person or supplier needs to answer.
On a podcast, Centrex IT guest Josh describes using simpler client-facing language for his security maturity approach while retaining the underlying control mappings. He recommends showing present coverage, what the MSP package supplies, gaps needing separate projects, and progress over time. Borrow that separation without presenting his approach as a validated scoring system.
My view: this page should help a client make a specific decision. It shouldn't try to compress an entire security assessment into a badge.
Use the Same Fields for Every Check
Put the client name, reporting date, period reviewed, and responsible MSP contact at the top. Add a short scope statement naming the environments included and any material exclusions. Keep the record of evidence in the client's documentation, with references the technical team can follow.
Use plain statuses such as Verified for the stated scope, Gap found, Unknown, and Outside agreed scope. Define Verified as meeting your documented check for the listed systems at the recorded time. It says nothing about systems you didn't inspect or changes made afterward.
A scorecard is a dashboard, and the evidence is the instrument behind each dial. If the instrument hasn't been read, painting the dial green doesn't improve the measurement. Keep the labels tied to what the team actually established.
| Check | Record Behind the Status | Next Decision |
|---|---|---|
| Endpoint Protection | Managed device scope, configuration evidence, exceptions, and date checked | Assign uncovered or unverified devices for investigation |
| MFA | Accounts and applications checked, requirement evidence, and recorded exclusions | Approve the work needed to resolve remaining coverage gaps |
| Awareness Training | People in scope, agreed training activity, participation records, and exceptions | Assign missing activity or decide an appropriate arrangement |
| Email Protection | Mail environments in scope, agreed controls checked, evidence, and exclusions | Assign configuration or coverage work for unresolved items |
| Recovery Readiness | Agreed recovery scope, test objective, result, limitations, and unresolved work | Approve the next test or remediation needed for the stated objective |
Alongside each row, include the actual status and check date, the person responsible, and the next agreed action. The table is a proposed template. Your technical lead must define the checks and verify them against the current systems, rather than treating these row names as a test procedure.
Keep the Status Narrow Enough to Defend
Picture a client whose managed device list doesn't match the protection console. Record the mismatch and assign it for reconciliation. Until the team establishes which devices are in scope and what coverage they have, the report shouldn't describe the client as fully covered.
Apply the same discipline to MFA. Ask the technical lead for evidence that the intended requirement applies to the listed accounts and applications. Keep enrollment records and approved exclusions visible. Don't infer the rest of the client's applications from the system your team happens to manage.
For training, report the agreed activity and the records you have. Don't turn attendance into a claim about how staff will respond to an attack. For recovery, state what was tested and whether it met the agreed objective. Leave untested workloads and recovery paths visible.
Avoid an arithmetic score unless you have an agreed reason for its weights and a clear statement of what it measures. For this reporting job, I would use the row statuses and decisions directly. That avoids implying that success on another row cancels out the unresolved one.
Give Leadership and Technicians Different Views
In a vendor discussion about security testing reports, Lisa Bryant describes an executive summary for leadership, host findings and remediation guidance for engineers, and a detailed record of test activity. Her point is that different audiences need different views of the same work. You can apply that reporting choice here without claiming the page is a penetration test.
Keep the client page focused on the business decision: the gap, the agreed action, its owner, and any approval required. Keep the technical detail available behind it. The short version must preserve limitations that would change the client's decision.
For each open action, distinguish work already included in the service from a separately scoped project or a client responsibility. Baseline security belongs in every plan under the model. Don't present an unresolved included task as an optional security upgrade simply because it appears on a sales-friendly report.
Review Changes Without Rewriting History
I would use the client review to compare the current page with the previous dated version. Keep the check definitions and scope consistent where possible. When they change, explain the change before describing the result as progress or deterioration.
A gap disappearing because the device left service is a different result from a control being deployed. A status changing because you finally obtained evidence is a different result from improving the underlying environment. Record the reason, so the client can understand the change.
- The technical lead verifies each status, its scope, and the supporting evidence before the page is shared.
- The account manager checks that the client-facing wording preserves the limitations and identifies the person who can make each decision.
- The project or service owner accepts the resulting work and records its agreed timing and completion evidence.
- The account manager carries unresolved decisions into the next review and updates the client when the situation requires action sooner.
A review date isn't permission to leave a material gap untouched until that meeting. Route it through your existing service or incident process as appropriate. The report should reflect the work being done, rather than become a separate waiting room for it.
Start With a Page You Can Substantiate
Choose a client whose service scope and records the team can inspect. Fill the page from the evidence, and leave unknowns visible. Ask the account manager to explain the next decision without the technical lead translating every row.
If the explanation needs a reassuring overall grade to hold together, revise the wording. A useful page lets the client see what you checked and decide what happens next. The open action with an owner matters more than a color at the top.
mspoutpost.com/articles/use-a-cybersecurity-scorecard-template-that-shows-gaps
Written by Dana Kowalski
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.