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

CC6.7 — Protection of data in transmission and movement

The transmission, movement, and removal of information is restricted and protected during transmission, movement, or removal.

Also written as CC 6.7, TSC CC6.7, SOC2 CC6.7, SOC 2 Type 2 CC6.7.

Written by Jett N. · Last reviewed

What SOC 2 CC6.7 requires

Protection of data in transmission and movement is one of 8 criteria in the Logical and Physical Access Controls (CC6) series of the Security (Common Criteria) category. The transmission, movement, and removal of information is restricted and protected during transmission, movement, or removal. 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.7, gather artefacts such as:

  • TLS configuration evidence (1.2+ on all endpoints)
  • Encryption of data transfers (SFTP, secure email)
  • Removable media restrictions and DLP configuration
  • Mobile device management (MDM) enrollment evidence

Points of focus for CC6.7

The Trust Services Criteria set out points of focus that describe what an auditor considers when assessing CC6.7. They are not themselves requirements, but they shape the testing:

How to implement CC6.7

  1. Prove TLS configuration rather than asserting itA scan report from a tool such as SSL Labs, covering every external endpoint, is concrete evidence. A statement that "all traffic is encrypted" is not. Check the endpoints nobody thinks about: legacy APIs, mail gateways, and anything a partner integrates with.
  2. Decide your position on removable media and enforce it technicallyBlocking USB mass storage through endpoint management is simpler to evidence than a policy asking people not to use it. If you allow it, encryption enforcement and logging become the evidence instead.
  3. Cover the transfer paths people actually useEmail, chat file sharing, personal cloud storage and AI tools are how data really leaves. A DLP or CASB position on these — even a documented decision to accept the risk — is stronger than a control that only addresses SFTP.
  4. Manage endpoints as part of the transmission storyMDM enrolment, disk encryption and remote wipe are what protect information in movement on devices. Enrolment coverage reconciled against the device inventory is the evidence, and the gap is usually contractor or BYOD hardware.
  5. Document secure disposalDisposal is explicitly in the criterion and is usually handled by a third party. Keep the certificates of destruction and make sure they reconcile to specific assets in your inventory.

Common audit findings for CC6.7

What actually gets raised against CC6.7, in rough order of how often it comes up:

Scoping CC6.7

CC6.7 is Common Criteria. It overlaps heavily with the Confidentiality category if you have scoped C1 in, and with ISO 27001 A.8.10 to A.8.12. Fully remote organisations should pay particular attention to the endpoint half of this criterion, which is where their exposure concentrates.

ISO 27001 mapping

CC6.7 corresponds to the following ISO 27001:2022 Annex A control(s): A.5.10, A.5.14, A.5.23, A.6.7, A.7.9, A.7.10, A.8.1, A.8.12, A.8.24. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC6.7 rather than duplicating work.

Map CC6.7 to ISO 27001 & NIST CSF →
Crosswalk this criterion in the Control Mapper & Gap Assessment.
Document the risk →
Record treatment for gaps against CC6.7 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.8 Prevention and detection of malicious software

All CC6 Logical and Physical Access Controls criteria →

Frequently asked questions

Is CC6.7 required for a SOC 2 report?

Yes. CC6.7 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.7?

In a Type 1 report the auditor assesses design only — does a control exist at a point in time that would meet CC6.7 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.7 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.7 map to ISO 27001?

Yes — CC6.7 aligns with ISO 27001:2022 Annex A control(s) A.5.10, A.5.14, A.5.23, A.6.7, A.7.9, A.7.10, A.8.1, A.8.12, A.8.24. 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.

What are the most common audit findings for CC6.7?

Endpoints still permitting TLS 1.0 or 1.1, typically on a legacy integration endpoint nobody owns. MDM enrolment coverage below the device inventory, usually contractor machines.