Why Most DoD Cyber Inspections Fail Before They Start

In 18+ years of Department of Defense (DoD) cybersecurity work — including multiple inspection cycles as an Information System Security Manager (ISSM) — I have watched commands fail assessments that they should have passed. Not because their technical controls were weak. Not because their people were incompetent. But because of process failures that had nothing to do with technology.

The pattern is almost always the same. The command spends months hardening systems and patching vulnerabilities. They run Assured Compliance Assessment Solution (ACAS) scans, close findings, update Security Technical Implementation Guides (STIGs). Then the inspector arrives and within two hours has identified a dozen discrepancies that no one had thought to check — artifacts from human behavior and process, not technical configuration.

Here is what I have seen cause these failures, and what actually prevents them.

The Six Pre-Inspection Failure Modes

1. The Stale Authorization Package The System Security Plan (SSP) and its supporting artifacts — Plan of Action and Milestones (POA&M), hardware inventory, software inventory, network diagrams — reflect the system as it was, not as it is. Every undocumented change since the last assessment is a finding waiting to be discovered. ISSMs who do not maintain continuous documentation treat Authority to Operate (ATO) as a finish line rather than a posture.
2. User Behavior That Slipped Through Someone has local admin rights they should not have. A contractor’s account is still active 60 days after they separated. A shared service account password has not rotated in 14 months. None of these are configuration failures — they are governance failures. ACAS does not catch them. Only a disciplined review process does.
3. Physical and Environmental Controls The server room badge log has not been reviewed in six months. The media destruction log has a three-week gap. The visitor log for the Sensitive Compartmented Information Facility (SCIF) does not match the access control system. Inspectors love these because they are easy to find and hard to explain away. They also indicate broader process decay.
4. Training Currency Gaps Twenty percent of system users are past their annual cyber awareness training due date. The Information System Security Officer (ISSO) completed their initial training but not the follow-on required for their current role. The CO has not signed the updated Acceptable Use Policy. These findings are always embarrassing because they are entirely preventable with a calendar.
5. Inherited Controls Without Evidence The authorization package claims reliance on inherited controls from a parent organization. But when the inspector asks for evidence that those controls are functioning — configuration baselines, audit logs, test results — there is nothing. Inherited does not mean free. It means someone else is doing the work, and you are accountable for verifying they did.
6. The 72-Hour Panic Preparation The worst thing a command can do is treat inspection preparation as a surge activity. When you patch 40 vulnerabilities in the week before the inspector arrives, your audit logs tell a story. Inspectors know exactly what fresh patches look like. Deferred maintenance compressed into a sprint is itself a finding — it reveals that continuous monitoring was not actually continuous.

What Passing Inspections Actually Looks Like

Commands that consistently pass inspections share one characteristic: they treat their security posture as an operational condition rather than a compliance event. The documentation is maintained because it is useful, not because an inspector might ask for it. The user accounts are reviewed monthly because an unmonitored account is a real risk, not because it appears on a checklist.

Concretely, the commands I have seen perform best do these things routinely:

• Monthly ACAS scans with immediate remediation tracking. Not quarterly. Not "when we get to it." Monthly, with findings triaged and assigned owners within 48 hours.
• Quarterly account reviews. Every privileged account, every service account, every contractor account verified against current access requirements. Exceptions documented, not hand-waved.
• Continuous documentation updates. Every change to the system — new hardware, software installs, network changes — reflected in the authorization package within 30 days. The SSP is a living document, not a snapshot.
• Training dashboards visible to leadership. The CO should be able to see training currency rates at a glance. When the number drops below 95%, someone calls it out. This is not a burden — it is a five-minute monthly review.
• Tabletop exercises. Walking through "what would happen if an inspector asked about X" before an inspector asks about X reveals gaps you did not know existed.

The ISSM's Real Job

There is a version of the ISSM role that is fundamentally reactive — responding to findings, closing tickets, processing requests. That version of the job produces commands that squeak through inspections.

The more effective version is proactive ownership: knowing the system's security posture at all times, anticipating where gaps will develop before they develop, and building the organizational habits that make continuous compliance automatic rather than effortful.

That second version is harder. It requires credibility with leadership — the ability to say "this is a real risk, not just a checklist item" and be believed. It requires access to information about system changes before they happen, not after. And it requires a certain willingness to be the person who raises uncomfortable issues before they become inspection findings.

The senior leader piece

Most inspection failures ultimately trace back to a senior leader who either did not understand the security program well enough to prioritize it, or understood it and chose not to. The ISSM can build the best security program in the world — if the CO does not enforce training requirements or allows undocumented changes because "we are too busy right now," the program fails.

Part of the ISSM’s job is educating leadership continuously — not just when there is a crisis or an inspection looming, but as part of normal operations. The commander who understands what an authorization boundary is, why account hygiene matters, and what a POA&M represents will make better decisions throughout the year. The one who hears about it for the first time from an inspector is already behind.

A Pre-Inspection Checklist That Actually Works

Six weeks before any scheduled assessment — and honestly, as a standing monthly review — work through this:

None of these items require a week of sprint preparation. Each one represents work that should already be done as part of normal security operations. If working through this list reveals gaps, that is useful — but the right response is to fix the underlying process, not patch the specific finding.

Inspections are a proxy measurement. They're designed to provide a snapshot of whether a security program is real. Commands that treat the inspection as the objective tend to fail it. Commands that treat the inspection as an audit of their ongoing program tend to pass — and more importantly, they actually are more secure.

— Travis D. Butera