- A vendor or community hardening benchmark for the platform, with its name and version noted
- A configuration export or settings review of a representative system on that platform
- The change-control process this baseline's future changes will run through
ATL-016WORKSHEETEDITORIAL REVIEW COMPLETE
Configuration Baseline Worksheet
A per-platform record of what 'correctly configured' means here: the vendor benchmark it derives from, which settings categories were reviewed, and a deviations table — setting, baseline value, actual value, justification, owner, expiry — that becomes the platform's exception register.
Using this artifact
Purpose, inputs, and completion
Purpose. Without a written baseline, every system's configuration is whatever the last person left it as, and drift is invisible because there is nothing to drift from. This worksheet defines, per platform, what correct looks like — anchored to a named vendor benchmark — and keeps the honest list of where reality deviates and why. The deviations table is the working end: it is the platform's exception register, with owners and expiry dates that make each exception temporary on paper until someone decides otherwise.
When to use it. Complete one worksheet per platform, starting with the platforms that touch sensitive contract information. Record the benchmark and version first, review each settings category against a real system's exported configuration, and log every departure in the deviations table. Re-review annually and at major version changes; between reviews, the deviations table is updated through change control — a new deviation is a change, and it arrives with a justification, an owner, and an expiry or it does not arrive at all.
- Complete one worksheet per platform — a Windows-endpoint baseline, a server baseline, a firewall baseline — rather than one heroic document covering everything vaguely.
- Anchor the baseline in a named, versioned benchmark and record where you departed from it; 'we mostly follow the vendor guide' is not a baseline, it is a mood.
- Review each settings category against a real system's export, not the build documentation — the baseline describes what is, verified, not what the image was supposed to produce.
- Log every deviation in the deviations table with a justification, an owner, and an expiry; an undated deviation is a permanent one, whatever anyone intended.
- Route any baseline change on production-adjacent equipment through change control with a rollback plan and the process owner's agreement — hardening a live line without a window is how hardening gets banned from the plant.
Keeping it honest
Evidence, validation, and failure modes
- A named, versioned baseline per platform tied to a published benchmark
- A dated review record showing which settings categories were verified against a real system
- A deviations table with justifications, owners, and expiries — the platform's living exception register
- Pull the actual configuration of one in-scope system and diff it against this worksheet; any difference must appear in the deviations table or the baseline is fiction.
- Check three deviation expiry dates: any past-expiry row still deviating means the exception process records exceptions but never closes them.
What looks done but is not
- The baseline is the benchmark PDF itself, unread and untailored — nobody can say which of its hundreds of settings actually apply here.
- Deviations live in admins' heads; the worksheet shows a clean baseline while half the fleet quietly runs exceptions.
- An OT-adjacent workstation is hardened to the IT baseline without the process owner, and the engineering software that runs the line stops launching mid-shift.
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 superseded baselines alongside the current one; when an incident asks 'was this setting always like that?', the dated baseline history is the answer.
Full document
Preview — exactly what prints
WORKSHEET · CONFIGURATION & CHANGEv1.0 · REVIEWED 2026-08-06
Configuration Baseline Worksheet
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
Without a written baseline, every system's configuration is whatever the last person left it as, and drift is invisible because there is nothing to drift from. This worksheet defines, per platform, what correct looks like — anchored to a named vendor benchmark — and keeps the honest list of where reality deviates and why. The deviations table is the working end: it is the platform's exception register, with owners and expiry dates that make each exception temporary on paper until someone decides otherwise.
How to use it
Complete one worksheet per platform, starting with the platforms that touch sensitive contract information. Record the benchmark and version first, review each settings category against a real system's exported configuration, and log every departure in the deviations table. Re-review annually and at major version changes; between reviews, the deviations table is updated through change control — a new deviation is a change, and it arrives with a justification, an owner, and an expiry or it does not arrive at all.
Platform baseline record
Name the platform, the benchmark it derives from, and the scope of systems this baseline claims — one record per platform worksheet.
Baseline identity
| Platform (e.g., Windows 11 endpoints, firewall, file server) | Baseline source (vendor / community benchmark, name and version) | Baseline version and date adopted | Owner | Systems in scope (count and how identified) |
|---|---|---|---|---|
Tailoring is expected — silence is not
No published benchmark fits a small business unmodified. Departing from the benchmark is normal engineering; the requirement this worksheet serves is that every departure is written down in the deviations table below, with a reason and an owner, instead of living as tribal knowledge.
Settings categories reviewed
Track review coverage by category so 'we reviewed the baseline' has a checkable meaning. Categories follow the benchmark's own structure.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Settings category | Reviewed against baseline? | Date | Notes |
|---|---|---|---|
| EXAMPLE: Accounts and authentication policies | Yes — verified on exported config of LT-0042 | 2026-07-10 | Two deviations logged below |
Deviations from baseline
The honest table. Every setting where reality departs from the baseline, with a justification that would survive being read aloud, an owner, and an expiry.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Setting | Baseline value | Actual value | Justification | Owner | Expiry / re-review date |
|---|---|---|---|---|---|
| EXAMPLE: SMBv1 protocol | Disabled | Enabled on legacy CMM workstation only | Metrology software requires it; replacement budgeted FY27; workstation isolated on its own VLAN | IT leader | 2027-01-31 |
Baseline changes on production equipment go through change control
On OT and production-adjacent systems, applying or correcting a baseline setting is a change like any other: process-owner agreement, an approved maintenance window, a tested rollback, and a safety review before anything is touched. Where a baseline setting cannot be applied safely, the row lands in this deviations table with a compensating measure — the safe operation wins, and the paper trail says so.
From deviations to the exception register
The deviations table is not an appendix — it is the platform's exception register, and it has a lifecycle.
Exception lifecycle rules
- A deviation enters this table only through change control, carrying its justification, owner, and expiry from the change record.
- At each expiry date the owner re-decides: close it (bring the system to baseline), renew it with a new expiry and reason, or escalate it into the retirement plan.
- The count of open deviations per platform is reported at the baseline's annual review; a register that only ever grows is a hardening program in reverse.
- When the same deviation appears on a second platform, treat it as a candidate baseline change instead — a repeated exception is the baseline asking to be corrected.
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 | System administrator |
| Approval authority | IT leader |
| Review frequency | Annually per platform, and at every major OS or platform version change |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain superseded baselines alongside the current one; when an incident asks 'was this setting always like that?', the dated baseline history is the answer. |
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.