Salesforce Data Retention Requirements: What the Platform Keeps, and For How Long

How long does Salesforce keep data by default?

Different data types, different answers. The distinction that matters is between record data and history data, and it is where most planning goes wrong.

Every row verified against Salesforce Help, August 2026. Salesforce states you can download setup history "for the past 180 days, and after 180 days, setup entity records are deleted", and that field history is retained up to 18 months, or up to 24 months via the API.

Two observations that follow directly:

Record data is retained too long, history data not long enough. Your Contacts sit in the org forever unless something deletes them, which is a data-minimisation problem. Meanwhile the evidence of what happened to those Contacts evaporates on a 180-day and 18-month schedule, which is an evidence problem. These pull in opposite directions and need different mechanisms.

Setup Audit Trail is the sharpest edge. It is the record of who changed your org's configuration: permission sets, sharing rules, field-level security, profile changes. It is exactly what an auditor asks for when testing change control under SOX or a security framework. It retains 180 days and then it is gone, and unlike Field History there is no add-on that extends it. If you have not been exporting it, the evidence for any period older than six months does not exist and cannot be recovered.

What do regulations actually require?

Retention obligations pull in both directions at once, and a policy that only handles one direction is incomplete.

Keep it long enough

• SOX, financial records and the controls evidence around them, commonly seven years.
• FINRA, books and records requirements with specific retention periods and format requirements for regulated communications.
• HIPAA, documentation retention of six years from creation or last effective date, on top of state medical-record rules that are often longer.
• Sector and contract: insurance, education and government contracts routinely impose their own schedules, sometimes longer than statute.

Delete it soon enough

• GDPR Article 5(1)(e), storage limitation: personal data kept in identifiable form no longer than necessary for the purpose.
• CCPA/CPRA and the state laws: retention disclosure obligations and, in several states, explicit minimisation duties.
• Right to erasure, deletion on request, which is retention policy operating per-person rather than per-schedule.

The two directions are not in conflict once you separate them properly: the retention obligation usually attaches to a *transaction record* or a *control artefact*, while the minimisation obligation attaches to *identifiable personal data*. De-identification often satisfies both simultaneously, you keep the record and remove the person from it. That is the single most useful design move in retention planning and it is routinely overlooked in favour of a binary keep-or-delete framing.

Why doesn't a retention policy document solve this?

Because a document is not a control.

Most orgs have a written retention schedule. Far fewer have anything that executes it. The gap between them is where audit findings live, and it is a worse position than having no policy at all: you have documented an obligation and then demonstrably failed to meet it. Auditors and regulators treat that combination as evidence of a control failure rather than an oversight.

Three failure patterns, all common:

• The policy exists but nothing runs it. Deletion happens when someone remembers, which is to say during quiet quarters and never during busy ones.
• Deletion runs but leaves fragments. The Contact is deleted; the Case description still names the person, the attachment still holds their ID document, and the custom object nobody remembers still has the row.
• Deletion runs and produces no evidence. Records are gone, which is what the policy asked for, but there is no artefact proving what was deleted, when, by whom, or under which rule. From an auditor's position, an absence is not proof of a deletion. It is indistinguishable from data that was never there, or from data deleted for the wrong reason.

The third is the one that turns a good outcome into a finding.

How do I close the retention gap in Salesforce?

Four approaches. They differ mainly in where the data ends up and who becomes responsible for proving it is intact and unaltered.

Option 1, Export to an external archive

Scheduled extract to a data warehouse, object store or archiving platform.

Good for: long retention at low storage cost; data you rarely need to query. Costs you: the archive is now in scope for your security programme, your Article 30 record and your breach-notification analysis. Personal data outside Salesforce is still personal data, and it is now in a system with different access controls. Restoring for an audit is a project, not a query. If a data subject requests erasure, you must reach the archive too, and teams routinely forget this, which turns the archive into a compliance liability rather than an asset.

Option 2, Big Objects

Salesforce's native store for high-volume archival data, queryable without affecting operational performance.

Good for: staying on-platform; very large volumes; keeping data inside the Salesforce trust boundary. Costs you: meaningful technical expertise. Big Objects have no standard UI, a restricted query model, and index design decisions that are difficult to reverse once data is loaded. Budget real architecture time, not a sprint.

Option 3, A dedicated archiving product

Purpose-built archiving tools, several of which are Big Objects–based.

Good for: teams who want the Big Objects benefits without building the plumbing; strong at the storage-management problem. Consider: whether the product produces *compliance evidence* or only *storage outcomes*. Archiving and retention-compliance are adjacent, not identical. Archiving answers "where did the data go"; compliance answers "prove the policy executed correctly on this date against these records". Ask to see the second artefact.

Option 4: Native retention automation

Policy-based deletion and de-identification running as Apex inside the org, on a schedule, producing an audit record of each run.

Good for: the compliance-evidence problem specifically; keeping personal data inside the org boundary; handling both directions of retention, archive what must be kept, delete or de-identify what must not, under one policy engine. Costs you: it is not a storage-cost tool first. If your primary problem is a data-storage bill rather than an audit finding, a dedicated archiving product may fit better. Be honest with yourself about which problem you actually have; they sound similar in a budget request and are not the same project.

This last option is what we build, so weigh that accordingly.

What should a Salesforce retention policy contain?

Working backwards from what an auditor asks for:

• A data inventory. Which objects and fields hold what categories of data. You cannot write a schedule for data you have not located, and in a mature org personal data is in long-text fields, attachments and abandoned custom objects. Personal data discovery produces this inventory.
• A retention period per category, with its justification. Not just "7 years" but "7 years, SOX §802". The justification is what makes the schedule defensible when someone asks why.
• A defined action at expiry. Delete, de-identify, or archive-then-delete. De-identification is frequently the right answer and is under-used.
• Cascade rules. What happens to child records when a parent expires. Get this wrong and you either orphan records or break the parent's dependants.
• Exception handling. Litigation hold, regulatory investigation, open dispute. A policy with no hold mechanism will eventually delete something that was under preservation obligation, which is a materially worse problem than over-retention.
• An execution schedule. When it runs, and what happens if a run fails.
• An evidence artefact. What each run produces, where it is stored, and how long *that* is retained. The evidence has its own retention period, and it is usually longer than the data's.

Items 5 and 7 are the ones most often missing, and they are the two an auditor tests first.

What should I do first?

If you are starting from nothing, in this order:

• Export Setup Audit Trail now, and schedule it. This is the only item on this page with a hard clock already running against you. Everything older than 180 days is already unrecoverable; everything newer is recoverable only until it is not.
• Inventory where personal data actually is. Not where you designed it to be, where it ended up.
• Write the schedule with justifications, including the hold mechanism.
• Automate the execution, so it survives a busy quarter.
• Verify the evidence artefact by asking someone outside the project to prove a specific record was deleted under a specific rule on a specific date, using only the artefact. If they cannot, the artefact is insufficient, find that out now rather than during an audit.

Where Cloud Compliance fits

Data Retention Manager is a Salesforce-native managed package for policy-based retention: scheduled, cascade-aware deletion and de-identification across standard and custom objects, with an audit record of every run. It runs as Apex inside your org, data does not leave Salesforce, and typically reduces storage by around 70% as a side effect of enforcing the policy rather than as its purpose.

The honest positioning: we are built for the compliance-evidence problem. If your actual problem is a storage bill, dedicated archiving products approach it more directly and you should look at them. If your problem is that an auditor asked for proof your retention policy executed and you could not produce it, that is what we are for.

We also do not set your retention periods. Those come from your regulators, counsel and contracts. Software executes the schedule and proves it ran; it does not tell you what the schedule should be.

Book a demo if you want to see the audit artefact against your own object model.

Last updated: 19 August 2026