What CM-7 least functionality asks for and why assessors care
If an audit, contract or authorization requires NIST SP 800-53 CM-7, the core demand is this: the organization must define the capabilities a system needs to fulfill its mission, configure the system to provide only those capabilities, and prohibit or restrict the functions, ports, protocols, software and services it does not need. CM-7 is a Configuration Management control in the Rev. 5 catalog. It is selected for the low, moderate and high security control baselines in SP 800-53B Release 5.2.0, but not for the privacy baseline. The risk it addresses is easy to state. Every service left running, every open port and every installed package is a path an attacker can use, and each one also has to be patched, monitored and explained to an assessor. The organization owns the decision about what is essential. An implementation partner can help build the configuration and evidence, but cannot make that decision for it.
The hard part is rarely the configuration itself. It is defining the mission-essential list in terms specific enough to test, then proving the restrictions still hold months later. Assessors will ask for the configuration management plan, the system component inventory and the common secure configuration checklists, then interview administrators to see how those documents are actually applied. They will also test whether the organization's processes prohibit or restrict the defined functions, ports, protocols, software and services. A list that says "web services only" will not satisfy that test. The list needs named services, ports and software, each tied to a stated mission need, and a way to show that drift from the baseline is detected and reviewed.
Before the assessment, confirm three things with your authorizing official or assessor: which CM-7 enhancements apply to your system (SP 800-53B selects CM-7(1), CM-7(2) and CM-7(5) in the moderate and high baselines), how often the periodic review must occur, and what form of allow-listing or prevention they expect. Those answers determine the evidence you need to collect, so settle them before you configure anything.
Which systems and teams fall under CM-7 least functionality
CM-7 applies to any system in an authorization boundary, but the impact level, the enhancements selected and the component types decide how much work it creates. The cards below cover the scoping choices that change the effort, plus the owners and provider-managed services whose settings must be included in the evidence.
Impact level sets the baseline
CM-7 is selected in the low, moderate and high baselines of SP 800-53B Release 5.2.0 but not in the privacy baseline. The impact categorization of the system determines which baseline applies. Only moderate and high systems pick up enhancements CM-7(1), CM-7(2) and CM-7(5), so a low-impact system needs the base control alone. Confirm the categorization with the authorizing official before scoping the enhancements.
Periodic review scope (CM-7(1))
CM-7(1) requires a periodic review of the functions, ports, protocols, software and services in use, with the aim of removing those that are not needed. Scope the review to every component in the boundary and define the review frequency in the configuration management plan. The main effort is building a current inventory of what runs on each system, so this card depends on accurate component records.
Allow-listing scope (CM-7(5))
CM-7(5) asks for an authorized software list with allow-by-exception, meaning only approved software runs unless it is explicitly authorized. Decide which software categories fall under the list, such as operating system packages, container images, browser extensions and developer tools, and name the owner who approves additions. Teams often underestimate how many runtime dependencies this covers, so check language libraries and container base images too.
Prevent program execution scope (CM-7(2))
CM-7(2) requires preventing program execution in line with the policy on which software is permitted. Identify the hosts where enforcement is technically possible, such as servers and managed endpoints, and the systems where it is not, such as some appliances and vendor-managed devices. For the gaps, document compensating measures and the owner who accepts the residual risk. Confirm each platform's enforcement capability with its vendor before writing the scope.
Mission-essential list owners
The base control requires the organization to define which capabilities are mission essential, so the list needs a named business owner, a system owner and a security reviewer. Application owners usually know which services are required, while platform engineers know which default services ship enabled. Record who approves each function, port, protocol and service, and keep that record with the baseline configuration so that the reasoning is traceable at assessment.
Provider-managed and cloud components
Where a third party controls the settings, such as a managed database, a SaaS administrative console or a cloud load balancer, the organization still needs to show least functionality. Ask the provider for the configuration options it exposes, its shared responsibility documentation and any independent audit evidence it can share. Components where the provider keeps all settings out of reach must be recorded as exceptions with the reason and the compensating review.
How an assessor tests CM-7 least functionality
This table maps the SP 800-53A assessment methods for CM-7 to what the assessor does, the objects they examine, interview or test, and the findings that most often appear. Use it to prepare the documents, people and settings an assessor will ask for, and to check your own readiness before fieldwork.
| Assessment element | What the assessor does | Evidence to have ready | Common findings |
|---|---|---|---|
| Examine: configuration management plan | Reads the plan to confirm it defines how mission-essential capabilities are identified and how prohibited functions, ports, protocols, software and services are handled. | Configuration management plan section on least functionality, with named owners and approval record. | Plan mentions least functionality in general terms but does not define what is prohibited or restricted for each system. |
| Examine: system component inventory | Compares the inventory against the list of enabled services, open ports and installed software to see whether each item has an approved purpose. | Current component inventory linked to a documented list of permitted services, ports and software per component. | Inventory lists components but not their running services, so the assessor cannot match enabled functions to an approved need. |
| Examine: common secure configuration checklists | Checks whether checklists for each component type remove or disable functions that are not needed for the mission. | Hardening checklists or baselines showing disabled services, closed ports and removed features, with the date of last review. | Checklists were adopted from a vendor template and never tailored, so unneeded services remain enabled. |
| Interview: security configuration management personnel | Asks how mission-essential capabilities were defined, who approves exceptions and how the restrictions are kept current after changes. | Named roles, a description of the approval path for exceptions, and examples of recent exception decisions. | Staff describe restrictions from memory, and no one can show who approved a specific exception. |
| Interview: system and network administrators | Asks which services and ports they keep open, why, and how they learn that a new function has been enabled on a system. | Administrator runbooks, configuration review notes and the process used to report newly enabled functions. | Administrators enable services during troubleshooting and do not revert them, so the running state differs from the documented baseline. |
| Test: organizational processes that prohibit or restrict functions, ports, protocols, software and services | Observes the process in action, for example by requesting an exception or introducing a test change, and checks that the restriction is enforced. | Records of a restriction being applied, exception requests with decisions, and the enforcement method in use. | Restrictions exist on paper, but a sample system still runs a prohibited protocol or an unapproved service. |
| Test: periodic review of allowed functions (CM-7(1) where selected) | Checks that the review happens at the defined frequency and that its results led to changes where needed. | Dated review records, the list of functions reviewed, and tickets for any functions removed or retained with justification. | Reviews are scheduled but completed late or without evidence that unneeded functions were removed. |
| Test: allow-listing of software (CM-7(5) where selected) | Attempts to run or install software that is not on the approved list and checks whether the system blocks it or records the attempt. | Allow-list with approval records, enforcement configuration, and logs showing blocked or unapproved execution. | An allow-list was written but never enforced on endpoints, or exceptions were granted without a documented decision. |
How to implement CM-7 in sequence
This sequence turns CM-7 from a policy statement into a working restriction set: defined capabilities, documented restricted functions, a secure configuration checklist, enforced allow-lists, periodic review, and a recorded exception register that an assessor can test.
Define mission-essential capabilities per system type
Start by grouping the system population into types, such as domain controllers, application servers, database hosts, developer workstations and kiosks. For each type, the system owner and the mission or business owner agree in writing which capabilities are essential to the function the system serves. Keep the list short and specific, for example a web tier that serves HTTPS and nothing else. Output: an approved capability list per system type, signed off by the authorizing official or the designated owner. You know it is done when every system in the inventory maps to one type and each type has an owner's approval on file.
Document the functions, ports, protocols, software and services to restrict
For each approved system type, list what must be disabled or blocked: unneeded network ports, protocols, services and daemons, installed software packages, and functions such as remote shells or removable media. Compare the list against the baseline configuration and the component inventory so nothing running on a system is unaccounted for. Output: a restriction register tied to each system type and to the baseline. You know it is done when a sample of live systems shows no listening service or installed package that is absent from both the approved capability list and the restriction register.
Build or adopt the secure configuration checklist
Turn the restriction register into a checklist the team can apply and verify. Many organizations start from a published hardening benchmark and tighten it to match their approved capabilities, while others write their own. Record the source of each setting, the value applied, and the reason for any deviation. The checklist is the common reference that CM-6 and CM-7 both depend on. Output: a versioned secure configuration checklist approved through the configuration change control process. You know it is done when each restriction in the register has a corresponding checklist item with an owner and a verification method.
Enforce restrictions and allow-lists under CM-7(5)
Apply the checklist to build images and live systems, disabling unneeded services and ports and configuring software allow-listing where the organization selects CM-7(5). Allow-listing approves specific software by exception, so anything not on the list is blocked from running or installing. Coordinate with CM-11 and CM-5 so that only authorized roles can change the allow-list. Output: deployed configurations and an authorized software list with its change history. You know it is done when a test installation of unlisted software is blocked and the attempt appears in logs.
Prevent unauthorized program execution under CM-7(2)
Where the organization selects CM-7(2), configure systems so that programs not on the authorized list cannot execute. This is usually implemented through application control or endpoint policy on the host, not through a document. Test the control with a known unauthorized binary on a representative system of each type. Output: an execution control policy per system type and recorded test results. You know it is done when the test binary fails to run and the result is retained with the date, system and tester.
Set up periodic review under CM-7(1)
Schedule a recurring review of enabled functions, ports, protocols, software and services against the approved capability list and the restriction register. The review frequency should be defined in the system's own documentation, and the review should be performed by someone other than the person who administers the system. Automated compliance checks can flag drift between reviews. Output: a review schedule, review records showing what was checked and what changed, and tickets for any findings. You know it is done when the most recent review record matches the current inventory and every finding has an owner and a disposition.
Test restrictions and record exceptions
Test each restriction against the live environment, sampling across system types, and compare the results with the secure configuration checklist. Any restriction that cannot be applied, such as a legacy application that needs a blocked protocol, becomes an exception with a documented business justification, compensating controls, an owner and an approval from the designated authority. Keep the exception register current and link it to the plan of action and milestones where remediation is planned. Output: test results and an exception register. You know it is done when every deviation from the checklist has an approved exception entry, and no entry lacks an owner or an expiration condition.
Evidence that passes a CM-7 assessment
An assessor testing CM-7 looks for proof that the system is limited to defined capabilities and that the limit holds today. The artifacts below connect the documented intent, the approved configuration, the running state and the exceptions that were allowed, so each one should be dated, owned and refreshed on a schedule.
Approved mission-essential capability list
This is the defined set of functions, ports, protocols, software and services each system type is allowed to provide, and it is the baseline every other artifact is measured against. Assessors examine it first because CM-7 begins with the organization defining what is essential. Check that each system type has its own list, that the owner named the business purpose for each item, and that the list was approved by someone who can accept the risk of the remaining capabilities. Illustrative example: a web tier list that permits HTTPS and a single application port but no remote shell service.
Configuration management plan entries
The configuration management plan should state who decides which capabilities are permitted, how restrictions are applied, and how deviations reach the change process. Assessors compare the plan with what the team actually does, so entries that describe a review cadence nobody follows will fail the test. Confirm that the plan references the capability list, names the responsible roles, and was reviewed under the organization's document control process.
Secure configuration checklists
Checklists translate the capability list into concrete settings, such as disabled services, closed ports and removed packages on each platform. They are the reference an assessor uses to verify that the running system matches intent. Record which benchmark or internal hardening standard each checklist is based on, the version used, and the date of the last review. A checklist that does not name the platform version it applies to is hard to defend in an assessment.
Enforced software allow-lists
An allow-list is evidence that the system blocks software outside the approved set, not only that the organization prefers that outcome. Where the system supports allow-by-exception, assessors look for the enforcement policy, the list of permitted executables or packages, and logs of blocked attempts. Confirm the list is generated from the approved baseline and that changes to it go through change control. Ask the platform owner which enforcement points are active on each system type.
Port and service scan results
Scan and policy results show the current state of open ports, running services and installed software compared with the approved list. Assessors use these outputs as independent evidence that the configuration is restricted in practice. Keep dated results for each system, record which findings were confirmed, and show how each deviation was closed or routed to an exception. Confirm which scanner, policy set and credentials were used, because an unauthenticated scan may miss services that are running locally.
Periodic review records with sign-off
CM-7 includes a periodic review of functions, ports, protocols, software and services to identify those that are not needed. Assessors ask for the dated review record, the list of items removed or confirmed, and the named approver who signed off. Keep the review results tied to the capability list so that a removed service is visible as a change. Confirm the review frequency is defined in the organization's own documents, since the review interval is set by the organization.
Exception approvals with expiry dates
When a business need requires a capability outside the approved list, the exception should record the risk accepted, the compensating controls, the approver and an expiry date. Assessors look for open exceptions without an end date, because they quietly become permanent gaps. Review the exception register at each periodic review, confirm that expired items were either removed or re-approved, and check that the running system matches the exception as written.
Open-source tools that produce CM-7 evidence
Wazuh's Security Configuration Assessment (SCA) module scans monitored endpoints against YAML policies. Most shipped policies are based on CIS benchmarks, and teams can add custom policies for their own configuration rules. The scan checks files, directories, registry keys and running processes, then reports which checks pass or fail and recommends remediation. That output supports CM-7 when a defined set of prohibited functions, services or processes is written as checks and run on a schedule.
- Policy coverage: Map each prohibited service, port or process in your CM-7 definition to a specific check, and record which shipped policy or custom policy contains it.
- Custom policies: Write checks for organization-specific restrictions, such as a banned service or an unapproved listening process, and version them under configuration control.
- Scan results: Export pass and fail results per endpoint over time to show periodic review under the enhancement for periodic review.
- Remediation records: Keep the recommended remediation alongside the change ticket that resolved each failed check.
- Scope limits: SCA checks configuration state. It does not, by itself, prove that a network firewall or application allow-list blocks traffic.
Before relying on this tab's evidence, confirm with your own control scope which shipped policies apply to your operating systems and versions, and whether your organization has defined its CM-7 functions, ports, protocols, software and services in a form the checks can test.
Fleet runs policies as osquery queries that ask each device a yes or no question, such as whether a restricted application is installed or a disallowed service is enabled. The policies page shows which devices in each fleet are passing or failing each policy. For CM-7, this gives a device-by-device view of whether the restrictions you defined are present on the endpoints that should follow them, which is useful evidence for the periodic review and software restriction parts of the control.
- Yes or no policies: Phrase each CM-7 restriction as a question with a clear pass condition, so the result can be read without interpretation.
- Fleet grouping: Assign devices to fleets by role or environment so that restrictions for a workstation population and a server population are evaluated separately.
- Pass and fail history: Capture the policies page results at a defined frequency and retain them as periodic review records.
- Failing device follow-up: Link each failing device to a ticket or documented exception, which is the evidence an assessor will ask for next.
- Coverage limits: Fleet reports on the state queries can see. Confirm with the vendor and your own testing which platforms, and which software or service states, your deployment can query.
Before relying on this tab's evidence, check that every restriction your CM-7 definition names can be expressed as a query on your operating systems, and that the policy definitions themselves are under change control.
Greenbone Community Edition runs the OpenVAS Scanner, which executes vulnerability tests from the Greenbone Community Feed against target systems. The feed is updated daily and the scanner is controlled by gvmd over the Open Scanner Protocol. Its results can help confirm which services are reachable on a system, which supports a CM-7 check that unnecessary ports and services are restricted. It is a vulnerability scanner first, so its output is best read as an independent view of exposure rather than proof of configuration.
- Exposed service checks: Run authenticated and unauthenticated scans against defined segments and compare open services with the approved list in your CM-7 definition.
- Scan scheduling: Record scan frequency, target lists and feed update dates so the scan itself can be assessed.
- Finding triage: Route findings for unapproved services to the change or exception process rather than closing them without a record.
- Feed and scope limits: Confirm with the Greenbone documentation which tests the Community Feed includes and which require other editions.
- License obligations: Greenbone Community Edition is licensed under AGPL-3.0-or-later. Confirm with counsel what that license requires where you modify or make the software available to users, before building it into a controlled evidence process.
Before relying on this tab's evidence, define which network segments and hosts are in scope for CM-7 scanning, and confirm that scan credentials and target lists are themselves controlled.
Trivy detects known vulnerabilities (CVEs) in operating system packages and language dependencies. It scans filesystems, Git repositories, virtual machine images and container images. Its strongest contribution is to patch and vulnerability evidence, which supports neighboring controls more than CM-7 restrictions. Use it to show that software in your environment is inventoried and checked for known flaws, not as the main proof that prohibited software is absent.
- Image gates: Scan container and virtual machine images before deployment, and record which images were approved for use in the build pipeline.
- Dependency inventory: Use scan output to show which packages and libraries are present in each approved image or filesystem.
- Known-vulnerability records: Retain scan reports with dates so that remediation of a flagged package can be traced to a change record.
- Restricted package checks: Trivy reports known CVEs. It does not, on its own, enforce a list of prohibited packages, so pair it with a separate policy check if your CM-7 definition restricts specific software.
- Documentation: Confirm current scanner capabilities and supported targets in the Trivy documentation before writing them into an assessment plan.
Before relying on this tab's evidence, decide whether your CM-7 restrictions cover software at all, and if so, which of the other tabs will test that restriction directly.
What meeting CM-7 costs in money and effort
This table lists the cost lines behind meeting CM-7 Least functionality, who is paid for each, and whether it recurs. NIST publishes no cost estimates, so every line should be confirmed in a written quote. The main takeaway is that the supplied open-source tools can keep license spend low, while hosting, capability definition and ongoing review remain the larger effort.
| Cost component | One-time or recurring | What drives it up | What keeps it down |
|---|---|---|---|
| Tooling and licenses | Recurring for hosting, one-time for setup | Number of system types needing separate policies, and any commercial add-ons chosen alongside the open-source tools | Self-hosted open-source scanners and policy engines; confirm each tool's license terms with its vendor |
| Hosting and infrastructure for scanners | Recurring | Number of endpoints, servers and images scanned, and scan frequency | Scoping scans to in-scope systems and tuning schedules to the review cycle |
| Engineering time to define capability lists | One-time, then updated on change | Number of mission-essential functions, ports, protocols and services to justify per system | Reusing a common secure configuration for similar system types and documenting only deviations |
| Building allow-lists and prohibited software lists (CM-7(5)) | One-time build, recurring maintenance | Number of software packages in scope and how often software changes | Limiting allow-lists to the moderate and high baselines where CM-7(5) applies, and automating updates |
| Evidence upkeep and periodic review (CM-7(1)) | Recurring | Review frequency set by the organization, number of systems and manual evidence steps | Exporting scanner results and policy pass or fail reports on a fixed schedule with stored records |
| External hardening or testing review | Recurring or per engagement | Legacy systems, third-party managed services and the depth of testing requested | Fixed-scope review agreed in writing before work starts, focused on in-scope components |
| Auditor sampling and assessment support | Recurring with each assessment cycle | Number of systems sampled, the assessment objects examined and the level of documentation requested | Keeping the configuration management plan, component inventory and secure configuration checklists current before the assessment |
| Third-party managed services | Recurring | Services that the organization does not control and must still evidence against CM-7 | Contract clauses that require the provider to supply configuration and port evidence |
Where CM-7 programs usually fall short and how to close the gap
CM-7 programs rarely fail because the principle is unclear. They fail because the list of mission-essential capabilities was never written down, restrictions drift after the first hardening pass, and exceptions and reviews are not tracked. The cards below cover the gaps assessors most often find and a closing action for each.
Mission-essential list never written down
CM-7 requires the organization to define the capabilities a system needs to perform its mission, and everything else is a candidate for removal. Many teams start from a vendor default image and disable only what they notice. Write the list per system role, covering functions, ports, protocols, software and services, and have the system owner approve it. Then compare the running system against that list. Anything running but not listed is either an undocumented dependency or an unnecessary function that needs a decision.
Restrictions applied once and drifted
Hardening done during deployment is often never checked again. Package updates, new agents and manual troubleshooting re-enable services and open ports. Assessors test whether the restrictions still hold, not whether they once held. Run a scheduled configuration assessment against the documented baseline, for example with Wazuh Security Configuration Assessment, and route failed checks into the change process. Confirm the policies cover your actual operating systems, since shipped content is mostly based on CIS benchmarks and may need custom policies.
Allow-lists exist without enforcement
CM-7(5) asks for software to be authorized and for unlisted software to be prevented from running, which is the allow-by-exception model. Many organizations keep an approved software list in a spreadsheet while endpoints run anything. The list is documentation only until an execution control enforces it. Confirm which mechanism blocks unapproved programs on each platform, whether application control, host policy or container runtime rules, and test it by attempting to run an unlisted program. Record the test result as evidence of enforcement, not just of the list.
Exceptions have no owner or expiry
Every deviation from the least functionality baseline, such as a port left open for a legacy integration, needs a named owner, a documented business reason and a review date. Without these, temporary exceptions become permanent and assessors cannot tell approved deviations from drift. Keep an exception register linked to the configuration baseline and the change record that approved it. Ask each owner to confirm the exception is still needed at its review date, and remove the exception when the dependency ends.
Periodic review is calendar-only
CM-7(1) requires the organization to review functions, ports, protocols, software and services at a defined frequency and to disable or remove what is not needed. Many programs hold a recurring meeting but keep no record of what was reviewed, what was found or what changed. Make the review produce evidence: a dated export of running services, listening ports and installed software compared with the approved list, signed off by the reviewer, with each deviation opened as a tracked item. Scanner results from tools such as Greenbone Community Edition can show exposed services during the same review.
Cloud and container images differ from baseline
A hardened golden image can be bypassed when teams pull a public base image, add a package during build or launch instances from a template that was never updated. The running workload then differs from the documented baseline even though the baseline itself is correct. Scan container images and filesystems for vulnerable packages and compare the built image's packages and exposed ports with the approved list before deployment. Trivy can scan images, filesystems and VM images in the build pipeline, so drift is caught before a workload reaches production.
Who does what for CM-7: your team, a partner and the auditor
Your organization owns CM-7. The control asks you to define which capabilities a system needs to perform its mission and which functions, ports, protocols, software and services must be prohibited or restricted. Those decisions depend on your business context, risk appetite and system owners, so an outside partner cannot make them for you. Your team also approves exceptions and runs the periodic review that the control enhancement CM-7(1) describes.
- Mission-essential definitions: Document, per system, the capabilities that are required and who signed off on them.
- Prohibited and restricted lists: Decide which functions, ports, protocols, software and services are blocked, and record the reason for each.
- Exception approval: Name the role that approves deviations and keep the approval records with a review date.
- Periodic review: Schedule the review at a frequency you set, compare the running state with the approved definitions and track the findings to closure.
- Allow-list ownership: Assign an owner for software allow-lists tied to CM-7(5) in moderate and high baselines.
Before you engage anyone, confirm that these owners exist, that the approval chain is written down and that the review cycle appears in your configuration management plan.
An implementation partner such as DeployOpen can prepare the self-hosted tooling and the evidence around CM-7 inside your own infrastructure. This work is usually outsourced as a build-out because it requires engineering time to deploy scanners, write checks and wire up reporting. The partner does not decide what your system needs, and it does not approve exceptions or attest that the control works. Those remain with your team and the auditor.
- Tooling preparation: Deploy and harden the self-hosted tools that check configuration state, such as Wazuh, Fleet and Greenbone Community Edition, in your environment.
- Checklists and allow-lists: Build the checklists and allow-lists from the definitions your team approves, and keep them under version control.
- Scanning and policy evidence: Configure scans and policy queries so that results show which devices pass or fail each rule.
- Documentation: Write runbooks that show how the evidence is produced, who reviews it and how findings are handled.
- Handover: Transfer administrative access, configuration and documentation so your team can run the control after the build-out ends.
Ask any partner to state in writing which items it delivers and which items remain your responsibility, and confirm that it will not issue assessment conclusions on your behalf.
An independent assessor tests CM-7 against the assessment procedures in SP 800-53A, which include examining the configuration management plan, the component inventory and common secure configuration checklists, interviewing administrators and testing whether the prohibitions work. Only an independent auditor, assessor or certification body can issue a report or certificate. Because that party must remain independent of the people who built the controls, a partner cannot sign off on the outcome, even when it did the implementation work.
- Examination: The assessor reviews the documents and checklists your team approved and checks that they match the system.
- Interviews: The assessor speaks with the people who define, approve and administer restrictions.
- Testing: The assessor attempts to run prohibited software, use blocked ports or reach disallowed services and records the results.
- Findings and reporting: The assessor documents deficiencies, which you then track in your plan of action and milestones.
- Independence boundary: The partner's evidence is an input to the assessment, not a substitute for it.
Before the assessment, confirm which assessor your sponsor or contract accepts, agree the scope in writing and make sure the evidence your partner produced is easy for that assessor to inspect.
Common questions about CM-7 cost, effort and whether to hire help
How much effort does CM-7 least functionality take?
The effort depends mostly on how many system types you run, how many functions, ports, protocols, software and services each one exposes, and how well your existing configuration baselines already document them. No researched figure for hours or cost is available for CM-7, so ask your team or a partner to size it from your own inventory. The main work is defining the mission-essential capabilities for each system, removing or restricting everything else, and then keeping that definition current. Large, heterogeneous estates with little existing documentation take the longest, while a small set of well-documented systems takes less. Ask for the effort estimate to be broken down by system type.
Can we meet CM-7 in-house with open-source tools?
Often yes, if your team has the skills to run the tools and the ownership to act on their results. Wazuh Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation. Fleet policies ask devices yes or no questions through osquery, showing which devices pass or fail. Greenbone Community Edition and Trivy help find vulnerable or exposed services and software. Tools produce evidence, but they do not decide which functions are mission-essential. That decision, and the documented exceptions, must come from your organization. Confirm each tool's current capabilities against its documentation before you rely on it.
What does CM-7 need from our own team?
CM-7 needs people who know what each system is for, which is the basis for deciding what is mission-essential. It also needs system and network administrators who can apply restrictions, security configuration management staff who maintain the baselines, and an approver for exceptions. The control is assessed through interviews with these roles, so they must be able to explain the decisions. Your team also owns the review cycle, the software allow-listing decisions where your baseline requires them, and the records that show each review happened. An implementation partner can prepare systems and evidence, but the organization must own the control and its exceptions.
Is CM-7 required at the privacy baseline?
No. According to NIST's SP 800-53B Release 5.2.0 profiles, CM-7 is selected for the low, moderate and high security control baselines but not for the privacy baseline. This matters if your only scope is a privacy baseline. Check your system's selected baseline and any tailoring or overlays before you assume CM-7 is out of scope, because a higher baseline or an agreement with a customer may still require it. Confirm the selection with your authorizing official or contract owner.
How long does CM-7 take, and why doesn't NIST set a timeline?
NIST does not set implementation timelines. Its risk management FAQ says those are left to OMB Circular A-130, and NIST does not estimate compliance costs or durations. Your timeline depends on the number of systems in scope, how mature your configuration management already is, and how many exceptions need approval. Your assessor and authorizing body set the evidence expectations that drive the schedule. Ask any partner for a timeline tied to a written scope, with the systems, phases and review points named, rather than a generic duration.
What should we ask a partner to include in a written quote?
Ask for a written scope that lists the systems, the baseline and enhancements in scope, and the deliverables. The quote should separate one-time work, such as defining mission-essential capabilities and building restrictions, from recurring work, such as periodic review, tool upkeep and evidence refresh. Ask which assessment methods and evidence the partner will prepare for examine, interview and test activities. Confirm who owns each exception decision, what is excluded, and how changes to scope are priced. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen works on this
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so CM-7 least functionality is set and evidenced where the systems actually run. The organization owns its controls, DeployOpen prepares the systems and evidence, and an independent assessor reaches the conclusions.
How we scope
- Agree in writing which systems, components and enclaves fall under the CM-7 scope before work starts.
- Record the mission-essential capabilities the organization defines, along with the functions, ports, protocols, software and services to be restricted.
- Confirm which SP 800-53B baseline applies, since CM-7 enhancements CM-7(1), CM-7(2) and CM-7(5) appear in moderate and high baselines.
How we build
- Harden each platform to a documented minimal service set, disabling unneeded ports, protocols and daemons on the systems in scope.
- Configure allow-listing for software and program execution where the organization has approved the permitted applications.
- Set up scheduled configuration checks, such as Wazuh policies or Fleet queries, that report deviations from the defined least functionality settings.
How we hand over
- Deliver the written configuration baseline, restricted function list and allow-list with the owner, approval record and review date for each item.
- Provide scan and policy result exports that show the settings tested against the six CM-7 determination statements in SP 800-53A.
- Document the periodic review procedure so the organization's staff can repeat the checks and answer an assessor's examine and interview questions.
How we support
- Offer ongoing support and continuous testing as a retainer after handover, covering changes to the least functionality settings.
- Re-run checks after upgrades or new components are added, and update the restricted function list through the organization's change control.
- Confirm with your independent assessor which evidence formats and review cadence they will accept before the first assessment.
