The entity restricts the transmission, movement, and removal of information to authorized users and processes

To meet the the entity restricts the transmission, movement, and removal of information to authorized users and processes requirement, you must implement technical and procedural controls that prevent data from leaving approved boundaries (systems, networks, accounts, and endpoints) unless an approved identity or system process is explicitly allowed. Auditors will expect both preventive controls (DLP, egress controls, device controls) and operating evidence that they work.

Key takeaways:

• Control “data leaving” through defined pathways: email, web upload, APIs, cloud sharing, removable media, and endpoint sync.
• Tie permissions to identities and system processes, then enforce with DLP/egress policy, encryption, and endpoint controls.
• Evidence beats intent: retain configurations, logs, alerts, exceptions, and periodic review sign-offs.

SOC 2 CC6.7 targets a failure mode that shows up in most real incidents: sensitive information moves faster than your controls. It can leave through legitimate channels (email, SaaS sharing links, API integrations) and illegitimate ones (personal cloud storage, removable media, unmanaged devices). The requirement is simple to state but easy to under-implement because teams confuse “access control” with “data movement control.” CC6.7 asks for both.

Operationalizing CC6.7 means you define approved routes for data transmission and removal, then you enforce those routes with guardrails that are hard to bypass. That includes controlling outbound network traffic, preventing unauthorized uploads and shares, restricting downloads and exports, locking down removable media, and governing automated processes like ETL jobs, backups, and integrations. It also means you can prove it, with evidence that a control was configured, enabled, monitored, and reviewed in the SOC 2 period.

This page gives requirement-level guidance for a Compliance Officer, CCO, or GRC lead: what to implement, how to scope it, what artifacts to retain, where audits get stuck, and how to execute quickly without writing a policy you cannot operate.

Regulatory text

Requirement (SOC 2 / Trust Services Criteria CC6.7): “The entity restricts the transmission, movement, and removal of information to authorized users and processes.” ¹

What the operator must do: You need enforceable controls that (1) define what “authorized” means for people and system processes, (2) restrict data exfiltration paths to only those authorized actors, and (3) produce evidence that restrictions are in place and operating. “Transmission” and “movement” include internal transfers between systems and external transfers out of the environment; “removal” includes downloads, exports, removable media, and data copied to unmanaged locations.

Plain-English interpretation (what CC6.7 is really testing)

CC6.7 tests whether your organization can stop data from leaving approved places unless the actor is explicitly allowed.

Think in verbs and pathways:

• Transmit: send data out (email, file transfer, web upload, API calls, SaaS sharing links).
• Move: transfer data between internal zones (prod to dev, customer tenant to tenant, restricted to unrestricted buckets).
• Remove: take data away from controlled storage (downloads to laptops, exports, screenshots/print-to-PDF, copying to USB, syncing to personal cloud).

“Authorized users and processes” means:

• Users: named identities with appropriate role-based access and business justification.
• Processes: service accounts, integrations, jobs, backup processes, and automation that are approved, authenticated, scoped, and monitored.

Who it applies to (entity and operational context)

Applies to the service organization in SOC 2 scope, including:

• Workforce members (employees, contractors) accessing systems that store or process customer data.
• Production systems and cloud services (IaaS/PaaS/SaaS) where customer data is stored, processed, or transmitted.
• Endpoints used to access in-scope systems (managed laptops, VDI, privileged workstations).
• Third parties and integrations that transmit or receive your data (support tools, ticketing, observability, payments, subprocessors).

Operational contexts where auditors focus:

• Customer data exports (support teams exporting tickets, admins exporting datasets).
• Engineering workflows (prod data copied to dev/test, logs containing sensitive data shipped to analytics).
• SaaS sharing (public links, external sharing, OAuth app grants).
• Remote work (downloads to endpoints, unmanaged devices, personal cloud sync).

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

Step 1: Define the “data movement boundary” (scope what must be controlled)

Create a simple boundary statement for in-scope information:

• Systems of record (databases, object storage, document stores)
• Approved collaboration/storage (corporate drive, approved ticketing/CRM)
• Approved transmission mechanisms (corporate email with controls, approved SFTP, approved API gateways)
• Approved endpoints (managed devices only, or VDI-only)

Deliverable: Data Movement & Egress Scope (one-page diagram + narrative).

Step 2: Inventory data egress paths and rank them

Build a table of common egress vectors and your current controls.

Minimum set to assess:

• Email (including forwarding rules)
• Web uploads (browser to cloud apps, paste sites)
• Cloud storage sharing (public links, external domains)
• API integrations and tokens (service accounts, OAuth apps)
• File transfer tools (SFTP, managed transfer, ad hoc tools)
• Endpoint channels (USB, local downloads, printing, clipboard, screen capture where feasible)
• Backups and exports (scheduled jobs, data warehouse extracts)

Deliverable: Egress Path Register with owner, systems, control coverage, and gaps.

Step 3: Set authorization rules for users and processes

Auditors want “authorized” to be explicit and reviewable.

For users, define:

• Which roles can export or download sensitive datasets
• Which roles can share externally, and to which domains
• Approval workflow for exceptions (time-bound, ticket-backed)

For processes, define:

• Which service accounts can transmit data externally
• Approved destinations (allowlist domains/IPs/buckets)
• Required auth method (short-lived tokens, mTLS, key management expectations)
• Monitoring requirements (logs, alerts on anomalous volume)

Deliverable: Data Movement Authorization Standard (policy + role matrix).

Step 4: Implement preventive technical controls (pick controls that block, not just detect)

Control choices vary by stack, but the control objectives are stable.

Email and collaboration

• Restrict auto-forwarding to external addresses (or require exception approval).
• Enforce external sharing rules: domain allowlists, block public links for sensitive repositories.
• Apply DLP rules for sensitive patterns and labeled documents where supported.

Network and cloud egress

• Route outbound traffic through controlled egress (proxy, secure web gateway, NAT with logging) where feasible.
• Use cloud controls to prevent public exposure and unauthorized replication (storage policies, bucket public access blocks, org policies).
• Restrict cross-environment movement (prod to dev) with segmentation and explicit break-glass workflows.

Endpoints

• Require managed devices for access to in-scope systems (MDM, device posture checks).
• Restrict removable media where risk warrants it; at minimum, log and monitor usage.
• Control local download locations for high-risk apps (VDI, hardened browsers, download restrictions where feasible).

Processes and integrations

• Centralize secrets and rotate keys; prefer scoped service identities.
• Restrict API tokens by least privilege and approved IPs/apps where possible.
• Log exports and bulk pulls; alert on unusual volumes or destinations.

Deliverable: Control Implementation Record mapping each egress path to a blocking/detecting control and system owner.

Step 5: Add monitoring, alerting, and exception handling that an auditor can trace

A working CC6.7 program has a closed loop:

• Alerts for blocked/allowed events (DLP hits, external shares, large exports, new OAuth grants)
• Ticketed triage and outcome (approved, remediated, false positive)
• Exception process that is time-bound and reviewed

Deliverable: Data Movement Exception Log with approvals and expiry dates.

Step 6: Prove operation with periodic reviews

Set a review cadence that matches your change rate:

• Review external sharing settings and public links.
• Review high-risk roles with export permissions.
• Review service accounts and integration destinations.
• Sample recent export/audit logs and confirm they align to authorization rules.

Deliverable: Quarterly (or monthly) CC6.7 Control Review sign-off.

Required evidence and artifacts to retain (what auditors ask for)

Retain evidence that shows design and operating effectiveness:

Design evidence

• Data classification and handling standard (focused on transmission/movement/removal rules)
• Egress Path Register and authorization matrix
• System configurations (screenshots/exports): sharing restrictions, DLP policies, email forwarding settings, cloud storage public access blocks, CASB/SWG policies, endpoint device control policies
• Architecture diagram showing controlled egress points (where applicable)

Operating evidence

• Audit logs showing exports/downloads/shares and the identities involved
• DLP/SWG/CASB alert samples with tickets and resolutions
• Change management records for policy changes (who approved, when applied)
• Exception approvals with expiry and re-approval evidence
• Access reviews for roles allowed to export/share

Tip for faster audits: maintain a CC6.7 evidence binder organized by egress channel (email, cloud sharing, endpoints, APIs, backups) with “config + 2–3 operating samples per month/quarter,” depending on your audit approach.

Common exam/audit questions and hangups

Auditors frequently probe these areas:

• “Show me how you prevent customer data from being emailed to a personal address.” If you only have a policy, you will struggle.
• “Who is allowed to export data, and how is that enforced?” They expect a role matrix plus system permissions.
• “How do you control service accounts moving data to third parties?” Service identities and destination allowlists are a common gap.
• “How do you detect bulk downloads or unusual exports?” Logging, thresholds, and triage evidence matter.
• “How do you prevent prod data from being copied into dev?” If you permit it, you need approvals, masking, or a documented, controlled pathway.

Hangup pattern: teams provide access control evidence (CC6.1-ish) but not data movement restriction evidence (CC6.7).

Frequent implementation mistakes (and how to avoid them)

1. Relying on “policy-only” controls.
   Fix: pair every policy statement with a technical enforcement point or a monitoring control with tickets.

2. Ignoring system processes.
   Fix: treat service accounts as first-class actors. Inventory them, scope their permissions, and log their egress.

3. Assuming “encryption in transit” satisfies CC6.7.
   Fix: encryption protects confidentiality in transit; CC6.7 tests whether the transfer is authorized at all.

4. Not scoping endpoints.
   Fix: define whether downloads to endpoints are allowed, and under what conditions (managed only, VDI only, restricted roles).

5. No exception lifecycle.
   Fix: require time-bound exceptions with re-approval and an owner. Auditors look for expired exceptions that stayed in place.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, but the risk is straightforward: weak controls over transmission/movement/removal increase the likelihood and impact of data exfiltration, unauthorized disclosure, and scope expansion during incident response. In SOC 2 terms, CC6.7 gaps often surface as control exceptions tied to data loss pathways (external sharing, exports, integrations, unmanaged devices).

Practical 30/60/90-day execution plan

Days 0–30: Establish control scope and quick wins

• Define in-scope data types and repositories tied to SOC 2 scope.
• Build the Egress Path Register and pick owners per path.
• Implement quick blocks: disable external auto-forwarding where feasible; block public links on sensitive repositories; enforce managed-device access for core admin tools.
• Stand up a lightweight exception workflow (ticket template + approver list).

Days 31–60: Implement enforceable restrictions across top egress paths

• Deploy/finish DLP or equivalent controls for email and cloud sharing where your stack supports it.
• Add outbound logging and alerting for high-risk egress points (proxy/SWG logs, cloud audit logs).
• Formalize the authorization matrix for export/share permissions and align system roles to it.
• Inventory service accounts and document approved data destinations for each integration.

Days 61–90: Prove operating effectiveness and make audit-ready

• Run a first periodic review: external shares, export-capable roles, service accounts, exceptions.
• Collect operating samples: blocked events, allowed events, triage tickets, and reviewer sign-offs.
• Close high-risk gaps found in review (stray public links, over-permissioned export roles, unknown integrations).
• Package evidence by egress channel for the auditor.

Where Daydream fits naturally: if you are juggling multiple systems for logs, approvals, and evidence, Daydream can centralize control narratives, map each egress path to its enforcing control, and keep operating evidence tied to the control so you are not rebuilding the audit trail every period.

Frequently Asked Questions

Does CC6.7 require DLP?

No. CC6.7 requires that transmission, movement, and removal are restricted to authorized users and processes. DLP is a common way to enforce and evidence that restriction, but other combinations (egress controls, sharing restrictions, endpoint controls, and logging with approvals) can meet the objective.

What counts as “removal of information” in practice?

Exports, downloads, printing to file, copying to removable media, and syncing/copying data to unmanaged locations are common “removal” paths. Auditors usually focus on the paths that allow data to leave controlled systems and become hard to track.

How do we handle support teams that need to export data for customers?

Define an approved export method, limit export permissions to specific roles, and require a ticket-based justification for each export or for elevated export access. Keep export logs and samples that tie the event back to the approved workflow.

Are service accounts and integrations in scope for “authorized processes”?

Yes. A scheduled job that pushes data to a third party is a “process” under CC6.7. You need an inventory of those processes, scoped permissions, approved destinations, and logs that show the activity is monitored.

If we allow external sharing in one SaaS app, will we fail SOC 2?

Allowing external sharing is not automatically a failure. You need explicit authorization rules (who can share, to which domains, what data types) and evidence that settings and monitoring enforce those rules, plus a documented exception process.

What evidence is fastest to produce for auditors?

Configuration exports/screenshots for the key restriction settings, audit logs showing export/share events, and a small set of triage tickets that show detection and response. Add a periodic access/exception review sign-off to demonstrate ongoing operation.

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