P4.2 Retention of personal information: SOC 2 evidence

What P4.2 asks you to prove about retaining personal information

P4.2 asks you to keep personal information only for as long as your privacy objectives allow, and to protect it for as long as you keep it. The first half is a limit on time and purpose; the second is a standard of safeguarding that applies from the moment data is stored until it is disposed of. For a SOC 2 examiner, the question is whether you have defined those retention periods, followed them in practice, and kept retained data secured throughout. The criterion is short, but it is hard to satisfy because most organizations never wrote down how long each category of personal information should live. Without a documented period tied to a purpose, there is nothing for the examiner to test against, and retention quietly becomes indefinite.

The practical difficulty is sprawl. Personal information rarely sits in one database. It is copied into analytics tools, support tickets, log pipelines, exports, staging environments, email attachments and backups, and each copy can outlive the purpose that justified the original collection. Third-party processors add another layer, because their retention settings may differ from yours. Start by inventorying where personal information lives and mapping each store to a retention period, a named owner and a justification drawn from your privacy notice and objectives. Confirm with your backup vendor or cloud provider how long backup copies persist and whether individual records can be removed from them, since the answer determines how you describe retention in your own policy.

P4.2 is easily confused with two neighboring criteria. P4.1 limits how personal information is used, while P4.2 limits how long it is kept. P4.3 covers the act of disposal itself, including capturing deletion requests and destroying or redacting data. Think of them as stages of one lifecycle: a purpose defines use, a retention period defines how long data stays, and disposal closes the loop. An examiner may test them together, so the evidence for retention periods should link to the disposal records that show those periods were enforced. Before fieldwork, confirm with your auditor how they plan to sample retained records and which retention schedule they will treat as your stated objective.

Which systems and data does P4.2 cover in a SOC 2 scope

P4.2 applies only where the privacy category is in scope and personal information sits inside the system description. The cards below walk through the decisions and stores that determine how much retention evidence an examination needs.

Deciding whether privacy is in scope

The privacy category is optional. Adding it brings in the P1 to P8 criteria, including P4.2, and the examination then tests whether personal information is retained consistently with the organization's privacy objectives. Decide this before fieldwork, and document why the category was included or excluded in the system description. Confirm with your auditor how the decision affects the evidence requests you will receive.

Production databases holding personal data

Production databases are usually the first store the examination looks at. Map which tables and fields hold personal information, who owns each one, and what retention period applies to each data category. Check whether deletion or anonymization jobs actually run, and keep their logs as evidence. A retention policy that no job enforces will be an exception.

Logs, analytics and support tooling

Application logs, product analytics, error trackers and support ticket systems often copy personal information without anyone planning for it. Each store needs its own retention setting, and each must be inside the system description if it is in the service. Ask engineering for a list of every log sink and third-party analytics tool, then confirm whether each one is covered by a retention period.

Backups and data warehouses

Backups and warehouse copies can keep personal information long after the source record is deleted. Decide how long backups are kept, whether deleted records age out of them, and how restores handle data that should already be gone. Document these decisions in the system description, because the examination tests the retention behavior of every copy the service holds.

Third parties holding copies

Subservice organizations and vendors such as cloud hosts, email providers, payment processors and support platforms may store personal information on your behalf. Identify which of them hold copies, what retention they apply, and what contract terms require deletion at the end of service. Their reports and commitments are part of the evidence for P4.2 and for the vendor criteria in CC9.

Setting retention per data category

Retention periods should be set for each data category, tied to the purpose the organization stated, and not as one blanket period for the whole platform. Examples of categories include account profiles, transaction records and support history, each with its own rule. Confirm each period with the business owner and legal counsel, and record the reason. Auditors test whether the stated periods match what the systems do.

How an assessor tests retention of personal information

This table walks through the four steps an SOC 2 assessor typically takes for P4.2, with the evidence each step asks for and where organizations most often fail. Read it as a preparation checklist: each row shows what the assessor will look for and what should already exist before fieldwork begins.

Test step	What the assessor does	Evidence requested	Common finding
Review retention objectives	Reads the documented privacy objectives and retention rules and checks that each category of personal information has a stated retention period tied to a purpose.	Privacy notice, retention schedule, approved privacy objectives and the owner who approved them.	Retention periods exist only in policy text and do not match what the business describes to customers.
Inspect configuration and schedules	Examines how retention is enforced in systems, such as database lifecycle rules, storage policies, scheduled jobs and log retention settings.	Configuration exports, screenshots or infrastructure-as-code definitions, job schedules and change records for those settings.	Retention is documented but no system setting, job or lifecycle rule enforces it.
Sample records past retention	Selects records that have passed their retention period and confirms they were deleted, anonymized or retained under a documented exception.	Population listings with creation dates, deletion logs, disposal tickets and exception approvals for any retained records.	Records remain beyond their period with no approved exception, or deletion logs cannot show what was removed.
Check backups and copies	Asks how personal information in backups, archives, test data and third-party systems is kept and when it expires.	Backup retention settings, backup rotation logs, data copies inventory and vendor retention terms.	Backups have no defined retention period, or copies in analytics and test environments are outside the schedule.
Verify protection during retention	Tests that access, encryption and monitoring controls still apply to stored personal information for the full retention period.	Access review records, encryption configuration, access logs for retained data stores and related security control evidence.	Retained data sits in stores with broader access or weaker controls than production systems.
Confirm exception handling	Checks how legal holds, regulatory needs and extended retention are approved, recorded and reviewed.	Legal hold register, approval records with rationale, and review dates for each exception.	Exceptions are granted informally and never reviewed or closed.

How to implement P4.2 step by step

This sequence turns the P4.2 retention criterion into a working program: a data inventory, retention periods tied to privacy objectives, enforced system settings, documented exceptions, and scheduled reviews that an assessor can test.

Inventory personal information and where it lives
Identify every category of personal information the organization collects, then map where each category is stored, processed and backed up, including SaaS applications, production databases, logs, analytics stores, file shares and third-party processors. Involve engineering, support, sales operations and finance, because the places people forget are usually outside the core platform. The output is a data inventory listing each category, its system of record, its owner and the systems that hold copies. The step is complete when the owner of each system has confirmed the list in writing.
Document the privacy objectives behind each data category
Record the purposes for which each category is collected, as stated in the privacy notice and internal privacy objectives, and the legal or contractual obligations that apply. Privacy and legal staff own this step, with product owners confirming the business purpose. The output is a purpose register that links each data category to its stated purpose and to any statutory or contractual duty that requires a longer or shorter period. Where a purpose has ended, the register should say so, since retention periods flow from it.
Set retention periods per data category
For each category in the inventory, set a retention period and a trigger that starts the clock, such as account closure, last transaction or end of contract. The period should be the shortest one that still serves the documented purpose and any obligation the organization has accepted. Management approves the schedule, and the approval is recorded with its date and the approver's name. The output is a retention schedule that an assessor can compare with the privacy objectives. Ask the organization's counsel to confirm any periods driven by law, since this page does not set them.
Configure systems to enforce the schedule
Translate each retention period into system behavior: automated deletion or anonymization jobs, lifecycle policies on storage, database purge routines, log rotation settings and backup expiry. Engineering implements these settings in the infrastructure and applications, ideally as code under change control so the configuration itself is evidence. Test each job in a non-production environment first, then confirm a sample of records is removed on schedule in production. The output is a set of configuration records, job logs and test results that show the schedule runs without manual intervention.
Protect personal information for the length of retention
While records are kept, they need the same safeguards that protect them at collection: access restricted to roles that need the data, encryption at rest and in transit, logging of access and a check that backups carry the same protection. Security staff confirm these controls cover every system listed in the inventory, including copies. The output is a mapping from each retained data store to its access controls, encryption settings and logging, showing that retention did not leave data exposed. Gaps found here go back into the inventory as open items.
Document legal holds and other exceptions
Some records must be kept past their scheduled deletion, for example under a legal hold, a regulatory request or an open dispute. Define who may place and release an exception, the approval needed, the records affected and the date the exception ends. Exceptions must be visible to the team running deletion jobs so they are suspended correctly, and each one needs a reason tied back to the purpose register. The output is an exception log with approvals, scope and end conditions. An assessor will look for exceptions that were never closed, so the log should show who reviews it.
Review retention periods and deletion results periodically
Set a recurring review, at an interval the governance body approves, that compares the retention schedule with current privacy objectives, new data categories, new systems and any changes in law or contracts. Each review also samples deletion logs to confirm jobs ran and records were removed or anonymized as scheduled. Findings are logged with owners and due dates, and changes to the schedule go through the same approval as the original. The output is a dated review record and a list of corrective actions. Keeping these records is what allows an independent auditor to test P4.2 over a period rather than at a single point.

Protecting personal information while it is retained

In production, protection of retained personal information comes down to who can reach it, how it is stored and moved, and whether access is recorded. P4.2 expects the organization to protect personal information during retention, so the controls here sit alongside the access and encryption criteria in CC6 rather than replacing them. An assessor will look for controls that match the retention periods the organization has defined, not only generic database hardening.

Access restriction: Limit read access to personal information tables, buckets and file shares to the roles that need it, and review those grants on a set cadence.
Encryption at rest: Confirm that databases, object storage and volumes holding personal information are encrypted, and document which key management service or keystore holds the keys.
Encryption in transit: Require TLS for service-to-service and user connections to stores that hold personal information, and record the configuration baseline.
Access logging: Enable audit logs on data stores and retain them in a location the application team cannot alter, so reads and exports of personal information can be traced.
Segregated environments: Keep production personal information out of development and test systems unless a documented process masks or limits it.

Ask your team to show the access review record, the encryption configuration for each store and a sample of audit log entries for a recent export.

Evidence that shows P4.2 is met and stays current

P4.2 is met with records, not intentions. The artifacts below show what the organization decided to keep, where that data lives, and whether systems actually enforced those decisions. Each one needs a refresh cadence, because a Type 2 examination samples across the observation period rather than testing a single snapshot.

Retention schedule

The retention schedule names each category of personal information, the period it is kept, the trigger that starts the clock (such as account closure or last transaction), and the reason tied to the organization's privacy objectives. Check that every period matches what the systems actually enforce, and that the owner approved the schedule and the date of each revision. Review it at least annually and after any new product or data source.

Data inventory and location map

A current inventory lists every store holding personal information, including production databases, backups, logs, analytics warehouses, support tickets and exports on laptops. Without it, a retention rule cannot be shown to cover the data it is meant to govern. Reconcile the inventory against cloud accounts and infrastructure as code each quarter, and record who owns each store.

Configuration exports showing enforced periods

Retention in a system is evidenced by configuration, such as a lifecycle policy, a table partition expiry, a TTL setting or a database job definition. Export the live setting, not the design document, and keep dated copies. Ask the platform owner to confirm that changes to these settings go through change management, since an unreviewed edit can silently extend retention.

Deletion job logs

Logs from scheduled purge jobs show what ran, when, how many records were removed, and whether any job failed. A failed job that nobody reviewed is a common retention gap. Confirm that failures alert someone, that logs are retained long enough to cover the observation period, and that the log itself does not hold the personal information it reports on.

Exception approvals

Some data must be held beyond its normal period, for example under a legal hold, a dispute or a regulator's request. Each exception needs a written justification, an approver outside the requesting team, an end date and a review date. Record when each exception closed and confirm that the data was then disposed of, so that open exceptions do not quietly become permanent retention.

Access reviews for retained stores

Data kept beyond its active use is often reachable by more people than need it. Access reviews for archives, backups and cold storage should list who can read or restore retained personal information, confirm each grant is still needed, and record removals. Run these on the same cadence as production access reviews so the auditor can follow one consistent process.

Vendor retention terms

Processors and subservice organizations that hold personal information on the organization's behalf need contract terms covering how long they keep it, how they delete it, and how they confirm deletion. Collect these terms, check them against the retention schedule, and request deletion certificates or logs when a contract ends. Ask the vendor's own SOC report how it covers retention and disposal.

What meeting P4.2 costs in money and effort

Meeting P4.2 is mostly paid for in internal and advisory time rather than software. The largest one-time item is the data inventory and retention schedule: someone has to find every store holding personal information, record what it holds, why it is kept, who owns it and how long the organization's privacy objectives allow it to stay. Engineering time follows, because retention periods only count if systems enforce them, through scheduled deletion jobs, lifecycle rules on object storage, expiry on backups and purge routines in databases and logs. Legal or privacy counsel is paid to confirm the periods themselves, since they must reflect contractual, regulatory and customer commitments, not only internal preference. Whoever is paying for each item should be clear before work starts.

Recurring cost is the part organizations underestimate. Each retention rule needs evidence that it ran: job logs, deletion reports, backup expiry records and exceptions for data held under legal hold. Someone must review that evidence on a schedule, investigate failed jobs and keep the schedule current as products and vendors change. During the audit, the auditor will sample records, so the team must also be able to explain and locate them quickly. Cost rises with the number of data stores, legacy systems that cannot apply automated deletion, shadow copies in spreadsheets or analytics exports, and third-party processors that hold copies. Cost falls when data is classified consistently at the start, so that retention rules attach to a small set of classes rather than to each system one at a time.

When you request a quote, ask for a fixed scope that lists the systems in the inventory, the retention rules each one must follow, the engineering tasks to enforce them, the legal review and the evidence to be produced for the auditor. Ask which items are one-time and which recur, and what a retainer for ongoing evidence support would cover. DeployOpen does not publish a price list, and the reader should confirm with any provider which figures, timelines or effort estimates apply to their own environment before relying on them.

Cost components for P4.2 and what drives each one

This table lists the cost components behind meeting P4.2 retention in a SOC 2 examination, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Read the first two columns to see where spend recurs, and the last column for levers you control. No fees are stated because none were supplied for this topic.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses	Recurring	Number of systems holding personal information, retention features needed for lifecycle rules, and whether a GRC platform tracks retention evidence	Self-hosted open-source storage and database tools remove license fees, though hosting and support still cost money; confirm license terms for any component you adopt
Engineering time to build retention rules	One-time, with ongoing changes	Count of data stores, how retention periods map to privacy objectives, and whether deletion jobs must be written from scratch	Document retention periods once per data category and reuse one tested deletion pattern across stores
Evidence upkeep	Recurring	Frequency of retention job runs, log volume, and how often the retention schedule changes or new systems are added	Automate job logs and export them to a single evidence location so a reviewer can see runs without manual collection
External review or testing	Recurring, scoped per engagement	Whether an outside party tests deletion and backup expiry, and how many systems are in scope	Agree a written scope with the tester and limit it to the stores that hold the most sensitive personal information
Auditor sampling and walkthroughs	Recurring, set by the examination	Number of retention samples the auditor selects across the observation period and the number of systems the auditor must walk through	Keep one retention record per sample ready, with the period, the approver and the disposal proof, so each request is quick to answer

Questions about P4.2 retention, cost and outsourcing

How long can we keep personal information under P4.2?

P4.2 does not set a number of years. It asks that you retain personal information consistently with your own privacy objectives, so the period comes from the purposes you declared for collecting the data and from any law that applies to your business. Your auditor will test whether you defined retention periods, whether they match those objectives, and whether systems follow them. Start with a retention schedule that lists each data category, the purpose it serves, the trigger that starts the clock (for example, account closure or last transaction), and the disposal method. Confirm legal minimums and maximums with your counsel for each jurisdiction you serve, because those rules vary and sit outside the criterion itself.

Do backups count as retained personal information?

Yes. A backup copy is still personal information held by your organization, so it falls under the same retention and protection expectations as production data. The practical question is how long backups persist after a record is deleted in production. Your retention schedule should state the backup retention window, the rotation process, and how restores handle records that should no longer exist. Auditors commonly ask whether a restore could bring back data that was disposed of under policy, and whether that exposure is documented and accepted. Ask your team to show backup configurations, retention settings in the backup tool, and a sample restore test as evidence.

How much effort does a P4.2 control take to build?

Effort depends mainly on how many systems hold personal information, how much of that data is already tagged, and whether deletion is automated. Writing the retention schedule is a bounded task for a small team. Mapping data stores, configuring retention in each system, and proving the settings work over the examination period is usually the larger share. Recurring effort comes from reviewing the schedule, sampling disposal records, and handling new data stores or product changes. No duration is given here because it depends on your environment. Ask any partner to break the estimate into inventory, configuration, evidence collection and ongoing review, and to state which items assume your engineers do the work.

Can an in-house team implement P4.2 without outside help?

Often yes, if the team has ownership of the data stores and enough time to maintain them. The organization owns its controls, so the retention policy, the schedule and the decisions about legal periods must come from the business, with privacy or legal input. Engineers usually handle configuration, scripted deletion, and backup settings. Outside help is most useful for data inventory across many systems, for designing evidence that an auditor will accept, or for building open-source tooling that enforces retention inside your own cloud or data center. Whichever path you choose, an independent CPA firm issues the report. An implementation partner can prepare systems and evidence, but it cannot issue or sign the attestation.

What should we ask a partner or auditor for before we sign?

Ask for the scope in writing before work starts. A partner should list the systems in scope, the data categories covered, the deliverables (such as a retention schedule, configuration records and evidence procedures), and the timeline with dependencies on your staff. Ask which tasks the partner performs and which remain with your team. For the auditor, ask how they will sample disposal records, what evidence they expect for backups, and whether the engagement letter covers Type 1 or Type 2 testing. DeployOpen fixed-scope engagements are agreed in writing before work begins, and a quote follows from that written scope rather than from a published price list.

What changes between a Type 1 and a Type 2 test for P4.2?

A Type 1 report assesses whether the retention design is suitable as of a specific date. A Type 2 report also tests whether the controls operated effectively over an observation period. For P4.2, a Type 1 focuses on whether the retention schedule, disposal method and backup approach exist and are designed to meet your objectives. A Type 2 adds the question of whether disposal actually happened across the period, which means the auditor will sample records of deletions, backup expirations and exceptions. Plan for Type 2 by setting up logs and recurring reviews early, because the auditor cannot test operation that left no record. Confirm the observation period and sampling approach with your CPA firm before fieldwork begins.

Which open-source tools help produce P4.2 evidence?

Tooling supports the control but does not replace the policy. Common building blocks include data inventory and classification tools, scheduled deletion jobs in your database or object storage, lifecycle rules in self-hosted storage platforms, and backup software with configurable retention. Ticketing or workflow tools can record disposal requests and approvals, and log aggregation can keep the audit trail. Confirm each tool's retention and deletion features in its own documentation, since capabilities differ by version and by how it is deployed. Keep configuration in version control so that the settings in force during the period can be shown to the auditor.

Who owns P4.2 and who prepares the evidence

Your organization owns P4.2. The retention criterion asks you to keep personal information consistently with your privacy objectives, so the decisions that define compliance belong to you: which categories of personal information you hold, how long each category is needed, what triggers the end of a retention period, and who approves exceptions. An implementation partner can build systems that enforce those decisions, but cannot make them for you, and an auditor will test whether the periods you set were actually followed.

Objectives and periods: Set and document the retention period for each data category, tied to the purpose it serves.
Ownership of controls: Name an accountable owner for retention and disposal, and make sure that person can explain the control to an assessor.
Approvals and exceptions: Decide who may extend a period, and record the reason and the approver.
Policy alignment: Keep the retention schedule consistent with the privacy notice and any contractual or legal retention duties.
Management assertion: Your management makes the written representations the auditor relies on, so confirm the retention statements are accurate before signing.

Before engagement, confirm internally who owns each period and who signs off on changes.

Where organizations fall short on P4.2 and how to close it

P4.2 asks whether personal information is kept only as long as the privacy objectives allow and protected while it is kept. Most shortfalls come from retention rules that exist on paper but never reach the systems that hold the data. The cards below cover the gaps assessors most often find and the closing action for each.

Retention periods exist only in policy

The retention policy states a period for each data category, but no system is configured to enforce it, and nobody can say which owner approved the period. Assessors look for a retention schedule that names each data store, its purpose, the period and the reason for that period, tied to the privacy objectives in the system description. To close the gap, map every store holding personal information to a schedule line, assign an owner for each line, and record the approval date. Confirm that the schedule matches what the privacy notice tells data subjects.

Backups and logs ignored

Production databases are purged on schedule, but backup sets, replicas, log archives and analytics exports keep personal information for years with no rule attached. Those copies are often outside the access reviews and the deletion workflow. Inventory every backup target, snapshot policy and log sink that receives personal information, and state a retention period for each. Check whether a deleted record can be restored from an old backup and, if so, document how restored data is re-purged. Ask your infrastructure team to show the backup lifecycle configuration rather than describing it from memory.

Third-party copies unmanaged

Personal information sent to SaaS tools, subprocessors, support platforms and data processors often persists after the service ends, and the organization has no record of where those copies sit. Retention in your own environment does not limit what a vendor keeps. For each third party that holds personal information, record the retention period in the contract or data processing terms, request deletion or return at exit, and collect written confirmation. Review these commitments periodically, since vendor terms change without notice to your team.

No evidence of deletion runs

Deletion jobs may run, but nobody records what they removed, when they ran or whether they failed. Without that record, the organization cannot show an assessor that the schedule was followed in practice. Keep job logs that show the scope, the record count, the run date and the outcome, and review exceptions such as failed or partial runs. Sample a few data subjects whose records passed their retention date and confirm that the records are gone from primary stores and the backups in scope. Assessors commonly test this through sampling across the audit period.

Legal holds without approval trail

Legal holds suspend deletion, sometimes for an unclear period and sometimes for records outside the matter. When holds are placed by email with no record, deletion either continues against a hold or stays suspended indefinitely. Establish a hold process that names who may place and release a hold, the scope of records affected, and the review date. Record each approval and release in a register that the deletion jobs check before they run. Confirm with counsel which hold rules apply, since the legal basis for retention is set outside the SOC 2 criteria.

How DeployOpen prepares retention controls and evidence for P4.2

DeployOpen prepares the systems, retention controls and evidence an organization needs to show that personal information is kept only as long as its privacy objectives allow and is protected while it is retained. The organization owns its privacy objectives and retention decisions, and an independent CPA firm performs the SOC 2 examination and issues the report.

How we scope

We agree a written scope that names the systems, data stores and teams holding personal information in the P4.2 review.
The scope records which retention periods the organization has defined and which of them still need a documented owner.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure self-hosted platforms in your own infrastructure so retention settings are defined, applied and logged consistently.
We protect retained personal information with access restrictions, encryption and backup controls that match the documented retention rules.
We script retention checks as code where possible so the results can be rerun and reviewed by the auditor.

How we hand over

We deliver a retention control description, mapping each stored data category to its objective, period and owner.
We hand over evidence packs such as configuration exports, job logs and review records that the CPA firm can sample.
We document known gaps and remediation steps so management can decide on them before the examination begins.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can keep retention settings and evidence current as systems change between audit periods.
Your CPA firm remains the party that tests the controls and issues any report or opinion.