Data Retention for Reports and Exports: What to Store, What to Hash, What to Forget

The question you only hear during an audit

You generate statements, invoices, certificates, and exports on a schedule.

Then someone asks: "Show me the exact document you sent Customer X on March 15, 2023."

At that moment you need three things:

1. You can find the document fast.
2. You can prove it matches what you sent.
3. You can explain why you kept it, and why you deleted other things.

This post helps you decide what to retain, and how to implement it.

Store the PDF, or store the recipe

Every generated report forces one decision: do you retain the PDF itself, or do you retain enough inputs to rebuild it later.

Option 1: retain the PDF

Retaining the PDF gives you the exact artifact you delivered. That matters when you need to prove disclosures, terms, pricing, wording, and layout as the recipient saw them.

Retain the PDF when any of these apply:

1. Regulations or contracts require the exact delivered artifact.
2. The underlying data can change later (address updates, corrections, backfills).
3. Templates, branding, or legal text can change over time.
4. You expect legal discovery, disputes, or audits.

Costs and responsibilities you take on:

1. Storage grows with volume and years of retention.
2. You need strong access controls and tenant isolation.
3. You need a consistent folder or key structure so retrieval works under pressure.
4. You need deletion automation, plus logs that prove you deleted.

Where teams usually store PDFs:

1. Google Drive when you already manage access in Google Workspace.
2. SharePoint when your org runs on Microsoft and expects document libraries.
3. Object storage like Amazon S3, Azure Blob, or Google Cloud Storage when volume is high and you want lifecycle rules.

Object storage usually wins for large archives because you can apply lifecycle policies and cheaper tiers as documents age.

Option 2: retain generation metadata and regenerate

Regeneration means you store small records instead of large files. Typical metadata includes:

1. Template id and template version
2. Parameters (customer id, date range, filters)
3. A timestamp for the "as of" time
4. Delivery destination and job id
5. Who triggered it, and from where

Regeneration only works if your system stays stable. In practice you need:

1. Template versioning so you can render with the same layout and legal text.
2. Stable data, or a snapshot, so the content does not drift over time.
3. Stable external dependencies, like APIs that still exist and return the same data.

If you cannot guarantee those, regeneration fails or produces a different document than you sent, which defeats the purpose.

A safe pattern is to regenerate only for low stakes internal reports where perfect historical accuracy does not matter.

Content hashes: proof without keeping everything

A content hash is a cryptographic fingerprint of the PDF bytes. You generate the PDF, compute a hash (for example SHA256), and store it next to the generation metadata.

Later you can:

1. Retrieve the stored PDF and re hash it to detect corruption or tampering.
2. If you regenerate, hash the regenerated PDF and compare.

Hashes work best as an integrity layer, not as a replacement for storing documents. If you cannot regenerate reliably, a hash alone does not help you satisfy an audit request because you still need the document.

Use hashes when you want stronger integrity checks on stored PDFs, or when you need quick detection of accidental changes in storage.

Digital signatures: when authenticity matters

Digital signatures let a recipient verify two things without calling you:

1. Your organization signed the document.
2. The content did not change after signing.

That helps for contracts, certificates, and filings where authenticity carries legal weight.

Digital signatures do not remove the need to retain the PDF. You still store the signed artifact for the required period. You also take on certificate and key management, and you need a plan for certificate renewal and validation across many years.

If you do not have a legal requirement for signatures, focus on access control, audit logs, and retention discipline first.

Also retain inputs and generation history

People fixate on PDFs and forget the records around them. Those records often answer the real audit questions.

Inputs you should usually retain:

1. Parameters used for the run
2. Template version used
3. Data source identifiers, queries, or dataset ids

Generation history you should retain:

1. Who triggered it (user, schedule, webhook)
2. When it ran, down to a timestamp
3. Success or failure, with error details
4. Delivery channel and destination
5. Downloads or access events if you track them

You often keep history longer than PDFs because it is small and it supports investigations.

Choose retention by document class

Do not treat every report the same. Use simple classes tied to clear business value.

Short term operational reports

Examples: daily internal dashboards, weekly summaries.

Retention: days to a few months.

Typical approach: deliver by email or to a shared folder, then auto delete after a fixed window.

Business records

Examples: invoices, customer statements used for support, vendor documents.

Retention: one to three years is common, but you should align it to your local rules and business needs.

Typical approach: store in Drive or SharePoint for easy access, then archive or delete automatically when the period ends.

Long term compliance archives

Examples: regulatory filings, audit reports, annual statements, documents under legal hold.

Retention: many years, often five to ten depending on jurisdiction and industry.

Typical approach: store in object storage with lifecycle transitions to lower cost tiers, enforce immutability if required, and keep strong access logs.

Implement retention without heroics

Use a system approach so policy does not depend on someone remembering.

1. Write down real requirements

Map each report type to:

1. Legal or regulatory retention
2. Business retention
3. Privacy limits that push you to delete sooner
4. Legal hold rules that override deletion

If you do not know the rule, treat it as a risk and resolve it, do not default to keeping everything forever.

2. Classify documents and tag them

At minimum tag each document with:

1. Document type
2. Generation date
3. Retention class
4. Expiration date

Those tags make automation possible across storage systems.

3. Configure delivery and storage

Set CxReports delivery to match your storage choice. For example:

1. Google Drive job delivery
2. Email delivery settings

If your app downloads PDFs via API, store them immediately and apply retention in your own storage.

4. Keep a durable audit trail

Store generation events and delivery outcomes in your logging or audit system. Make it easy to answer who, what, when, where.

5. Automate deletion and keep deletion evidence

Manual deletion fails. Use lifecycle rules or scheduled cleanup jobs. Keep deletion logs that record what you deleted, when, and which policy triggered it.

Also align backups with your retention story. If backups retain deleted files for 90 days, your effective retention includes that window.

6. Test it

Teams often discover too late that cleanup never ran, permissions blocked it, or archives are not searchable. Run periodic tests:

1. Retrieve an old document under a realistic time constraint.
2. Verify that expired documents disappear on schedule.
3. Confirm that legal hold blocks deletion when required.

How CxReports fits in

CxReports generates and delivers reports, it does not act as your long term archive. You implement retention in your chosen storage system.

CxReports does retain your templates and configuration for active use. You can also export configuration bundles using Data Export for backup and migration: https://docs.cx-reports.com/settings/data-export

Treat that export as part of business continuity. It helps you restore your reporting environment, but it does not replace storing PDFs when you need exact historical artifacts.

Common mistakes you can avoid

1. Keeping everything forever. This increases cost, increases discovery scope, and can violate data minimization rules.
2. Assuming source data equals the report. Layout, wording, and template versions matter.
3. Forgetting backups. Deleting from primary storage does not mean the data is gone.
4. Not testing retrieval and deletion. Policy on paper is not policy in production.
5. Locking retention logic to one storage provider. Use tags and age based rules so you can migrate later.

A practical default

If you want a safe default for regulated or customer facing documents:

1. Retain the PDF for the required period.
2. Store the template version and run parameters.
3. Store a content hash for integrity checks.
4. Keep generation and delivery history longer than the PDF.
5. Automate deletion and log it.

That setup gives you fast retrieval, strong integrity, and a clean story for auditors.