P4.3 Disposal of personal information: SOC 2 evidence

What SOC 2 P4.3 asks for when personal information is disposed of

P4.3 asks the organization to dispose of personal information securely in line with its privacy objectives. In a SOC 2 with the privacy category in scope, that means the disposal process must be designed so an auditor can see that personal information is removed, destroyed or redacted when the organization's own purposes end, and that the removal actually happens. The commitment you make in your privacy notice and system description is only as good as the proof that data leaves the systems at end of life, including copies in backups, logs, analytics stores and vendor environments. Start by listing every place personal information lives in scope and deciding, for each, what disposal means: deletion, secure destruction of media, or redaction of records that must be kept for another reason.

P4.2 and P4.3 sit side by side but ask different things. P4.2 covers how long personal information is retained and how it is protected while held, measured against the privacy objectives. P4.3 starts where retention ends and asks whether disposal is secure and matches those objectives. Disposal also overlaps with two other criteria. CC6.5 addresses disposal of physical assets and media that may hold data, and C1.2 addresses disposal of confidential information when it is no longer needed. An auditor may test one disposal process against several criteria, so the same records can serve more than one purpose, but P4.3 is the only criterion that ties disposal to the privacy objectives and to data subjects. Confirm with your auditor how they plan to map your disposal evidence across these criteria before fieldwork.

Deletion requests are where most organizations struggle. A request must be captured, recorded and flagged so it reaches the systems that hold the person's data, and it must be tracked to completion. Ask who receives requests, how they are logged, which systems are checked for each data subject, and how a deletion is confirmed in backups and third-party processors that cannot be edited directly. Illustratively, a request processed in the production database but left in a nightly export or a support tool would fail the test even though the core system was clean. Document the exceptions you will allow, such as legal holds, and make sure the auditor can see who approved each one.

Which systems, data and teams fall under P4.3 disposal in a SOC 2

P4.3 only applies when the privacy category is in the SOC 2 scope, so the first decision is whether to include it at all. Once it is, the disposal work follows wherever personal information is stored, copied or passed to a processor, and each of those places needs an owner and a documented method.

Privacy category scope decision

P4.3 is one of the privacy criteria, so it applies only when the organization includes the privacy category in its SOC 2 examination. Confirm that decision in writing before the system description is drafted, because it determines which personal information must be inventoried. If privacy is out of scope, disposal of personal information may still matter for contracts and customer questionnaires, but it is not tested under P4.3.

Production databases and object storage

These are the primary stores where personal information lives, so they are the first place a deletion request must reach. Map which tables, buckets and fields hold personal information, and define how a record is deleted, anonymized or redacted. Confirm whether soft-deleted rows, archived partitions and replicas are included in the disposal procedure, since an auditor will ask whether deletion is complete.

Backups and disaster recovery copies

Backups usually hold personal information beyond its retention period, and a deleted record may reappear after a restore. Document how deletion requests are handled for backups, whether through expiry schedules, restore-time suppression or a defined rotation. Ask the platform owner to confirm backup retention periods in writing and to record how restores are checked against the deletion log.

Logs, telemetry and error reports

Application logs, access logs, APM traces and crash reports often capture identifiers, email addresses or IP addresses without anyone deciding to store them. Review log fields for personal information, set retention per log source, and decide whether personal data is masked at ingestion. Note that these stores are frequently overlooked in a first examination and are easy to miss in a deletion workflow.

Analytics, staging and exported copies

Data warehouses, BI extracts, staging environments and spreadsheets used for analysis are copies of production data that tend to outlive their purpose. Decide whether these copies should receive personal information at all, and if they do, make sure deletion requests and retention rules reach them. Test staging refreshes, since a copy restored from production can reintroduce records that were deleted.

Support tickets and customer communications

Helpdesk systems, chat transcripts and call recordings often contain names, contact details and account information supplied by customers. Identify which of these channels hold personal information, set retention for attachments and transcripts, and assign who redacts or deletes them when a request arrives. Ask the support lead to confirm how agents are trained to recognize and route deletion requests.

Third-party processors and subservice organizations

Vendors that host, process or receive personal information must dispose of it too, and the organization should be able to show that they did. Build a list of processors that hold personal information, record the disposal method and certificate or confirmation each one gives, and decide how this evidence feeds the vendor review. Confirm the contractual right to request deletion and the time a processor is given to comply.

How an assessor tests disposal of personal information

This table walks through each step an assessor takes to test P4.3, what they inspect, the evidence they request and where disposal controls commonly fail. Read it as a preparation checklist: each row names a test step and the record that should exist before fieldwork starts.

Test step	What the assessor inspects	Evidence requested	Common finding
Policy and objectives	Whether the disposal policy and retention schedule follow the organization's stated privacy objectives and name who approves disposal	Approved disposal or retention policy, privacy objectives, version history and approval records	Policy exists but does not state disposal triggers or owners
Deletion request workflow	How requests are captured, identified as deletion requests, verified and routed to systems that hold the data	Intake channel records, request queue, verification steps, routing tickets	Requests arrive by email or phone and are not logged in the system of record
Request timestamps	Whether each deletion request records when it was received, when it was flagged and when it was closed	Ticket exports showing received, flagged and completed dates for a population of requests	Deletion requests with no timestamp, making response time impossible to verify
Sample of completed requests	Whether a sample of closed requests shows the personal information was actually disposed of, destroyed or redacted	Sampled tickets with linked disposal records, database deletion logs or redaction reports	Tickets closed without evidence that data was removed from every system in scope
Disposal and redaction tickets	Whether disposal activities follow an approved method and are checked after execution	Change or disposal tickets, method used (delete, destroy or redact), sign-off by a second person	Manual deletions run by administrators with no peer review or record of method
System logs	Whether logs confirm deletion or redaction in production and in supporting systems such as analytics, search indexes and exports	Audit log extracts covering the sampled requests, log retention settings	Logs are disabled or rotated before the sampling period, so deletion cannot be confirmed
Backups	Whether personal information in backups is handled under a documented rule, such as expiry or restore-time deletion, and whether that rule is applied	Backup retention schedule, restore procedure showing deleted records are suppressed, evidence of backup expiry	Deleted records reappear after restore, and no one has verified deletion in backups
Third-party disposal	Whether processors and other third parties that hold personal information are instructed to dispose of it and confirm completion	Deletion instructions sent to vendors, vendor confirmations, contract clauses on return or deletion	Vendor deletion is assumed but never requested or confirmed in writing

Implementing secure disposal step by step

This sequence turns the P4.3 disposal points of focus into a repeatable process: find the personal information, set disposal rules, capture and flag deletion requests, dispose of data in each system and its copies, and keep a record that an assessor can test.

Map where personal information lives
Inventory every system, database, file store, log, analytics tool, backup set and third-party processor that holds personal information, and name the owner of each. Record the data elements, the data subjects they describe and the business purpose for keeping them. The step is complete when the owner of each system has confirmed the inventory entry and the list is reviewed against recent changes to the architecture. Without this map, no later deletion step can be shown to be complete.
Define disposal rules tied to privacy objectives
Write disposal rules that state, for each category of personal information, when it must be deleted, destroyed or redacted and what triggers that action, such as the end of the stated purpose, a withdrawn consent or a valid request. Link each rule to the privacy objectives and the retention commitments in the privacy notice, and have privacy and legal owners approve them. The output is an approved disposal schedule that the engineering team can implement and an assessor can compare against actual behavior.
Build request capture and flagging
Route deletion requests from every intake channel, such as the web form, support inbox and account settings, into one ticketing queue with a defined format. Each request should be identified, its requester authenticated, and the affected systems flagged so that disposal work is assigned. The step is done when a test request from each channel creates a ticket, reaches the correct owner and carries a flag for every system in the inventory that holds that person's data. Document any request that cannot be fulfilled and the reason.
Dispose of personal information in each system
For each flagged system, apply the method the disposal rule requires: delete records, destroy media, or redact fields where the rest of the record must be kept. Technical owners should use documented procedures, and the method should be verified after execution, for example by querying for the identifier or confirming the field is empty. The output is a system-level result for each flagged item showing what was removed, by whom and when, with exceptions escalated to the privacy owner.
Extend disposal to backups and processors
Confirm how backups, replicas, archives and data held by processors are handled. Some copies may expire on a set schedule rather than be edited, so the disposal rule should say how that expiry is controlled and what restoration risk is managed in the meantime. Send disposal instructions to processors under the contract terms, and request written confirmation. The step is complete when each copy category has a documented method and each processor has returned confirmation or been escalated.
Record each disposal action
Log every request, decision, disposal action, verification result and processor confirmation in a system of record with timestamps and the responsible person. Keep exceptions and their approvals in the same record. This log is the evidence that an assessor will sample during a Type 2 examination, so it should be retained under the organization's retention rules and reviewed periodically for gaps. Confirm with the assessor in advance which records they will request and in what format.

How a deletion request moves through systems and backups

The point of this section is that a deletion request is only disposed of when every copy it touches is handled by a documented rule, and the auditor will test that the rule was followed for real requests. Start by treating the request as a tracked record from the moment it arrives. Intake may come through a web form, an email to a privacy address, a support ticket or an account setting, and each channel should feed one case queue with a unique reference, the date received, the requester's identity and the categories of personal information in scope. Verification comes next: confirm the requester is who they claim to be, using the same authentication standard the organization uses for access requests under P5.1, and record the outcome, including any denial and the reason given to the requester.

Once a request is verified, the case should be flagged so that every downstream system knows it is pending. Flagging is the step most often missed. Identify where personal information lives, including production databases, analytics stores, support desk tools, CRM records, logs, object storage and any processor such as a payroll or email provider. For each location, record the owner, the deletion method (hard delete, pseudonymization, or redaction of specific fields) and the expected confirmation. Propagation to processors should follow written instructions and produce a confirmation the organization can file as evidence. Closure requires a record showing which systems were actioned, what was retained and why, such as a legal hold, and when the requester was told.

Backups and archives need a documented rule because they cannot practically be edited record by record without damaging recovery. Choose and write down one approach: for example, backups expire on a defined schedule and no restore is permitted without re-applying pending deletions, or a suppression list is checked before any restore goes live. The organization should confirm the retention period for each backup tier with its platform owner, confirm that restore runbooks include the suppression step, and test that a restored dataset does not reintroduce deleted records. Silent omission, where nobody documents how backups are treated, is the gap assessors look for. Disposal guidance for infrastructure assets sits under CC6.5, and confidential data disposal under C1.2, so cross-reference those records rather than duplicating them.

Evidence that passes P4.3 and how to keep it current

An auditor testing P4.3 wants to see that deletion requests were captured, that disposal actually happened, and that the rules behind it are reviewed. The cards below group the records that show each step, and they describe how to keep those records current between Type 2 observation periods.

Deletion request log

Keep a single log of every request to delete or redact personal information, whether it arrives through a web form, email, support desk or a data subject's account settings. Record the date received, identity verification outcome, the systems in scope, the requested action and the final response. An auditor will sample this log and trace entries forward to disposal, so gaps between receipt and action are the first thing to explain. Confirm that requests raised through support tools reach this log automatically.

Disposal tickets and approvals

Each disposal action should have a ticket that names the dataset, the owner, the retention basis and the approver. Tickets make a disposal reviewable as a discrete event rather than an undocumented database command. Require a second person to approve bulk deletions, and confirm that the ticket closes only after the disposal is verified. Auditors commonly ask who could have approved a deletion they cannot see, so the approval field matters as much as the outcome.

System deletion and redaction records

Keep system-generated records showing what was deleted or redacted, when, and by which job or administrator. Application logs, database audit trails and job output usually serve this purpose. Check that the records show the outcome rather than only the command, and that they are protected from the same person who performed the disposal. Redaction is harder to prove than deletion, so capture before and after row counts or field-level checks for redacted records.

Backup expiry records

Personal information usually persists in backups after it is deleted from production, so the disposal evidence must address backup retention. Document the backup retention period, how deleted records are excluded or aged out during restores, and the job logs showing that expired backups were destroyed. Confirm with the team that restoring a backup does not silently reintroduce deleted records. Explain the approach in the disposal policy so the auditor does not have to reconstruct it.

Processor and subprocessor confirmations

When a vendor or cloud provider stores personal information for you, you need written confirmation that it disposed of the data when instructed. Request these confirmations at a defined point, such as after each deletion batch or on contract exit, and file them with the request that triggered them. Track which processors hold each dataset so that no deletion is complete without them. Confirm contractual terms for return and deletion with your legal team.

Disposal policy, retention schedule and reviews

The disposal policy and retention schedule set the rules that every other record is tested against. Each dataset should have a stated retention period, a disposal method and an owner, with a dated review at least annually. Record the review outcome, including changes made and who approved them. Between Type 2 observation periods, the review records show the control operated continuously, so schedule them on a calendar that the audit team can see and stop treating them as one-time documents.

What meeting P4.3 costs in money and effort

This table breaks down the cost components of meeting P4.3 by who is paid, whether the cost is one-time or recurring, and what drives it up or down. No prices or durations are supplied for this criterion, so use it to build a scope and ask for written quotes, not to estimate a budget.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Engineering time to build deletion and redaction	Internal engineers or an implementation partner for fixed-scope work	One-time, with ongoing change effort	Number of stores holding personal information and how many need custom deletion logic
Deletion request capture and flagging workflow	Internal product or engineering teams, possibly a ticketing or privacy tool vendor	One-time build, recurring operation	Volume of requests, identity verification steps and how requests reach systems
Tooling and licenses	Software vendors for privacy, GRC or data discovery tools	Recurring subscription or support	Vendor pricing model and whether open-source components can replace paid tools
Self-hosted open-source alternatives	Internal staff or a partner for installation, hardening and upgrades	One-time setup, recurring patching	Reduces license spend but moves maintenance and support effort in-house
Evidence upkeep	Internal compliance or operations staff	Recurring across the observation period	How disposal jobs log results, how often evidence is collected and whether it is automated
External privacy or testing review	Privacy counsel, consultants or security testers if scoped	Usually one-time readiness review, optional recurring checks	Complexity of data flows, number of processors and whether redaction is tested
Auditor sampling effort	Independent CPA firm, plus internal time to produce samples	Recurring each examination period	Number of disposal events the auditor selects and how easily records can be retrieved
Data sprawl and processor count	Raises engineering, tooling and evidence costs across all rows above	Recurring as the footprint grows	Each new database, backup, log store, analytics tool or subprocessor adds disposal work

Who owns disposal: your team, a partner and the auditor

Your organization owns the privacy objectives that define how long personal information is kept and when it must be disposed of. That ownership cannot be transferred. Your privacy, legal and security leads decide which data categories are in scope, what counts as a valid deletion request, how requests are verified, and which exceptions (such as legal holds) override deletion. Your operations staff then run the process and sign off on completed requests.

Disposal rules: Documented retention and disposal rules tied to your privacy objectives, reviewed on a set schedule.
Request handling: A defined intake path, identity verification step and owner for every deletion or redaction request.
Exception decisions: Written approval for any record kept past its normal disposal date, with the reason and review date.
Sign-off and records: Named approvers who confirm completion and retain the evidence that disposal happened.
Subservice oversight: Monitoring of vendors that hold copies of the data, including requests to them to delete.

Before the audit, confirm that every rule has a named owner and that the request log matches what actually happened in your systems.

Common P4.3 gaps and how to close them

Most P4.3 findings are not missing deletion code. They are missing rules, missing records and missing reach into systems that hold copies of personal information. The cards below cover the gaps assessors most often raise and the closure action for each, so the organization can show disposal in line with its privacy objectives.

No disposal rule per data class

Many organizations set one retention period for everything, or none at all. P4.3 expects disposal to follow the organization's own privacy objectives, so each category of personal information (customer profiles, support tickets, payment references, applicant files) needs a written disposal trigger and method. Check that every data class in the data inventory has an owner, a trigger such as account closure or purpose completion, and a disposal method. Illustrative: a support ticket archive with no trigger will keep customer names indefinitely.

Deletion requests tracked in email

When deletion requests arrive in a shared mailbox and are handled by hand, the organization cannot show when each request was received, who acted on it, or whether every system was reached. P4.3 looks for capturing, identifying and flagging of deletion requests. Move intake into a ticketing queue with a required field for the data subject's identity check, the systems in scope and the completion date. Retain the ticket as the disposal record.

Backups and logs ignored

Production databases are often purged while backup sets, log archives and analytics exports keep the same personal information for years. Assessors will ask how disposed data is handled in these copies. Document the backup retention window, whether restores can re-expose deleted records, and the procedure for suppressing deleted subjects during restore. Ask your backup vendor or platform team to confirm how their tooling handles expiry of backup sets, because the answer varies by product.

Processors not instructed to delete

Hosting providers, email services, support desks and analytics vendors often hold copies of personal information. If the organization has not instructed them to delete data when the purpose ends or a request is verified, disposal stops at its own boundary. Include deletion instructions and confirmation expectations in contracts, and record each confirmation against the originating request. This ties to P6.4 third-party commitments and is worth checking before the examination period starts.

No evidence of redaction

Where personal information must be kept for legal or financial reasons but is no longer needed in full, redaction or masking is a disposal method. A common gap is redacting a document copy while the original, or a search index built from it, still contains the values. Keep a redaction log showing the record, the fields removed, who performed the change and the verification step. Confirm that redacted fields are also removed from exports and search indexes.

Disposal without a sample trail

An auditor testing disposal will select records and trace them from request or trigger through to removal. A policy that says deletion happens cannot answer that test. Build a repeatable check that compares deletion tickets against system state, and keep the output as dated evidence. Keep these checks aligned with the physical disposal expectations in CC6.5 and the confidential information disposal in C1.2, which use similar evidence.

Questions teams ask about P4.3 disposal and outside help

What does P4.3 disposal effort actually involve for a SaaS team?

P4.3 effort is the work of making personal information disappear on purpose once your privacy objectives no longer allow you to keep it. The effort splits into three parts: capturing and flagging deletion requests, identifying every system that holds the data, and carrying out disposal, destruction or redaction in each one. The first part is a workflow question, the second is an inventory question, and the third is an engineering question. Most of the cost sits in the inventory and the engineering, because a team that has not mapped its data stores cannot prove that a deletion reached all of them. The Trust Services Criteria do not prescribe a tool or a number of days, so the scope depends on how many systems hold personal information and how much of their deletion is already automated. Ask any provider to break its estimate into these three parts.

Can our team do P4.3 in-house, or do we need outside help?

A team can do P4.3 in-house if it has engineers who know where personal information lives, a privacy owner who sets the retention and disposal rules, and time to test deletions end to end. Outside help is usually useful for the inventory, for designing a deletion workflow that spans several platforms, and for building evidence that an auditor can sample. The organization keeps ownership of its privacy objectives and its controls, while an implementation partner can prepare the systems, scripts and records. Only an independent CPA firm issues the SOC 2 report. Before deciding, count the systems that hold personal information, check whether any are run by a vendor, and decide who signs off each disposal request.

What do engineering and privacy staff each need to contribute?

Privacy staff need to define what personal information is kept, for how long, and which requests override retention. Engineering staff need to make those rules work in code and infrastructure. In practice, privacy staff own the retention schedule, the request categories and the exceptions, such as legal holds. Engineers own the deletion jobs, the logs that show they ran, and the checks that confirm the data is gone or redacted. Both groups need to agree on how a request is identified, verified and closed. The gap between the two groups is where most P4.3 evidence breaks down, so assign one named owner for each step before any work begins.

How should backups be handled when personal information must be disposed of?

Backups are usually handled by documenting the deletion behavior and the restore process, not by editing every backup in place. Many teams set a backup retention period, state in their procedures that deleted data will age out of backups within that period, and block any restore that would bring deleted records back without re-applying the deletions. Confirm the exact approach with your privacy owner and your auditor before relying on it, because the answer depends on your privacy objectives, your backup technology and your contracts. Your backup platform should be able to show when each backup set expires, and your restore runbook should include a step that re-runs pending deletions.

Can the SOC 2 auditor help us build the P4.3 process?

No. The auditor's role is to examine the controls you designed and test whether they operated over the examination period. An auditor that also designs the process has a conflict with its own independence, so the design work normally comes from your team or from a separate implementation partner. Ask your CPA firm early which evidence it will sample, such as request logs, deletion job output and redaction records, so the controls can be built to produce that evidence. Auditors can explain what they expect to see, but the organization must decide how the controls work.

How is a partner's scope set in writing for disposal work?

A partner's scope should be set in a written statement of work that lists the systems in scope, the deliverables, the evidence each deliverable produces, the responsibilities of each party, and the dates. DeployOpen works on a fixed-scope basis, so the scope, deliverables and timeline are agreed in writing before work starts and a quote follows from that written scope. For P4.3, a useful statement of work names each data store, each deletion or redaction method, the request intake channel, the logging format and the test plan. It should also say what is out of scope, such as the auditor's examination and any policy decisions that remain with your privacy owner. Ask for this document before signing anything.

What drives the cost of P4.3 work up or down?

The main cost drivers are the number of systems that hold personal information, how many of them already support automated deletion, how many third parties process the data, and how complex your legal and contractual exceptions are. A single application with one database and clear retention rules costs far less to bring into line than a product with many microservices, analytics pipelines and vendor-hosted stores. One-time costs include the inventory, the workflow design and the first round of testing. Recurring costs include reviewing retention rules, monitoring deletion jobs and gathering evidence for each examination period. Request a quote that separates these two categories and states which systems are priced individually.

How DeployOpen scopes and prepares P4.3 evidence

DeployOpen's role in P4.3 is to plan, build and document the disposal and deletion workflows inside your own infrastructure, then prepare the evidence an independent CPA firm will test. Work starts with a fixed-scope plan agreed in writing before any change is made. That plan names the personal information stores in scope (production databases, object storage, log pipelines, analytics copies, backups and support tooling), the request intake channels that feed deletion, the owners for each step, and the retention rules that decide when disposal is due. Nothing is implied beyond that written scope, so the scope document is the first thing to review with your privacy and security leads.

Implementation covers the mechanics: a request-capture point that records each deletion request with a timestamp and identity check, a flag that tracks the request through identification, disposal, destruction or redaction, scheduled jobs that remove or redact records in each store, and a log of what was disposed of and when. Where a platform supports these functions natively, the work is configuration and integration; where it does not, the work may include custom tooling. Confirm with your platform vendor and your own engineers which capabilities each self-hosted component actually provides before you assume a workflow exists. DeployOpen does not issue SOC 2 reports. An independent CPA firm performs the examination, decides which evidence it samples, and issues the report. DeployOpen prepares systems, procedures and records so that the CPA firm can test them.

After go-live, ongoing support can be placed on a retainer covering disposal job monitoring, changes to retention rules, upgrades to the self-hosted platforms and periodic testing of the workflows. Ask any provider to state in the proposal which evidence artifacts they will deliver, how long those artifacts are retained, who owns them, and what remains your responsibility, such as approving retention periods and signing off management's assertion. The quote should follow directly from that written scope, so an unclear scope is the most common reason an estimate changes later.

P4.3 Disposal of personal information