TSC-CC6.7 Guidance

TSC-CC6.7 is one of the most operational SOC 2 criteria because it forces a simple question: “Who, or what automated process, is allowed to move company data out of its current boundary?” The boundary might be a production database, a cloud tenant, a corporate endpoint, or a controlled SaaS workspace. Auditors typically look for two things: (1) you have defined rules for permitted transmissions and removals, and (2) those rules are actually enforced through systems, not just written down.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate CC6.7 into a small set of enforceable guardrails: approved transfer channels, controlled exports, restricted removable media, and monitoring for bypass attempts. This requirement also covers “authorized processes,” which many teams miss; service accounts, integrations, batch jobs, and CI/CD pipelines must be constrained just like human users.

The goal is not to stop the business from moving data. The goal is to make data movement intentional, approved, and traceable to a person or process you can defend in an audit ¹.

Regulatory text

Requirement (excerpt): “The entity restricts the transmission, movement, and removal of information to authorized users and processes” ¹.

Operator interpretation (what you must do):

• Restrict transmission: control how data leaves or moves between networks/systems (email, web uploads, APIs, SFTP, sharing links, SaaS connectors).
• Restrict movement: control internal transfers and copies that change the data’s security boundary (prod to dev, workspace to workspace, tenant to tenant, region to region).
• Restrict removal: control exports and local copies (downloads, print, clipboard, screenshots, removable media, local sync folders).
• Authorized users and processes: permissions must apply to both people and non-human identities (service accounts, jobs, integration tokens) ¹.

Your audit story should be: “We define approved data movement paths; we block or require approval for unapproved paths; we detect and investigate exceptions; we review the control’s effectiveness on a recurring cadence.”

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

CC6.7 tests whether you can prevent “easy exfiltration” and uncontrolled sprawl. Auditors know that once data can be copied anywhere, other controls weaken fast (access reviews, retention, incident response, even encryption). This criterion is satisfied when:

• The organization can name the systems and channels through which sensitive information is allowed to move.
• Only the right users and processes can use those channels, based on job role and business need.
• Attempts to bypass controls are visible in logs and handled through a defined workflow ¹.

Who it applies to

Entity scope: Organizations undergoing a SOC 2 audit using the AICPA Trust Services Criteria ¹.

Operational contexts where CC6.7 is commonly evaluated:

• Cloud environments: object storage sharing, cross-account replication, outbound internet access from workloads.
• SaaS collaboration: file sharing links, external guests, downloads to unmanaged devices.
• Endpoints: USB, local sync, browser downloads, copy/paste to personal accounts.
• Data pipelines: ETL jobs, analytics exports, backups, and vendor data feeds.
• Third-party connections: support tooling, ticket attachments, shared drives, customer data extracts.

If you process customer data, regulated data, or proprietary code, CC6.7 tends to land directly in scope because data movement paths are part of the system boundaries defined for SOC 2.

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

1) Define “information” and classify what needs restriction

• Create a practical classification model used in operations (example: Public, Internal, Confidential, Restricted).
• Map where each class lives (core SaaS, cloud storage, databases, endpoints).
• Write the policy statement: which classes require restricted transfer and which may move freely ¹.

Deliverable: Data handling / data movement standard tied to classification.

2) Define approved transmission, movement, and removal paths

Build an “Approved Data Movement Matrix” that lists:

• Source system (e.g., production DB)
• Destination type (e.g., customer, third party, internal analytics)
• Allowed method/channel (API, SFTP, secure link, managed endpoint sync)
• Required controls (encryption, auth method, approval, logging, DLP)
• Authorized roles/processes (support engineer role; ETL service account)
• Exception path (how to request a one-off export)

This matrix becomes your control baseline and your audit map ¹.

3) Enforce restrictions with technical controls (not just policy)

Common enforcement points auditors expect to see:

• Identity and access management (IAM): least privilege for exports, downloads, and sharing; separate admin roles; scoped API tokens.
• Egress controls: outbound firewall rules, proxy allowlists, VPC endpoints/private links, blocked unsanctioned file transfer services.
• DLP / content controls: prevent sharing externally, block uploads of certain data types, prevent downloads to unmanaged devices.
• Endpoint controls: restrict USB/removable media, require device management for local sync, control printing if relevant.
• Service accounts and processes: restrict where automated jobs can write data; rotate credentials; narrow token scopes ¹.

If you can’t block a path, require compensating controls: ticketed approval, time-bounded access, and enhanced monitoring.

4) Implement an exceptions and approvals workflow

Auditors accept exceptions when they are controlled. Minimum viable workflow:

• Request form or ticket template captures: dataset, purpose, recipient, method, retention period, and approver.
• Approval by data owner (business) and security/compliance for restricted data.
• Time-bound access and documented secure transfer method.
• Post-transfer verification: confirm recipient, confirm deletion/retention terms where applicable ¹.

5) Log, monitor, and review data movement events

CC6.7 expects you to prove operation:

• Centralize logs for exports/downloads/shares where feasible (SaaS audit logs, cloud access logs, endpoint telemetry).
• Alert on high-risk events (mass downloads, external share link creation, unusual geo/IP, service account exporting outside normal schedule).
• Run periodic reviews: sample events, validate approvals exist, confirm exceptions were closed ¹.

6) Test control effectiveness and document results

Run control tests aligned to your matrix:

• Attempt an unapproved external share; confirm it is blocked or triggers approval.
• Attempt export by a non-authorized role; confirm denied.
• Validate service account cannot write to unapproved destinations.
• Verify logging exists and is queryable for the audit period ¹.

Where Daydream fits (practitioner use)

If you struggle to keep policy, system configs, review evidence, and exception tickets tied together, Daydream can act as the control binder: a single place to map CC6.7 to your approved movement matrix, collect config snapshots/log samples, and track recurring review tasks so the audit evidence stays current.

Required evidence and artifacts to retain

Keep artifacts that show design and operation:

Design evidence

• Data classification and handling standard that includes transfer/removal rules ¹.
• Approved Data Movement Matrix with roles/processes and allowed channels.
• Procedures for exports, external sharing, and exceptions.
• System boundary description showing where data is stored and how it is allowed to flow.

Operational evidence

• Configuration screenshots/exports: IAM permissions, DLP rules, egress allowlists, endpoint policies.
• Audit logs: representative samples of downloads/exports/shares; cloud access logs; SaaS sharing logs.
• Exceptions/approvals tickets with approvals, timestamps, and closure notes.
• Monitoring artifacts: alert rules, alert triage records, investigation tickets.
• Periodic review results and remediation actions ¹.

Common exam/audit questions and hangups

Expect auditors to ask:

• “Show me how you prevent unauthorized exports from production data stores.”
• “Who can create external share links? How do you restrict guests?”
• “How do you control service accounts and integrations that move data?”
• “Show evidence that you review high-risk transfers and exceptions.”
• “What happens if an engineer needs a one-time customer data extract?” ¹

Common hangups:

• Teams provide policies but lack proof that settings enforce them.
• Logging exists, but nobody can demonstrate a review or investigation trail.
• Controls cover humans but not “authorized processes.”

Frequent implementation mistakes (and how to avoid them)

1. No definition of “authorized process.”
   Fix: inventory service accounts/integration tokens; apply least privilege; document approved destinations per process ¹.

2. Relying on “training” instead of enforcement.
   Fix: block or gate external sharing and exports; use exceptions workflow for business needs.

3. Over-scoping: trying to control every byte everywhere.
   Fix: start with Restricted/Confidential data and the systems in SOC 2 scope; expand after stabilization.

4. Evidence gaps during the audit period.
   Fix: schedule recurring evidence capture (config snapshots, log samples, review sign-offs) and store in a single control record ¹.

Risk implications (why auditors care)

Uncontrolled data movement creates:

• Data leakage risk (customer data, secrets, source code).
• Loss of chain-of-custody for incident response.
• Compliance breakdown in retention and deletion.
• Contractual failures if customer terms restrict subcontractors or cross-border transfers.

SOC 2 is an audit framework rather than a regulator, but CC6.7 failures often become report exceptions that customers treat as a security red flag ¹.

Practical 30/60/90-day execution plan

Days 0–30: Baseline and quick controls

• Confirm in-scope systems and data types for SOC 2 boundary.
• Publish a short data movement standard and interim export procedure ¹.
• Build the Approved Data Movement Matrix for top systems (prod DB, cloud storage, primary collaboration tool).
• Turn on audit logging in key platforms; confirm retention supports the audit period.
• Implement quick wins: restrict external sharing defaults, require managed devices for downloads where feasible.

Days 31–60: Enforcement + exceptions workflow

• Implement egress restrictions for cloud workloads where practical.
• Tighten IAM permissions for exports/downloads; remove broad “admin-like” roles.
• Stand up the exceptions workflow with required fields, approvals, and closure checks.
• Define alerting for high-risk transfers and create an investigation runbook ¹.

Days 61–90: Operational maturity + testing

• Run a first periodic review cycle (sample transfer events, validate approvals, document findings).
• Execute control tests and record results; remediate gaps and retest.
• Improve “authorized process” controls: token scope reviews, service account destination restrictions.
• Package evidence by control so auditors can trace policy → configuration → logs → review/testing ¹.

Frequently Asked Questions

Does TSC-CC6.7 require DLP tooling?

No specific tool is required; CC6.7 requires that transmission/movement/removal is restricted to authorized users and processes ¹. DLP is one common way to enforce and evidence that restriction.

What counts as an “authorized process”?

Any non-human identity or automation that can move data: service accounts, integration tokens, scheduled jobs, CI/CD pipelines, and managed scripts ¹. Treat them like users: least privilege, approved destinations, and logging.

Are one-off customer data extracts allowed?

Yes, if you control them. Use a documented exception workflow with approvals, secure transfer method, and logs that show who exported what and when ¹.

How do we handle external collaboration (customers/partners) without failing CC6.7?

Define allowed collaboration methods (guest access rules, secure links, managed workspaces) in the movement matrix, restrict everything else, and monitor external sharing events through audit logs ¹.

What evidence is most often missing in audits?

Proof of operation: log samples tied to specific restricted actions, documented periodic reviews, and exception tickets that match observed exports or shares ¹.

Our data is spread across many SaaS tools. Where do we start?

Start with the systems in SOC 2 scope and the data classes that would cause the most harm if exfiltrated. Build the movement matrix for those first, then expand coverage tool-by-tool ¹.

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