Guide · for owners with a deal on the line
What a Customer's Security Review Will Ask You
William Belle — Cloud Deployment and Software Engineering Questions: support@williambelle.co
At some point after your app starts working, someone stops asking what it does and starts asking whether it is safe. It is usually a customer about to sign, sometimes their IT person, occasionally an investor. The email is polite and it contains a list.
If you built the app yourself with an AI tool, that list can be alarming, because it is written in a vocabulary nobody handed you. This guide is that list translated, along with what a good answer looks like and where these apps usually come up short.
The useful thing to know first: almost nobody fails this because their code was bad. They fail it because nobody can answer where the data lives and who can reach it.
What they actually ask
Reviews vary, but the questions cluster into five groups. If you can answer these five, you can answer most of any list you are sent.
1. Where does our data live?
Which company holds it, in which country, and who else can reach it.
A good answer names things. "It runs in Microsoft Azure, in their East US region, in an account owned by my company. The database is not reachable from the public internet. Two people have access: me, and my engineer, and his access can be withdrawn at any time."
Where these apps fall down: the honest answer is often "I pressed deploy in the tool and I am not sure." That answer, given to a cautious buyer, ends the conversation more often than any technical flaw would.
2. Is our data encrypted?
Both while it moves and while it sits.
A good answer covers both halves. In transit is usually fine already, because modern hosting gives you a secure connection by default. At rest is a setting on the database and on file storage, it is often off, and no warning tells you.
Where these apps fall down: owners answer "yes, we use HTTPS," which only covers the first half. A reviewer who knows the difference hears half an answer.
3. Who can log in, and what can they reach?
Sign-in, a second step, and whether one customer can reach another's records.
A good answer separates the two. Keeping strangers out is one question. Making sure a signed-in customer can only reach their own records is a different one, and it is the harder one.
Where these apps fall down: this is the most common serious flaw I find. A sign-in page works, and inside the app, records are reachable by changing a number in the address bar. You can test this yourself in five minutes, and you should, today. Sign in as one test user, take the address of a record belonging to a different user, and load it. If it opens, that is your first job.
4. What happens when it breaks?
Backups, whether they have ever been restored, and how you find out about an outage.
A good answer includes the word "tested." A backup nobody has ever restored is a belief, not a backup. "Backed up nightly, retained 30 days, and I have restored one to a test copy to prove it works" is a materially stronger answer than "yes, it's backed up."
Where these apps fall down: backups usually exist and have never been restored, and nobody is watching whether the app is up. The owner learns it is down from a customer.
5. Can you show us?
Documentation, a record of what is configured, and often a form of theirs to fill in.
A good answer is a document you already have, written before anyone asked, that covers every account, password and security setting in plain language.
Where these apps fall down: there is nothing written down. Everything the owner knows is in their head, and assembling it under deadline while a deal waits is where the weekend goes.
The three answers worth having ready
If a review is coming and you have limited time, these three carry the most weight.
Name the infrastructure. Which provider, which region, whose account, and who has access. A reviewer relaxes noticeably when the answer is specific.
Prove one customer cannot reach another's data. Test it, fix it if it fails, and be able to say you tested it.
Have something written. Even four pages beats a promise to follow up. What runs where, who can reach it, what is encrypted, how it is backed up, and what you do when it breaks.
What you will not be asked
Worth saying, because owners brace for the wrong things.
Nobody asks which tool wrote your code. Reviewers care about where the data is and who can reach it, not about how the code came to exist. If you have been quietly worried that "I built it with Lovable" is the answer that sinks you, it is not.
Nobody asks for a security certification either, unless you are selling to a large enterprise. A small business buyer wants to know you have thought about it and can show your work.
How this maps to a deployment
Everything above is what a Secure Cloud Deployment is for, which is why the list is so familiar to me.
The app moves onto cloud accounts in your name, so question one has a specific answer. Encryption is turned on in both places, so question two has both halves. Access is configured and tested, so question three is something you have proved rather than assumed. Backups are set up and one is restored to prove it works, so question four contains the word "tested." And it ends in a written handover covering every account, password and security setting, so question five is a document you already have.
If your app also holds health records, tax data or legal matters, a Compliance-Ready Deployment adds the written check against the rules your field imposes and the evidence packet that goes with it.
Get a free 20-minute review — show me what you have and I'll tell you the first three things I'd fix in it, and why. No pitch, and nothing to prepare.