Service evidence you can inspect before you sign
Anyone can say they monitor backups and patch devices. The proof is in the records: the log showing last night's job, the restore test showing the backup actually works, the scorecard showing MFA coverage moving the right way. These are sanitised examples of what our clients receive.
/ About these samples
What they are
Sanitised samples with fictional names and figures, in the same format clients receive
What they aren't
Live client data, or published performance guarantees
How often
Monthly reports, with incidents reported as they happen
/ Direct answer
What evidence should a managed IT provider be able to show you?
A managed IT provider should be able to show backup job logs with restore test results, patch and endpoint compliance reports, an identity or security scorecard, uptime and incident reports, and a record of every change made to your systems. If a provider can't produce sanitised versions of these before you sign, they probably don't produce them afterwards either.
- Backups proven by restore tests
- Risk tracked as a monthly trend
- Every change traceable to an approval
/ 01
What does a useful backup log look like?
A useful backup log shows every protected system, when its last job ran, whether it succeeded, and when a restore was last tested. The restore column matters most. A backup that has never been restored is a hope, not a control.
Warnings aren't hidden. In a real report, the FS01 warning would carry a ticket number and an owner, and the overdue restore test would already have a date.
Sanitised sample · fictional environment
| System | Last job | Result | Last restore test |
|---|---|---|---|
| Microsoft 365 mailboxes (148) | 02:10 | Success | Single mailbox, 12 days ago |
| SharePoint and OneDrive | 02:40 | Success | Folder restore, 12 days ago |
| FS01 file server | 23:00 | Warning: 3 locked files skipped | Full VM, 41 days ago |
| SQL01 finance database | 23:30 | Success | Overdue, booked for this week |
| Laptop fleet (62 devices) | Rolling | 58 current, 4 not seen for 7+ days | Spot check, 1 device |
/ 02
What is in an IT risk scorecard?
A risk scorecard turns security posture into a handful of numbers tracked month to month: MFA coverage, admin account count, device encryption and protection coverage, patch compliance, email authentication status and open high-risk findings. The trend matters more than any single month.
Sanitised sample · fictional environment
| Measure | 3 months ago | Last month | This month |
|---|---|---|---|
| MFA coverage | 81% | 94% | 99% |
| Global Administrators | 9 | 5 | 4 |
| Devices encrypted | 70% | 88% | 97% |
| Patched within agreed window | 63% | 85% | 93% |
| DMARC policy | none | quarantine | quarantine |
| Open high-risk findings | 14 | 6 | 3 |
/ 03
What does an uptime and incident report show?
Availability for each monitored service, every incident with its priority, cause, duration and fix, and anything that keeps recurring. It should read as a short account of the month, not a wall of green ticks.
For how availability percentages translate into real minutes of downtime, see the uptime reporting sample.
Sanitised sample · fictional environment, 30-day month
| Service | Availability | Incidents | Notes |
|---|---|---|---|
| Email and Teams (Microsoft 365) | 99.97% | 1 · Microsoft-side, 13 min | Tracked via service health; no action needed |
| Head office internet | 99.82% | 1 · P2, ISP fault, 78 min | Failover to 4G worked; ISP ticket raised |
| Line-of-business app server | 100% | 0 | Patched in the maintenance window |
| VPN and remote access | 99.95% | 1 · P3, certificate renewal, 22 min | Certificate expiry now monitored separately |
/ 04
How do you record changes made to client systems?
Every change has a ticket: what changed, why, who approved it, when it happened and how to undo it. Remote sessions are logged against the same ticket. At any point you can ask "who changed this, and why?" and get the answer from the record rather than from someone's memory.
Sanitised sample · fictional environment
| Date | Change | Approved by | Rollback |
|---|---|---|---|
| 03 Sep | Conditional Access: block legacy authentication (enforced) | Client operations manager | Return policy to report-only |
| 05 Sep | Patch ring 2 deadline moved by 48 hours | BPro service lead | Not needed (schedule change) |
| 09 Sep | FS01 backup: excluded temporary folder | Client IT contact | Remove the exclusion |
/ 05
Why publish samples instead of real client reports?
Because real reports contain client names, device names, user accounts and security weaknesses, and publishing any of that would be a breach of trust. The samples use the same structure, the same fields and realistic figures, with every identifying detail replaced.
Frequently Asked Questions
No. Every name, figure and date on this page is fictional, but the formats match what clients receive.
Monthly as standard, with a review call alongside. Incidents and urgent findings are reported as they happen, not saved up for the monthly report.
Within reason, yes. The core sections (backups, patching, security, incidents and changes) always stay, because leaving them out is how problems hide. Beyond that, the report is shaped around what your leadership actually reads.
The report explains it, with a cause and an action. A dip in patch compliance because a rollout was paused reads very differently from one caused by devices nobody can find, and the report should say which.
Yes. The same records (MFA coverage, backup tests, patch compliance, change logs) are what insurers and auditors ask for, so answering their questionnaires becomes a matter of exporting evidence rather than reconstructing it.
/ Next step
Want this reviewed against your own environment?
Share your users, tools and the problem you are trying to solve. We will tell you plainly whether this service fits, and what we would look at first.