Compliance Tools Are Not a Compliance Program: A Practical Guide Using CMMC as the Case Study

By Josh Hammer

A compliance platform can map controls, collect evidence, and display a reassuring green dashboard. It can also leave your organization unprepared.

That is the uncomfortable truth many leaders discover too late: owning a compliance tool is not the same as operating a compliance program.

Organizations often begin with the product. They buy a GRC platform, deploy a SIEM, purchase an EDR solution, or search for a “CMMC compliance automation” package before answering basic questions:

• Which regulations and contracts actually apply?
• What information must be protected?
• Which systems and vendors are in scope?
• Which controls are missing or ineffective?
• What should be fixed first?
• Who owns each remediation task?

The proper sequence is process first, tools second. CMMC provides a useful case study because its requirements are contractual, technical, operational, and evidence-based. The same principle applies to NIST, SOC 2, FedRAMP, HIPAA, RMF, and AI governance.

The Difference Between a Compliance Tool and a Compliance Program

A compliance tool is an instrument. It may automate control mapping, evidence requests, policy distribution, vulnerability scanning, ticketing, or reporting.

A compliance program is the management system that determines:

1. What obligations apply.
2. What information and systems are covered.
3. Which risks matter most.
4. What controls are required.
5. Whether those controls are designed and operating effectively.
6. How exceptions are handled.
7. How leadership accepts, transfers, or mitigates risk.
8. How the organization continuously monitors its posture.

A tool can support those activities. It cannot replace them.

A compliance automation platform cannot define your system boundary without accurate information from your team. It cannot determine whether a control is truly operating merely because a policy has been uploaded. It cannot make an inaccurate representation accurate. It cannot replace an independent assessor, auditor, or government authorization decision. And it cannot make risk decisions for leadership.

Think of compliance technology as the instrumentation in an aircraft. Instruments are essential, but they do not choose the destination, maintain the aircraft, or decide how the pilot responds to a storm.

CMMC: Start With Applicability and Scope

CMMC 2.0 readiness does not begin with buying software. It begins with determining whether CMMC applies and what level is required.

The first step is contract analysis. Review the solicitation, contract clauses, DFARS requirements, prime-contractor instructions, and applicable subcontractor flow-downs. Pay particular attention to:

• Federal Contract Information (FCI): information provided by or generated for the government under a contract that is not intended for public release.
• Controlled Unclassified Information (CUI): information requiring safeguarding or dissemination controls under law, regulation, or government-wide policy.

A company may handle FCI without handling CUI. It may also handle both. That distinction affects the applicable CMMC level, assessment expectations, system scope, and security requirements.

For CUI environments, NIST SP 800-171 remains central to current DoD contractor obligations. The publication addresses systems that process, store, or transmit CUI and includes requirements covering access control, identification and authentication, configuration management, audit and accountability, incident response, system integrity, and other security domains.

Your next question is not, “Which CMMC tool should we buy?”

It is: Where does CUI exist, and which systems protect it?

CMMC’s Current Context: A Pause Is Not an Exemption

As of this writing, CMMC Phase II third-party assessment requirements are paused. That pause should not be interpreted as the elimination of CMMC or the underlying cybersecurity obligations.

Organizations must continue to evaluate their contracts and comply with applicable requirements to protect CUI, implement the currently referenced NIST SP 800-171 requirements, maintain accurate self-assessments where required, and satisfy applicable DFARS clauses.

The DoD CIO CMMC resource page provides current program information. The official text of relevant clauses is available through Acquisition.gov, including:

• DFARS 252.204-7012, covering safeguarding covered defense information and cyber incident reporting.
• DFARS 252.204-7019, addressing NIST SP 800-171 assessment requirements.
• DFARS 252.204-7020, addressing DoD assessment access and support.
• DFARS 252.204-7021, addressing CMMC contractual requirements.

The lesson is straightforward: regulatory timing may change, but your obligation to understand and manage risk does not.

Why Scope Matters More Than Software

Consider a construction firm supporting a federal facility project. Its environment may include:

• Microsoft 365 or another cloud collaboration suite.
• Estimating and project-management systems.
• Remote-access tools.
• Subcontractor portals.
• Engineering workstations.
• Building automation systems.
• HVAC, access control, lighting, or energy-management systems.
• Portable media and field laptops.

If CUI moves through only one controlled enclave, the company may be able to reduce assessment scope. If employees download CUI onto general-purpose laptops or email it to subcontractors, the boundary expands.

That difference has major consequences. It changes the assets requiring protection, the users requiring MFA, the logs that must be retained, the vendors requiring review, and the evidence an assessor may expect.

A tool cannot infer this reliably from a license inventory. The organization must first understand its information flows, architecture, business processes, and contractual relationships.

The August 19, 2026 CISA joint advisory on active threats to Siemens S7 PLCs makes the same point for facility operators and contractors operating industrial control environments. The advisory describes active targeting and AI-assisted exploitation activity involving Siemens S7 programmable logic controllers.

The recommended response begins with inventory, not procurement:

• Identify every PLC and associated engineering workstation.
• Remove direct Internet exposure.
• Segment operational technology from business IT.
• Enforce strong access controls and least privilege.
• Patch where operationally safe.
• Monitor for unauthorized connections, configuration changes, and ladder-logic modifications.

A SIEM or OT monitoring product may help. But it cannot tell you which PLCs exist, whether a contractor has unapproved remote access, or whether your segmentation design reflects how the facility actually operates.

The Six-Part Process to Follow Before Buying Tools

1. Identify regulatory and business drivers

List the contracts, customer commitments, laws, and business objectives driving the program.

For a federal contractor, this may include CMMC, DFARS clauses, NIST 800-171 compliance, and prime-contractor requirements. A technology company may need SOC 2. A cloud service provider serving federal agencies may need FedRAMP compliance automation support as part of a much larger authorization effort.

Do not assume that a framework applies because a competitor uses it. Confirm applicability from the contract, regulation, customer requirement, or legal interpretation.

2. Define the information and system boundary

Identify where FCI, CUI, ePHI, customer data, intellectual property, or AI model data is created, received, stored, processed, or transmitted.

Include cloud services, personal devices, vendors, subcontractors, remote-access paths, backup systems, and facility-related control systems. Document what is inside the boundary, what is outside it, and why.

This is where many “easy compliance” projects become difficult. The difficulty is not a software defect. It is an incomplete understanding of the environment.

3. Assess risk and control effectiveness

Evaluate each applicable requirement against actual evidence.

For example, “MFA is enabled” is not enough. Ask:

• Is MFA enforced for every in-scope user?
• Are service accounts excluded?
• Are privileged accounts protected differently?
• Does remote access to OT use MFA or a controlled jump host?
• Are emergency accounts monitored?
• Can vendors bypass the standard identity provider?

For CMMC, assess the applicable NIST SP 800-171 requirements. For NIST CSF 2.0, develop current-state and target-state profiles across Govern, Identify, Protect, Detect, Respond, and Recover.

For HIPAA, HHS guidance emphasizes an accurate and thorough risk analysis covering threats, vulnerabilities, safeguards, likelihood, and impact.

4. Build a prioritized remediation plan

Create a POA&M or equivalent remediation plan based on risk and business impact.

Each finding should have:

• A clear description.
• The related requirement.
• A responsible owner.
• A target date.
• Dependencies.
• Required resources.
• Validation criteria.
• Residual-risk treatment.

Do not treat every gap as equal. A missing policy may matter, but an Internet-exposed PLC, unrestricted administrator account, or unprotected CUI repository may deserve immediate attention.

5. Select tools based on identified needs

Only now should you compare products.

You may need a compliance automation platform for control mapping, evidence collection, remediation tracking, and automated compliance monitoring. You may need an EDR platform, vulnerability scanner, identity tool, SIEM, secure configuration service, or vendor-risk workflow.

The right question is not, “Which platform has the longest feature list?”

Ask instead:

• Does it integrate with the systems in our defined boundary?
• Can it collect objective evidence rather than screenshots alone?
• Can it distinguish inherited, shared, and organization-specific controls?
• Can it support facility and OT environments?
• Can it track remediation owners and deadlines?
• Can it map overlapping requirements without obscuring important differences?

6. Operate and monitor continuously

Compliance is an operating condition, not a project closeout.

Users change. Vendors change. cloud configurations change. New contracts introduce new data. Facilities add connected systems. AI tools enter workflows without formal approval.

Your program should therefore monitor control health, investigate exceptions, update documentation, and reassess scope when material changes occur.

The Same Principle Across Popular Frameworks

The labels differ, but the process is remarkably consistent.

• NIST CSF 2.0: establish governance, understand risk, define a current state, set a target state, and measure progress.
• NIST SP 800-171: identify the systems handling CUI, implement requirements, assess evidence, document shortcomings, and maintain the environment.
• SOC 2: define the service and system description, select relevant Trust Services Criteria, operate controls over the examination period, and provide evidence to the independent service auditor. A SOC 2 automation tool can organize that work; it cannot create an effective control environment.
• FedRAMP: define the cloud service boundary, select and tailor the applicable NIST SP 800-53 baseline, complete independent assessment, support the authorization decision, and perform continuous monitoring. FedRAMP compliance automation can accelerate documentation and evidence workflows, but it does not produce an Authority to Operate.
• HIPAA: perform the required risk analysis, select safeguards, document decisions, and review the environment as it changes.
• RMF and NIST SP 800-53: categorize, select, implement, assess, authorize, and monitor. The NIST RMF is explicitly a lifecycle for risk decisions and continuous monitoring.
• AI governance: use the NIST AI Risk Management Framework to govern, map, measure, and manage AI risks. Before buying an AI governance platform, identify the use cases, data, models, owners, failure modes, and decision impacts.

Across all of these frameworks, automation is most valuable after the organization has made the difficult judgments.

Where H&V Complynt Fits

At H&V Complynt, we believe the strongest model combines expert guidance with automation.

Complynt supports control mapping, evidence collection, remediation tracking, policy content, and continuous compliance monitoring. Its dashboard is designed to provide real-time visibility rather than a static audit binder.

Our CMMC Level 2 compliance service supports organizations from gap assessment and scoping through implementation planning and ongoing monitoring. For organizations with complex facility environments, our RMF Division 25 and FRCS hardening services address the reality that building systems and operational technology cannot be treated like ordinary office IT.

The goal is not to promise certification. It is to help you understand your obligations, build a defensible process, and use technology where it creates measurable leverage.

That is the meaning of “map once, satisfy many.” Properly designed controls may support CMMC, NIST, SOC 2, RMF, HIPAA, and other obligations. But the mapping is useful only when the underlying control is properly scoped, implemented, evidenced, and maintained.

Before you buy another compliance product, begin with the process. Determine what applies. Define what matters. Assess what is real. Prioritize what must change. Then select the tools that help your people operate the program.

Start with a compliance readiness assessment or contact H&V Complynt to discuss the process before the product.