“Perform maintenance on organizational systems only with approved and controlled tools, techniques, mechanisms, and personnel.” — NIST SP 800-171 Rev. 2, 3.7.5
Of all the controls in NIST SP 800-171, few test the trust between an organization and its providers quite like 3.7.5.
Maintenance seems simple—your IT team or service provider updates systems, installs patches, and keeps things running smoothly. But from a compliance perspective, maintenance introduces serious risk. Each time someone logs in remotely or installs software, that’s a potential doorway into your environment.
Control 3.7.5 requires that all maintenance activities are performed only with approved and controlled tools, techniques, mechanisms, and personnel.
In other words: you must know who is maintaining your systems, what tools they’re using, and how that access is approved and secured.
When assessing this control, a C3PAO will look for evidence that your organization:
We’re not just checking for patches—we’re looking for control.
Can your organization explain how it knows maintenance is happening securely? Do you review access logs? Do you know which tools your MSP uses to connect remotely?
If those answers live only with your provider, the responsibility isn’t truly shared—it’s outsourced.
Most organizations rely heavily on managed service providers (MSPs) or cloud vendors for system maintenance. That’s fine—and often necessary—but it doesn’t remove your oversight obligation.
Your MSP might use remote access software, automation scripts, or cloud consoles to maintain your systems. But the authorization to perform that work must come from your organization.
That means leadership needs to ensure:
These requirements are not about distrust—they’re about structured trust.
In a shared responsibility model, your provider is responsible for performing maintenance securely, but you are responsible for allowing it to happen.
The decision to grant access, define boundaries, and review logs belongs to the OSC.
Control 3.7.5 sits at a tricky intersection between technology and governance. Many organizations assume their MSP “handles it,” but from a compliance standpoint, that’s not enough.
The OSC must define what “approved” means.
That might include listing:
Providers can’t define these things for you—they can only comply with what your organization decides.
That’s why the Shared Responsibility Matrix (SRM) is essential. It should clearly show that the OSC defines maintenance approval policies, while the provider executes them under those rules.
During an assessment, we can often tell which organizations have clear SRMs. Their leadership can describe the process confidently. The others usually start by saying, “Our MSP handles all that.”
That’s a red flag.
CMMC isn’t about assuming trust—it’s about proving trust is controlled.
Maintenance is where that principle is tested in real life. Every external connection, remote session, and software update is an exercise in risk management.
As a leader, your job isn’t to perform maintenance—it’s to ensure it happens securely, consistently, and under your authority.
When your C3PAO asks how maintenance is approved and tracked, your answer should show both trust and verification.
Because in compliance, trust without oversight isn’t confidence—it’s risk.