DoD STIG Compliance and NIST 800-53 Hardening Consultant
Compliance hardening to the standard the DoD audits against — DISA STIGs, SCAP scans, remediation, and the documentation that gets you through the audit.
The usual trigger is a contract clause. A prime, a customer, or a regulator has told you that the systems touching their data have to be hardened to DISA STIGs and mapped to NIST 800-53, and now an audit or an assessment is on the calendar. Somebody ran a SCAP scan, the report came back with a wall of red, and the open CAT I findings are sitting there with no remediation and no plan to explain them. That is a hard place to be, because the deadline does not move and the findings do not fix themselves.
That is the work I do. I take Windows servers, RHEL hosts, and network systems and harden them to the same standard the DoD audits against — applying the relevant STIGs, running the SCAP scans, remediating the findings that can be remediated, and documenting the ones that cannot. I do it remote-first from Fort Worth and across the DFW metro, on a defined window with a clear deliverable at the end, so you are buying a finished package and not an open-ended retainer.
What done looks like
Done is a package you can hand an auditor without flinching. The SCAP scans come back clean — or as clean as your environment allows — with the CAT I findings closed and the CAT II and III findings either remediated or accounted for. Every finding that stays open has a documented exception with a reason, a compensating control, and an owner, written into a POA&M (plan of action and milestones) so the assessor sees a managed risk instead of a gap nobody noticed.
On top of that you get the NIST 800-53 control mappings that tie each hardening step back to the control it satisfies, the before-and-after scan evidence, and a plain-language summary of what was changed and why. The point is that when the assessor asks "show me," you can — not from memory, but from the record.
How I work it, and why me
Hardening breaks applications when someone applies a benchmark blindly and walks away. I do not work that way. Every change starts as a written runbook before anything touches a production system. I validate each setting against the STIG gates, and I test that the hardening did not break the application the system exists to run — because a locked-down box that no longer serves the business is not a win. I own the rollback: before I change a thing, I know how to put it back and I have confirmed I can.
I have about four years of production experience doing this on real systems with real users, not lab images. I hold CompTIA Security plus (ce), the RHCSA for the Linux side, and the DOW ESS Administrator 201 and 301 certifications for endpoint hardening, including Trellix endpoint security. The scripts and documentation stay in your repo when the engagement ends, so your next pass — by me or anyone else — starts from a known baseline instead of a blank page.
- Scanning: baseline and confirmation SCAP scans across Windows, RHEL, and network systems.
- Remediation: STIG finding remediation, scripted where it is safe to script and tested before it ships.
- Endpoint hardening: Trellix and ESS-managed endpoint configuration and validation.
- Documentation: POA and M, documented exceptions, and NIST 800-53 control mappings for the audit package.
If you want the longer walk-through of how this work runs end to end, I wrote it up in my STIG hardening guide.
If an audit is coming and the scan looks worse than you hoped, tell me what platforms you are running and when the deadline is. I will tell you what a realistic package looks like and how long it takes to get there.
Common questions
How long does a STIG hardening pass take?
For a single system type it is usually a week or two from first scan to an audit-ready package — a baseline SCAP scan, a remediation pass, a re-scan to confirm, and the write-up of any exceptions. A mixed fleet of Windows, RHEL, and network gear runs longer, and I scope it per platform so you can see exactly where the open findings are. I always re-scan after remediation, because a fix that is not validated against the benchmark is just a hope.
Do I need expensive tools to do this?
No. The core of the work runs on free, government-supplied tooling — the DISA STIG content, the SCAP Security Guide, and a SCAP scanner. I can work with whatever you already license, but I do not need you to buy anything to get a clean scan and a defensible package. The cost is the hardening work itself, not a stack of software.
Do you work fully remote?
Yes. STIG hardening, SCAP scanning, remediation, and the documentation are all things I do remote-first over a jump host or management connection, and most engagements never need me in the room. When a client in Fort Worth or the wider DFW metro wants someone on-site for the audit or a hands-on cutover, I can be there.
Have a project like this?
Tell me the environment, the timeline, and your constraints. I reply the same business day with a fit assessment and either a quote or a referral.