The COTS exception is narrow enough that one word in the DFARS matters a great deal: solely. DFARS 212.371 lists several cybersecurity provisions and clauses that do not apply to contracts or subcontracts solely for commercially available off-the-shelf items. That can be significant for a reseller or manufacturer, but it is not a blanket exemption for every business that sells a commercial product.
The safest way to use the exception is as a contract-classification decision supported by the acquisition record. Identify the line items, confirm why they are COTS, check whether services or modification are mixed into the work, and retain the clause basis for the conclusion.
COTS is a defined acquisition category
Commercially available off-the-shelf is not a marketing adjective. It is an acquisition term with defined characteristics. A product being sold to many commercial customers does not automatically make every contract for that product 'COTS only.' The classification should come from the procurement and the facts of what is being acquired.
Contracts teams should avoid letting website copy such as 'commercial off-the-shelf solution' become the legal analysis. Keep the acquisition classification, line-item description, and contract treatment together so security decisions can rely on something more authoritative than a sales description.
The word 'solely' is the first screening test
DFARS 212.371 addresses contracts or subcontracts solely for COTS items. If the statement of work includes integration, engineering, customization, installation, data analysis, managed services, or other non-COTS performance, do not assume the exception survives unchanged. Mixed work needs a closer clause review.
A useful internal test is to ask what the company is actually being paid to do. If the answer includes services or modification beyond selling the item in the form normally sold in the commercial market, route the contract to contracts or counsel for classification instead of using the COTS exception as a shortcut.
Which cyber clauses are commonly affected
The current DFARS COTS inapplicability list includes FAR 52.204-21 and several DFARS cybersecurity clauses, including 252.204-7012, 7019, 7020, and 7021. That does not mean a company with one COTS-only contract can remove those controls from its entire environment. Applicability is contract-specific.
A company may have another defense contract involving CUI, a subcontract that is not solely COTS, or a customer data-sharing arrangement that carries separate obligations. Keep the COTS analysis attached to the specific contract or subcontract rather than turning it into a company-wide cybersecurity policy.
Document the exception in a one-page triage record
For each contract where the exception is relied upon, record the solicitation or contract number, relevant line items, the basis for COTS classification, whether the work is solely COTS, the clauses reviewed, the person who approved the interpretation, and the date. Attach the relevant acquisition language or a link to the source.
That record is valuable later when a modification adds services or a new buyer asks why the cybersecurity clauses were omitted. Without the original rationale, staff may either over-apply controls unnecessarily or keep using an exception after the facts changed.
Recheck modifications, options, and subcontracts
A contract can start as a simple COTS acquisition and later grow support, integration, training, or engineering work. Build a trigger into contract administration: when the statement of work or line-item mix changes, re-run the COTS-only test. Do not rely on the original classification indefinitely.
Apply the same discipline to subcontracts. A prime may buy a commercial product from one supplier and a customized engineering service from another. Analyze each instrument on its own facts. Using a single cyber clause template for every supplier can hide the reason a clause does or does not apply.
Do not confuse an exception with low risk
Even where the specific DFARS cyber clauses do not apply because the acquisition is solely COTS, the company may still choose ordinary security controls for business reasons, customer expectations, intellectual-property protection, export control, or other contracts. The exception answers a clause-applicability question; it does not certify that the business has no cybersecurity exposure.
Keep that distinction clear in management communications. Say 'this contract is being treated as COTS-only for these clauses based on the acquisition record,' not 'CMMC does not apply to our company.' Narrow language is both more accurate and easier to revise if the work changes.
A mixed-order example: product plus integration
A supplier sells a standard commercial sensor that may qualify as COTS, but the same order also requires engineering integration, custom configuration, and on-site support. Treating the entire order as 'COTS' because the hardware is sold off the shelf skips the word 'solely' in the DFARS exception. The services and modifications need separate acquisition analysis.
Contracts should break the requirement into line items and identify how each is classified. If the procurement itself treats the acquisition as mixed, security should not rely on a COTS-only exception without a documented basis. A short written conclusion reviewed by the responsible contracts professional is better than an assumption embedded in a compliance spreadsheet.
The opposite error is also expensive: applying a full cybersecurity clause package to a truly COTS-only subcontract because nobody reviewed the exception. That can create unnecessary supplier friction and false representations. Triage should be accurate in both directions, not simply conservative by default.
When an option year adds support services, reopen the analysis. The original hardware classification may still be correct while the expanded contract no longer fits the same exception. Contract changes are the natural trigger for re-checking clause applicability.
Keep security involved even when the COTS exception is valid. The contract may not carry the listed cybersecurity clauses, but staff can still receive Government communications, supplier data, or other information under separate obligations. The exception should narrow the compliance analysis for that acquisition, not cause the organization to stop basic security or forget requirements attached to its other contracts.
A good exception memo should also say what would invalidate the conclusion. Examples include adding non-COTS services, customization, integration, or a separate data-handling requirement. Writing the trigger into the original record makes later contract modifications easier to review and reduces dependence on the employee who performed the first analysis.
Mixed purchases deserve special attention. A line item may look like a standard commercial product while the surrounding work includes installation, integration, engineering support, data migration, or other services that change the analysis. Do not let the product label decide the entire order. Break the purchase into what is actually being acquired and document why the exception applies—or does not apply—to the contractual instrument you are reviewing.
A short working check
- ✓Confirm the acquisition is solely COTS
- ✓Do not equate all commercial items with COTS
- ✓Review each contract and subcontract separately
- ✓Record the clause basis for the exception
- ✓Check for mixed services or modification work
- ✓Revisit the analysis when scope changes
Common questions
Does selling a commercial product automatically create a COTS exception?
No. COTS has a specific acquisition meaning, and the cited DFARS exception is written for contracts or subcontracts solely for COTS items.
If one contract is COTS-only, can the company ignore CMMC everywhere?
No. Other contracts or systems can independently carry FCI, CUI, or cybersecurity clauses.
What commonly breaks a COTS-only analysis?
Mixed work. Installation, customization, integration, engineering support, data migration, or other non-COTS services can change the clause analysis for the acquisition. Review what the contract actually buys, not only the product label.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
