See why application control is key to winning and keeping DoD contracts.
A written software policy says what should be allowed to run. Application control enforces that policy and produces evidence that it is operating as intended.
That distinction matters for Cybersecurity Maturity Model Certification (CMMC) readiness. Organizations handling Controlled Unclassified Information (CUI) must implement applicable safeguards and be able to demonstrate that those safeguards operate effectively. Application control can help enforce which applications, scripts, and other executable files are allowed to run while creating records that support assessments and ongoing compliance efforts.
For organizations pursuing U.S. Department of Defense (DoD) work, that makes application control more than another security project. It can become part of the company’s ability to qualify for and retain contracts.
Why Application Control Is Now a Business Problem
Imagine you’re back in a planning meeting at your manufacturing company, asking to move application control up the priority list. Your team has identified engineering workstations where unapproved software can run. You want to reduce the opportunities available to an attacker by restricting which applications and scripts can execute. But the answer from leadership is familiar: “Can we revisit it next quarter?”
You understand the hesitation. The identity project needs funding, the backup upgrade is overdue, and you recommended both. You can’t exactly argue that everyone else’s priorities should wait. Meanwhile, the application control gap remains yours to worry about.
Then your sales director brings in an opportunity to supply components for Navy ships. Leadership is discussing production capacity and potential new hires when someone asks you: “Are we ready to meet the cybersecurity requirements?”
The solicitation requires a current status under the Cybersecurity Maturity Model Certification (CMMC) program your company has yet to achieve. Without a current CMMC status, the Department of Defense (DoD) cannot award your company the contract.
You pull up the same application control proposal because the security gap hasn’t changed. What has changed is the business context.
Leaving the gap unresolved no longer represents only another three months of security exposure. If the gap prevents the company from demonstrating that it has implemented an applicable CMMC security requirement, it could affect the company’s ability to qualify for the contract.
In other words, application control has moved from the security backlog into the contract-readiness discussion.
You Don’t Have to Build Navy Ships for CMMC Requirements to Affect Your Business
Whether your company builds the ships themselves or simply sells the paint for those ships (or somewhere in between), you may be part of the defense supply chain and subject to CMMC requirements.
CMMC can extend beyond prime contractors and major weapons manufacturers to companies providing components, coatings, engineering services, maintenance, and other support. The determining factor is not how prominent your company’s role appears. It is the information your systems will process, store, or transmit and the requirements included in or flowed down through the contract.
When the work involves Controlled Unclassified Information (CUI), your company is responsible for protecting the CUI it receives or creates in connection with that work, even if it concerns something as seemingly innocuous as the color of the paint being selected.
Among the CMMC Level 2 requirements is controlling which software can run. Practice CM.L2-3.4.8 requires organizations to apply either a deny-by-exception policy that prevents unauthorized software from being used or a deny-all, permit-by-exception policy that allows authorized software to execute. CMMC Level 2 incorporates this and the other security requirements in NIST SP 800-171 Revision 2, as established in 32 CFR § 170.14 and detailed in the official CMMC Level 2 Assessment Guide.
CMMC Turns ‘We should’ into ‘Enforce it – and show me’
“Don’t we already have a software policy?”
You can imagine the question coming from someone who approved the policy and assumed the company had dealt with application control. On paper, the company may have spelled out exactly which software is allowed. But if a program the policy prohibits can still run on an engineering workstation, you have documented a restriction without technically enforcing it.
CMMC assessments reach into the difference between the document and the workstation. The company needs to specify which software is permitted or prohibited, implement its chosen policy, and demonstrate that the policy operates as intended. The approved policy helps explain what should happen. Evidence of enforcement shows whether it’s actually happening. You can’t substantiate the latter by handing over another copy of the former.
For application control, that evidence could include the enforcement configuration applied to in-scope systems, a test showing that prohibited software is blocked, logs of permitted and denied execution attempts, and records of application approvals or policy exceptions. No single record establishes CMMC compliance by itself, but together they can help demonstrate that the company has implemented and is maintaining the control it documented.
Before you get much further, though, someone may raise an objection: “Isn’t the next phase of CMMC on pause? Shouldn’t we wait until we know what’s required?”
I understand the appeal, especially when you’re already trying to fit too many security projects into the same budget. But the Phase II suspension hasn’t removed the Phase I self-assessment requirements or the existing obligations to protect CUI. The Department’s current CMMC guidance explicitly preserves those responsibilities during the pause.
A self-assessment still needs to reflect what your company has implemented, not simply what it has approved for implementation someday. For application control, the question remains whether the software restrictions operate as specified. You’re not asking leadership to anticipate every possible outcome of the CMMC review. You’re asking to close a gap between what the company says it controls and what it can demonstrate it controls now.
How Application Control Supports Your CMMC Readiness
For the engineering workstations that would handle CUI, your application control proposal addresses the CMMC Level 2 requirement to control which software can run. Application control provides a technical mechanism for enforcing the company’s software-execution policy. It can prevent unapproved applications and scripts from running while recording execution attempts and policy decisions.
Application control can also support related CMMC practices by helping your company restrict nonessential programs, control and monitor user-installed software, create audit records, protect systems against malicious code, and identify unauthorized system use.
It does not establish CMMC compliance by itself. But it can help implement relevant safeguards and produce evidence that supports the company’s assessment of those safeguards. You can now connect the gap to the specifications, the systems that will handle them, the work those systems must support, and the evidence your company will need to demonstrate enforcement.
And winning the contract doesn’t put cybersecurity readiness behind you. Where a contract requires CMMC status, your company must maintain a current status at the required level throughout the life of the contract. When those requirements apply, the government must verify the required status before exercising an option or extending the period of performance. Delivering every component on time doesn’t remove the cybersecurity condition for continuing the work. For leadership, the implications extend beyond a promising new order. The DoD work already built into next year’s plans may depend on meeting cybersecurity requirements too.
When ‘Show me’ Becomes a Condition of Doing Business
Suppose your team tests whether a program prohibited by the software policy will run on one of the engineering workstations, and you discover it does, in fact, launch. You can now concretely show that your company has documented the restriction but cannot yet demonstrate that it works on a system intended to handle CUI. Testing the enforcement mechanism establishes whether the policy operates as specified, and in this case, produces evidence of a gap that needs to be closed
After application control is implemented, the team can repeat the test. This time, the prohibited program should be blocked. The team can preserve the test result, enforcement configuration, and execution record as evidence that the policy is operating on the workstation.
The progression is straightforward:
- The policy defines the rule.
- Application control enforces the rule.
- Testing and execution records help demonstrate that the enforcement works.
You could report the finding as an unmet requirement, complete with the relevant practice number. But the question for leadership goes beyond which requirement needs attention. Could leaving the failure unresolved prevent the company from qualifying for the order everyone is preparing to fulfill?
Under DFARS 204.7502, a contracting officer may not award the contract, task or delivery order to a company without a current CMMC status at the level required by the solicitation. Leadership may be willing to accept some continued security exposure while other projects take priority. Accepting the risk internally does not waive the customer’s conditions for awarding the work.
Closing the application control gap serves both needs: protecting the information entrusted to your company and producing evidence of enforcement that supports its effort to achieve and maintain the required CMMC status.
Now leadership has a different decision to make. The competing security investments haven’t become less important. But postponing application control needs to be weighed against both the exposure left on those workstations and the company’s ability to qualify for the contract. The potential order belongs in that discussion alongside the cost of fixing the gap.
Conclusion
Don’t Let an Application Control Gap Cost You DoD Contracts
You don’t have to wait for the next contract opportunity to prompt another cybersecurity question.
Ask your sales director which DoD opportunities the company is pursuing and which existing contracts leadership expects to keep. Where CMMC status is required to win or continue the work, you have a shared reason to make application control part of the business planning, not a security concern to revisit afterward.
Bring leadership a proposal tied to those plans, with a clear account of:
- Which systems will process, store, or transmit CUI
- Which application control requirements apply to those systems
- What your team needs to close the enforcement gap
- How the team will test whether the control works
- What evidence the company will retain to support its assessment
The Phase II pause leaves applicable self-assessment and information-protection obligations in place, so an uncertain restart date needn’t dictate when you begin.
You already know how to explain the security exposure. Now you can put the application control decision alongside a business objective leadership has committed to pursuing and ask for the action needed to support it. “Here’s what we need to do to help qualify for the Navy contract” gives the next meeting somewhere useful to go.
Enforce Your Application Policy—and Show That It Works
Airlock Digital helps organizations control which applications, scripts, installers, and other executable files can run across their environments. Centralized policy enforcement and detailed execution records can help turn a written software policy into an implemented, demonstrable security control.
See how Airlock Digital supports CMMC readiness with application control.