The security questions to ask before anyone builds your software

When you buy software off the shelf, the vendor's security team is part of what you're paying for. When you have software built for you, that job moves over to you, and nobody really tells you it's happened. There's no email about it.

These are the questions I ask when I'm about to take responsibility for a system someone else built. They're the same ones worth asking before anyone starts building yours.

Where it runs and who can get in

Start with where does this live, and who can get into the live system? You want a short list of named people, not "the team." Ask how someone gets added to that list and how they're taken off it. If the answer involves a login several people share, stop there and get that fixed first.

Next, ask how do you look after the passwords and keys the system itself uses? Every application has them: the password to its database, the keys it uses to connect to other services, its security certificates. A good answer is that they're kept in a locked store made for the purpose, either a dedicated tool or the hosting company's encrypted settings. Bad answers are a file sitting in with the code, a note in a shared password manager, or a long pause.

Then ask does getting into the live system take a second step, like a code from a phone? I don't mean signing in to the application. I mean the hosting account, the database, and the tools used to put updates live. Someone who gets into those has everything, not just part of it.

What happens when something goes wrong

The question that tells you the most is walk me through the last time you tested restoring a backup. Ask it exactly that way, instead of "do you have backups," because everyone has backups. Far fewer have ever restored one, and until a backup has been restored, you're only hoping it works. A good answer includes a date, roughly how long it took, and something that went wrong and got fixed. A vague answer tells you what you need to know.

Then ask if the database were lost at 3pm, how many hours of work would people have to redo? Taking backups every hour and taking them every night are both reasonable choices. Not knowing which one you have isn't.

Also ask how often do you apply security updates, and who keeps an eye out for warnings? Most of any application is made of components other people wrote. One of those with a known weakness, left unpatched for eight months, is the ordinary way this goes wrong, and it tends to happen long after launch, when nobody is looking. Ask whether updates are part of the ongoing arrangement or billed each time something comes up. That tells you whether they'll get done.

What you can show afterwards

Ask what gets recorded about who did what, and how long is that kept? A year from now you want to be able to say who changed a record, and when. That comes up in ordinary disagreements far more often than it does after a break-in.

Ask if there's a breach, who tells whom, and how quickly? Illinois, like most states, has a breach notification requirement. Agree before anything happens on who makes that call and on what timeline, because the day of a breach is a bad time to find out nobody knows.

And ask what information are we collecting that we don't need? This is the cheapest protection there is, because data you never stored can't leak. It's worth one conversation while the system is being designed about why each sensitive piece of information is there at all. A surprising number of them don't make the cut.

Answers that should worry you

Be wary of "the hosting company handles that." Some of it, yes, but not the settings that are yours to get right. Be wary of "we can add security later," too. Deciding who can sign in, what each person is allowed to see, and keeping a record of who did what all have to be designed in from the start, and adding them afterwards usually means rebuilding. "We've never had a problem" isn't a safeguard, and it isn't evidence of one either. And watch out for any answer that comes back confident and instant with no specifics in it.

Why we're careful about this

Fourteen years of running the IT and security that other people's businesses depend on makes you cautious in particular ways. We host, update and monitor what we build ourselves instead of handing it to a subcontractor, partly because that's the only way to answer the backup question with a date instead of a shrug.

If you're having software built by anyone, us or someone else, ask these nine questions. A good developer will be glad you did and happy to talk them through.