- The responsibility matrix for the engagement — the package evidences the provider-side column
- The client's declared cadences and response times, so package items match what the client committed to
- The provider's reporting capabilities per platform, honestly assessed — an item nobody can produce monthly does not belong at monthly
ATL-032REGISTEREDITORIAL REVIEW COMPLETE
ESP Client-Evidence Package Checklist
The standing evidence package a service provider delivers to each client on a schedule — and, read from the other seat, the exact list a contractor should ask its MSP for. Twelve starter items with cadence, format, and an acknowledgment loop, plus the multi-tenant hygiene rules that keep one client's data out of another's package.
Using this artifact
Purpose, inputs, and completion
Purpose. Provider-run controls fail assessments for one reason more than any other: nobody can produce the record. This register is the fix, agreed once between provider and client — the standing package of evidence the ESP delivers on a schedule, in fileable form, with an acknowledgment loop. For the provider it turns 'monitoring the provider' from an audit into a subscription; for the contractor it is the exact list to hand an MSP and the standard to hold delivery to.
When to use it. Complete the register together at engagement start or next renewal, seeding from the twelve starter items and striking what the service does not cover — an honest 'not included' beats a silent gap. The provider produces and delivers per the cadence column; the client files each delivery and acknowledges it; both sides reconcile quarterly. Read from the contractor seat, the same register is the ask-list: hand it to your provider and the conversation about what you will actually receive becomes specific.
- Agree the package once, in the register: item, what it demonstrates, cadence, format, and who produces it. Ambiguity here becomes a dispute at assessment time.
- Deliver as files the client can retain — exports and reports, never portal-access-only. Evidence the client cannot file is evidence the client does not have.
- Close the loop: the client acknowledges receipt each cycle, and the acknowledgment column is part of the record on both sides.
- Strip multi-tenant bleed before anything leaves the provider: no other client's names, hostnames, findings, or metrics — ever.
- Reconcile quarterly: items delivered against items agreed, with gaps named and dated rather than quietly skipped.
Keeping it honest
Evidence, validation, and failure modes
- A per-client register of agreed evidence items with cadences and formats
- Dated delivery and acknowledgment records for each cycle
- A quarterly reconciliation of delivered-versus-agreed, with gaps dispositioned
- Pick the last full cycle and reconcile: every register item at or past its cadence has a delivery date and a client acknowledgment — a blank in either column is the finding.
- Open one delivered report at random and check it names only this client's environment; any other tenant's identifier appearing is a stop-everything defect, not a formatting nit.
What looks done but is not
- Dashboard-access-standing-in-for-delivery: the client 'could log in and see it,' so nothing was ever filed, and at assessment time the evidence trail is a login page.
- The package exists but never changes: services evolved, the register did not, and half the items evidence a service shape from two years ago.
- One-way delivery: reports go out, nobody at the client files or acknowledges them, and both sides discover at assessment time that the archive lives nowhere.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
OT-09 — OT supply chain securityIT-06 — Risk-based vulnerability managementIT-09 — Backup and disaster recovery
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: The client retains delivered packages per its evidence-retention schedule; the provider retains delivery records and acknowledgments per client for the engagement plus its record-retention period.
Full document
Preview — exactly what prints
REGISTER · EVIDENCE & ASSESSMENT READINESSv1.0 · REVIEWED 2026-08-07
ESP Client-Evidence Package Checklist
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Provider-run controls fail assessments for one reason more than any other: nobody can produce the record. This register is the fix, agreed once between provider and client — the standing package of evidence the ESP delivers on a schedule, in fileable form, with an acknowledgment loop. For the provider it turns 'monitoring the provider' from an audit into a subscription; for the contractor it is the exact list to hand an MSP and the standard to hold delivery to.
How to use it
Complete the register together at engagement start or next renewal, seeding from the twelve starter items and striking what the service does not cover — an honest 'not included' beats a silent gap. The provider produces and delivers per the cadence column; the client files each delivery and acknowledges it; both sides reconcile quarterly. Read from the contractor seat, the same register is the ask-list: hand it to your provider and the conversation about what you will actually receive becomes specific.
How both seats use this register
| Seat | What this register is to you | Your obligations against it |
|---|---|---|
| ESP (provider) | The delivery contract for your evidence stream — one agreed list per client instead of ad-hoc requests. | Produce per cadence, deliver as retainable files, keep delivery records, strip multi-tenant data, flag composition changes. |
| OSC (contractor) | The ask-list and the oversight record: what arrives, when, and whether you filed it. | File every delivery, acknowledge receipt, reconcile quarterly, and escalate gaps — an unfiled report is evidence you do not have. |
This register evidences the matrix — it does not replace it
Who does what lives in the responsibility matrix for the engagement; this register covers only the provider-side evidence stream. Complete the matrix first, then build the package from its provider column. A package item with no matrix row behind it is evidence of nothing in particular.
The standing package — twelve starter items
Starter composition for a typical managed-services engagement. Strike what the service does not cover, add what it does, and put a real cadence on every kept row.
Rows beginning EXAMPLE: show a completed delivery record — replace with your own once the package is running.
| Evidence item | What it demonstrates | Cadence | Format | Last delivered | Client ack |
|---|---|---|---|---|---|
| Patch completion report, by ring and platform, with deferrals and their compensations | Flaw remediation operating against declared response times | Monthly | PDF or export | ||
| Backup success summary plus the latest restore-test result with date, scope, and elapsed time | Recovery proven, not assumed | Monthly; restore tests per agreed cycle | Report + test record | ||
| Monitoring and log-review summary: items reviewed, investigated, and dispositioned | Review cadence actually happening, not just collection | Monthly | Report | ||
| Alert and incident summary, including any notifications made and the notification-path test result | Detection-to-notification working end to end | Monthly; path test per agreed cycle | Report | ||
| MFA and identity coverage: enrolled-and-enforced over active accounts, by privilege tier | Identity coverage as a number, not an assertion | Monthly | Export | ||
| Access recertification export for provider-managed accounts, including the provider's own technician accounts | Access reviewed, reductions actioned | Quarterly | Export + decisions | ||
| Vulnerability register extract with SLA aging for provider-remediated findings | Remediation tracked against commitments | Monthly | Export | ||
| Change log of client-affecting platform and baseline changes, with any parameter impacts flagged | Change control visible to the client whose declared values it touches | Monthly | Export | ||
| Provider technician roster changes and current rules-of-behavior acknowledgments | Who can touch the environment, signed | Quarterly and on change | Roster + acknowledgments | ||
| Subcontractor and tooling-stack change disclosures | The client's supply chain kept current | On change; confirmed annually | Notice | ||
| Responsibility-matrix review record for the engagement | The split still matches the service | Annual | Signed review | ||
| Offboarding commitment: data return, deletion attestation, access removal procedure | The exit is planned while relations are good | At start; reconfirmed annually | Documented procedure | ||
| EXAMPLE: Patch completion report (July) | Flaw remediation operating | Monthly | 2026-08-05 | Filed + acked 2026-08-06, J. Doe |
Delivery mechanics and multi-tenant hygiene
- Deliver as retainable files to an agreed location the client controls — never portal-access-only, and never attachments to whoever happened to open the ticket.
- Bundle to the cadence: one monthly package beats twelve loose emails, and the bundle's cover sheet lists what is inside against the register.
- Acknowledgment closes each cycle: the client confirms receipt and filing; the provider records it. Both sides now hold the same trail.
- Gaps are stated, not skipped: a cycle where an item cannot be produced ships with a one-line reason and a make-up date.
Multi-tenant hygiene is non-negotiable
Every report leaving the provider is screened so it names only the receiving client's environment: no other customer's names, hostnames, ticket numbers, findings, or aggregate metrics from which another tenant is identifiable. One cross-tenant leak in an evidence package is a security incident and a relationship-ending defect — build the screening into report generation, not into someone's memory. And the package itself contains operational security detail: both sides store and transmit it with the same care as the systems it describes.
Reading the package from the contractor seat
What good looks like when the deliveries arrive — and the three signals that the stream is decorative.
- Numbers move month to month: identical coverage figures across cycles usually means a template, not a measurement.
- Bad news appears: a package that never contains a deferral, a missed SLA, or an investigated alert is describing a fictional environment.
- Items trace to the matrix: you can point from each delivered item to the responsibility-matrix row it evidences.
- You could survive an assessor tomorrow: the filed packages, not the provider's goodwill, answer 'show me the provider-run control operating'.
Quarterly reconciliation
| Quarter | Items agreed | Items delivered on cadence | Gaps and disposition | Reviewed by (both parties) |
|---|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | ESP service delivery lead — or, on the contractor side, whoever owns the provider relationship |
| Approval authority | ESP: service line owner. OSC: executive sponsor. |
| Review frequency | Package composition reviewed annually and at every service change; delivery runs on the per-item cadence in the register |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | The client retains delivered packages per its evidence-retention schedule; the provider retains delivery records and acknowledgments per client for the engagement plus its record-retention period. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.