03.04.06 Least functionality: requirements and evidence

What 03.04.06 least functionality asks for and why it is hard

A compliance lead preparing for an assessment of a CUI system needs to show that the system runs only what its mission requires. 03.04.06 Least functionality asks the organization to configure the system to provide mission-essential capabilities only, to prohibit or restrict defined functions, ports, protocols, connections and services, and to review the system at a defined frequency for unnecessary or nonsecure ones and remove or disable them. The requirement is about subtraction: the default state of a system is rarely the state that the mission needs, and the gap between the two is where exposure sits.

The risk is straightforward. Every enabled service, open port, unused protocol, installed feature and standing network connection adds something an attacker can probe, exploit or use to move sideways toward systems holding CUI. Many of these items are left over from installation defaults, vendor bundles or past projects, and nobody remembers why they are running. Reducing them shrinks the attack surface, but it also requires someone to know what each item is for, which is why the work is slower than it looks on a whiteboard.

The difficulty comes from the fact that NIST does not decide the answers for you. The requirement carries six organization-defined parameters: the functions, ports, protocols, connections and services to be prohibited or restricted, and the frequency of the review. Your organization must set those values and document them in a way an assessor can test. Rev. 3 also folded Rev. 2's 3.4.7 into this requirement, so the restriction work that once sat in a separate item now has to be covered here. If you are working from a CMMC Level 2 scope, confirm with your assessor how the Rev. 2 wording maps to these parameters before you write the policy.

Which systems, teams and third parties fall under least functionality

Least functionality applies to every component inside the CUI boundary, but the boundary is only as clear as the system security plan that defines it. The cards below cover the component classes, owning teams and external services that determine how much configuration review 03.04.06 requires, and where the six organization-defined parameters must be set.

Servers and workloads in the boundary

Every server that stores, processes or transmits CUI, and every service that supports it, falls under 03.04.06. Review each host for running services, listening ports and enabled protocols, then compare them against the functions and services the system needs to carry out its mission. Record which ports and services are permitted in the system security plan so that the ODP values for functions, ports, protocols and services have a concrete list to reference. Confirm with the system owner whether administrative services such as remote management are considered essential.

Endpoints that handle CUI

Laptops, desktops and mobile devices that access CUI are in scope when they are part of the system, even if the organization does not own every device. Browser extensions, removable media support, and unneeded local services are common sources of nonessential functions on endpoints. Ask the endpoint team to show which configuration checks run on each device class and how failing devices are reported, so the review frequency ODP has an observable basis.

Network devices and boundary controls

Firewalls, routers, switches and VPN gateways enforce which connections and protocols the system accepts. Least functionality for these devices covers unused management protocols, default services, and connections that no approved data flow requires. Document the connections each boundary device must permit, because the ODP for connections is usually set by reference to the approved data flows in the system security plan. Confirm with the network team how changes to these rules are reviewed.

Cloud workloads and container images

Cloud accounts, virtual machines and container images that process CUI often start from vendor or community templates containing services the workload never uses. Review base images and instance configurations before deployment, and check that any open security group rules trace to an approved connection. Vulnerability scanners and image scanners can help identify unnecessary packages, but they do not decide which functions are essential, so the review still needs a documented owner.

Teams that own configuration

03.04.06 touches several teams: platform engineering owns the hardening, security operations reviews the findings, IT operations removes services from endpoints, and the application owners justify which functions are mission-essential. Assign one accountable owner for the least functionality review and write down the handoffs. Without that assignment, a service removed by one team may be re-enabled by another during a routine rebuild.

Vendor-managed and external services

Software-as-a-service tools, managed hosting and outsourced help desks may run functions on the organization's behalf. The organization still needs to show that these services are restricted to the functions and connections it approved, even when the provider controls the underlying system. Obtain the provider's configuration documentation or contract terms that describe enabled features, and confirm with the provider which functions the organization can disable. Where the provider cannot restrict a function, record it as a known exception in the system security plan.

How an assessor tests least functionality under SP 800-171A

This table maps each part of the 03.04.06 assessment under SP 800-171A Rev. 3 to the method, the example objects an assessor examines, interviews or tests, and the evidence to prepare. Read it as a checklist: the determination statements and ODP checks decide what must exist, and the evidence column shows what a reviewer will ask to see.

Assessment element	What the assessor does	Evidence to prepare
Determination statements (8)	Confirms each of the eight statements is met, covering the mission-essential configuration, the prohibited or restricted items, the review and the removal of unnecessary or nonsecure items.	A documented least-functionality configuration and a record that each statement has been addressed for the system in scope.
ODP value checks (6)	Confirms the organization has defined values for the functions, ports, protocols, connections, services and the review frequency. An undefined value fails the check even when the technical control is in place.	A dated parameter list in the configuration management plan or procedures, with the values approved by the accountable owner.
Examine: policy and procedures	Reads the configuration management policy and the procedures for least functionality to confirm they cover prohibiting, restricting, reviewing and removing items.	Current signed policy, procedure documents with version and review dates, and a mapping from each procedure step to 03.04.06.
Examine: configuration management plan	Checks that the plan describes how least functionality is applied and maintained across the system.	A plan section describing the baseline of allowed services, ports and protocols and who maintains it.
Interview: configuration and review personnel	Asks the people who configure and review the system how they decide what to disable and how reviews are carried out.	Named role assignments and staff able to explain the review cycle, the approval path and recent removals.
Interview: personnel reviewing functions and services	Asks reviewers to describe the review frequency, the tools used and how findings reach remediation.	Review schedule, reviewer sign-off records and tickets showing findings were acted on.
Test: prohibit or restrict processes	Observes that the system actually blocks or restricts the defined functions, ports, protocols, connections and services.	Configuration exports, scan or policy results and a demonstration of a disabled service or blocked port.
Common finding: undefined ODP values	Assessors often find the review frequency or the list of prohibited items was never set, so the requirement cannot be fully met.	Fill every ODP and confirm the values are approved and visible in the plan.
Common finding: reviews without records	Reviews may happen informally, leaving no dated output for the assessor to examine.	Keep dated review reports, scan outputs and remediation tickets for each review cycle.

How to implement least functionality in order

This sequence turns 03.04.06 into a working configuration: defined parameters, an inventory of what the system actually runs, a configuration that removes everything outside mission-essential use, documented exceptions, and a recurring review that proves the reduction holds over time.

Set the six organization-defined parameters per system class
Before any configuration work, the organization defines the six ODP values for 03.04.06: the functions, ports, protocols, connections and services to prohibit or restrict, and how often the system is reviewed for unnecessary or nonsecure ones. Because NIST does not assign ODP values, and a nonfederal organization must assign them when the federal agency does not, the owner of the system security plan should set them, and the contracting agency should be asked whether it has specified any. Define them per system class (for example, enclave servers, engineering workstations and remote endpoints) so each class has its own parameter set. The output is a signed parameter set tied to the system security plan. The step is done when every ODP has a value and an approver is recorded.
Build the service, port and protocol inventory
Using the baseline configuration and a live scan of each system class, list every running service, listening port, enabled protocol, active network connection type and installed function that the system exposes. Compare what is found against the baseline so that undocumented items stand out. Scanning tools such as Greenbone Community Edition can show open ports and services on target systems, and Fleet can query devices for installed software and running state, but the team should confirm what each tool reports for its own environment before relying on it. The output is a service and port inventory for each system class, reconciled to the baseline. The step is done when every item has either a business owner or is flagged for removal.
Define the mission-essential capability list
Working from the baseline configuration, the system security plan and the business purpose of each system class, the team writes down the capabilities the system must provide and nothing more. Each entry should name the function, the port or protocol it needs, the connection it uses and the business owner who depends on it. Anything the list cannot justify is a candidate for restriction. Security and operations staff should both review the list, because removing a dependency that nobody documented is a common cause of outages. The output is an approved mission-essential capability list. The step is done when the list is approved and each item traces to a system security plan entry.
Configure the system to allow only listed capabilities
Engineers disable or restrict every function, service, port, protocol and connection that is not on the approved list. Where the platform supports it, this is done through configuration management (for example, disabling unused services in the baseline image, closing listening ports at the host firewall and removing unused protocols from the network profile), and changes go through the change control process already defined for the system. Deny-by-default rules are usually easier to audit than long lists of exceptions. The output is a configuration record showing each disabled or restricted item, the change ticket and the person who approved it. The step is done when the rebuilt baseline matches the approved list and a fresh inventory shows nothing outside it.
Document approved exceptions in an exception register
Some items cannot be removed because a business process depends on them. Each exception should be recorded with the function, port, protocol, connection or service involved, the business justification, the compensating measures, the risk owner who accepted it and the date of the next review. The register is a living record, so exceptions that lapse must be removed from it. Auditors commonly ask how an exception was approved and whether it is still needed, so the register should link to the change tickets and the system security plan. The output is an exception register. The step is done when every item that remains enabled outside the baseline has a documented, approved entry.
Schedule the review at the defined frequency
The organization sets a recurring review of each system class for unnecessary or nonsecure functions, ports, protocols, connections and services, using the frequency it defined in the ODPs. The review can combine automated checks (such as configuration assessments against a hardening benchmark, and scheduled osquery-based policy checks that show which devices pass or fail a rule) with a human review of the exception register. Automated results should be reviewed by someone who can decide, not simply exported. The output is a review calendar and a runbook for each system class. The step is done when the schedule is approved and the first review date is set.
Run the review and record findings
On the scheduled date, the reviewer compares the current system against the approved baseline, the mission-essential capability list and the exception register. Each finding is classified as an unauthorized item, an expired exception, a new capability that needs an owner or a drift from the baseline. Vulnerability scanning of the system's software, using a tool such as Trivy for images and packages, can be added to show whether any retained service carries known vulnerabilities. The output is a review report with each finding and its owner. The step is done when every finding has a disposition.
Remove or justify each finding and retain the record
Each finding is either removed through the change control process, justified and added to the exception register, or escalated if it reveals an unauthorized change. Removals are verified by re-running the inventory and the configuration check, so the evidence shows the change took effect. The review report, the updated inventory, the exception register and the change tickets together form the evidence set for 03.04.06 that assessors examine and interview staff about. The step is done when the post-change inventory matches the approved list and the records are retained where the assessor can access them. Confirm the retention period with the contracting agency and the assessor, because the requirement does not set one in the supplied facts.

Evidence that passes a least functionality assessment

An assessor testing 03.04.06 looks for a defined set of allowed capabilities, a record of what was disabled or closed, and proof that the list is reviewed on schedule. The cards below connect the policy decisions in the ODP values to the configuration records, exceptions and review outputs that show those decisions were carried out.

Approved ODP values

The six organization-defined parameters for 03.04.06 set which functions, ports, protocols, connections and services are prohibited or restricted, and how often the system is reviewed. Each value must be written down and approved by the people who own the system. Assessors check that every value is defined, because the determination statements that test ODP values are assessed separately. Keep the approval record dated and link it to the system security plan so changes to a value trigger a documented review.

Mission-essential capability list

This document names the capabilities each system needs to perform its mission, and everything outside that list is a candidate for removal. Build it from the system's function, data flows and documented business purpose, not from what happens to be installed. Assessors interview the people who maintain the list, so record its owner and the date it was last confirmed. Update it when the mission of a system changes.

Hardening records showing closed ports

Configuration records show which services were disabled, which ports were closed and which protocols were blocked, with the setting or command used to do it. Export these from the configuration management tool or the baseline itself so the record reflects the running state. Compare the records against the approved ODP values and flag any disabled item that is still listed as allowed. Keep dated snapshots so you can show the state at the time of assessment.

Exception register with approvals

Some systems must keep a function or port that the baseline would otherwise restrict. Each exception needs a stated business reason, the compensating measures, the named approver and a review date. Without a register, an assessor cannot tell a deliberate exception from an overlooked service. Remove an exception when its reason ends, and record that removal too.

Scheduled review reports

Reports from scheduled reviews show what was found, what was judged unnecessary or nonsecure and what was removed. Automated scans can produce these, but the report should also name the reviewer and the disposition of each finding. Assessors look for evidence that the review ran at the frequency set in the ODP values, not only that a tool was configured. Keep each report with its date so the review cycle is provable.

Change records linking new services

Every new service, port or function added through change control should trigger a least functionality review before it goes live. Link the review output to the change ticket that introduced the item so the assessor can trace the decision from request to removal or approval. This linkage is what keeps the evidence current between audits, because it shows the review happens as part of normal change work. Check that the ticket references the exception register when an item is approved to stay.

What meeting least functionality costs in money and effort

This table breaks the cost of meeting 03.04.06 into components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none were researched, so use the table to build the questions you put into a written scope and quote. The main takeaway is that most of the recurring cost comes from review frequency, the number of system classes and the exceptions you must document.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Tooling and licenses	Software vendors or none if self-hosted open source	Recurring if commercial, otherwise minimal	Commercial endpoint or scanning licenses rise with device count; open-source tools such as Wazuh, Fleet or Greenbone can remove license spend but still need hosting and staff time
Defining the six ODP values	Your staff, with an implementation partner if scoped	One-time, revisited on change	Number of system classes and how many functions, ports, protocols, connections and services need a documented decision
Configuring systems to allow only mission-essential capabilities	Internal engineers or an implementation partner under a fixed-scope agreement	One-time per system class, then recurring for new builds	Legacy services and undocumented ports increase effort; standard baselines reduce it
Automated discovery and policy checks	Internal platform team or implementation partner	One-time setup, recurring tuning	Number of endpoints, policy count and how often checks must run to meet your review frequency
Recurring reviews and evidence upkeep	Your compliance and operations staff	Recurring at the review frequency you define	Review frequency, number of exceptions, and whether evidence is generated automatically or collected by hand
External testing or independent review	Security testing firm or consultant, if you buy it	Usually periodic	Scope of system boundary, depth of configuration testing, and whether results are reused for other assessments
Assessor sampling time	Independent assessor or certification body, paid by you	Recurring at each assessment cycle	How many systems and exceptions the assessor samples, and how complete your procedures and records are before assessment

Open-source tools that produce least functionality evidence

Least functionality is proven by showing which functions, ports, protocols, connections and services were restricted and that unnecessary ones were removed after review. The tools below can each produce a piece of that record, but none of them defines the mission-essential baseline. The organization owns that decision and must document it in its configuration management plan.

Wazuh configuration assessment checks

Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and checks files, directories, registry keys and running processes. Its findings show where a system exposes settings or running components the organization did not intend to allow, and it recommends remediation. Custom policies can encode the organization's own list of prohibited functions. The license is GPL-2.0-only, so confirm how distribution and modification affect your deployment. Confirm that the shipped policies match your operating systems and your defined baseline before treating a pass as evidence.

Fleet policies for device checks

Fleet policies are yes or no questions asked of devices as osquery queries, such as whether a prohibited service is running or a disallowed feature is enabled. The policies page shows which devices in each fleet pass or fail, which gives a per-device record over time. Fleet is licensed under MIT. Write each policy to mirror a specific prohibited function or service in your documented list, and confirm that osquery can see the item you are checking on each platform you run.

Greenbone scans for open services

Greenbone Community Edition runs the OpenVAS Scanner against target systems using the daily updated Greenbone Community Feed. Its vulnerability tests can reveal listening services and open ports that should not be reachable, which supports the review step of 03.04.06. Because the scanner reports vulnerabilities rather than your approved service list, you must compare its results against that list yourself. The license is AGPL-3.0-or-later, so confirm the obligations that apply if you modify and provide the software to others.

Trivy package and image findings

Trivy detects known vulnerabilities (CVEs) in OS packages and language dependencies across filesystems, Git repositories, virtual machine images and container images. It helps show that unnecessary packages or libraries are identified and tracked, particularly in images built for a defined purpose. Trivy is licensed under Apache-2.0. It reports known vulnerabilities, not whether a package is needed, so pair its output with your review of which components the system requires. Confirm which image and filesystem types your pipeline scans.

Who owns least functionality: your team, a partner and the auditor

Your organization owns requirement 03.04.06 in full. The system owner must decide which functions, ports, protocols, connections and services the system needs to carry out its mission, and must record those decisions in the system security plan and configuration management documentation. The organization also sets the six organization-defined parameters, which NIST leaves to the agency or the nonfederal organization to assign, and it approves any exceptions. Someone on your staff must run the periodic review and act on what it finds.

Mission-essential list: Document which capabilities the system must provide and why, then treat anything outside that list as a candidate for removal.
Parameter decisions: Set and record values for the functions, ports, protocols, connections, services and review frequency. Confirm with your contracting officer whether the agency has already assigned values.
Approvals and exceptions: Name who may approve a restricted function that operations need, and keep the approval record with the change.
The review itself: Staff must perform and sign the recurring review, including checking results from scanners and configuration tools against the approved list.
Remediation tracking: Track each unnecessary or nonsecure item to disablement or removal, or to a documented, approved exception.

Confirm that the named owner for each decision can show the approval record during an assessment.

Where least functionality assessments usually fail

Assessors test 03.04.06 by examining written procedures, interviewing the people who review functions and services, and testing whether prohibited items are actually blocked. Most failures trace back to decisions that were never written down, owned or repeated. The cards below cover the gaps we see most often and the fix for each.

ODP values left undefined

Rev. 3 requires the organization to define six organization-defined parameters for 03.04.06: the functions, ports, protocols, connections and services to prohibit or restrict, and how often the system is reviewed. NIST does not assign these values, and if the federal agency does not specify them, the organization must. Assessors check that each value is defined, so a blank or default placeholder fails the determination statements that test the parameters. Confirm each value is written into the system security plan with an owner and a review date.

Mission-essential list kept in memory

The requirement asks the system to provide only mission-essential capabilities, which means the organization must be able to state what those capabilities are. When the list exists only in the heads of a few administrators, interviews with personnel responsible for functions, ports, protocols and services produce inconsistent answers. Write the list per system role, such as the web tier, database tier or engineering workstation, and tie each entry to a business purpose. Keep it under configuration management so changes go through the same control as the baseline.

Reviews without written records

The organization must review the system at the frequency it defined for unnecessary or nonsecure functions, ports, protocols, connections and services, then disable or remove what it finds. Assessors look for evidence that the review happened on schedule and produced decisions. A scan run that nobody reviewed, or a review with no dated output, shows the process exists only on paper. Keep a dated record for each review that lists the items found, the action taken and the person who approved it. Wazuh configuration assessment or Fleet policy results can support this record when they are retained and reviewed.

Exceptions approved informally

Business owners often need a port, protocol or service that the mission-essential list does not include. When that exception is granted by email or verbal agreement, it has no approver, no justification and no end date, so it outlives the project that needed it. Require a written request, a named approver and an expiry date for every exception, and record it in the same place as the review results. During assessment, ask staff to show the exception register and pick one entry to trace back to its approval.

Services re-enabled by updates and images

Operating system updates, vendor packages and new container or virtual machine images can turn on services that the organization previously disabled. Each new image or patch cycle can therefore reopen a gap that the last review closed. Treat changes to default services as configuration changes under 03.04.03 and check the images used to build systems against the hardening baseline before they are deployed. Trivy can scan container and virtual machine images for known vulnerabilities, which helps catch unexpected packages during the build process.

CUI boundary components left out

Reviews often cover servers and workstations but skip firewalls, VPN concentrators, jump hosts, remote access gateways, logging collectors and cloud management planes. These components sit at the edge of the CUI environment and frequently run the most services, so leaving them out undermines the whole review. Include every component within the system security plan boundary in the review scope and document the reason for any exclusion. Confirm the scope with the assessor before the review cycle begins.

Least functionality questions buyers ask before hiring help

How much effort does least functionality take compared with other configuration requirements?

Least functionality is usually a moderate task within the configuration management family, and its size depends on how many services, ports, protocols and connections your systems expose today. SP 800-171A Rev. 3 assesses 03.04.06 with eight determination statements, plus six that check the organization-defined parameters are defined, which shows what an assessor will look for. Compared with 03.04.02 configuration settings, which covers every hardening parameter in the baseline, most of the effort sits in the first inventory, the decisions about what stays enabled, and the review cycle that keeps the result current. Ask any provider to size the work by system count, service count and the number of parameter decisions.

Can we implement 03.04.06 in-house without an outside partner?

Yes. The organization owns its controls, so an internal team can implement 03.04.06 without outside help, and many do. The work is configuration and documentation on systems you already run: decide which functions, ports, protocols, connections and services each system needs, disable or remove the rest, document the six parameter values, and set the review frequency. An implementation partner can prepare systems, configuration evidence and the review process, but it does not decide your mission needs and does not issue any assessment result. Only an independent assessor or certification body issues that outcome. Outside help makes the most sense when the internal team lacks time or when several enclaves need the same design.

What does least functionality require from our internal team?

The work needs people who know each system well enough to say which services it must keep. Expect to involve:

A configuration management owner who holds the baseline and approves changes.
System administrators who can list running services, open ports and enabled protocols on each host.
Security staff who set the six parameter values and the review cadence.
Network staff who document allowed connections and boundary rules.
Business owners who confirm which functions are mission-essential.

SP 800-171A Rev. 3 expects an assessor to interview personnel with configuration management responsibilities and those who review functions, ports, protocols and services, so name these roles and make sure they can explain each decision.

How long does least functionality implementation take?

Duration depends on scope: how many systems and enclaves sit inside the boundary, how many services each one runs, how much current documentation exists, and how many change approvals the review cycle needs. DeployOpen does not publish a timeline for this requirement. Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask any provider for the systems covered, the list of deliverables, which parameter decisions are included, who approves the final settings, and who performs the first review. Also ask how evidence will be kept for the assessor.

Can 03.04.06 go on a POA&M in a CMMC assessment?

No, not for Conditional status. Under 32 CFR 170.21, CMMC does not allow 03.04.06 on a plan of action and milestones for Conditional status. CMMC Level 2 still uses the Rev. 2 requirements and assesses this practice as CM.L2-3.4.6, worth 5 points under the scoring methodology in 32 CFR 170.24. Because DoD guidance on Rev. 2 and Rev. 3 is changing, confirm which version the contract cites and how the current rule applies to your assessment with your contracting officer and your assessor before you plan the work.

How does least functionality differ from 03.04.02 settings and 03.04.08 allowlisting?

03.04.02 asks you to set the most restrictive configuration values consistent with operations and to document any deviations. 03.04.08 asks you to control which software may run, using a deny-all, allow-by-exception policy. 03.04.06 asks which capabilities exist at all:

03.04.02 covers configuration parameters and options.
03.04.08 covers which programs are permitted to execute.
03.04.06 covers which functions, ports, protocols, connections and services are enabled, and removes the unnecessary ones on a defined review schedule.

Overlap is normal, since disabling a service also changes a setting. Map each finding to one primary requirement so the evidence is clear to the assessor.

Who is responsible for implementing least functionality under NIST's FAQ?

NIST's FAQ says the application and implementation of SP 800-171, and any compliance issues, are the responsibility of the federal agency that holds the contract or agreement with the nonfederal organization, regardless of the organization's size. For 03.04.06, the agency decides how compliance is confirmed under its contract, while your organization still has to configure its own systems. Confirm with the contracting officer which version and which parameter values apply. A FAR overhaul proposed rule would have contractors use parameter values published by the DoW CIO, and that rule was not final as of October 2026.

Which open-source tools can produce evidence for least functionality?

Wazuh's Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, mostly based on CIS benchmarks and extendable with custom checks for files, directories, registry keys and running processes. Fleet policies ask devices yes or no questions as osquery queries, and the policies page shows which devices pass or fail, which helps confirm that an unneeded service is absent. Greenbone Community Edition and Trivy find vulnerabilities in services and packages, so they support the review for nonsecure components but do not show which functions are mission-essential. Confirm each tool's coverage on your own platforms before relying on it as evidence.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares the least functionality configuration and its evidence for your assessment. DeployOpen does not issue assessment results; your assessor determines whether the requirement is met.

How we scope

Engagements are fixed-scope, with the systems, ports, protocols and services in boundary agreed in writing before work starts.
The written scope names the six organization-defined parameter values for 03.04.06, or records the decisions you must make for each.
Scope lists the review frequency for unnecessary or nonsecure functions and the owner who approves each review result.
Ongoing support for periodic reviews is available as a retainer, scoped separately from the initial implementation.

How we build

We reduce each in-scope system to its mission-essential services, ports and protocols and document each removal and its reason.
We configure deny-by-default restrictions on functions, connections and services, using your approved ODP values as the rule set.
We run configuration assessment and vulnerability scans against in-scope systems to find unnecessary or nonsecure services for review.
We record exceptions and their approvals so each retained service has a documented business justification and an owner.

How we hand over

You receive the least functionality procedure, the configuration records, and the review schedule mapped to the 03.04.06 determination statements.
Evidence packages include baseline configuration exports, scan results, and change records showing removals and approved exceptions.
We walk your assessment team through where each piece of evidence sits, so your staff can answer examine and interview questions.
Your organization owns the controls and signs the system security plan. We do not issue reports, attestations or certifications.

How we support

Recurring reviews of functions, ports, protocols, connections and services follow the frequency your organization sets.
Changes to the system, such as new services or software, are checked against the least functionality rules before they go live.
Upgrades and hardening updates are applied and documented so the configuration record stays current with the system.
Continuous testing and retainer support are available if you want an outside party to re-check the configuration between assessments.