CMMC Software Approval Process: A Step-by-Step Workflow

Every application added to a system that handles CUI is a security decision. A CMMC software approval process is the repeatable way to make that decision and to leave a record that survives staff turnover and assessments. It supports several practices at once, most directly CM.L2-3.4.8 on application execution and CM.L2-3.4.9 on user-installed software.

The workflow below has seven steps. Adapt the depth of each step to the risk of the software: a small utility with no network access needs less analysis than a platform that stores data in the cloud.

Step 1: Intake the request

Capture the information you need to decide. At minimum: the application name and exact version, the vendor, the business reason, the requester and their manager, the target systems, and whether the software will touch CUI or sit inside the assessment scope. Use a form or ticket type so requests arrive complete.

Step 2: Triage against what you already have

Check whether an approved application already does the job, whether the request is a version update of something approved, and whether the software is inside the scope boundary. Many requests end here with a pointer to an existing tool, which is the cheapest outcome.

Step 3: Screen the vendor

Before anyone runs the software, look at who is behind it. Identify the legal entity and its ownership, check the vendor against sanctions and prohibited-source lists, and review its security posture: whether it publishes a vulnerability disclosure channel, how fast it patches and whether the product is still supported. Screening vendors for sanctions and ownership covers this step in detail. A vendor that fails here should be rejected without further spend.

Step 4: Analyze the software itself

Verify the digital signature and record the SHA-256 hash of the installer. Run the installer in an isolated sandbox and observe what it does: network destinations, files and registry keys written, services and drivers installed, and the privileges it requests. Sandbox analysis explains what this step can and cannot show.

Step 5: Decide and document

Use three outcomes: approve, approve with conditions, or reject. Conditions are specific and enforceable, for example a list of permitted network destinations or a requirement to run without administrator rights. Record the decision, the rationale, the approver and the date. A decision without a rationale is not evidence.

Step 6: Implement

Add the approved version to the application execution policy using the rule type that fits, as compared in WDAC and AppLocker rule types. Deploy through your managed tooling, apply any firewall conditions and update your software inventory and baseline documentation in the system security plan.

Step 7: Maintain

Approval is not permanent. Define triggers for re-review: a new version, a vendor ownership change, a publicly reported vulnerability, the end of vendor support, or a fixed interval. Remove entries that are no longer used. Keep the approved software list as the single source of truth.

Roles

Keep the roles distinct. The requester explains the need. IT or engineering performs the triage and implementation. Security performs or commissions the screening and analysis. A named approver signs off. When the same person fills all four roles, assessors will reasonably ask how independence is preserved.

Using an external provider for steps 3 to 5

Steps 3 to 5 take specialist time, often many hours per application. DigVel performs them as a service: Phase 1 OSINT screening to fail fast, then Phase 2 sandbox analysis for software that passes, ending in a report with a recommendation and control mapping. See the service overview and the two-phase methodology. The decision to approve remains yours.