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

Source: https://truvocyber.com/blog/soc-2-cc6-8-malware-prevention
Published: 2026-07-29
Topic cluster: SOC 2

> SOC 2 CC6.8 explained: what the criterion requires, its points of focus, malware prevention and software integrity for cloud and on-prem, and the evidence auditors expect.

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.

**CC6.8 at a glance**

- **Series:** CC6 Logical and Physical Access Controls | **Source:** AICPA TSC 2017 (rev. 2022)

- **COSO principle:** AICPA supplemental (beyond the 17 COSO principles)

- **Points of focus:** 5

- **ISO 27001:2022:** A 8.7, A 8.8, A 8.25, A 8.26-8.29 (Full overlap)

- **Reference card:** [FEX Framework Explorer](https://fex.truvocyber.com/browse/soc2)

- **Part of:** the [SOC 2 Trust Services Criteria guide](/blog/soc-2-trust-services-criteria-guide)

## What does SOC 2 CC6.8 require?

*The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity's objectives.*

AICPA, *Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy* (TSC section 100), 2017, revised 2022. © AICPA. Quoted for purposes of commentary and reference.

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](/blog/soc-2-cc7-1-vulnerability-management). 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.
- **Browser-side script controls.** Public web apps send a Content-Security-Policy header so the browser runs scripts only from approved sources, which blocks injected code. A [free security headers check](https://truvocyber.com/tools/security-headers-checker) shows whether the live site sends one.

## 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](/blog/soc2-endpoint-security-on-prem) 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

Point-of-focus theme
Cloud implementation
On-prem implementation

Restricting installation
MDM application controls; standard users cannot install
Application allowlisting and removal of local admin rights

Detecting unauthorized changes
Immutable images; drift and file-integrity detection
File-integrity monitoring on critical systems

Change control for software
Pull-request review and approved CI/CD deployment
Defined change process with documented approvals

Antivirus and anti-malware
EDR on managed endpoints
Anti-malware or EDR on servers and workstations

Scanning imported assets
Container and dependency scanning in the pipeline
Scanning of removable media and returned devices

## What evidence do auditors expect for CC6.8?

Artifact
What it demonstrates
Cadence

Anti-malware or EDR coverage report
Endpoints and servers are protected and monitored
Continuous

Application installation and admin-rights settings
Software installation is restricted to authorized users
Continuous

CI/CD scanning results (SAST, SCA, container)
Code and dependencies are checked before deployment
Per build

Change and deployment approval records
Software reaches production through a defined process
Per change

File-integrity monitoring alerts and reviews
Unauthorized changes to critical files are detected
Continuous

Media and device scanning records
Imported assets are checked before connecting
Per event

**A common gap: endpoints are covered but the pipeline is not**

A common gap that comes up during readiness assessments is treating CC6.8 as an antivirus question and stopping at the laptop. A team can have solid endpoint protection and still have no control over the code, container images, and open-source packages moving into production, which is where unauthorized or malicious software often enters a modern environment. The remediation is to extend the same prevent-or-detect logic to the build pipeline: run static analysis, dependency scanning, and image scanning in CI/CD, require review and approval before code deploys, and keep the scan results as evidence. The point-of-focus about a defined change-control process is the bridge, since it applies whether software is installed on a server or shipped through a pipeline.

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

ISO 27001:2022 Annex A controls
Overlap type
SOC 2 evidence reusable

A 8.7 (protection against malware), A 8.8 (management of technical vulnerabilities), A 8.25 (secure development lifecycle), A 8.26 to A 8.29 (application security, secure architecture, secure coding, and security testing)
Full
Anti-malware and EDR reports, CI/CD scanning results, change-approval records, secure development evidence

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](/blog/iso-27001-soc-2-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](/blog/soc-2-cc6-7-data-transmission), 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](/blog/soc-2-cc7-1-vulnerability-management), 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](/blog/soc-2-cc6-1-logical-access-security).

**Part of Truvo's criterion-by-criterion SOC 2 reference series**

Browse every criterion in the [Framework Explorer](https://fex.truvocyber.com/browse/soc2) or start from the [Trust Services Criteria guide](/blog/soc-2-trust-services-criteria-guide). For a second set of eyes on control scoping before an audit as part of an effective security program, Truvo runs [scoping calls](/contact-us).

 

## 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.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What does SOC 2 CC6.8 mean?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "What evidence satisfies CC6.8?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Does CC6.8 only mean antivirus?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How does CC6.8 apply to the software supply chain?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How is CC6.8 different from CC7.1?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    }
  ]
}