- The artifacts and records your practices already produce — inventories, exports, test records, review logs
- The roles matrix (ATL-004), so every row's owner is a person already accountable for something
- An agreed storage location with access control, so 'Location' means one findable place
ATL-008REGISTEREDITORIAL REVIEW COMPLETE
Evidence Index
The master list of the organization's evidence artifacts — what each one is, which practice and requirement reference it relates to, where it lives, who owns it, how fresh it is, and when it gets regenerated — so that producing proof is a lookup, not an archaeology dig.
Using this artifact
Purpose, inputs, and completion
Purpose. Every practice that operates leaves a trail — exports, logs, test records, review minutes. The evidence index is the master list of that trail: one row per artifact, with its category, owner, location, freshness, and refresh cadence. Kept current, it turns 'show me' from a scramble into a lookup, and its own dates quietly reveal which practices are running and which have gone still.
When to use it. Build it from what already exists rather than from what a checklist wishes existed; the first pass is an inventory, not an aspiration. Give each artifact an owner from the roles matrix and a location a stranger could follow, then run the monthly freshness sweep against the cadence column. Read the category mix quarterly — it is the honest answer to whether you hold proof of operation or just pictures of settings.
- Inventory what exists first — walk each practice and list what it already produces before inventing new evidence to create.
- Give every artifact one row: an ID, a category, a location specific enough that a stranger could retrieve it, and a named owner.
- Record the date each artifact was last produced and the cadence at which it should be regenerated.
- Run the monthly freshness sweep: flag every row whose date has outlived its cadence and chase the owner, not the file.
Keeping it honest
Evidence, validation, and failure modes
- A single master index from which any evidence artifact can be located in minutes
- A freshness record showing evidence is regenerated on cadence, not manufactured before reviews
- A category breakdown revealing whether the organization holds operating evidence or only configuration snapshots
- Pick five rows at random and retrieve each artifact from its recorded location within ten minutes; every miss is either a wrong location or a missing artifact, and both are findings.
- Count rows by category: if Operations and Validation are nearly empty while Configuration is full, the index is documenting settings, not a running program.
What looks done but is not
- Locations like 'the shared drive' or 'with the MSP' — descriptions of a haystack, recorded as if they were coordinates.
- Evidence produced only when a review looms, so every date in the index clusters suspiciously two weeks before each assessment.
- The index tracks documents that describe intentions — policies, plans — and almost nothing that demonstrates operation.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
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: Retain the index itself indefinitely; each evidence artifact follows the retention recorded on its own row, and superseded evidence is archived, not deleted.
Full document
Preview — exactly what prints
REGISTER · GOVERNANCE & PROGRAM MANAGEMENTv1.0 · REVIEWED 2026-08-06
Evidence Index
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
Every practice that operates leaves a trail — exports, logs, test records, review minutes. The evidence index is the master list of that trail: one row per artifact, with its category, owner, location, freshness, and refresh cadence. Kept current, it turns 'show me' from a scramble into a lookup, and its own dates quietly reveal which practices are running and which have gone still.
How to use it
Build it from what already exists rather than from what a checklist wishes existed; the first pass is an inventory, not an aspiration. Give each artifact an owner from the roles matrix and a location a stranger could follow, then run the monthly freshness sweep against the cadence column. Read the category mix quarterly — it is the honest answer to whether you hold proof of operation or just pictures of settings.
How to use this index
The index stores pointers, never the evidence itself — artifacts stay in their controlled locations and this document says where. Categories: Governance (decisions and plans), Configuration (how systems are set), Operations (records of the work happening), Validation (tests and reviews of whether it worked). Every artifact gets exactly one row and one category.
An index of your evidence is a map of your posture
The completed index reveals what you protect and how. Store it inside the environment with access limited to those who maintain it, and keep the evidence artifacts themselves — not just this index — under access control appropriate to what they show.
Operating evidence versus configuration snapshots
A configuration snapshot — a policy export, a settings screenshot — shows how a system was set at one moment. Operating evidence — a month of review sign-offs, a restore-test record, a closed-ticket trail — shows the practice running over time. Reviewers weigh the second far more heavily, because settings can be staged the night before and months of operating records cannot.
Both belong in the index; the Category column is what keeps you honest about the mix. Aim for every practice to be represented by at least one Operations or Validation row, not only by Configuration rows.
The index
The working table. The CSV download carries the same columns for spreadsheet use.
Rows beginning EXAMPLE: show the expected shape — replace them with your own. Requirement references are mapped relationships, not equivalence claims.
| ID | Evidence artifact | Category | Related practice | Related requirement reference | Location | Owner | Freshness (date produced) | Refresh cadence | Notes |
|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE: EV-001 | Conditional-access policy export | Configuration | IT-01 | Rev. 2 3.5.3 (mapped) | Compliance library / Identity / exports | Identity admin | 2026-07-14 | Quarterly, and after any policy change | Regenerate — do not edit — after changes |
| EXAMPLE: EV-002 | Restore-test record, file server | Validation | IT-09 | Rev. 2 3.8.9 (mapped) | Compliance library / Backup / restore-tests | IT leader | 2026-06-30 | Quarterly | Operating proof the backup practice runs, not just that it is configured |
Freshness and refresh discipline
- Every row has a produced date and a cadence — no blanks in either column
- A row without a date is a rumor with an ID.
- Monthly sweep: flag every row whose date has outlived its cadence, and chase the owner
- Regenerate evidence on cadence, not before reviews
- Dates clustered just before assessments tell a reviewer the program runs for audits, not for itself.
- Archive superseded evidence; never overwrite it
- The history of an artifact is often better evidence than its latest version.
- New practices add their rows here as part of going live, not months later
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 | Compliance lead or IT leader |
| Approval authority | Executive sponsor |
| Review frequency | Monthly freshness sweep of dates against cadences; full index review quarterly |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain the index itself indefinitely; each evidence artifact follows the retention recorded on its own row, and superseded evidence is archived, not deleted. |
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.