Without knowing anything about your software: * Build your software to stream data directly from Client A's API to Client B's API without it ever being at re

Without knowing anything about your software: * Build your software to stream data directly from Client A's API to Client B's API without it ever being at rest on a machine you control. * If your users want reports based off their data, then see if you can fetch the relevant data from the client on demand, build the report email in memory, then forget the raw data. * Tell your clients you prefer to use their oauth provider of choice to authorize instead of storing usernames and password hashes yourself. * Key your access logs off of an (arbitrary and short lived) session id instead of a user id. Maybe none of that's appropriate for your use case. Maybe your company already stores the minimum viable dataset for its needs, and maybe that minimum viable dataset is still huge. But the fact remains that you can't leak what you don't have, and even marginal differences can still make the data you do hold a little less valuable to thieves and a little harder to deanonymize and collate with other leaks. I use the term "code smell" in the same sense sense as "`if` statements are a code smell". It doesn't mean never to use them, it just means that solutions that don't use them tend to be consistently better than solutions that do. Solutions that store less (or no) data tend to be consistently more secure than solutions that do store more data. That doesn't mean those solutions always exist, just that one should prefer them when they do.