Nine Months Undetected: What the Pentagon Breach Says About Encryption and Monitoring Evidence

By Josh Hammer, CEO, H&V Complynt

The real lesson is not the size of the breach

The public reporting about the Defense Manpower Data Center incident has focused on the number of people affected. That is understandable. Approximately 3.05 million people were included in the affected population: 2.76 million living individuals and 294,000 deceased individuals.

But the more important control lesson is the duration.

According to the reported DMDC notification, unauthorized users accessed files on a file-sharing server from approximately October 2025 until the vulnerability was discovered and patched on July 16, 2026, roughly nine months. The files contained unencrypted personal information, including Social Security numbers, names, dates of birth, contact information, and military personnel details. Officials have stated that, at the time of reporting, no evidence of misuse of the accessed information had been reported.

That last sentence requires care. “No evidence of misuse has been reported” does not mean the data was not misused. It means officials had not identified evidence of misuse at the time those statements were made.

The question for security and compliance leaders is therefore not simply, “How bad is this?” The better question is:

What would have changed if the organization could demonstrate, throughout those nine months, that its controls were operating as intended?

That question takes us beyond checklists. It goes to the distinction between implementing a control and proving that the control continues to operate.

SecurityWeek reported that the vulnerability affected a DMDC file-sharing system and exposed unencrypted personally identifiable information. TIME and ABC News separately reported the access period, affected population, and patching response.

Tier 1: What happened, on the public record

The facts currently available are straightforward.

A vulnerability in a DMDC file-sharing system allowed unauthorized access to files stored on a server. The data was unencrypted at rest. Unauthorized access began around October 2025 and continued until the vulnerability was discovered and patched on July 16, 2026.

The affected records included information associated with military and civilian personnel, contractors, retirees, veterans, family members, and others whose information was maintained by the center. The reported data elements included:

• Social Security numbers
• Names
• Dates of birth
• Contact information
• Military personnel details, including occupational information

Officials stated that approximately 3.05 million people were affected. The Pentagon and DMDC began notifying affected individuals after the incident was identified and the system was remediated. Reporting from Security Affairs and Stars and Stripes provides additional coverage of the notification and scope.

No public reporting cited here establishes who caused the unauthorized access, why it occurred, or what the accessed information was ultimately used for. Those questions are outside the evidence available for this analysis.

The control lesson is narrower and more useful: sensitive information remained unencrypted, unauthorized access persisted for an extended period, and the condition was not discovered until the vulnerability was found.

Detection is difficult. Large environments contain legacy systems, inherited configurations, third-party dependencies, and complex access paths. No serious security leader believes every issue can be prevented or detected instantly.

But nine months is precisely the kind of detection gap that evidence practices are meant to shorten.

If an organization can show that it continuously checked encryption status, monitored access activity, tracked vulnerabilities, and reviewed high-impact assets, it can answer critical questions earlier:

• Was encryption enabled on the affected storage?
• When did the configuration change?
• Which accounts accessed the system?
• Were those accounts authorized?
• Was the vulnerability known, reported, or present in inventory?
• Who owned remediation?
• What evidence shows that the issue was identified and corrected?

Without those records, an organization may have policies and tools while still lacking assurance.

Tier 2: Mapping the incident to security controls

1. Encryption at rest: configuration is not verification

NIST SP 800-171 Rev. 3 places protection of sensitive information within the System and Communications Protection family, including requirements in the 3.13.x series. At the enterprise level, NIST SP 800-53 addresses comparable protections through the SC family.

The objective is not abstract. Sensitive information should be protected when it is stored and when it moves across systems.

Unencrypted Social Security numbers on a file-sharing system represent the precise condition this control objective exists to prevent.

However, there is an important distinction between:

1. Having an encryption policy;
2. Configuring encryption on a system; and
3. Verifying, continuously, that encryption remains enabled on the specific storage containing the specific data.

The first is governance. The second is implementation. The third is assurance.

Those are not interchangeable.

A screenshot from a prior review may show that encryption was enabled on a particular date. It does not establish that encryption remained enabled afterward. A policy may require encryption everywhere. It does not prove that a legacy file share, storage volume, backup repository, or cloud-connected appliance complied with the policy.

An unverified control is indistinguishable from an absent control until the moment it fails.

For federal contractors and facility operators, this distinction matters because environments are rarely static. Systems are migrated. Storage is repurposed. Service accounts change. File shares are inherited from older architectures. A control that worked last quarter may not be operating today.

The evidence should therefore include the asset, the control state, the capture date, the verification date, and the method used to validate the condition.

2. Flaw remediation: nine months is a process finding

NIST SP 800-171 Rev. 3 also addresses System and Information Integrity through the 3.14.x requirements, including the identification, reporting, and timely correction of system flaws.

The public record does not establish whether the DMDC vulnerability was known before discovery, whether it appeared in a vulnerability catalog, or how the remediation process operated internally. We should not invent those facts

But a nine-month access window still creates a useful process question:

Was the vulnerability unknown, or was it known but not moved through the remediation path quickly enough?

Either possibility is a finding about the process.

CISA’s Known Exploited Vulnerabilities Catalog is designed to help organizations prioritize vulnerabilities that have been exploited in the wild. CISA’s Binding Operational Directive 26-04 describes a risk-based model that considers:

• Whether an asset is publicly exposed;
• Whether the vulnerability is listed in the KEV catalog;
• Whether exploitation can be automated; and
• The technical impact of exploitation.

BOD 26-04 does not apply identically to every system or organization, and its own scope language includes important federal-system limitations. Nevertheless, its risk model is instructive for any organization managing sensitive environments.

A remediation program should connect the vulnerability to the asset, the asset to the information it stores, and the risk rating to a documented owner and deadline. It should also retain evidence that the remediation occurred and that the fix was verified.

A patch ticket marked “closed” is not the same as proof that the vulnerable condition no longer exists.

3. Audit and accountability: logs must answer questions

The Audit and Accountability, or AU, family is often misunderstood as a requirement to collect logs.

Logging is necessary, but it is not the end state.

The useful question is whether the organization can reconstruct:

• Who accessed the file-sharing system;
• What files or repositories were accessed;
• When access occurred;
• Whether the account was authorized;
• What administrative or configuration changes took place; and
• Whether the access pattern should have triggered an alert.

A log repository can be full and still be operationally weak. Logs may be retained for too short a period. They may not include the necessary fields. They may be distributed across systems that cannot be correlated. They may not distinguish normal administrative activity from unusual access.

Evidence of operation means demonstrating that logging was enabled, that records were retained, that alerts were reviewed, and that the organization could use those records to investigate.

If you cannot reconstruct the access window after the fact, you may not be able to scope notification accurately. More importantly for assurance, you may not be able to prove that monitoring worked before the incident.

4. Risk assessment: inventory is not prioritization

The Risk Assessment, or RA, family is where an organization turns facts about assets and vulnerabilities into a defensible order of priority.

A file-sharing system containing Social Security numbers and military personnel information for millions of people should be treated as a high-impact asset. That does not mean every security decision becomes simple. It does mean the asset’s sensitivity, scale, exposure, dependencies, and access paths should be reflected in the risk assessment before an incident occurs.

Many organizations have an asset inventory. Fewer maintain an inventory that answers:

• What information does this asset hold?
• Which controls protect it?
• Who owns those controls?
• What evidence proves they are operating?
• What changes would increase the asset’s risk?
• How quickly must a vulnerability affecting it be addressed?

A risk register that records a vulnerability without connecting it to business and information impact is incomplete. It tells you what is wrong, but not what should be fixed first.

5. Continuous monitoring closes the detection gap

Point-in-time checks produce point-in-time confidence.

That is not useless. Audits, assessments, penetration tests, configuration reviews, and interviews all have value. But a point-in-time review cannot, by itself, demonstrate what happened between review dates.

Continuous monitoring exists to shrink that gap.

For encryption, continuous monitoring can test whether protected storage remains encrypted. For vulnerability management, it can compare active assets against current findings and remediation status. For audit and accountability, it can confirm that logging remains enabled, retained, and connected to review workflows. For risk assessment, it can surface changes in asset ownership, data classification, exposure, and architecture.

This is also the direction of the federal ecosystem. FedRAMP’s move toward continuous Key Security Indicator validation and machine-readable evidence reflects a broader shift from static compliance packages toward evidence generated from operating environments. The FedRAMP 20x materials describe an authorization model built around measurable, repeatable, and increasingly automated validation.

The principle is simple: evidence should be generated as the system operates, not reconstructed only when an assessor asks for it.

Compliance tools are not the compliance process

This incident also illustrates a point I make frequently: a compliance tool is not a compliance program.

A platform can collect evidence, map controls, monitor systems, and organize findings. It cannot decide whether your inventory is complete. It cannot determine whether a file-sharing system has been assigned the correct owner. It cannot resolve an unclear responsibility between a contractor and a cloud provider. It cannot substitute for leadership decisions about risk acceptance, remediation priorities, or operating discipline.

The proper sequence is:

1. Audit your current state.
2. Identify control gaps and evidence gaps.
3. Build a practical remediation and monitoring plan.
4. Then select tools that support that plan.

Choosing software first often produces a well-organized version of an incomplete process.

The objective is not to collect more documents. It is to create a defensible chain from requirement to control, control to asset, asset to evidence, and evidence to an informed decision.

Tier 3: Where Complynt supports the operating layer

At H&V Complynt, we focus on the operating layer between the framework and the evidence.

Complynt supports:

• Automated control mapping;
• Evidence collection with capture and verification dates;
• Continuous monitoring;
• Pre-built content packs;
• Policy-as-code;
• Cross-framework alignment across more than 150 compliance standards; and
• Visibility into whether controls are operating across complex enterprise, facility, and control-system environments.

The goal is to help organizations map once and satisfy many without losing sight of the underlying process. A single technical condition, such as encryption on a storage system, may support requirements across multiple frameworks. The evidence still needs to be tied to the right asset, scope, owner, date, and verification method.

Complynt operates on infrastructure authorized for FedRAMP High and DoD IL5 on Palantir’s federal cloud, supporting organizations that need strong security and compliance foundations for sensitive environments.

I want to be equally clear about the limits. H&V does not issue certification and cannot guarantee an assessment outcome. Complynt is a tool and operating layer that supports your compliance process. It does not replace your audit, your risk decisions, your system owners, or your independent assessor.

If you want to understand your current position, begin with a free readiness check. If the gaps are broader, review our compliance automation services. In either case, start with the audit and plan, not the software purchase.

What to do this week

Use the Pentagon breach as a practical control review rather than a news story to file away.

• Identify your highest-impact file repositories. Include file shares, databases, cloud storage, backups, and legacy systems.
• Verify encryption at rest. Do not rely on policy language or historical screenshots. Capture the current state and record when it was verified.
• Review access logs. Confirm that you can answer who accessed sensitive data, what they accessed, when they accessed it, and whether the access was authorized.
• Test your vulnerability workflow. Select one high-impact asset and trace a vulnerability from discovery through ownership, remediation, closure, and verification.
• Compare your inventory to reality. Look for systems, storage locations, service accounts, and interfaces that are missing or incorrectly classified.
• Review your retention period. Make sure audit records would allow you to reconstruct a comparable access window.
• Assign control ownership. Every critical control should have a named owner and a defined verification method.
• Build a monitoring plan before selecting a platform. Decide what must be checked continuously, what can be reviewed periodically, and what evidence each check must produce.

Frequently asked questions

1. Does encryption at rest eliminate the need for monitoring?

No. Encryption reduces the harm that may result from unauthorized access to stored data, but it does not identify vulnerabilities, unauthorized accounts, excessive permissions, or suspicious activity. You need both protective controls and evidence that those controls remain active.

2. Is a control implemented if the organization has a policy requiring it?

Not necessarily. A policy establishes an expectation. Implementation requires configuring the control in the relevant system. Assurance requires verifying that the control is operating over time and retaining evidence of that verification.

3. What should audit logs prove?

Logs should support answers to practical questions: who accessed what, when the access occurred, whether it was authorized, and whether the activity was reviewed or investigated. Simply possessing a large volume of logs does not prove that audit and accountability controls are effective.

4. How should organizations prioritize vulnerability remediation?

Start with asset and information risk. Consider exposure, known exploitation status, exploit automation, technical impact, business importance, and the sensitivity of the information involved. CISA’s KEV catalog and BOD 26-04 provide useful inputs, but each organization must apply risk judgment to its own environment.

5. Should an organization buy a compliance platform before conducting an audit?

No. Audit the current state first, identify control and evidence gaps, and build a remediation and monitoring plan. Then choose tools that support the process you actually need to operate.

Read Next in This Series

• Technical Guide #5: How to Write Your System Security Plan (SSP)
• The Plant Floor Is the Next Compliance Frontier: FRCS, OT Resilience, and What Contractors Are Missing
• Compliance Tools Are Not a Compliance Program
• Technical Guide #9: Evidence Collection forthcoming
• Compliance automation services

The central lesson is not that organizations need more compliance paperwork. It is that they need reliable evidence showing whether important controls are operating on important assets, every day.

Encryption should be verified. Vulnerabilities should move through a defined remediation path. Logs should answer questions. Risk assessments should reflect the value of the information at stake. And monitoring should shorten the distance between a control failure and its discovery.

That is the difference between having controls and having assurance.