Safety Maintenance (MCS): Definition and Method

An information system that is secure on the day it goes live is no longer secure six months later. Patches accumulate, versions reach end-of-support, and configurations drift as maintenance is performed. Security maintenance, or MCS, refers to all the activities that prevent this decline in security.

What is secure custody?

MCS encompasses the measures that maintain the security level of an information system over time, once it is in operation. It is not about deploying new security measures, but rather ensuring that those already in place remain effective in the face of evolving threats and an ever-changing IT infrastructure.

Specifically, the MCS covers system and application updates, addressing disclosed vulnerabilities, tracking end-of-support dates, monitoring security configurations, reviewing accounts and permissions, logging, and verifying that backups can actually be restored.

The term originates from the vocabulary of large public systems and the defense sector, where a distinction has long been made between maintaining operational readiness and maintaining safety. It has spread to the private sector with the rise of regulatory requirements.

MCO and MCS: Two Different Objectives Within the Same System

Confusion between the two is common, and it has tangible consequences for the terms of an IT outsourcing contract.

• Operational Maintenance (MCO) focuses on availability and performance. The key question is: Is the service functioning, and is it doing so within the promised timeframe?
• Security maintenance (MCS) focuses on resistance to attacks. The key question is: Does the system remain difficult to compromise, despite the vulnerabilities discovered since it was put into service?

The two often overlap, but not always in the same way. A server that hasn’t been restarted in eight months shows exemplary availability under MCO, while accumulating unapplied patches under MCS. Conversely, a maintenance window to apply a critical patch temporarily reduces availability in order to improve security.

That’s why a contract that only mentions GTI, GTR, and availability rates says nothing about MCS. These are two distinct commitments that must be addressed separately. If you’re interested in the availability aspect, our page on hybrid cloud and on-premises infrastructure maintenance provides details on the MCO side.

What the MCS Actually Covers

Security patches. Operating systems, hypervisors, firmware, browsers, line-of-business applications, network equipment. Workstations are often well protected, but peripheral devices are much less so.

Addressing vulnerabilities. A published CVE cannot always be patched immediately. The MCS requires determining whether a system is exposed, when the patch will be available, and what workaround applies in the meantime.

End-of-life. Windows 10, Exchange Server 2016, and Exchange Server 2019 reached end of support from Microsoft on October 14, 2025. A component that is no longer supported no longer receives security patches: no update policy, no matter how rigorous, can compensate for this. Monitoring end-of-support dates is therefore an integral part of MCS.

Configurations. The security hardening applied during installation breaks down over time due to troubleshooting, exceptions granted, and migrations. Periodically checking for deviations from the baseline is a separate process from patching—one that is often overlooked. Our guide on hardening Windows workstations details the workstation-specific aspects.

Accounts and permissions. Inactive accounts, accounts with elevated privileges, and permissions granted for a project that was completed two years ago. Regular reviews are the responsibility of the MCS and rely on privileged access management tools.

Logging and detection. Logs that are not collected—or that are collected but not analyzed—allow a security breach to occur unnoticed. The MCS verifies that logging is working, that it is being performed on the correct components, and that someone is reviewing the logs.

Backups. A backup that runs without errors is not a restorable backup. The restore test is the only proof, and it has an expiration date.

What the regulations require

MCS is not just an optional best practice; it is a requirement formalized in two reference documents.

The ANSSI IT Security Guide (Version 2.0, January 2017) devotes several of its 42 measures to this topic: Measure 34 requires defining a policy for updating information system components; Measure 35 requires anticipating the end of software and system support and limiting software dependencies; Measure 36 requires enabling and configuring logs for the most critical components; and Measure 37 requires defining and implementing a backup policy for critical components.

The NIS2 Directive addresses this topic in Article 21, which lists the minimum risk management measures. Point (e) addresses the security of the procurement, development, and maintenance of networks and information systems, including the handling and disclosure of vulnerabilities. In other words, maintaining security is specified as an obligation, not a recommendation. To find out if your company falls within the scope of the directive, see our article “NIS2: Directive, Compliance, and Obligations.”

Why MCS Fails, Even in Well-Equipped Companies

Inventory is the first point of failure. You can’t update what you don’t know you have, and the actual inventory almost always differs from the documented inventory—especially when it comes to virtual machines and network equipment.

Next comes the maintenance window. In an SME without redundancy, applying a patch requires interrupting a service, which means securing a time slot and obtaining business approval. Without clear guidance, the patch is put on hold.

Finally, application dependencies. A business application certified for a single version of the runtime prevents the entire server hosting it from being updated. The MCS therefore requires addressing the issue at its root—through isolation or migration—rather than postponing it indefinitely.

Implement a robust MCS

1. Take inventory. Assets, versions, end-of-support dates, business criticality. Without this foundation, everything else is merely declarative.
2. Prioritize. Not all components warrant the same level of effort. A server exposed to the internet and a test workstation do not operate at the same pace.
3. Draft the update policy. Target deadlines based on the severity of the vulnerability, designated person in charge, time windows approved by the business units, and rollback procedure.
4. Organize your monitoring efforts. Track vulnerability disclosures that affect your actual infrastructure, not all cybersecurity news.
5. Monitor deviations. Periodically compare production configurations to the build reference.
6. Test the restorations. At fixed intervals, covering a rotating area, with a written report.
7. Measure: Compliance rate of the IT infrastructure, average time to apply critical patches, number of unsupported components, and age of the most recent tested restore.

A security audit provides a baseline assessment. The MCS, on the other hand, is what prevents that baseline from deteriorating once the recommendations have been implemented.

In-House or Outsource Your MCS

MCS is a recurring activity that receives little attention but has significant consequences. This is precisely the kind of task that tends to fall by the wayside when the internal team is overwhelmed by day-to-day emergencies.

In-house management is a viable option when the team is large enough to handle the workload of monitoring and patching without constant prioritization, and when the IT infrastructure is homogeneous. Outsourcing is justified when coverage must extend beyond business hours, when detection requires analysts to be available around the clock, or when proof of compliance must be provided to a third party, such as an insurer, a major client, or a regulatory authority.

At IT Systèmes, the MCS relies on infrastructure security for patch and vulnerability management, on monitoring to detect anomalies, and on our French SOC for continuous monitoring, investigation, and remediation by analysts. It’s the same process, from the applied patch to the resolved incident.

Frequently asked questions

What does MCS mean in computing?

MCS stands for "maintaining security." The term refers to all activities that ensure the ongoing security of an information system in operation, including patches, vulnerability management, tracking end-of-support dates, configuration management, access rights reviews, logging, and recovery testing.

What is the difference between MCO and MCS?

MCO (Maintenance of Operational Readiness) focuses on service availability and performance. MCS focuses on the system’s resilience to attacks. A system can be fully available yet highly vulnerable, which is why a commitment to availability does not equate to a commitment to security.

Is the MCS mandatory?

This is the case for entities regulated by the NIS2 Directive, Article 21 of which lists the security of system maintenance and the handling of vulnerabilities among the minimum measures. For other companies, it is considered a best practice—specifically, measures 34 through 37 of the ANSSI IT Security Guide—and is often a prerequisite for cyber insurance coverage or for being listed as a supplier by a major client.

How often should security patches be applied?

There is no single frequency. The standard practice is to set target timeframes based on severity level—for example, urgent remediation for a critical vulnerability that is actively being exploited on an exposed component, and a monthly schedule for the rest of the system. The key is that these timeframes be documented, known, and tracked.

What should you do with software that is no longer supported?

There are only three options: migrate to a supported version, isolate the component from the rest of the network until it is migrated, or formally acknowledge the risk with management. Keeping an unsupported component in use without any mitigating measures or a written decision is the scenario that most often backfires on the company after an incident.

Can you entrust the MCS to your IT service provider?

Yes, provided that the contract explicitly states so. Many IT outsourcing contracts cover availability without specifying the scope of security. Check what is included: a list of patched components, application deadlines, end-of-support management, recovery testing, and related reporting.

Has your fleet's MCS not been reviewed in a while? Let's talk about it.

‍

‍