Questions to ask a vendor before they touch your app’s security

Security work covers very different jobs. A scanner run takes hours and produces a long list. A manual code review takes days. It finds logic flaws a scanner cannot see, such as a user opening another customer’s invoice by editing the ID in the address bar.

Ask which of these you are buying and in what proportion. Ask for a sample report with client details removed. If findings read as generic text copied from a tool, you are paying for a scan.

Also ask which parts of the application are in scope. Mobile apps, admin panels, APIs and file uploads are often left out unless you name them.

Good vendors say what they cannot promise. No firm can certify that software is free of flaws. They can say what they tested, on what dates, against which version.

Watch for words such as hack proof or fully secure. Look instead for a scope statement, a test period and a named build. A report that stops at those limits is more useful in front of a customer or an insurer.

If you need ISO 27001 or SOC 2 evidence, ask whether the vendor is an assessor or only a supplier of inputs to one.

Access is the quiet risk. The vendor may need a staging copy, a test account for each role and read access to the Git repository. Ask that they use named accounts, never a shared login, and that every credential expires on a date written into the statement of work.

Production data should stay out of testing where possible. If real records are needed, agree on masking and on deletion of copies at the end. Put it in the contract.

Confirm where reports are stored. A findings document is a map to your weaknesses, so it should sit in an encrypted location with a short list of readers.

A list of eighty findings is no use without order. Ask how they rate severity, whether they use CVSS or their own scale, and how they weigh your context. A flaw in a public login page outranks the same flaw on a screen only two staff can reach. Context matters.

Ask what each finding includes. You want the exact request or screen, a way to reproduce it, and a suggested fix in your framework, whether Laravel, Django or Node.

Then ask who fixes. Some vendors only report. Others fix and retest. Separate the two so the person marking the work is not the person who did it.

Find out whether retesting is included and for how long. A fix that is not checked is a guess. Ask for a closing note listing each finding as fixed, accepted or open.

Ask how they handle something severe found mid project. You want a phone call that day, not a line in a final document.

Before you sign, give the vendor your list of questions and read the written answers aloud to your team. Choose the one whose answers you could repeat to a customer.