The security questions to ask before anyone builds your software

When you buy software from a vendor, their security team is part of what you're paying for. When you commission custom software, that responsibility moves to you, and it moves quietly. Nobody sends an email about it.

These are the questions I ask when someone else has built a system I am about to be responsible for. They are the same ones worth asking before anyone starts building yours.

Where it runs

1. Where does this actually live, and who has access to production?

You want a short list of named people, not "the team". Ask how someone gets added to that list and how they get removed. If the answer involves a shared login, stop there and fix that first.

2. How do you handle secrets?

API keys, database passwords, certificates. The right answer involves a secrets manager or the hosting platform's encrypted environment variables. The wrong answers are a config file in the repository, a shared password manager note, or a long pause.

3. Is production access behind MFA?

Not the application. The hosting account, the database, the deployment pipeline. This is where a compromise is total rather than partial.

What happens when something goes wrong

4. Walk me through your last restore test.

This is the single most revealing question on the list, which is why it is worth asking exactly this way rather than "do you have backups". Everyone has backups. Far fewer have ever restored one, and a backup nobody has restored is a hypothesis rather than a safeguard.

A good answer includes a date, roughly how long it took, and something that went wrong and got fixed. A vague answer is the answer.

5. What is the recovery point, in hours?

If the database is lost at 3pm, how much work do people have to redo? Hourly snapshots and nightly snapshots are both defensible positions. Not knowing which one you have is not.

6. What is your patching cadence, and who watches for advisories?

Applications are mostly other people's code. A dependency with a known vulnerability sitting unpatched for eight months is the ordinary way this goes wrong, and it goes wrong long after launch, which is exactly when nobody is looking.

Ask whether patching is part of the ongoing arrangement or billed as incidents. The answer tells you whether it will happen.

What you can prove afterwards

7. What gets logged, and how long is it kept?

You want to be able to answer "who changed this record, and when" a year later. This matters for ordinary disputes far more often than it matters for breaches.

8. If there is a breach, who tells whom, and how fast?

Illinois, like most states, has a notification requirement. Know before the incident who is making the call and on what timeline, because the day of is a bad time to discover nobody knows.

9. What data are we collecting that we don't need?

The cheapest security control available. Data you never stored cannot leak. It is worth one conversation at design time asking why each sensitive field is there at all, and a surprising number do not survive the question.

The answers that should worry you

• "That is handled by the hosting provider." Some of it is. Not the parts that are your configuration.
• "We can add security later." Authentication, authorization and audit trails are architecture. Retrofitting them means rewriting.
• "We have never had a problem." Not a control. Not evidence of one either.
• Any answer that is confident, immediate and contains no specifics.

Why we are conservative about this

14 years of running mission-critical IT and security for other people's businesses tends to make you cautious in specific ways. We host, patch and monitor what we build rather than subcontract it, partly because that is the only way to answer question four with a date instead of a shrug.

If you're commissioning software from anyone, ours or otherwise, ask these nine. The good shops will enjoy the conversation.