C1.2 Disposal of confidential information: SOC 2 evidence

What C1.2 asks for when confidential data is no longer needed

C1.2 requires the organization to dispose of confidential information in line with its confidentiality objectives, so the question an auditor or customer is really asking is whether you can show that confidential data is destroyed when its purpose ends, and that the destruction follows the commitments you made. The criterion has two parts that an assessor will test separately: identifying which confidential information is due for destruction, and destroying it. Its points of focus are written around those two activities, and the physical side of disposal, such as shredding paper records or wiping and removing retired drives, is covered alongside CC6.5, which addresses disposal of physical assets. Read C1.2 as the data-level counterpart to that physical control, not as a replacement for it.

The risk is rarely the production database. It is the copies that outlive their purpose: a nightly export pulled into a spreadsheet for a one-time analysis, a staging environment seeded with customer records, a support ticket attachment, a backup set that still holds data from a customer who has left, or a laptop that synced a shared folder. Data sprawls across SaaS applications, self-hosted systems, backup repositories, object storage and endpoints, and each one has its own retention behavior. Identification is hard because most teams do not have a single inventory of where confidential data lives, so the disposal decision depends on knowing the locations first. Confirm with your own environment which systems hold confidential data, which of them have automated deletion, and which depend on someone remembering to act.

Before the audit period starts, decide three things and write them down: which categories of confidential information have a defined end of purpose, what triggers destruction for each (contract termination, retention period expiry, or a customer request), and who approves the destruction and keeps the record. Ask your auditor how they expect disposal to be evidenced for the period under review, because the answer determines whether you need deletion logs, certificates of destruction from a vendor, or ticket records. Ask your backup and retention vendors what they actually delete and how long deleted data persists in backups, since those answers are what an assessor will test against your stated commitments.

Which data, systems and third parties fall under C1.2 disposal

The disposal work is only as complete as the scope behind it. Scope follows the system description and the organization's confidentiality commitments, so the first step is deciding which data counts as confidential and where copies of it live. The cards below cover the decisions and locations that most often change the size of the disposal program.

Confidential data as the organization defines it

C1.2 is measured against the confidentiality commitments the organization has made to customers, so the scope starts with its own definition of confidential information. Contracts, statements of work, data processing terms and the system description usually name the data types in play, such as customer records, credentials, financial files or proprietary code. Check that the classification used by the disposal process matches the wording in those commitments, because a gap between the two is a common source of exceptions.

Production and staging stores

Primary databases, object storage, file shares and caches in production are the obvious locations, but staging environments often hold copies of production data taken for testing. Each copy that contains confidential information belongs in the disposal inventory, along with the retention rule that applies to it. Ask engineering to list every environment that receives data extracts, including ad hoc exports used for debugging or support.

Backups, logs and analytics copies

Backup sets, log pipelines and analytics warehouses are the stores most often left out of disposal schedules, because they are managed by different teams and keep data for reasons other than operations. Application logs can capture payloads, and analytics platforms can replicate tables with personal or customer identifiers. Confirm the retention period for each of these stores, who can trigger deletion, and whether deleted records are removed from replicas and archived snapshots.

SaaS and subservice provider copies

Any SaaS tool, email platform, support desk, payment processor or hosting provider that receives confidential information holds a copy that the organization must dispose of or have disposed of. Review each contract and data processing terms for deletion obligations, return-or-delete options and the timing of deletion after termination. Where a subservice organization performs disposal, request its documented procedure and the evidence it provides, and record how that evidence is kept for the auditor.

Customer-owned data in self-hosted deployments

When the software runs in a customer's own cloud account, data center or air-gapped network, the customer usually controls the storage and the provider may never hold the data at all. The commitments then determine who is responsible for disposal, and the provider's role may be limited to delivering deletion procedures, tooling and instructions. Document which party performs each step, what the customer must confirm, and what evidence the provider can reasonably supply without taking custody of the data.

Decommissioned hardware and removable media

Retired servers, laptops, drives and removable media can carry confidential information long after the system they supported has been switched off. Disposal scope should include the asset register, the sanitization method for each media type and the chain of custody when hardware leaves the organization. Coordinate this list with the physical asset disposal work covered under CC6.5 so the two controls do not leave gaps between them.

How to decide what is due for destruction

A disposal schedule for C1.2 starts from one question: which confidential information is no longer needed for the purpose it was collected for, and what did the organization promise customers about when it would go? Retention periods, contractual end-of-service triggers, customer offboarding and legal holds are the four inputs that turn those promises into dated, owned decisions. Each data category should have a retention rule that names the trigger (for example, contract termination, account closure or a fixed period after last use), the owner who approves destruction, and the system or repository where the data lives. Where a legal hold can suspend destruction, the schedule must also say who places and lifts holds, so that a hold is not silently ignored by an automated purge job.

C1.2 is judged against the organization's own confidentiality objectives, not against a generic standard. An auditor will compare the schedule with the confidentiality commitments in the system description, the master service agreement, the data processing terms and the privacy notice. If a customer contract says data is returned or destroyed within a stated window after termination, the schedule must produce that outcome, and the organization should confirm that the window in its own documents matches the window in its code. A mismatch between a promise and a purge job is a common source of exceptions, so the reader should sample several contract types and trace each one into the schedule before fieldwork begins.

The 2022 revised points of focus for C1.2 describe identifying confidential information for destruction and destroying it. These are characteristics to consider when designing and evaluating the control, not separate requirements, and not every point of focus has to be addressed. In practice, the reader should confirm three things: that someone can produce a list of records that have reached their disposal trigger, that destruction is carried out and recorded, and that backups, replicas and third-party copies are covered by the same rule or by a documented reason they are not. The Trust Services Criteria text is available from the AICPA 2017 Trust Services Criteria with revised points of focus, and it is worth reading the points of focus alongside the organization's own schedule.

How an assessor tests C1.2 disposal

This table sets out the four procedures a service auditor typically performs on C1.2, the evidence each one asks for, and the findings that most often lead to exceptions. Read it as a checklist of what to have ready before fieldwork, and check each row against your own disposal schedule and systems.

Test procedure	What the assessor does	Evidence the assessor expects	Where it usually fails
Inquiry of disposal owners	Interviews the people who run deletion, such as engineering, data, customer success and the people who handle returned hardware, to learn how confidential data is identified for disposal and when it is destroyed.	Named owners, a documented disposal process, and a walkthrough showing how a record reaches the destruction queue.	Staff describe a process that differs from the written policy, or no one can name who approves disposal.
Inspection of the disposal schedule	Reads the retention and disposal schedule and checks it against the confidentiality commitments in customer contracts, the privacy notice and the system description.	A schedule that lists data categories, retention periods, triggers for disposal, and the approver for each category.	Retention periods are undefined, or the schedule does not match what customers were promised in contracts.
Inspection of disposal tickets and deletion logs	Selects disposal events from the period under review and traces each one to a ticket, an approval and a system record showing that the data was removed.	Tickets with dates and approvals, deletion logs from databases, object stores and file systems, and destruction certificates for physical media.	Tickets exist for some data stores but not others, or logs cannot show which records were removed.
Sampling of disposed data sets	Chooses a sample of data sets that passed their retention period and checks whether they are still present in production, analytics, exports or support tooling.	Query results or system exports taken during fieldwork that show the sampled data is no longer retrievable.	Confidential data persists in analytics warehouses, search indexes, or exported spreadsheets after its retention period has ended.
Reconciliation of backup and replica deletion	Confirms how disposal reaches backups, replicas and disaster recovery copies, and whether the stated disposal approach matches the backup retention settings.	Backup retention configuration, a documented rule for when backup copies expire, and evidence that expired backups were purged or aged out.	Backups are kept far longer than the disposal schedule states, or no one has ever purged them. Assessors often ask how long a deleted record survives in backups.
Vendor and subservice disposal	Checks how confidential data held by third parties is returned or destroyed at the end of a contract, and whether the organization obtained confirmation.	Vendor destruction attestations, contract clauses on return or destruction, and a register of third parties holding confidential data.	Vendor offboarding does not trigger a destruction request, and no written confirmation is on file.
Timing against commitments	Compares the dates in disposal records with the periods the organization committed to customers, so the auditor can see whether disposal happened as promised.	A mapping from each commitment to the disposal period and the records showing it was met.	Disposal is performed on a different cycle from the one committed to customers, or the commitment is not written down anywhere.
Exception handling	Asks how legal holds, customer requests to retain data, and failed deletions are recorded and resolved.	A hold register, approvals for exceptions, and follow-up tickets for failed deletions.	Holds are applied informally, so data is kept without any record of who approved keeping it.

Implementing C1.2 disposal in five steps

The sequence turns a confidentiality commitment into a disposal process an assessor can test: know where confidential data lives, decide when it must go, delete it everywhere it sits, record each disposal, and keep the schedule current.

Inventory every store holding confidential information
List each system, database, file share, backup set, log pipeline, ticketing tool and SaaS application that holds confidential information, and name an owner for each. Start from the classification work under C1.1 so the inventory matches what the organization has already labeled as confidential. The output is a register with the data type, location, owner and whether the store is in scope for disposal. You know the step is done when the system owner signs off that the register covers their platforms, including self-hosted services and their backups.
Define retention and disposal triggers from commitments
For each data type in the register, write down the rule that starts disposal, such as the end of a contract, the end of a stated retention period, a customer deletion request, or the completion of a purpose. Tie each trigger to the confidentiality commitments in the customer contracts, the privacy notice where it applies, and any legal hold process. The output is a retention and disposal schedule approved by the owner of the confidentiality commitments. Ask legal counsel to confirm any retention periods that come from statute or contract, since those vary by jurisdiction and agreement.
Automate or document deletion in each store
For every store in the register, decide whether deletion runs automatically through a job, lifecycle policy or application function, or is carried out by a documented manual procedure with a named operator. Cover backups and logs explicitly: state how long copies persist, how they expire, and what happens to data that was deleted from primary storage but remains in a backup set. Where a platform cannot delete a record on request, document the limitation and the compensating control. The output is a runbook or configuration record per store. You know it is done when someone outside the team can follow the runbook and reach the same result.
Record each disposal in a ticket or log entry
Each disposal event, whether automated or manual, creates a record that shows what was disposed of, from which store, when, under which trigger, and who or what carried it out. Automated jobs should write to a log that is retained and protected from edits, and manual disposals should go through a ticket that links to the schedule entry. Keep records of exceptions too, such as a deletion that failed or was deferred under a legal hold. The output is a disposal log or ticket queue that an auditor can sample. Confirm with the audit firm which record format it will accept before the observation period begins.
Review the disposal schedule at least annually
Once a year, the owner of the confidentiality commitments and the system owners review the register and schedule against the current systems, contracts and any changes in data flows. The review checks for new stores, retired systems, changed retention terms and disposal records that show gaps. Record the review date, the attendees, the changes made and the open actions. The output is a dated review record and an updated schedule. You know the step is complete when every change to systems or commitments since the last review is reflected in the register and the disposal runbooks.

Disposal evidence that passes an assessment

An assessor testing C1.2 wants to see that disposal follows a written schedule, that each destruction is traceable to an approver, and that exceptions are recorded and justified. The cards below cover the artifacts that show this, along with the habits that keep them complete between audit periods.

Approved retention and disposal schedule

The schedule lists each category of confidential information, the period it is kept, the trigger that starts the clock, and the method used to destroy it. It is the baseline every other record is measured against, so an assessor will compare deletions and tickets to it. Check that the schedule is approved by a named owner, dated, and tied to the confidentiality commitments in customer contracts. Review it at least annually and keep each prior version.

Deletion job configurations and run logs

Automated purges, lifecycle rules and scheduled scripts are the most common way disposal is performed at scale. Keep the configuration under version control so the rule in force on any date can be shown, and keep the run logs that record what was deleted, when, and how many records were affected. Confirm that failed runs generate alerts and that someone reviews them. A rule with no logs cannot be shown to have run.

Disposal tickets with approver sign-off

Manual destruction, such as removing a dataset from a non-production store or purging a customer export, should go through a ticket that names the data, the requester, the schedule rule that applies, and the approver. The approver should be independent of the person doing the deletion. Record the completion step and the verification that the data is gone. Tickets with missing approvals are a frequent source of exceptions in the report.

Backup expiry records

Confidential data often survives in backups long after it is deleted from production. Document backup retention periods, the expiry jobs that remove old snapshots, and how restores of expired data are prevented or re-purged. Your disposal evidence should show that backups age out on the schedule and that restores do not resurrect data that should have been destroyed. Confirm this behavior with a test restore rather than assuming it from configuration alone.

Third-party destruction certificates

When a subservice provider, hardware recycler or document destruction firm holds confidential information, obtain a certificate of destruction that identifies the media or records, the method, the date, and the party responsible. Keep these with the vendor record and tie them to your disposal ticket. Review whether the vendor's own SOC report covers disposal, since that bears on how far your assertion can rely on it.

Legal hold exception logs

Data subject to a legal hold or regulatory preservation order must not be destroyed on schedule. Keep an exception log that records the hold, its scope, the date it was applied, the authority that issued it, and the date it was released. Each suspended deletion should point to the hold. Confirm with legal counsel how holds are communicated to engineering so that automated purges skip the affected data.

What meeting C1.2 costs in money and effort

This table breaks down the cost of meeting C1.2 into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a quote request, since no figures are supplied for this topic and each line should be priced against your own systems and retention rules.

Cost component	One-time or recurring	What drives it
Tooling or licenses for deletion and discovery	Recurring (subscription) or one-time (purchase)	Number of data stores in scope and whether the tool is commercial or open source; self-hosted open-source tools can remove this line but still need hosting and maintenance
Engineering time to build deletion jobs	One-time build, then recurring upkeep	Number of systems holding confidential data, how many have native retention settings, and how often schemas change
Data inventory and classification effort	One-time, refreshed periodically	Number of data stores, third-party SaaS tools holding customer data, and how well ownership is already recorded
Backup retention and purge scheduling	Recurring	Length of backup retention, whether backups are immutable, and how deletion is reflected in restored copies
External review of the disposal design	One-time or periodic	Scope of the design, whether the organization has an internal reviewer, and how many exceptions the review must document
Evidence upkeep (deletion logs, tickets, approvals)	Recurring	Frequency of disposal events, log retention, and how much of the evidence is generated automatically
Auditor sampling and testing during the examination	Recurring with each examination period	Number of disposal events in the period, the sampling approach the auditor selects, and how quickly evidence can be produced

Who owns disposal, who helps, and what the auditor checks

Your organization owns the confidentiality commitments and every retention decision that follows from them. Management decides which data is confidential under the agreements with customers, how long each category is kept, and what triggers destruction, such as contract end, a customer's written request or the end of a legal hold. Those decisions belong in a written policy that a named owner approves and reviews. Your team also runs disposal day to day, approves exceptions and keeps the records that show destruction happened.

Retention decisions: Management sets retention periods per data class and documents the reason for each one.
Disposal ownership: A named role signs off on each batch of destruction and on any exception, such as a legal hold.
Operational execution: Staff or automated jobs carry out deletion in production, backups, logs and third-party copies.
Records of destruction: Tickets, job logs or certificates of destruction are kept in a location the auditor can sample.
Customer requests: Someone owns the process for handling contract-end and deletion requests from customers.

Before the audit, confirm that your policy names an owner for each of these duties and that the owner can produce a sample of completed disposal records on request.

Where C1.2 disposal usually falls short

Disposal fails less often in the primary system than in the places nobody thinks to look: backups, copies made for convenience, and third-party platforms. The cards below cover the gaps that assessors most often find when they trace confidential information through its lifecycle. Each gap has a closing action you can check before the examination window opens.

Backups and replicas never purged

Production databases are often purged on schedule while backup sets, disaster recovery replicas and read replicas keep the same records for months or years. C1.2 expects confidential information to be destroyed when it is no longer needed, so the disposal process has to reach every copy, not only the primary store. Confirm that your backup retention period is written down and that expired backup sets are actually deleted. Ask engineering to show one dated example of a purge reaching a replica.

Shadow copies in spreadsheets and tools

Support teams export customer records into spreadsheets, engineers paste sample data into tickets, and analysts keep extracts on laptops. These copies sit outside the retention schedule because no system knows they exist. Run a search across shared drives, ticketing systems and chat exports for the data classes you hold, and set a rule that exports carry an expiry date. Note that this gap is easy to miss because the source system looks clean.

No link to customer contracts

Retention periods often come from a generic policy, while customer agreements specify shorter or different return and deletion obligations. When the two are never reconciled, the organization keeps data longer than a contract allows, or deletes it before a customer's own retention need has ended. Map each customer contract's return and deletion terms to the systems that hold that customer's data. Ask legal to confirm which contract clauses drive disposal timing.

Deletion with no record

Teams often delete data without recording what was removed, when, under which request, or by whom. An assessor testing C1.2 will ask for evidence that disposal happened, and a deletion that leaves no trace cannot be shown to have occurred. Keep a disposal log with the data set, the trigger, the approver, the date and the systems affected, and retain the log itself under your records policy. Ask for a sample entry from the last quarter.

Offboarding that misses SaaS subprocessors

When a customer leaves or a project closes, the offboarding checklist usually covers the core platform but not the SaaS tools that also received the data, such as analytics, email, error tracking, support desks and backup vendors. Those subprocessors keep copies under their own retention settings. Build a list of every subprocessor that received customer data, then request written deletion confirmation from each one. Confirm that the list is reviewed when a vendor is added or dropped.

Questions buyers ask about C1.2 disposal

How much effort does C1.2 disposal take to get ready for a SOC 2?

The effort depends on how much confidential information the system holds, how many places it lives, and whether disposal already happens on a schedule. No supplied figure gives a duration, so ask any auditor or consultant for a written estimate based on your own data stores. Most of the work is one-time: defining what counts as confidential, mapping where it is kept, and writing a disposal procedure. The recurring work is running that procedure, keeping destruction records, and reviewing exceptions. Ask for the estimate to split those two parts so you can see what continues after the first examination.

Can our team handle C1.2 disposal in-house?

Often yes, if engineering and legal already share a view of what confidential information is and how long it is kept. The team needs to own the disposal procedure, run the deletion jobs or manual destruction steps, and keep records that prove each step happened. An implementation partner can prepare the systems, scripts and evidence, but the organization still owns the control. Independent auditors and certification bodies issue reports, so they stay separate from whoever builds the process. Confirm early whether your team has time for the recurring review, because gaps usually appear there.

How long does it take to get disposal evidence ready for an auditor?

Evidence for a Type 1 report can be prepared before the examination date, while evidence for a Type 2 report must cover the whole observation period. No supplied fact gives a duration for either, so confirm the observation period and the auditor's sampling approach in writing before you plan. Auditors typically ask for a disposal request, approval where required, a destruction or deletion record, and proof that backups and third parties were handled. Start collecting these records from the first disposal event, not the week before fieldwork.

What does C1.2 disposal need from engineering?

Engineering usually carries most of the technical work. The main tasks are:

Finding every store of confidential data, including databases, object storage, logs, caches, analytics copies and developer environments.
Building deletion or anonymization jobs that run on a defined schedule and record what they removed.
Handling backups, replicas and restored copies, so disposal is not undone by a recovery.
Logging each job run in a system that the auditor can sample.

Ask whether your current stack can produce those logs without manual steps.

What does C1.2 disposal need from legal?

Legal defines the confidentiality commitments that disposal must meet. That includes the retention periods in customer contracts, any statutory retention duties, and rules for legal holds that suspend deletion. Legal also reviews the wording of the disposal policy so it matches what customers were promised. Without a clear retention schedule from legal, engineering cannot show that a deletion was correct. Confirm with counsel which obligations apply to your data before the disposal procedure is written.

How does C1.2 relate to C1.1 and CC6.5?

C1.1 covers identifying confidential information and protecting it while you keep it. C1.2 starts where C1.1 ends, by destroying that information when the commitment no longer requires it. CC6.5 covers disposal of physical assets, such as drives, laptops and paper records, which is a separate category of destruction. Auditors often test them together because the same classification labels drive all three. If your classification is weak under C1.1, your disposal records will be hard to defend under C1.2.

Does DeployOpen handle C1.2 disposal for our self-hosted platform?

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For C1.2, that can include preparing the deletion jobs, backup handling, logging and evidence collection for the platforms in scope, under a fixed-scope written agreement. DeployOpen does not issue audit reports or certifications, and it does not decide what your confidentiality commitments are. Your legal team and an independent CPA firm still own those parts.

Where to read the criterion and its points of focus

Start with the primary text: the AICPA's *2017 Trust Services Criteria with revised points of focus (2022)*. C1.2 is one of the two criteria in the confidentiality category, and it asks the organization to dispose of confidential information in line with its confidentiality objectives. The points of focus beneath it are the part that tells you what an assessor expects to see: identifying confidential information that is due for destruction, and then destroying it. Read those points of focus as characteristics that help you design and evaluate the control, not as a checklist you must satisfy line by line. The points of focus are the fastest way to see how the auditor will frame the disposal control in your own system description. Before the readiness work starts, pull the current version of the document and note the exact wording of the C1.2 points of focus so your control narrative uses the same vocabulary the auditor will use.

The second source is the NIST Privacy Framework crosswalk to the AICPA 2017 Trust Services Criteria, published in 2023. It is most useful when your confidential information overlaps with personal data, because it maps the Trust Services Criteria to the privacy engineering outcomes NIST describes. For C1.2, use it to check whether the disposal steps you plan for confidential records also meet the retention and disposal expectations that appear under the privacy category, if privacy is in your scope. Treat the crosswalk as an interpretive aid. It does not change what C1.2 requires, and it does not replace the auditor's own reading of the criterion. Ask your auditor early whether they will rely on the crosswalk when they test disposal, and record their answer in the engagement correspondence.

Use both sources together to draft the question you will bring to your auditor: which records count as confidential under your own commitments, who decides when they are due for destruction, and what evidence will show the destruction happened. The criterion does not define those answers for you, so the decisions and their documentation sit with management. Confirm the current revision of each document with the AICPA and NIST before you cite it in any control matrix, because the criteria and guidance are revised from time to time.

How DeployOpen prepares C1.2 disposal for your audit

DeployOpen plans, implements and documents the self-hosted open-source systems that hold your confidential information, so disposal of that information can be carried out and evidenced for C1.2 Disposal of confidential information. The organization owns its confidentiality commitments and disposal decisions, and an independent CPA firm performs the SOC 2 examination and issues the report.

How we scope

We agree in writing which systems, data stores, backups and retention periods fall inside the C1.2 disposal scope before work starts.
We list the confidentiality commitments your organization has made to customers that disposal rules must reflect.
We confirm with you who approves destruction requests and who receives the resulting records.

How we build

We configure retention and deletion routines in your self-hosted platforms so confidential data is identified for destruction on a defined basis.
We set up destruction steps for primary stores, replicas and backups, and document which steps cannot be automated.
We build logging that records each disposal action with its date, scope and approver for later review.

How we hand over

We deliver a written disposal procedure, a control description mapped to C1.2, and the configuration files that run the routines.
We provide sample disposal records and an evidence index so your auditor can select items for testing.
We walk your control owners through the procedure and confirm they can run it without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so disposal routines keep working after platform changes.
We review disposal logs with your team before each audit period so gaps are found and corrected in time.
When your auditor asks questions about disposal evidence, we help your team assemble the records they request.