CC6.8 CC6 · Logical and Physical Access Controls · Security (Common Criteria)

CC6.8 — Prevention and detection of malicious software

Controls are implemented to prevent or detect and act upon the introduction of unauthorized or malicious software.

Also written as CC 6.8, TSC CC6.8, SOC2 CC6.8, SOC 2 Type 2 CC6.8.

What SOC 2 CC6.8 requires

Prevention and detection of malicious software is one of 8 criteria in the Logical and Physical Access Controls (CC6) series of the Security (Common Criteria) category. Controls are implemented to prevent or detect and act upon the introduction of unauthorized or malicious software. CC6 is the heaviest-tested series in most SOC 2 reports and the one where exceptions most often appear — expect user access reviews, provisioning and deprovisioning tickets, and configuration exports to be sampled across the full period.

Audit evidence assessors look for

When preparing for a SOC 2 audit against CC6.8, gather artefacts such as:

  • EDR / anti-malware deployment and coverage report
  • Malware detection and remediation logs
  • Application allow-listing or hardening configuration
  • Patch management records for endpoints and servers

ISO 27001 mapping

CC6.8 corresponds to the following ISO 27001:2022 Annex A control(s): A.8.1, A.8.7, A.8.18, A.8.19, A.8.23. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC6.8 rather than duplicating work.

Map CC6.8 to ISO 27001 & NIST CSF →
Crosswalk this criterion in the Control Mapper & Gap Assessment.
Document the risk →
Record treatment for gaps against CC6.8 in the Risk Register.

Other Logical and Physical Access Controls criteria

CC6.1 Logical access security architecture CC6.2 Provisioning and deprovisioning CC6.3 Role-based access and least privilege CC6.4 Physical access restriction CC6.5 Secure disposal CC6.6 Protection against external threats CC6.7 Protection of data in transmission and movement

All CC6 Logical and Physical Access Controls criteria →

Frequently asked questions

Is CC6.8 required for a SOC 2 report?

Yes. CC6.8 sits in the Common Criteria, which apply to every SOC 2 engagement regardless of which additional categories you scope in — there is no SOC 2 report that omits them.

How does an auditor test CC6.8?

In a Type 1 report the auditor assesses design only — does a control exist at a point in time that would meet CC6.8 if it operated. In a Type 2 report they also test operating effectiveness by sampling evidence from across the review period, typically 3 to 12 months. That difference is why Type 2 evidence has to be continuous rather than assembled the week before fieldwork.

What happens if CC6.8 fails testing?

A control that fails becomes an exception, which the auditor describes in the report along with management's response. Exceptions do not automatically make a report "failed" — a SOC 2 report is an opinion, not a pass/fail certificate — but a qualified opinion is what customers notice, so remediate and re-test before fieldwork closes where you can.

Does SOC 2 CC6.8 map to ISO 27001?

Yes — CC6.8 aligns with ISO 27001:2022 Annex A control(s) A.8.1, A.8.7, A.8.18, A.8.19, A.8.23. If you already run a certified ISMS, re-point that evidence rather than building a parallel set; the underlying control is the same and only the reporting format differs.