CC6.7 Data transmission, movement and removal

Assessors testing CC6.7 for data in motion want to see that every channel carrying customer or internal data is encrypted, that the configuration allows only approved protocols, and that certificates are issued, tracked and renewed under control. The evidence is mostly configuration state plus records showing that state held over time. Platform or security engineers generate it from load balancers, ingress controllers, service mesh settings, database connection settings and the certificate authority, and the auditor samples both current settings and historical changes.

• Configuration exports: Snapshots of TLS settings from reverse proxies, ingress controllers and internal services, showing enabled protocol versions and cipher suites, taken from the running configuration rather than the template.
• Certificate inventory: A list of every certificate in use, with issuer, subject, expiry date and the owning system. For Kubernetes workloads, cert-manager resources and their Secrets are the usual source.
• Renewal logs: Records showing automatic or manual renewals before expiry, including failed attempts and how they were resolved.
• Change records: Tickets or pull requests for any change to TLS policy, linked to approval.

In a Type 2 sample, the auditor usually selects several sample dates across the period and asks for the configuration and certificate inventory as of each date, then checks a handful of renewals. Confirm with your auditor how many dates and renewals they expect for your population, and capture these records on a fixed schedule so no gap needs explaining.

Where applications encrypt data themselves, or call a service to do so, the auditor needs proof that keys are controlled, rotated and used only by authorized people and processes. Evidence here centers on the key management system, so the platform team typically owns it, with the security team reviewing it. Key version history and key operation logs are the core artifacts, and they must be kept for the whole period, not reconstructed at audit time.

• Key version history: Export of key versions, creation dates and state changes from the key management system, such as the OpenBao transit secrets engine, which supports versioned keys and rotation.
• Rotation records: Evidence that rotation ran on the schedule your policy sets, including the operator or automation identity that performed it.
• Key operation audit logs: Logs of encrypt, decrypt, sign and key administration calls, showing which identities made them.
• Access to key operations: Current and historical policies that define who may administer keys and who may use them, with periodic access reviews.

In a Type 2 sample, the auditor often picks a key, traces its version history across the period, and then checks that rotations happened when the policy said they should. They may also sample key operation logs to confirm that only expected service identities decrypted data. Ask your auditor whether they want logs from the key system or from the application, and confirm that log retention covers the whole period.

Self-hosted file platforms move data between users, devices and external parties, so CC6.7 evidence must show both how files are protected at rest and in transit and how sharing is restricted. Nextcloud, for example, offers server-side encryption that protects file contents on local and external storage with keys held on the server, but it does not encrypt file names or folder structure, so your evidence must describe that limit. Administrators generate the configuration evidence, and the security team reviews sharing policy.

• Encryption settings: Snapshots of the server-side encryption state, showing whether it is enabled, which storage is covered and who may enable or disable it.
• Admin configuration snapshots: Exports of the configuration files that control sharing, link expiry, password requirements for public links and external user access, captured on the dates the auditor selects.
• Sharing and external link policy: The written rule set, plus records of any exceptions granted.
• Sync client controls: Settings that govern which devices may sync and whether remote wipe is available, where the platform supports it.

In a Type 2 sample, the auditor usually asks for the configuration as of several dates, then selects a few external shares and checks that they followed policy and were approved where required. Confirm with your auditor how they want to see the limit on file name encryption addressed, since an unexplained gap is more likely to draw questions than a documented one.

Removing information from the system through a USB drive, an external disk or a laptop is where CC6.7 meets endpoint management. Evidence has to show that device controls exist, that exceptions are approved and bounded, and that every in-scope endpoint is inventoried with its encryption status. The endpoint or IT team generates most of this from device management tools, and the security team approves exceptions. Because device state changes constantly, auditors rely heavily on dated exports.

• Device policy exports: Exports of the mobile or endpoint management policy showing removable media restrictions, disk encryption requirements and screen lock rules, with the policy version and assignment groups.
• USB restriction settings: Configuration showing which device classes are blocked or allowed, and whether restrictions apply to all users or only some.
• Exception approvals: Signed or ticketed approvals for any device or user granted an exception, including the business reason and an end date.
• Device inventory with encryption status: A list of devices with owner, operating system, last check-in and disk encryption state, exported for each sample date.

In a Type 2 sample, the auditor typically takes the inventory as of several dates, checks that each sampled device shows encryption enabled, and then reviews exceptions to confirm they were approved and expired on time. Ask your auditor how they will treat devices that are offline at the sample date, and decide in advance how your team records them.

Your organization owns CC6.7 in full. The criterion asks you to limit how information is transmitted, moved and removed, and to protect it along the way, so the decisions about what is allowed belong to you. No outside party can decide which data may leave the environment, which channels are approved, or whether an exception is acceptable. Those choices must be documented, approved by someone with authority over the risk, and reviewed when the system changes.

• Data classification: Decide which information is sensitive enough to require encryption, approval for transfer, or blocking from removable media.
• Approved channels: Name the transfer methods permitted for each data class, such as managed file sharing, secure APIs or email with encryption, and retire the rest.
• Policy and standards: Write the transmission, removable media and endpoint policies, and assign an owner for each.
• Exception sign-off: Record each exception, its business reason, its compensating control, its expiry date and the approver's name.
• Ongoing review: Confirm the channel list and exceptions still match the system description after every material change.

Before engaging anyone, check that these decisions already exist in writing, because an auditor will test whether the approvals were actually followed.

An implementation partner such as DeployOpen works on the technical controls that carry the decisions above. Under a fixed-scope written agreement, a partner can plan and configure self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, set up encryption and certificate issuance, and prepare the evidence the auditor will request. The partner prepares systems and records. It does not own the policy, approve exceptions, or attest that the controls work.

• Encryption setup: Configure server-side or key-managed encryption for stored and transmitted data on the platforms in scope.
• Certificate issuance: Build internal certificate authorities or automated issuance for internal services, with renewal and revocation procedures.
• Transfer and endpoint evidence: Produce configuration exports, logs and reports showing which channels are enabled and which devices are protected.
• Documentation: Write runbooks and a control matrix mapping each CC6.7 point of focus to the system that implements it.
• Scope limits: Confirm in writing which systems, environments and evidence types are covered, and who approves changes to that scope.

Ask for the deliverables, the named evidence and the acceptance criteria in the written scope before work begins.

The auditor is an independent licensed CPA firm. It tests whether CC6.7 controls are designed appropriately and, in a Type 2 examination, whether they operated effectively over the period. It then issues the report. Independence is the core requirement: the firm cannot design, implement or operate the controls it tests, because that would mean testing its own work. The line between preparing evidence and performing the examination is where most engagement questions arise.

• Design testing: Evaluate whether the channel rules, encryption settings and removable media controls would meet the criterion if they worked as described.
• Operating testing: Sample transfers, device records and certificate renewals across the period to confirm the controls ran as designed.
• Independence: Expect the firm to decline work that would make it responsible for your controls, such as writing your policies or configuring your systems.
• Evidence requests: Expect a request list covering approvals, exception logs and configuration exports, and check that each item exists before fieldwork.
• Report: Only the auditor issues the SOC 2 report, and it states its own opinion, not yours or your partner's.

Confirm with the firm, before signing, which preparation services it will provide and which it will decline.