SOC 2 CC6.8: Preventing and Detecting Unauthorized or Malicious Software

SOC 2 CC6.8 requires controls that prevent, or detect and act on, the introduction of unauthorized or malicious software. It sits in the CC6 series (Logical and Physical Access Controls), and a frequent finding under it is a company that runs antivirus on laptops but has no equivalent control over what code and packages reach its production systems.

What does SOC 2 CC6.8 require?

In plain terms, CC6.8 asks how the company keeps software it did not intend to run off its systems, and how it notices and responds when something slips through. That covers two fronts that teams often treat separately. One is the classic endpoint and server picture: antivirus, endpoint detection and response, and controls on who can install applications. The other is the software supply chain: the code, container images, and third-party packages that flow into production through the build pipeline.

The criterion offers a choice of posture. Prevention stops unauthorized software from being introduced at all, through installation restrictions and change control. Detection catches it after the fact, through anti-malware, file-integrity monitoring, and scanning of anything imported into the environment. Most programs use both, applying prevention where they can and detection everywhere else.

CC6.8 sits close to the change-management and vulnerability criteria. The defined change-control process it references is the same discipline covered under CC8.1, and the scanning of code and dependencies overlaps with the vulnerability detection under CC7.1. Its distinct focus is the integrity of the software running in the environment.

What are the CC6.8 points of focus?

The AICPA defines 5 points of focus for CC6.8. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Restricts software installation. The ability to install applications and software is limited to authorized individuals, so ordinary users cannot introduce arbitrary programs.
• Detects unauthorized changes. Processes detect changes to software and configuration that could indicate unauthorized or malicious code, such as file-integrity monitoring on critical systems.
• Uses a defined change-control process. Software reaches production through a management-defined change process, which keeps unreviewed code out.
• Uses antivirus and anti-malware. Antivirus and anti-malware tooling is deployed and maintained to intercept or detect and remediate malicious software.
• Scans imported assets. Information assets transferred or returned into the company's custody are scanned for malware and unauthorized software before they are connected to the network.

How do you meet CC6.8 in cloud environments?

Cloud environments meet CC6.8 across endpoints and the build pipeline, since production software is deployed rather than installed by hand:

• Managed endpoints with EDR. Company laptops run endpoint detection and response and enforce application controls through mobile device management, so installation is restricted and malware is detected. Virtual desktops do not remove this requirement; the device connecting through them still needs an endpoint agent for the compliance check.
• Pipeline security scanning. Static analysis, dependency and software composition analysis, and container image scanning run in CI/CD, so vulnerable or unauthorized code is caught before deployment. Results are retained as evidence.
• Change control on deployments. Code reaches production through pull-request review and an approved deployment process, which is the defined change-control point of focus applied to a modern stack.
• Immutable and hardened images. Servers run from hardened, version-controlled images rather than being modified in place, so unexpected software on a running host is itself an anomaly worth investigating.

How do you meet CC6.8 on-prem?

On-prem environments apply the same intent to owned hardware and, often, longer-lived systems. The endpoint security on-prem guide covers the detail; the shape is:

• Anti-malware on servers and endpoints. Anti-malware or EDR is deployed across workstations and servers and kept current, with central reporting of coverage and detections.
• Application allowlisting and admin restrictions. Standard users cannot install software, and where the environment supports it, only approved applications are permitted to run.
• File-integrity monitoring. Critical system and configuration files are monitored for unauthorized change, feeding alerts into the same monitoring pipeline as other security events.
• Scanning of imported media and returned devices. Removable media and devices that were outside the company's control are scanned before they reconnect to the network.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC6.8?

How does CC6.8 map to ISO 27001:2022?

Organizations pursuing both frameworks can reuse CC6.8 evidence directly for these Annex A controls, which span both anti-malware and secure software development. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC6.8 closes the CC6 series by protecting the integrity of the software running inside the boundary the earlier criteria set up and defend. The previous criterion, CC6.7, protects information as it moves, and CC6.8 protects the system from unauthorized code moving in. Its scanning of code and dependencies overlaps with the vulnerability detection under CC7.1, and its change-control point of focus is the same discipline that CC8.1 covers in full. The installation and admin restrictions it relies on are part of the logical access model set under CC6.1.

Frequently Asked Questions

What does SOC 2 CC6.8 mean?

SOC 2 CC6.8 requires controls that prevent, or detect and act on, the introduction of unauthorized or malicious software. In practice it covers antivirus and endpoint detection and response, restrictions on who can install software, a defined change-control process, file-integrity monitoring, and scanning of code and imported assets.

What evidence satisfies CC6.8?

The core evidence is an anti-malware or EDR coverage report, application installation and admin-rights settings, CI/CD scanning results such as SAST, SCA, and container scans, change and deployment approval records, file-integrity monitoring alerts, and records of scanning imported media and returned devices.

Does CC6.8 only mean antivirus?

No. Antivirus and anti-malware are one point of focus, but CC6.8 also covers restricting software installation, a defined change-control process, detecting unauthorized changes, and scanning imported assets. For most modern environments that includes securing the build pipeline, where code and dependencies enter production.

How does CC6.8 apply to the software supply chain?

Code, container images, and third-party packages are a common way unauthorized software enters an environment. Static analysis, dependency and software composition analysis, and image scanning in CI/CD, combined with required review and approval before deployment, apply the criterion's prevent-or-detect logic to the pipeline.

How is CC6.8 different from CC7.1?

CC6.8 is about the integrity of software in the environment: keeping unauthorized or malicious code out and detecting it if it gets in. CC7.1 is about detecting configuration changes that introduce vulnerabilities and identifying newly discovered vulnerabilities. They overlap in code and dependency scanning, but CC6.8 focuses on unauthorized software and CC7.1 on vulnerability detection.