TSC-C1.2 Guidance

TSC-C1.2 is a SOC 2 Confidentiality criterion that forces a practical question: “When we no longer need confidential information, can we prove we dispose of it safely and consistently?” The criterion is short, but the operational surface area is large. Confidential information can exist in production databases, data warehouses, analytics tools, collaboration platforms, endpoint caches, email, backups, removable media, paper files, and with third parties.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate TSC-C1.2 into a lifecycle control: define disposal triggers (retention schedules, contract termination, access revocation, customer request where applicable), map approved disposal methods to data types and systems, and create auditable workflows that generate durable evidence.

This page gives requirement-level implementation guidance you can execute quickly: scoping questions, step-by-step control design, artifacts to retain, and the audit friction points that commonly cause SOC 2 exceptions (missing evidence, unclear retention, and “we delete it manually sometimes” processes). The goal is simple: disposal that matches your objectives, and proof that it operates.

Regulatory text

Requirement (excerpt): “The entity disposes of confidential information to meet the entity’s objectives.” ¹

What the operator must do:
You need a defined, operating process that disposes of confidential information in a way that aligns to your organization’s stated objectives (legal/regulatory obligations, contractual commitments, security risk tolerance, and operational needs). For SOC 2 purposes, your auditor will expect you to (1) document the control activity, (2) show evidence it operated during the period, and (3) show you test/monitor it for effectiveness ¹.

Plain-English interpretation (what TSC-C1.2 really means)

Dispose means you don’t keep confidential data “just because it’s there.” You remove it, destroy it, or make it unrecoverable when it’s no longer needed.

To pass an audit, disposal must be:

• Intentional: tied to a retention schedule or disposal triggers, not ad hoc.
• Appropriate: the method fits the medium (cloud object storage vs. paper vs. encrypted disks).
• Provable: you can show an auditor what happened, when, by whom (or by what automated job), and under what policy.

Who it applies to (entity + operational context)

Applies to: any organization undergoing a SOC 2 audit that includes the Confidentiality category ¹.

Operationally, it applies wherever confidential information exists, including:

• Internal systems: production apps, databases, file stores, SaaS platforms, data warehouses, logs, CI/CD artifacts.
• Resilience layers: backups, snapshots, archives, DR replicas.
• Endpoints and collaboration: laptops, mobile devices, email, shared drives, chat tools.
• Physical media: printed documents, badges, removable drives.
• Third parties: cloud providers, managed service providers, shredding/destruction vendors, outsourced support.

If your SOC 2 scope includes customer data classified as confidential, your disposal controls must cover both your environment and any in-scope third parties that store or process that data.

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

Use this sequence to operationalize quickly. Treat it like a control build, not a policy-writing exercise.

1) Define “confidential information” for disposal purposes

Create (or reference) a classification definition that states what qualifies as confidential in your environment (customer data, regulated data types, sensitive business data). Then explicitly connect it to disposal requirements: “Confidential information must be disposed of per the retention schedule and approved methods.”

Output: data classification standard + disposal applicability statement.

2) Build a system-of-record for where confidential data lives

You do not need perfection, but you need defensible coverage of in-scope systems. Create a simple inventory that lists:

• System name and owner
• Data types (confidential categories)
• Storage locations (prod, non-prod, logs)
• Backup/archival approach
• Disposal method and trigger

Practical tip: Start with systems in SOC 2 scope, then expand.

Output: confidential data inventory (minimum viable register).

3) Define disposal triggers (the “when”)

Common triggers auditors recognize as objective-driven:

• Retention schedule expiration
• Contract termination / customer offboarding
• Employee/contractor offboarding (for endpoint/local copies)
• Media end-of-life (device disposal)
• Legal hold override (explicitly documented exception path)

Output: retention and disposal standard, including exception handling for legal holds and investigations.

4) Standardize disposal methods (the “how”)

Map method to medium and risk. Keep it simple and explicit:

Medium / location	Approved disposal method	Evidence produced
SaaS records (CRM, ticketing)	Admin deletion + retention settings	Admin logs, ticket, config export
Cloud storage objects	Lifecycle policies + deletion	Policy screenshot/export, deletion logs
Databases	Deletion job + access-controlled scripts	Job logs, change record, peer review
Backups/archives	Expiration policies; cryptographic erasure where supported	Backup policy evidence, key destruction record
Endpoints	Remote wipe; secure erase on decommission	MDM logs, decommission checklist
Paper	Cross-cut shred or certified destruction	Certificate of destruction, pickup manifest

You are aiming for “reasonable assurance” that disposed data cannot be reconstructed through normal means, and that the method matches your objectives.

Output: disposal methods matrix + referenced procedures/runbooks.

5) Implement workflow, approvals, and segregation of duties

Auditors get uncomfortable when one person can request, approve, and execute disposal for high-risk datasets.

Minimum workflow elements:

• Request/ticket raised with scope (system, dataset, reason/trigger)
• Approval by data owner (and security/privacy where appropriate)
• Execution by IT/engineering or automated job with change tracking
• Verification step (spot check, job success confirmation)
• Evidence attached to the record

Output: ticketing workflow + RACI.

6) Extend to third parties (TPDD alignment)

If a third party stores/processes your confidential information, you need contractual and operational disposal coverage:

• Contract clauses for return/disposal at termination
• SLAs or commitments for disposal timelines (write your own target; don’t invent “industry standard” numbers)
• Right to receive disposal attestations (certificate of destruction, deletion confirmation)
• Offboarding checklist requiring third-party confirmation

Output: standard contract language + offboarding checklist + completed samples.

7) Monitoring, review, and periodic assessment

TSC-C1.2 is commonly tested through sampling. Make sampling easy:

• Quarterly (or other defined cadence) review a set of completed disposal tickets/jobs
• Validate evidence quality: trigger, approval, method, proof
• Track defects and remediation

Output: review log, findings, remediation tickets, and closure evidence.

8) Test control effectiveness (SOC 2 readiness)

Before the audit window, perform an internal test:

• Select a sample across systems and disposal types
• Confirm evidence exists and is consistent
• Document results, gaps, and remediation

Output: control test plan, test results, and gap remediation evidence.

Required evidence and artifacts to retain

Auditors generally want to see both design evidence and operating evidence ¹. Build an evidence packet that includes:

Design artifacts

• Confidentiality/data classification policy (with disposal requirements)
• Data retention & disposal policy/standard
• Disposal methods matrix (by medium/system)
• System inventory showing where confidential information resides
• Third-party contract templates/clauses for disposal and offboarding

Operating artifacts (sampleable)

• Disposal tickets/requests with approvals
• System logs demonstrating deletion/erasure
• Backup retention/expiration configuration exports
• Certificates of destruction (physical media/paper)
• Offboarding checklists with third-party confirmations
• Periodic review and assessment records
• Control testing results and remediation evidence

Auditability rule: if the process is automated, keep configuration evidence and run logs; if manual, keep tickets, checklists, and sign-offs.

Common exam/audit questions and hangups

Expect these, and pre-wire your evidence:

1. “Define confidential information.”
   Auditors need your definition and scoping logic, not a generic statement.

2. “Show me where disposal is documented and who owns it.”
   Have a named control owner and a RACI.

3. “How do you dispose of data in backups?”
   Many teams rely on “backups age out” but cannot show the configuration or that it applies to all in-scope backup sets.

4. “Prove it happened during the audit period.”
   Policies do not pass sampling. Logs, tickets, and destruction certificates do.

5. “How do you handle exceptions like legal holds?”
   You need a documented override path and evidence that it’s controlled.

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating disposal as “delete in the app UI.”
  Fix: define approved methods and minimum verification steps per system.

• Mistake: ignoring non-production copies.
  Fix: include test/staging, analytics extracts, and support exports in your inventory and triggers.

• Mistake: no evidence trail for automated deletion.
  Fix: keep lifecycle policy configs, job run logs, and change records.

• Mistake: backups are out of sight, out of scope.
  Fix: explicitly document backup retention, expiration, and key management/erasure approach.

• Mistake: third-party offboarding has no closure criteria.
  Fix: require written deletion confirmation/certificate and store it with the offboarding record.

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime. Your direct risk is a SOC 2 exception, a qualified opinion, or customer trust friction if you cannot demonstrate disposal. Operationally, weak disposal increases breach impact (more data retained than needed), complicates incident response, and can create contractual failures around termination and data return/destruction.

30/60/90-day execution plan

This plan assumes you’re building to auditable maturity quickly. Adjust sequencing based on your SOC 2 audit period.

First 30 days: establish scope + minimum viable control

• Name a control owner and publish a one-page disposal standard tied to confidentiality classification.
• Build an inventory of in-scope systems where confidential data lives (start with production + backups + key SaaS tools).
• Define disposal triggers and exception handling (legal holds).
• Create the disposal methods matrix for top systems and media types.
• Stand up a ticket template/workflow for disposal with required fields and approvals.

Days 31–60: operationalize + third-party coverage

• Implement lifecycle/retention settings in high-volume systems (object storage, key SaaS repositories, backups where possible).
• Train system owners and IT/engineering on the disposal workflow and evidence expectations.
• Add third-party disposal language to templates; update offboarding checklists to require deletion confirmation.
• Run a first monthly/quarterly review of completed disposal events and document findings.

Days 61–90: test + harden for audit sampling

• Perform a control effectiveness test across disposal scenarios (app deletion, backup aging, endpoint wipe, third-party offboarding).
• Fix evidence gaps: missing approvals, missing logs, unclear triggers.
• Stabilize reporting: a simple dashboard or register of disposal requests/jobs completed, exceptions, and review outcomes.
• Prepare an audit-ready evidence binder organized by system and disposal type.

Where Daydream fits (practical)

If you manage disposal evidence across multiple systems and third parties, the work usually fails at the same point: scattered proof. Daydream can act as the system of record for the disposal control by standardizing control narratives, mapping systems/third parties to disposal methods, and collecting time-stamped evidence (tickets, logs, certificates) into an audit-ready package aligned to TSC-C1.2.

Frequently Asked Questions

Does TSC-C1.2 require a formal data retention schedule?

The criterion requires disposal to meet your objectives ¹. A retention schedule is the most common way to define those objectives operationally and make disposal auditable.

How do we show disposal for cloud backups if we can’t delete individual records?

Document your backup retention/expiration configuration and show that backups expire per policy, plus evidence that settings were in place during the audit period. If you rely on cryptographic erasure, retain key destruction records and the supporting procedure.

Are we required to shred paper, or is recycling acceptable?

Choose a method consistent with the sensitivity of the information and your objectives, then document it ¹. For confidential paper records, auditors typically expect shredding or certified destruction with evidence.

What evidence is “good enough” for automated deletion jobs?

Keep configuration evidence (what runs, on what cadence, and scope), change history, and run logs that show successful execution during the audit period. Pair that with periodic review results.

Do third parties have to provide a certificate of destruction?

TSC-C1.2 focuses on your ability to dispose of confidential information ¹. For third parties, a certificate or written confirmation is a clean, auditable artifact; make it a contract/offboarding requirement where feasible.

How do we handle legal holds without failing the control?

Write an exception process: legal hold approval, scope, duration, and release steps. Auditors usually accept retention beyond schedule if the exception is documented and controlled.

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 Trust Services Criteria 2017, TSC-C1.2