The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software

To meet the the entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software requirement (SOC 2 TSC-CC6.8), you must run preventative and detective controls across endpoints, servers, and cloud workloads, then prove you can contain and remediate malware events. Operationalize it by standardizing approved software, blocking unauthorized installs, monitoring for malicious code, and retaining evidence that alerts were investigated and resolved.

Key takeaways:

• You need both prevention (allowlisting, least privilege, hardening) and detection/response (EDR alerts, triage, containment, post-incident actions).
• Auditors will test scope, consistent operation, and evidence quality, not tool names.
• Your fastest path is a defined control statement, mapped in-scope assets, EDR/AV coverage, and ticketed incident handling with retained logs.

TSC-CC6.8 is a requirement-level expectation that your organization can stop or quickly deal with unauthorized or malicious software before it impacts the services in SOC 2 scope. For most service organizations, this becomes real in three places: endpoints (employee laptops), production systems (servers, containers, managed services), and the software supply chain (installers, packages, CI/CD artifacts).

CCOs and GRC leads typically run into two challenges with this requirement. First, teams rely on “we have antivirus” as the entire story. Auditors want more: how you prevent unauthorized software, how you detect malware behavior, and how you prove you acted on alerts. Second, evidence is often scattered across security tools, IT tickets, and cloud logs. Without a clean control narrative and a predictable evidence package, you end up scrambling during the audit window.

This page gives you a practical way to implement and defend TSC-CC6.8: define the control, set minimum technical guardrails, wire detection to response workflows, and retain artifacts that show operation over time. The goal is a control that survives both real incidents and SOC 2 testing.

Regulatory text

SOC 2 Trust Services Criteria (TSC-CC6.8) excerpt: “The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software.” ¹

What the operator must do (requirement meaning):

• Prevent introduction of unauthorized or malicious software where feasible (policy + technical enforcement).
• Detect malware or unauthorized software that bypasses prevention (continuous monitoring/telemetry).
• Act upon detections (triage, containment, eradication, recovery, and documented closure).

Auditors will typically evaluate whether your control design covers the systems that could affect the SOC 2 scoped services, and whether your team can show operational evidence that alerts or detections were handled according to a defined process. ¹

Plain-English interpretation of the requirement

You must be able to answer, with evidence:

1. What software is allowed?
2. How do you block or limit unauthorized installs/execution?
3. How do you detect malware and suspicious execution?
4. What happens when you detect it, and how do you prove you responded?

This is not limited to classic “viruses.” In practice, it includes remote access trojans, crypto-miners, malicious packages, unauthorized admin tools, and “shadow IT” executables that increase attack surface.

Who it applies to (entity and operational context)

This applies to service organizations seeking a SOC 2 report where systems supporting the service are in scope. ¹

Include these operational areas in your scoping conversation:

• Corporate endpoints used to administer production (developers, SREs, IT admins).
• Production compute (VMs, bare metal, containers, Kubernetes nodes).
• Cloud control planes where agents run (managed services still require monitoring and configuration controls).
• Build and deployment systems (CI runners, artifact repositories) because malware can enter through dependencies or build tooling.
• Third-party software installed in production or used for administration (monitoring agents, remote support, package managers).

A common, defensible boundary: “All endpoints and workloads that can access, administer, or process customer data for the in-scope services.”

What you actually need to do (step-by-step)

1) Write a control statement that matches how you operate

Create a single control narrative that an auditor can test. Example structure:

• Objective: prevent/detect/respond to unauthorized or malicious software.
• Scope: in-scope endpoints and production workloads.
• Mechanisms: allowlisting/installation controls, EDR/AV, scanning, logging/alerting, incident workflow.
• Frequency: continuous monitoring, with defined response SLAs (your internal targets are fine as guidance).
• Owners: Security Operations (detection/response), IT (endpoint management), Engineering/SRE (production).

If you use Daydream, store the control narrative, ownership, and evidence checklist in one place so audits don’t become a scavenger hunt.

2) Establish “authorized software” and enforce installation boundaries

Minimum operators’ checklist:

• Approved software policy/standard: define what’s permitted and how exceptions are approved.
• Least privilege: remove local admin where feasible; use just-in-time admin or privileged access workflows for installs.
• Device management enforcement: configuration profiles that block unknown apps where feasible (by OS).
• Allowlisting (where appropriate): especially for hardened admin workstations or production jump hosts.
• Third-party intake: require security review for new endpoint agents and production libraries that run with elevated privileges.

Evidence focus: auditors want to see you can distinguish between approved and unapproved software and that the distinction has teeth.

3) Deploy malware prevention and detection coverage (EDR/AV + telemetry)

Implement technical controls across scope:

• Endpoints: EDR/AV installed, running, and reporting; tamper protection enabled where available.
• Servers/workloads: EDR agent or equivalent workload protection; if agentless, document how you detect malicious activity through logs and runtime signals.
• Email/web entry points: if you rely on separate controls (gateway scanning, attachment detonation), document how those controls feed incident response.

Operational detail that matters in audits:

• Define what “coverage” means (device enrolled + agent healthy + recent check-in).
• Track exceptions (legacy systems, constrained workloads) and apply compensating controls.

4) Connect detections to an “act upon it” workflow

You need a repeatable path from alert to closure:

1. Alert intake: security tool generates an alert (malware, suspicious execution, known bad hash, persistence attempt).
2. Triage: severity assessment and validation steps.
3. Containment: isolate endpoint/workload, disable credentials, block indicators (hash/domain/IP) where relevant.
4. Eradication and recovery: remove malicious artifacts, reimage if required, restore services safely.
5. Post-incident actions: root cause, control improvements, user coaching, patching/hardening updates.
6. Closure: ticket notes, timelines, approvals, and final status.

Auditors test the “act upon” part by sampling alerts and asking for the corresponding tickets and resolution evidence.

5) Add preventative controls for the software supply chain (practical baseline)

Even though CC6.8 is framed as “software introduction,” auditors commonly accept supply-chain controls as part of the story if they reduce malicious code risk:

• Restrict who can publish artifacts and who can modify CI/CD pipelines.
• Scan dependencies and images (SCA/container scanning) and block known malicious packages based on your risk appetite.
• Require signed artifacts or controlled repositories for production deployments where feasible.

Do not overpromise. Document what is enforced versus what is monitored.

6) Define and test metrics that prove operation (not just configuration)

Pick a small set of operational checks that are easy to evidence:

• A recurring report showing in-scope devices with healthy EDR/AV status.
• A sample set of alerts with tickets showing triage and closure.
• Evidence that unauthorized software attempts were blocked or remediated.

Required evidence and artifacts to retain

Keep evidence that proves both design and operating effectiveness:

Control design artifacts

• Control narrative for TSC-CC6.8 mapped to in-scope systems ¹
• Approved software standard and exception process
• Incident response procedures/work instructions for malware events
• Asset inventory or scoped system list (endpoints + production workloads)

Operating effectiveness artifacts

• EDR/AV deployment report (device list, last check-in, health status)
• Configuration screenshots/exports showing key settings (tamper protection, real-time protection, policy assignments)
• Alert samples with full ticket chain: detection → triage → containment → remediation → closure
• For exceptions: documented risk acceptance and compensating controls, plus review/renewal history

Practical tip: retain evidence continuously. Waiting for the audit period leads to missing logs and incomplete tickets.

Common exam/audit questions and hangups

Auditors and customers tend to ask:

• What systems are in scope and how do you know EDR covers them?
• How do you prevent unauthorized software installs on endpoints?
• Show me three malware/suspicious activity alerts and what you did.
• How do you handle developer workstations with elevated access?
• How do you treat production containers and ephemeral workloads?
• What happens if the security agent is disabled or stops checking in?

Hangup to expect: “We have alerts, but no documented follow-up.” A tool alert without a ticketed response usually fails the “act upon” clause.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in SOC 2 testing	Fix
“Antivirus exists” with no response workflow	Doesn’t prove you acted on detections	Require tickets for alerts above a defined threshold and retain closure evidence
Incomplete scope (endpoints covered, production ignored)	Malware can enter or persist in workloads	Define scope explicitly and show coverage reports per environment
Exceptions handled informally in chat	No audit trail	Use a formal exception register with approvals and compensating controls
No “authorized software” baseline	Cannot show “unauthorized” vs “authorized”	Document approved software categories and install controls
Evidence assembled only during audit	Missing logs and unclear timelines	Create a monthly evidence capture routine

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, failures here increase the chance that a malware event becomes a reportable incident, causes service downtime, or leads to customer trust erosion during due diligence. In SOC 2 terms, the risk is a control deficiency because you cannot demonstrate prevention/detection/response operating effectively. ¹

Practical 30/60/90-day execution plan

Days 1–30: Baseline and scope lock

• Confirm in-scope system inventory: endpoints, admin hosts, production workloads, CI/CD runners.
• Draft the TSC-CC6.8 control narrative (owner, tooling, scope, workflow).
• Validate EDR/AV coverage and identify gaps/exceptions.
• Stand up a simple evidence folder structure or use Daydream to centralize the control, mapping, and evidence checklist.

Deliverables: scoped asset list, control statement, initial coverage report, exception register template.

Days 31–60: Enforcement + response proof

• Implement or tighten installation controls (least privilege, software approval, allowlisting for high-risk admin devices).
• Configure alert routing and ticket creation for relevant detections.
• Run a tabletop or live test: simulate a malware alert, execute containment, document the ticket end-to-end.
• Start monthly evidence capture: coverage report + alert/ticket samples.

Deliverables: approved software standard, alert-to-ticket workflow, first monthly evidence package.

Days 61–90: Hardening, metrics, audit-ready packaging

• Reduce exceptions (reimage unmanaged devices, enroll stragglers, replace unsupported agents).
• Add supply-chain guardrails that match your environment (artifact controls, dependency scanning policy).
• Define recurring operational checks: agent health drift, unauthorized software detections, response timeliness targets.
• Prepare an auditor-ready packet: narrative, scope, evidence index, sample set.

Deliverables: audit packet, metrics dashboard or recurring reports, updated exception register with compensating controls.

Frequently Asked Questions

Do we need allowlisting to meet TSC-CC6.8?

No specific technology is mandated in the criterion text, but you must show effective prevention or limitation of unauthorized software and proof of operation. If you can’t enforce allowlisting, document alternative controls (least privilege + device management + monitoring) and retain evidence they work. ¹

Does “unauthorized software” include browser extensions and scripts?

It can, if extensions or scripts can affect in-scope services or admin access. Set a policy for high-risk categories (password managers, remote access tools, extensions with broad permissions) and show enforcement or monitoring.

How do we evidence “act upon” without a dedicated SOC team?

Use a lightweight but consistent ticket workflow with clear owners, timestamps, and closure notes. Auditors mainly need to see that alerts are reviewed and resolved with documented actions.

What about production containers where agents are hard to deploy?

Document how you detect malicious behavior through alternative telemetry (runtime security, cloud logs, Kubernetes audit logs) and how alerts still route into the same incident workflow. Pair that with hardened build/deploy controls to reduce introduction paths.

Are vulnerability scanners enough to satisfy this requirement?

Vulnerability scanning helps, but it doesn’t directly prove you prevent/detect/respond to malware or unauthorized software execution. Treat scanning as a supporting control, not the primary control for CC6.8. ¹

What’s the minimum evidence set auditors usually accept?

A clear control narrative, an in-scope asset list, recurring EDR/AV health reporting, and sampled alerts tied to incident tickets with containment and remediation details. Keep exception approvals and compensating controls with the same rigor. ¹

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017