.svg)
There is a specific phrase that comes up in nearly every environment that has never been through a formal configuration review: We know our systems. It is said with genuine confidence, usually by someone who built the environment, and it is almost always wrong in ways that matter for compliance.
The Configuration Management (CM) and Maintenance (MA) families in ITSP.10.171 address a straightforward problem. Systems drift from their intended state over time, and maintenance activities introduce risk when they happen outside of documented procedures. For organizations entering the Canadian defence supply chain under the CPCSC, these two control families require something most commercial IT environments lack: documented proof that configurations are intentional and that maintenance is controlled.
This is Post 8 in our ITSP.10.171 domain deep-dive series, covering the CM and MA families. These families apply at CPCSC Level 2, which requires compliance with the full ITSP.10.171 standard across all 17 control families. The Government of Canada has not yet published the final Level 1 control list, but CM and MA are not among the six families expected at Level 1.
Level 2 Controls
Configuration Management and Maintenance are expected at CPCSC Level 2, which requires compliance with the full ITSP.10.171 standard. Organizations preparing for Level 2 should begin building these controls now.
What Configuration Management Actually Requires
The CM family is not about having configuration management tooling. It is about having documented, defensible baselines and a controlled process for changing them. The distinction matters because many organizations have sophisticated automation but no documented standard for what correctly configured means.
Baseline Configurations (CM-2)
Every system that processes, stores, or transmits controlled information needs a documented baseline configuration. This means a record of the approved software, firmware, settings, and services for each system type, not a mental model held by the person who built it.
The standard expects baselines to be reviewed and updated as part of system changes, upgrades, and patches. In practice, this means maintaining a configuration document or template that reflects the current approved state, not the state the system was in when it was first deployed three years ago.
Organizations with infrastructure-as-code (IaC) practices using tools like Ansible or Terraform sometimes assume their code repositories satisfy this requirement. They can, but only if the code is documented, validated against drift, and treated as the authoritative baseline rather than just a provisioning tool. There is a meaningful gap between code that provisions a system at a point in time and a validated baseline that confirms the system still matches that configuration today.
IaC is Not Automatically a Baseline
Infrastructure-as-code satisfies the baseline requirement only when it is documented as the authoritative source, validated regularly against actual system state, and updated through a controlled change process. Provisioning code alone is not a configuration baseline.
Change Control (CM-3)
Changes to baseline configurations need to go through a documented change control process that includes security impact analysis. This does not need to be a heavyweight change advisory board process, but it does need to exist as something more than a Slack message and a deployment.
For CPCSC Level 2 certification, the expectation is that changes are tracked, reviewed for security implications before implementation, and documented after the fact. The common gap is not that organizations lack change control entirely, but rather that security impact analysis is absent from the process. Changes get reviewed for functionality and tested for breakage, but nobody asks whether the change affects the security posture of the system.
Least Functionality (CM-7)
Systems should be configured to provide only essential capabilities and to restrict or disable unnecessary functions, ports, protocols, and services. This is where a significant number of environments accumulate technical debt.
Systems that have been working fine for years tend to accumulate the deepest gaps here. Default services that were never disabled, ports that were opened for a migration and never closed, software that was installed for troubleshooting and never removed. Familiarity with an environment substitutes for controls, and the result is an attack surface that nobody has formally reviewed.
Configuration Settings (CM-6)
Security configuration settings need to be established, documented, and enforced. This is where CIS Benchmarks become relevant, though applying them requires more nuance than running a scan and fixing everything.
The first time an organization runs a CIS benchmark scan against a production system, the results look catastrophic. Depending on the platform, a CIS benchmark can contain hundreds of rules, and dozens or more will show as failures on first scan. The instinct is either to panic or to dismiss the results entirely. Neither response is productive.
The practical approach is to create a justified baseline: review each finding and categorize it as remediate, accept risk, or not applicable. A Windows server running a specific application may legitimately need certain services that the benchmark flags. The point is not to achieve a perfect score but to document a custom policy that reflects intentional decisions. Auditors and assessors are satisfied by documented, justified baselines. They are not satisfied by we have not looked at this.
A Tiered Approach to Configuration Scanning
Applying the same level of configuration scrutiny to every asset in an environment is a waste of limited resources, particularly for smaller teams common in the defence supply chain. A two-tiered approach prevents teams from burning time on low-value scanning while ensuring critical systems receive appropriate attention.
Tier 1: Secure Deployment Baseline for Everything
Every system gets a documented baseline configuration applied at deployment. This is the minimum standard, covering items like disabling default accounts, enforcing password policies, removing unnecessary services, and applying current patches. This does not require automated scanning. It requires a documented build standard and a checklist.
Tier 2: CIS Benchmark Scanning for Sensitive Systems
Production systems, internet-facing servers, and systems that handle controlled information get periodic benchmark scanning. Match the scanning frequency to risk: production and internet-facing systems weekly or monthly, hypervisors and internal infrastructure quarterly, network devices and endpoints annually.
This tiered model aligns with how NIST 800-171 expects organizations to apply controls proportionally. It also produces defensible evidence without requiring a full-time configuration management function, something most defence subcontractors cannot staff.
| System Tier | Scanning Approach | Frequency |
| Production / Internet-facing | CIS benchmark scan | Weekly or monthly |
| Hypervisors / Internal infrastructure | CIS benchmark scan | Quarterly |
| Network devices / Endpoints | CIS benchmark scan | Annually |
| All other systems | Documented deployment baseline + checklist | At deployment |
What Maintenance Controls Require
The MA family addresses a different risk: that maintenance activities, whether performed locally or remotely, can introduce vulnerabilities or provide unauthorized access to controlled information. For organizations that rely on third-party managed service providers (MSPs) for system maintenance, these controls have direct implications.
Controlled Maintenance (MA-2)
Maintenance activities need to be scheduled, performed in accordance with manufacturer specifications, and documented. This applies to both physical equipment and software systems. The evidence expectation is straightforward: maintenance logs that show what was done, when, and by whom.
The common gap is not that maintenance does not happen, but that it happens informally. A technician reboots a server, applies a firmware update, or replaces a drive, and the only record is a closed ticket that says resolved. For CPCSC purposes, the maintenance record needs to include what was done to the system and confirmation that the system was returned to its approved configuration state afterward.
Maintenance Tools (MA-3)
Tools used for maintenance, both hardware diagnostic equipment and software utilities, need to be inspected and controlled. In practice, this means knowing what tools are being used on systems that handle controlled information and ensuring those tools are not introducing risk.
For software-based maintenance, this translates to controlling which remote access tools, diagnostic utilities, and scripts can be run on controlled systems. An MSP technician connecting via their preferred remote access tool with admin credentials represents a maintenance tool that the organization needs to approve and document.
Nonlocal (Remote) Maintenance (MA-4)
Remote maintenance sessions need to be authorized, monitored, and documented. If a session is terminated before completion, the organization needs to verify the system's integrity afterward. This control exists because remote maintenance creates a window of elevated access that, if unsupervised, represents a significant risk to controlled information.
MSP Oversight Gap
Organizations that outsource infrastructure management to MSPs frequently have a gap here. The MSP has standing remote access, often with administrative credentials, and maintenance happens on their schedule with minimal oversight. Under ITSP.10.171, the organization retains responsibility for controlling and documenting that access regardless of who performs the work.
Maintenance Personnel (MA-5)
Personnel performing maintenance on systems that handle controlled information need to be authorized, and their activities need to be supervised if they do not have the appropriate clearance or authorization level. This applies to both internal staff and external contractors.
For MSP relationships, this means maintaining a current list of authorized maintenance personnel and having a process for verifying that the person connecting remotely is actually on that list. It also means having a supervision mechanism, whether that is session recording, real-time monitoring, or escorted access, for personnel who have not been formally cleared.
Where SOC 2 and ISO 27001 Already Cover You
Organizations with existing SOC 2 or ISO 27001 certifications will find meaningful overlap in the CM family. SOC 2's CC8 (Change Management) maps closely to CM-3, and ISO 27001 Annex A controls for secure configuration (A.8.9) and change management (A.8.32) align with the baseline and change control requirements.
The maintenance family has less overlap with commercial frameworks. SOC 2 and ISO 27001 address vendor management and access control, but they do not specifically address controlled maintenance procedures, maintenance tool oversight, or the supervision requirements for maintenance personnel. These are areas where defence-specific requirements go beyond what commercial certifications expect.
Organizations extending an existing security program into CPCSC compliance should expect the CM controls to require refinement rather than net-new implementation, while the MA controls will likely need new procedures and documentation.
Common Gaps That Surface During Assessment
Across environments preparing for defence certification, several configuration and maintenance gaps appear consistently:
Configuration and Maintenance Gaps
Institutional knowledge instead of documented baselines. The person who built the environment knows how it is configured. That knowledge lives in their head, not in a document. When that person leaves or is unavailable, the organization cannot demonstrate what the intended configuration actually is.
Change control without security analysis. Changes go through a review process, but the review focuses exclusively on functionality and uptime. Nobody evaluates whether the change affects security controls, opens new attack surface, or impacts the protection of controlled information.
Unsupervised remote maintenance. MSP technicians have persistent remote access with administrative credentials. Maintenance sessions are not logged in a way that shows what was done, and there is no formal process for authorizing specific maintenance activities before they occur.
No configuration drift detection. A baseline was established at deployment, but nothing validates whether systems still match that baseline months or years later. The baseline document describes an environment that no longer exists.
Quarterly reviews that never happen. Firewall rule reviews are straightforward to implement and frequently missed. A 30-minute quarterly review of active firewall rules creates four evidence artifacts per year and demonstrates ongoing attention to least functionality. Many organizations have never reviewed their firewall rules after the initial deployment.
Practical Implementation Steps
For organizations preparing for CPCSC Level 2 certification, configuration management and maintenance controls can be implemented without enterprise tooling:
1. Document baseline configurations for each system type. Start with your most critical systems and work outward. A configuration document template that captures approved software, services, settings, and hardening decisions is sufficient.
2. Add security impact analysis to your change process. This can be as simple as a required field in your change request template that asks: Does this change affect the security posture of the system? Include a brief justification.
3. Run an initial CIS benchmark scan on critical systems. Use the free CIS-CAT Lite tool or equivalent. Create your justified baseline by categorizing each finding. Document your decisions.
4. Implement a tiered scanning schedule. Weekly or monthly for production and internet-facing, quarterly for internal infrastructure, annually for everything else.
5. Formalize your MSP maintenance oversight. Document authorized personnel, require advance notification for maintenance activities, implement session logging, and verify system integrity after remote maintenance sessions.
6. Schedule quarterly firewall rule reviews. Block 30 minutes on the calendar, review active rules against business need, document the review. Four times per year. This single practice creates consistent evidence of least functionality enforcement.
Get Your Configuration Baselines Right the First Time
We build effective security programs with documented baselines and controlled processes that produce compliance evidence as a natural output.
Frequently Asked Questions
Does IaC (Ansible, Terraform) satisfy the baseline configuration requirement?
It can, but not automatically. IaC satisfies the requirement when it is documented as the authoritative baseline, validated regularly against actual system state to detect drift, and updated through a controlled change process. If the IaC code provisions systems but nobody checks whether deployed systems still match the code, you have a provisioning tool, not a configuration baseline.
What if our MSP will not agree to maintenance oversight requirements?
This is a contractual conversation that needs to happen before you pursue defence contracts. If your MSP cannot provide authorized personnel lists, advance maintenance notification, session logging, and post-maintenance verification, you either need contract amendments or a different MSP. The organization retains responsibility for these controls regardless of who performs the maintenance.
Do we need to pass every CIS benchmark rule?
No. The expectation is a documented, justified baseline, not a perfect score. Rules that are not applicable to your environment, that conflict with application requirements, or that represent accepted risk should be documented with justification. Assessors evaluate whether your configuration decisions are intentional and documented, not whether you achieved 100% compliance with a generic benchmark.
How does this differ from CMMC configuration management requirements?
ITSP.10.171's CM family is derived from NIST 800-171, which is the same source as CMMC. The control objectives are substantially similar. Organizations operating under both Canadian and U.S. defence requirements can build one configuration management program that satisfies both, with minor adjustments for jurisdiction-specific documentation expectations.
Configuration management and system maintenance are operational disciplines, not project milestones. The organizations that handle these controls well are the ones that build them into their standard operating procedures rather than treating them as compliance artifacts to produce before an assessment.
For defence contractors navigating CPCSC requirements, these controls represent the difference between an environment that is understood and documented and one that merely works. Both may function identically today, but only one can demonstrate compliance, and only one will survive the departure of the person who built it.
If your organization is preparing for CPCSC certification and needs help establishing configuration baselines or formalizing maintenance procedures, we build security programs that produce compliance as a byproduct. Start a conversation about where your current program stands.
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
About the Author
Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.
Ready for CPCSC Level 1?
Score your readiness across the 6 expected control families. Free.
Take the Scorecard