GDPR & Client Data: Auditing Multi-Cloud Storage for Compliance

Why multi-cloud compliance is hard

If you are a freelancer or a small business, your clients' data probably did not arrive in one tidy place. A logo lands in Google Drive. A contract gets attached in OneDrive. Raw footage goes to an S3 bucket because it was cheap. An old project archive still sits in Backblaze B2, and a working copy lives in a Local folder on your laptop. Each provider has its own login, its own search box, and its own idea of what "metadata" means.

Compliance frameworks like the GDPR start from a simple expectation that is surprisingly hard to meet in this world: you should know what personal data you hold, where it lives, why you have it, and how it is protected. When the data is scattered across five providers, even answering "where is all of my client's data?" turns into an afternoon of clicking through web consoles - and you can never be sure you found everything.

FileFortress changes the shape of that problem. It scans every provider and builds a single index that lives on your device, never on a server. That local-first design is itself a data-minimization win: the catalog of your files, including their names and metadata, is not copied into yet another cloud you would then have to account for. Once that index exists, the questions a compliance review asks - what do I hold, is it encrypted, does it contain personal data, is it stale - become searches you can run in seconds and repeat on demand.

The five-step audit at a glance

1. Build a data inventory

You cannot protect, classify, or delete data you do not know you have. So the audit starts with a complete, current picture of everything you hold across every provider. The fastest way to get there is to scan all of your configured remotes in one pass, which refreshes the local index for Google Drive, OneDrive, S3, Backblaze B2, and any Local remotes at once.

# Refresh the index for every configured remote in one pass
filefortress remotes scan --all

# Or scan a single provider by name (useful for spot checks)
filefortress remotes scan "Client Drive"

With a fresh index in place, search becomes your inventory tool. Run it with no term to list everything, or narrow to a single client folder, a provider, or a file type. The key move for compliance is to export the result to a dated file so you have a snapshot of exactly what you held on the day you looked.

# Inventory everything, written to a dated JSON file
filefortress search --view json --save-to-file inventory-2026-06-21.json

# Inventory a single client by folder path
filefortress search --path-filter "Clients/Acme/*" --view json --save-to-file acme-inventory.json

# Inventory everything in one provider only
filefortress search --remote "Backblaze Archive" --view json -o b2-inventory.json

The --view json output (short form -v json) gives you structured records you can hand to a spreadsheet, a script, or simply archive as evidence that you performed the review. The --save-to-file flag (short form -o) writes it to disk so nothing is lost when the terminal scrolls.

2. Encryption audit

Once you know what you hold, the next question is whether it is protected. The GDPR repeatedly points to encryption as an example of an appropriate technical measure, and "encrypted at rest" is one of the first boxes most client security questionnaires ask you to tick. FileFortress tracks an encryption status for each indexed file, so you can ask the index directly: show me everything that is not client-side encrypted.

# Find files that are NOT client-side encrypted
filefortress search --encrypted false

# Scope the check to one client's data
filefortress search --path-filter "Clients/Acme/*" --encrypted false

# Export the gap list for review or remediation tracking
filefortress search --encrypted false --view json --save-to-file unencrypted-2026-06-21.json

The --encrypted filter takes true or false. Passing false returns the files FileFortress does not see as client-side encrypted - your remediation worklist. Flip it to --encrypted true to confirm what is already covered.

Remediating the gaps

To close the gaps the audit found, configure client-side encryption per remote so new and re-uploaded files are encrypted before they reach the provider. FileFortress supports RClone-compatible encryption and custom AES-256 encryption on a remote-by-remote basis. The two guides below cover the concepts and the setup:

• Understanding FileFortress Encryption Options - choose the right mode for your data
• Remote Storage Encryption Guide - configure encrypted remotes step by step

After you have encrypted the flagged data, re-run the same search --encrypted false query. A shrinking result set is concrete, repeatable evidence that the gap is closing.

3. Locate sensitive & PII data

Encryption protects everything equally, but compliance also asks you to know where the sensitive material is - the personal data, the credentials, the things that turn a minor incident into a reportable breach. Two filters do most of the work here: a geolocation check for photos, and filename pattern matching for secrets.

Location data hidden in photos

Photos taken on phones and many cameras embed GPS coordinates in their EXIF metadata. For a wedding photographer or a real-estate agent, that is personal data about where someone was at a point in time - and clients are often surprised it is there at all. If your remotes are enriched, FileFortress can surface every file that carries a GPS location.

# Find files that carry GPS location data
filefortress search --has-geo true

# Same, scoped to a client and exported for the record
filefortress search --path-filter "Clients/Acme/*" --has-geo true \
  --view json --save-to-file acme-geotagged.json

The --has-geo filter takes true or false. Location data only appears in the index after enrichment extracts it, so if you get no results, confirm your files have been enriched first - see the Local Tools Guide. For more on why metadata like this is easy to leak, the blog post on how metadata leaks privacy is worth a read.

Secrets, keys, and config files

The other category of sensitive data is the one nobody means to upload: a private key, a .env file, an exported credential, a document literally named "passwords". These tend to ride along in project folders and then sit forgotten in the cloud. You can hunt for them by name using the search term or the --path-filter pattern.

# Private keys and certificates anywhere in the index
filefortress search --path-filter "*.pem"
filefortress search --path-filter "*.key"

# Environment and config files that often hold credentials
filefortress search --path-filter "*.env"

# Anything that names itself a secret
filefortress search "secret"
filefortress search --path-filter "*secret*"

The --path-filter option (short form -p) matches path patterns such as *.pem or docs/*, while a bare search term matches the file name. Run these across all remotes at once and you will often turn up a key that was committed to a backup folder years ago.

4. Retention & data minimization

Data minimization is a core GDPR principle: do not keep personal data longer than you need it. In practice that means periodically finding the oldest material and asking, "do I still have a reason to hold this?" FileFortress does not yet have an "older than" filter, but ls can sort by modification time, and reversing that sort puts the stalest files right at the top.

# Oldest files first - stale data rises to the top
filefortress ls --sort time --reverse

# Within a single client folder
filefortress ls "Clients/Acme" --sort time --reverse --long

# Within one provider, recursively
filefortress ls --remote "Backblaze Archive" --recursive --sort time --reverse

The --sort time option orders by modification time, and --reverse flips it so the oldest entries appear first. Add --long (short form -l) to see size, modified time, and which remote each file lives on - useful when you are deciding what is safe to retire.

Scan the top of that list against your retention policy. A contract you are legally required to keep stays; raw exports from a project that closed three years ago probably do not. Pairing this stale-data view with the encryption audit gives you a tidy decision: anything old and unencrypted is a strong candidate for deletion rather than remediation.

5. Keep it repeatable

A one-time audit goes stale the moment someone uploads a new file. Compliance is an ongoing posture, so the real value comes from turning these checks into named queries you can re-run any time - and proving you actually do. The search command can save a query under a name with --save-query.

# Save the encryption-gap check for reuse
filefortress search --encrypted false --save-query unencrypted-files

# Save the geotagged-photo check
filefortress search --has-geo true --save-query geotagged-files

# Save a per-client inventory query
filefortress search --path-filter "Clients/Acme/*" --save-query acme-inventory

Once a query is named, you can re-run it after every scan and export a fresh, dated snapshot. The pattern is always the same: scan everything, then run each saved compliance query and save its output to a file stamped with today's date.

# A monthly compliance pass you can drop into a script
filefortress remotes scan --all
filefortress search --encrypted false --view json --save-to-file unencrypted-2026-06-21.json
filefortress search --has-geo true   --view json --save-to-file geotagged-2026-06-21.json
filefortress search --path-filter "*.pem" --view json --save-to-file keys-2026-06-21.json

Schedule that script with Task Scheduler on Windows or cron on macOS and Linux, and your audit runs itself. For the full mechanics of saving, chaining, and freezing queries, see the Saved Queries guide. For the complete list of filters you can combine into these checks, keep the Structured Filters reference handy.

A note on what's coming

Everything above is built from primitives that ship today. We are also working toward making this far less manual. The following are on the roadmap and are not available yet - do not plan around them as current features:

• A dedicated audit command that runs the inventory, encryption, sensitive-data, and retention checks in a single pass and produces one report.
• Compliance scoring, so you get a clear read on how much of your footprint is encrypted, geotagged, or stale - and whether that number is improving over time.
• Ready-made GDPR and SOC 2 policy templates you can map your data against, instead of assembling checks by hand.

Until those land, the saved-query approach in step 5 gets you most of the way there: a repeatable, exportable, dated audit you control end to end. When the dedicated tooling arrives, the queries and the habits you build now will carry straight over.

Related guides

• Encryption Options Guide - choose client-side encryption for client data
• Remote Storage Encryption Guide - set up encrypted remotes to close gaps
• Structured Filters Reference - every filter you can combine into a check
• Saved Queries Guide - make your audit repeatable and scheduled
• The Complete Guide to Cloud Storage Privacy - what your provider isn't telling you
• How Metadata Leaks Privacy - why hidden metadata matters for client data