15 Practices, 142 Artifacts: The Anatomy of an L1 Self-Assessment With a Map

📘 By Rob Maupin, founder of Overwatch Tools and author of CMMC Level 1: A Practical Guide for Small to Medium GovCon Contractors

It's a Tuesday afternoon. You have fourteen browser tabs open. One is a spreadsheet you downloaded from somewhere reputable, listing all fifteen CMMC Level 1 practices, one per row, with a column headed Status. Row one says: Limit information system access to authorized users, processes acting on behalf of authorized users, or devices.

You read it three times. You probably do that, you think. You have passwords. Not everyone can see everything. But the cursor is blinking in the Status column and you have no idea what to type, because you have no idea what "done" physically looks like. A written policy? A screenshot? A list of employees? All three? Signed by whom? Kept where?

So you close the tab. Not because you disagree that this needs doing — we settled that in Part 1 — but because "implement the fifteen practices" is not an instruction any human being can act on.

This article is about the thing that fixes that. Not motivation. Not a deadline. A map.

The Instruction That Isn't One

CMMC Level 1 is fifteen practices, drawn from FAR clause 52.204-21 and mapped to NIST SP 800-171. That's the entire requirement — small enough that a 5-person shop can finish it.

But a practice is a requirement statement, not a work item. Requirement statements are written to be legally complete across every possible organization, from a two-person machine shop to a shipyard, and that generality is exactly what makes them useless as a to-do list. "Limit information system access to authorized users" is true, correct, binding — and completely silent on what you should be doing between 2:00 and 3:30 this afternoon.

The gap between a requirement and a task is where small contractors lose months. Not because the work is hard, but because they're doing the requirement-to-task translation themselves, alone, with no way to tell whether they got it right.

What an Artifact Actually Is

Compliance vocabulary makes simple things sound institutional, so here's the plainest possible version.

An artifact is a thing you can point to. If someone sat down across from you and said "show me," an artifact is what you'd slide across the table. It comes in four flavors:

• A signed page. A policy or a written decision, dated, with a name on it.
• A written procedure. The steps somebody actually follows — who does what, when, and what they record.
• A setting. A configuration in your Microsoft 365 or Google Workspace admin console, on a laptop, on a firewall — captured as a dated screenshot or export.
• A record. A log, a roster, an inventory, an approval ticket, a receipt. Proof the procedure ran, not just that it exists.

None of those are abstract — you can hold all four. The official CMMC Assessment Guide — Level 1 is built on the same premise: under every practice it lists the assessment objectives ("determine if…") and then the methods and objects an assessor would examine — policies, procedures, configuration settings and associated documentation, lists, records, logs. The guide is already telling you what the artifacts are. It just isn't organized as a checklist for your business.

Turning it into one is the job.

The Three Layers: Policy → Procedure → Evidence

Every artifact at Level 1 lands in one of three layers, and the layer tells you what that artifact has to accomplish.

Most stalled self-assessments have a bloated first layer, a missing second layer, and nothing at all in the third. That's the signature of DIY without structure: people write policy because policy is the part that feels like compliance, then run out of energy before the part an assessor would actually credit. A policy proves you intended to. Evidence proves you did.

Three Practices, Fully Unpacked

Enough theory. Below are three of the fifteen, taken straight from the official Assessment Guide and decomposed the way a map decomposes them. Read them as the pattern rather than an exhaustive list — but they're concrete enough that you could genuinely start on any of the three this week.

Why Counting Artifacts Gives You a Finish Line

Run that decomposition across all fifteen practices and you land at roughly 142 artifacts. Some practices carry a dozen; a couple carry four or five.

The number isn't the point — the granularity is. Here's what it buys:

• A real percentage complete. "4 of 15 practices" is nearly meaningless, because practices don't finish evenly. "61 of 142" is a number you can put in front of a prime — or a spouse who wants to know when the evenings end.
• Parallel work. 142 items can be split across three people. Fifteen ambiguous requirements can't be split across anyone.
• An actual definition of done. An artifact is binary. The policy is signed or it isn't. The export is dated or it isn't. There is no "mostly."
• A stopping point. Without a map, contractors don't just under-build — they over-build, writing enterprise documentation for a fifteen-practice requirement because nobody told them where the edge was.

Ambiguity Is the Labor Multiplier

When the Department of War suspended CMMC Phase II on July 13, 2026, the Small Business Administration's supporting statement put numbers on what compliance had been costing small firms. They're worth reading carefully, because they're almost always quoted wrong.

Sit with the second figure. $388,600 with no third-party assessor involved at all. No audit in that number. No C3PAO. Nobody sent a bill for an assessment.

So where does it come from? Labor and rework. Months of evenings. Documentation written, discarded, rewritten. Scoping decided wrong at the start and discovered late. Consultants brought in to translate. Enterprise templates bought and then adapted line by line to a company one-fortieth the size.

The Rework Tax: Writing It Three Times

Most contractors who do this without a map write the same material three times.

1. Once wrong. The first draft is a policy downloaded from a search result. It's written for an organization with a security team and a change advisory board — half of it describes controls you don't have, the other half is silent on the two systems you actually use.
2. Once incomplete. The rewrite is right-sized but stops at intent. Policies, no procedures, no evidence. It reads well and proves nothing. This is the version most people submit against.
3. Once finally right. The third pass adds the layer that was always the actual requirement — records, exports, rosters, logs — and forces a partial rewrite of the first two, because now the procedure has to describe what the evidence shows.

That isn't a discipline failure, it's a sequencing failure. When you know the artifact list up front, you write the policy knowing which procedure it supports and which record proves it. One pass.

Generic Templates Are Where Rework Comes From

One more source of the tax, and the one people underestimate most: an artifact list for Microsoft 365 and an artifact list for Google Workspace are not the same document. The requirement is identical; the evidence isn't. The policy layer barely changes between platforms, but the procedure and evidence layers change substantially — different consoles, different names for things, different exports, different places the setting lives.

A generic template hands you a blank labeled "capture your MFA report." A platform-specific one names the console, the path, and what the finished capture should show. The first costs an hour of searching and a decent chance of grabbing the wrong screen — multiply by the number of evidence artifacts and you've found a meaningful slice of that $388,600.

You Can Absolutely Build This Map Yourself

Let's be straight about what's proprietary here, because it isn't the information. Everything above is derivable from public documents: the Assessment Guide lists the objectives and assessment objects under every practice, NIST SP 800-171 gives the underlying discussion, FAR 52.204-21 is the source clause, NIST SP 800-88 covers media sanitization. All free, all authoritative, all sitting on federal websites right now.

What you'd be buying isn't access. It's the weeks.

Building your own artifact map means reading several hundred pages, deciding for each objective what a defensible artifact looks like for a company your size, resolving every place the guidance says "as appropriate," and translating each evidence item into the specific screen in your specific admin console. Entirely doable. It takes weeks of evenings, and the first version won't be right — the rework tax, arriving on schedule.

Some contractors should do exactly that: the ones who want to own the methodology and have the time. That's who the book is for. Others want the artifact list to already exist on Monday morning. That's what the package is.

What's Next: Roughly Half of This Is Settings

Something becomes obvious once the artifact list is laid out: a large share of the technical evidence isn't paperwork at all. It's configuration — laptop, phone, router and firewall, admin console — captured as proof.

That's good news, because settings are fast. A configuration change takes minutes where a policy takes an afternoon. But it comes with a rule that catches people out: a setting you can't prove is a setting nobody can credit you for. Configure it, capture it immediately, file it, move on. Part 3 covers exactly that — the device and network configuration guides, per device type, and how to capture proof as you go instead of reconstructing it three weeks later from memory.

In the meantime, the window is still quiet. Nothing is due, no assessor is scheduled, and the Task Force isn't expected to report until roughly mid-September. Whatever it decides, a completed self-assessment built on NIST SP 800-171 serves you in every outcome — and the underlying obligations never went anywhere. This is the cheapest, calmest stretch you'll get to do required work. Most of your competitors are using it to wait.