What is a STIG checklist?Guide

STIG checklists in one paragraph

A Security Technical Implementation Guide (STIG) is DISA's configuration standard for one technology — an operating system, a database, a browser, a network device. A STIG checklist is your working copy of that STIG for one specific system: every requirement from the STIG, each marked with a status (Open, Not a Finding, Not Applicable, or Not Reviewed), plus the comments and finding details that justify it. The finished checklist is the evidence an assessor reviews when your system goes for an Authority to Operate (ATO).

You can browse every current checklist in the A–Z index of STIG checklists, or search their content across the whole library with Search.

What is inside a STIG checklist

Each requirement in a checklist — often called a finding or a vulnerability — carries the same fields:

• Vulnerability ID (V-number), such as V-257777 — the stable identifier for the requirement across releases.
• Rule ID (SV-number), such as SV-257777r1155676 — the V-number plus a revision that changes whenever DISA edits the rule.
• STIG ID, such as RHEL-09-211010 — the vendor-style identifier DISA assigns within the STIG.
• Severity — CAT I (high), CAT II (medium), or CAT III (low). CAT I findings are the ones that most often block an ATO.
• Check text — how to verify the setting, usually with the exact command to run and what a finding looks like.
• Fix text — how to remediate it.
• CCI references — Control Correlation Identifiers that tie the requirement back to NIST SP 800-53 controls. See the CCI reference.

The four statuses

• Open — the system does not meet the requirement. It needs a fix or a POA&M entry.
• Not a Finding — the system meets the requirement.
• Not Applicable — the requirement doesn't apply to this system (for example, a service that isn't installed). Say why in the comments.
• Not Reviewed — nobody has assessed it yet. A checklist handed to an assessor should have none of these.

How to create a STIG checklist

1. Find the STIG for your technology and its current release — for example the Red Hat Enterprise Linux 9 STIG. Use the A–Z index or Search.
2. Download it as a checklist (.ckl) and open it in DISA STIG Viewer — or start one from the STIG in STIG Viewer itself.
3. Fill in the asset details: host name, IP address, role, and technology area.
4. Run the automated part first. Most operating systems and many applications have a SCAP benchmark that SCAP Compliance Checker (SCC) can evaluate and export as checklist results.
5. Review the remaining requirements by hand, following each check text, and record the status and your evidence.
6. Save the checklist (.ckl or .cklb), then import it into your ATO tooling, such as eMASS, with Open findings tracked in your POA&M.

Keeping checklists current

DISA revises STIGs on a quarterly release cycle, and each release can add, remove, or change requirements. When a new release lands, compare it with the one your checklist was built on before you re-assess — STIG Compare shows exactly which requirements were added, removed, or changed, and in which fields. The dashboard tracks recent release cycles across the whole library.