Security problems are cheapest to fix before launch and most expensive to fix after a customer finds them for you. You do not need to be technical to make sure the basics are covered. You need to ask the right questions and expect clear answers.
Here are ten to ask your team before anything goes live.
Accounts and access
1. Is everything in your name? The domain, the app store accounts, the cloud hosting, the code repository and the email service. If a supplier holds them, you do not fully control your own product.
2. Who can get in, and how? Ask for a list of everyone with administrator access, and confirm that each one uses two-factor sign-in. Former contractors should not still be on that list.
3. Where are the passwords and keys kept? The secret keys that connect your software to payment providers, email services and databases should live in a proper secret store, never in the code and never in a shared document.
Your users and their data
4. What personal data do you collect, and why? Collect only what the product needs. Every extra field is something you have to protect and, under privacy law, justify.
5. Can one user see another user’s data? This is one of the most common serious flaws: change a number in a web address or a request, and someone else’s record appears. Ask how this is prevented, and how it was tested.
6. Are sign-in and password reset protected against abuse? Limits on repeated attempts, codes that expire, and emails that do not reveal whether an account exists.
The software itself
7. Is everything that comes in checked? Every form, upload and connection from outside should be validated before your system trusts it. That includes anything produced by AI features.
8. Are the building blocks up to date? Modern software is assembled from many open-source packages. Ask when they were last checked for known security problems, and how you will hear about new ones.
9. Is there a backup you have actually restored? A backup that has never been tested is a hope, not a plan. Ask when a restore was last tried, and how long it took.
After launch
10. What happens when something goes wrong? Who gets alerted, who responds, and how would you find out? Ask for error monitoring, a short written plan for an incident, and a named person responsible.
How to use this list
Send these ten questions to your team and ask for a short written answer to each. Clear, specific answers are a good sign. Vague ones (“we follow best practice”) are worth a follow-up.
If the answers do not add up, or you would simply like a second pair of eyes before launch, an independent review can check the parts you cannot: the code, the configuration and how the system really behaves. The point is not to catch anyone out. It is to make sure the thing your business depends on is as solid as everyone believes it is.