FilePreserve
How it works Features Pricing
CAPA & complaint teamsDevice & pharma quality RADV audit responseHealth plan audit teams
Resources hub Guides Buyer's guide Setup guide Roadmap FAQ
About Security Pricing FAQ
Join the waitlist
Product
How it works Features Pricing
Solutions
CAPA & complaint teams RADV audit response
Resources
Resources hub Guides Buyer's guide Setup guide Roadmap FAQ
Company
About Security Terms Privacy
Join the waitlist
Security

Your data never leaves infrastructure you already own and control.

This isn't a marketing claim layered on top of a hosted product — it's the core principle FilePreserve was built around, and the reason it's designed the way it is.

Where your data actually lives

Two places. Both already yours.

Salesforce record data — stays in your org

FilePreserve runs entirely inside your own Salesforce organization as a managed package. It reads object/record data using the permissions and sharing rules of whichever user is running it — it never sees or accesses more than that user already has access to. There's no external API call and no third-party service involved in reading or evaluating your Salesforce records.

Archived files — your own AWS S3 bucket

When an archive job runs, files move to an AWS S3 bucket you create and control in your own AWS account — never FilePreserve's own infrastructure. Connection uses Salesforce's native AWS Signature Version 4 authentication, a built-in Named Credential/External Credential pattern — no custom signing code, no separate storage layer in between.

Native, with-sharing Apex — no external API surface

Every Apex class that touches data runs with sharing. There's no FilePreserve-operated server, no proxy, and no external API surface beyond the S3 connection you configure yourself — built to touch as little of your architecture as possible.

Why BYO storage, deliberately

Keeping your data in your own AWS account means your compliance posture stays yours.

Your archived files carry the same regulatory weight your Salesforce records already do — FDA CAPA/complaint documentation, PHI-adjacent records for CMS RADV response. Storing them in an AWS account you already control and audit, instead of a vendor's shared infrastructure, means that posture never depends on a third party's certifications or security practices. Bring-your-own-storage isn't a limitation — it's the deliberate, considered choice.

Hosted-storage archive vendor
  • Your compliance data sits in a third-party vendor's own multi-tenant storage
  • You're trusting their certification stack, not auditing it yourself
  • A vendor breach is now your compliance incident too
FilePreserve — BYO S3
  • Your archived files sit in an AWS account you already control and audit
  • Your compliance posture is governed by your own AWS controls, not a third party's
  • We never host, proxy, or retain a copy of your archived files ourselves
What FilePreserve is not claiming

Stated plainly, not buried in a footnote.

What FilePreserve is — and isn't. FilePreserve is built to help produce complete, audit-ready documentation packets faster. It is not itself SOC 2, HIPAA, or otherwise compliance-certified, and it doesn't claim to be — that's the direct consequence of the BYO-storage decision above, not an oversight. Your data's compliance posture stays governed by your own AWS account and controls, not a third-party vendor's certification stack. Billing is handled by Stripe, a PCI-compliant processor — the only third-party data processor involved anywhere in FilePreserve, and it only ever touches billing information, never your Salesforce records or archived files. See the Privacy Policy for the exact breakdown of what's touched and where it lives.

Read the exact data-handling breakdown.

The Privacy Policy and Setup Guide go into the specific technical detail behind everything on this page.

Read the Privacy Policy See the Setup Guide