CMMC System and Information Integrity: Write a Policy Your Team Can Follow

System and Information Integrity Policy

1 Purpose

Protect company systems and CUI by finding and correcting flaws, maintaining malicious code protection, and monitoring for attacks and unauthorized use. This policy also requires security alert and advisory review, protection updates, and scanning for signs of compromise.

2 Scope

This policy applies to employees, contractors, vendors, systems, endpoints, servers, network services, and security tools within the CUI assessment boundary, including supporting security systems described in the System Security Plan (SSP). It covers systems that process, store, or transmit CUI and the systems that protect them.

3 Responsibilities

The policy owner maintains this policy and its supporting procedures. The IT Manager or designated system administrators run vulnerability management, patching, malware protection, scanning, and monitoring tools and retain the records of that work. The Compliance Lead maintains the assessment mapping and tracks open gaps.

Managers ensure staff report suspected malware, unusual system behavior, and unauthorized use through the Incident Response process. Users must not disable required security tools without documented approval and a defined time to restore them.

4 Requirements

Flaw identification, reporting, and correction. Identify system flaws through vendor advisories, vulnerability scans, configuration reviews, and other approved sources. Record findings in the ticketing system. Correct flaws according to risk and the timelines in the Flaw Remediation Procedure. If an immediate fix is not possible, document and apply an approved temporary mitigation. Track the remaining risk until the flaw is remediated. When practical, test fixes in a controlled environment before broad deployment.

Malicious code protection. Use malicious code protection at the locations defined in the Malicious Code Protection Procedure, including applicable endpoints, servers, email and file entry points, and other paths. Configure periodic scans and real-time scans of files from external sources as they are downloaded, opened, or executed, in accordance with organizational capability. Block or quarantine detected malicious code and alert designated personnel.

Protection updates. Keep malicious code protection mechanisms and their signatures or definitions current. Follow the update schedule in the Malicious Code Protection Procedure and apply relevant vendor emergency updates. Document any update that cannot be applied and assign an owner to restore current protection.

Security alerts and advisories. Monitor approved sources for security alerts, advisories, and directives. Sources may include vendor notices, CISA or similar government sources, and contracted threat or vulnerability feeds. Review and respond using the Alert and Advisory Handling Procedure. If an advisory does not apply, record why and retain that decision.

System and traffic monitoring. Monitor organizational systems and inbound and outbound communications traffic for attacks and signs of potential attacks. Use approved tools and log sources. Define who reviews alerts, how often they review them, and when to escalate through Incident Response. Keep monitoring outputs and review records that show the process is operating.

Unauthorized use. Identify unauthorized system use through monitoring, access and activity reviews, and reports from users or managers. Investigate suspected unauthorized use through Incident Response. Correct access or configuration issues through Access Control and related procedures. Retain the investigation and remediation records.

5 Implementation and evidence

Supporting procedures must identify the tools, scan and update schedules, remediation timelines, responsible personnel, escalation paths, and records to retain. The SSP describes how SI requirements are implemented within the assessment boundary.

Keep vulnerability scan results, remediation tickets, patch and mitigation records, malware protection configurations and update records, alert handling records, monitoring review notes, and unauthorized-use investigation records. Document implementation gaps and assign owners for corrective action. Removing a requirement from this policy does not close a gap, and approving this policy does not establish compliance.

Confirm the remediation timelines, scan frequencies, malware update schedules, and alert review intervals in supporting procedures before adopting them.

6 Enforcement

Violations may result in removal of access and disciplinary action under company policy. Disabling required integrity or malware protections without approval is prohibited. Report suspected malware, attacks, or unauthorized use through the Incident Response process.

7 Supporting documents

The policy owner maintains current approved versions and references for the Flaw Remediation Procedure, Malicious Code Protection Procedure, Alert and Advisory Handling Procedure, System Monitoring Procedure, Incident Response Plan, Access Control Policy, and System Security Plan. The example Flaw Remediation Procedure below covers only part of this policy.

8 Approval

Approved by: [Name and title]
Approval date: [Date]

Flaw Remediation Procedure

Purpose and scope

This procedure explains how to find, prioritize, fix or mitigate, and verify system flaws, then retain evidence of the work. It applies to vulnerabilities, missing patches, and related configuration weaknesses on systems in scope of the SSP. Separate procedures cover malware protection, alert handling, and continuous monitoring.

Confirm the severity definitions, remediation timelines, and scan frequency below before adopting this procedure.

A Identify and report flaws

1. IT runs authenticated vulnerability scans of in-scope systems at the approved frequency of [scan frequency, for example monthly], and after major system changes when practical.
2. IT monitors vendor security advisories and other approved alert sources for products used in the environment.
3. Anyone who identifies a suspected flaw opens a ticket. Include the asset name, product or CVE if known, how the flaw was found, and whether CUI systems are affected.
4. IT checks the finding against the asset inventory and records all affected systems in the ticket.

Evidence to keep: Scan reports or exports, advisory references, and the ticket with the affected asset list and discovery source.

B Prioritize

1. IT assigns a severity using the approved scheme, such as Critical, High, Medium, or Low. Consider exploitability, exposure, and whether CUI or privileged systems are involved.
2. IT sets a due date using the approved timelines: Critical within [number] days; High within [number] days; Medium within [number] days; Low within [number] days or the next scheduled maintenance window.
3. If the deadline cannot be met, IT documents an approved temporary mitigation, the remaining risk, a revised target date, and an assigned owner.

Evidence to keep: The severity, due date, and owner in the ticket, plus mitigation approval when applicable.

C Patch or mitigate

1. IT obtains the vendor fix or approved configuration change.
2. When practical, IT tests the change on nonproduction systems or a limited set of systems before broader deployment.
3. IT applies the fix to affected in-scope systems or implements the approved temporary mitigation. A mitigation might include a network block, disabling a service, or another compensating control.
4. IT records what changed, which systems were affected, and when the change was made.

Evidence to keep: Change or ticket notes, patch versions or configuration references, and the maintenance window record if used.

D Verify and close

1. IT rescans or otherwise checks each affected system to confirm the flaw is remediated or the mitigation is in place and effective.
2. If verification fails, IT reopens remediation and escalates the issue before the deadline passes without notice.
3. IT closes the ticket with verification results and timestamps. Any remaining risk from a temporary mitigation stays tracked until remediation is complete.
4. For recurring or widespread findings, IT updates hardening baselines or deployment images so new systems do not reintroduce the flaw.

Evidence to keep: Verification scan or check results, the closure timestamp, and any related baseline or image update notes.

E Exceptions and gaps

1. Record any system that cannot be scanned or patched. Include the business justification and compensating controls.
2. Assign an owner and a review date to each exception. Deleting a policy requirement does not close the gap.
3. Include open exceptions in risk tracking and the SSP or plan-of-action process, as required by the contract and applicable CMMC status rules.

Evidence to keep: The exception log, assigned owner, review date, and description of compensating controls.

Approval

Approved by: [Name and title]
Approval date: [Date]