DISA STIG Compliance
Security Technical Implementation Guide automation
Security Technical Implementation Guides provide detailed hardening guidance for DoD systems. Thalorin automates STIG compliance through continuous scanning, automated remediation guidance, and deviation tracking that maintains security posture while documenting operational necessities.
DISA republishes its SRG and STIG library on a quarterly cycle, and each release is a new baseline rather than an amendment to the one your systems were assessed against. Rules are added, retired, renumbered and re-scored between releases, so a checklist completed at one version does not carry forward intact to the next. Individual STIGs also publish out of cycle and are effective immediately on release. A rule promoted to CAT I in an update is open on every system running that technology from the day it lands, with nothing on those systems having changed.
Coverage is the structural problem. A STIG exists for a specific product at a specific version, and most of what a modern estate runs has none. DISA's Security Requirements Guides sit above the STIGs as the technology-family requirements the product guides are written from, and they are the intended fallback where no product guide exists. Choosing between an SRG, a vendor baseline and a commercial equivalency is a judgement, made once, that an assessor will revisit years later — and the reasoning behind it is almost never written down at the time it is made.
A scanner cannot answer all of a STIG, and the part it cannot answer is what gets missed. The SCAP benchmark DISA ships alongside a STIG covers the machine-checkable subset; the remainder are manual checks needing a person to read a configuration, interview an administrator or confirm a documented procedure. A benchmark scan reported as a finished assessment leaves those rules unreviewed, and an unreviewed rule summarises as clean rather than as absent. Findings accumulate in that gap and surface when somebody works the checklist rule by rule.
Hardening state is held per rule, not per checklist. Thalorin carries each finding with the Vulnerability ID, the STIG version and release that produced it, its severity category and the justification if it was accepted, so a quarterly re-release resolves to exactly the answers it invalidates and leaves the rest standing. Deviations carry the Authorizing Official's acceptance and the date it falls due for review, because a risk accepted against a rule that has since been rewritten is no longer an accepted risk.
The path to authorization is complex
Answers expire with the release
A finding is only meaningful against the Vulnerability ID, version and release that produced it. Carry an old answer forward without checking whether the rule survived, changed severity or was renumbered, and the checklist is confidently describing a rule that no longer exists.
The benchmark is not the STIG
DISA's SCAP content automates only the machine-checkable rules. The manual checks left behind are where findings gather, because a rule nobody reviewed reports as the absence of a finding rather than as work not done.
CORA scores threat, not checklists
JFHQ-DODIN's Cyber Operational Readiness Assessment, launched 1 March 2024, measures against risk-based metrics derived from MITRE ATT&CK techniques and is weighted towards the network boundary. An estate of green checklists can still assess badly.
No STIG for the product in front of you
Published coverage lags the technology estate by design. Falling back to the applicable Security Requirements Guide or to a commercial baseline is a decision that has to be recorded and defended, not a gap left unstated.
How Thalorin helps
Automated STIG scanning and assessment
Benchmark results in XCCDF and checklist exports are ingested against the host they were actually run on, with automated results held separately from the rules the scanner never evaluated.
Remediation guidance and automation
Every finding keeps the STIG's own check text and fix text alongside its CAT severity, so remediation is worked against the published rule instead of a paraphrase that drifts from the source.
Deviation documentation and tracking
A documented deviation binds the operational necessity, the compensating control and the Authorizing Official's acceptance to the Vulnerability ID and the release it was granted against, with a review date attached.
STIG version transition management
Each quarterly release is diffed against the assessed one: which rules are new, which were retired, which changed severity, and which prior answers still stand without being re-tested.
Benchmark coverage reporting
Coverage is reported as a property of the assessment rather than of the system — how much of each STIG the automated content reaches, and precisely which rules remain unanswered.
Compliance trend analysis
Open findings are tracked by severity across releases, separating newly discovered findings from newly published rules, so a quarterly update does not read as a regression nobody caused.
DISA STIG Compliance: common questions
Does an SCC scan count as a completed STIG assessment?
No. The SCAP benchmark DISA publishes with a STIG evaluates only the rules a tool can check. The rest require manual review — reading a configuration, interviewing an administrator, confirming a documented procedure — and a scan leaves them unanswered rather than passed. A checklist showing no open findings while a large share of its rules were never reviewed is a partial assessment presented as a complete one, and that is exactly what an assessor tests first.
What happens to my STIG checklist when DISA publishes a new release?
It stops being current. Quarterly releases add rules, retire rules, revise check and fix text and sometimes change severity, and Vulnerability IDs do not map one-to-one across versions. The efficient response is a difference: identify what changed, re-test only that, and carry forward answers to rules that did not move. Re-running an entire checklist every quarter is what makes STIG compliance feel unsustainable, and it is avoidable if findings are held per rule and release.
What applies when there is no STIG for a product?
The applicable Security Requirements Guide. SRGs carry the technology-family requirements that product STIGs are written from, and they are the intended fallback when no product-specific guide has been published. In cloud environments the DoD Cloud Computing SRG names industry baselines such as the CIS Benchmarks as an acceptable alternative to STIGs and SRGs at Impact Level 2, with the STIGs and SRGs themselves preferred and expected above it. Whichever route is taken, the reasoning belongs in the authorization package, not in an engineer's memory.
Did CORA replace CCRI, and what changed for STIG compliance?
It renamed and reworked it. JFHQ-DODIN launched the Cyber Operational Readiness Assessment on 1 March 2024 after a nine-month pilot, closing four years of transforming the Command Cyber Readiness Inspection programme from an inspection-compliance mindset to an operational-readiness one. Scoring now runs on risk-based metrics built from MITRE ATT&CK tactics and key indicators of risk, weighted towards internet-facing boundary devices. STIG findings still carry the evidence, but a uniformly clean checklist across low-risk terrain no longer buys what it used to.
Can a STIG finding be waived?
Not waived, accepted. There is no exemption that makes a rule inapplicable; there is a documented deviation in which the operational necessity, the compensating controls and the residual risk are written down and an Authorizing Official accepts them. That acceptance is specific to the rule, the system and the release it was granted against, and it does not survive a rewrite of the rule. A deviation nobody revisits quietly becomes an undocumented one.
Regulatory state described as of August 2026. Requirements change; verify against the current rule before relying on any date above.
Talk to us about DISA STIG Compliance.
See how one evidence artifact satisfies DISA STIG Compliance requirements alongside every other framework you carry.