2026-06-27
Keep data in the customer's Drive: the minimal-retention design
How to lower the data-breach risk of a business SaaS. The idea of keeping the data in the customer's hands and minimizing server retention.
The more you hoard, the bigger the risk
The more customer data a provider hoards on its servers, the larger the damage if attacked. Conversely, keeping less on the server structurally shrinks the blast radius. The less there is to protect, the simpler the protection can be and the less likely a check is missed. The starting point of design is to ask, 'do we really need to keep this on the server?'
Keep the data in the customer's Drive
Make the final destination a spreadsheet inside the customer's own Google Drive and the data's controller returns to the customer. The provider only relays it and does not keep it long-term. Customers can decide who may view it through their own access settings, and even when they end the contract the data itself stays in their hands. A design that doesn't hold data hostage also adds reassurance at adoption.
Time-box server retention
Hold only the transient data between submission and approval, erase it on approval, and auto-erase even unapproved data within 24 hours. Being able to state 'it stays at most 24 hours' helps the adopter's review pass. What matters here is that erasure runs automatically rather than depending on a person's action, and that the retention ceiling can be explained in words. A vague 'we delete it as soon as possible' gives the reviewer nothing to judge.
Erasure alone isn't enough
Minimal retention is powerful but doesn't make you safe by itself. Only when you also have the basics — encrypted transport, separated write permissions, and operation logs — does it become something you can use with confidence. For example, thinking of three things as a set reduces gaps: it can't be read by a third party while held, writes are limited to the needed scope, and you can trace afterward what happened.
Sample questions to check before adopting
As a guide, an adopter can put these questions to the provider: 'Where does the data itself live?' 'What is the upper limit on how long it stays on the server?' 'Is erasure automatic or manual?' 'If we want to revoke access, what is the procedure?' The more concrete the answers, and the more they can be explained as a mechanism, the easier it is to judge that the design is well organized. Conversely, if the answer depends on the carefulness of an operator, that is a spot that tends to be a weakness. Finally, check whether the design explanation is available in writing; it helps later in internal approval and review.
Related articles
A tool for a culture of improvement and fair evaluation that implements these ideas.