The security requirements you must set – even without your own security expert

Security often feels like something only specialists can weigh in on, so many buyers leave the question entirely to the vendor. That’s a mistake. You don’t need your own security expert to set the right baseline requirements – you need to know which areas matter and be willing to ask how they’re handled. A vendor that takes security seriously can explain its practices so you understand them. If it can’t, you’ve already learned something important.

The requirement areas you should cover

Most security problems in development projects aren’t about advanced attacks – they’re about basic gaps. Four areas cover most of the risk, and you can require them without deep technical knowledge.

Each of these answers to a common real-world risk. Weak access control is how data leaks through forgotten or overly broad permissions. Without encryption, sensitive information sits unprotected if something goes astray. Outdated dependencies are one of the most common ways in, since known holes stay unpatched. And without logging, you’re blind if something goes wrong – you don’t even know what happened.

Questions about the vendor’s own practices

A secure system is built by a team with secure practices. So part of setting requirements is about the vendor itself, not just the code. Ask the questions directly:

• How do you handle access internally? Who at the vendor can reach your code and data, and how is that limited?
• How do you keep dependencies updated? Is there a routine for finding and fixing known vulnerabilities in the components you use?
• Do you review your own code for security flaws? Does it happen systematically, or only when someone happens to think of it?
• How do you act during an incident? Is there a plan, and who contacts whom?

Also ask whether they’ve had incidents before and what they learned. A vendor that answers openly and concretely is more trustworthy than one that claims it’s never had a single problem – because everyone who’s been in business long enough has.

A scenario: the requirement that saved a launch

A company was about to launch a service that handled personal data and, despite not having its own security expert, set a simple requirement: the vendor had to disclose every third-party component and its known vulnerabilities before launch. The review revealed a core component with a known, serious hole that had never been patched. It was replaced the week before launch.

The requirement wasn’t technically advanced – it was just a question that forced a check. Without it, the service would have gone live with an open door nobody had checked for.

Follow up on the requirements, not just write them down

The most common way to fail at security is to write impressive requirements into the contract and then never check them. Requirements that aren’t followed up on are ineffective, no matter how well worded.

So build follow-up into the work itself. Make sure security is part of the delivery criteria, so a feature isn’t counted as done until it’s secure. Check the requirements at milestones rather than only at the end. And ask for known vulnerabilities in dependencies to be fixed on an ongoing basis, not saved up for some future big cleanup. Follow-up is what makes the difference between security on paper and security in practice.

One last thing determines whether follow-up actually happens: that someone on your side owns it. Assign a person responsible for checking the requirements, even if that person isn’t a technologist themselves. The job isn’t to review the code, but to make sure the question gets asked at every milestone and the answers get documented. A requirement without an owner tends to get forgotten exactly when it matters most, and then you’re back to security on paper.

If you’d like help setting reasonable security requirements for your specific project, without needing your own expert, we at Weapp are happy to help – get in touch with a description of what the service will handle.