When you hire a software development firm, you’re not just buying code; you’re trusting someone to build a digital extension of your business. It’ll hold your data, power your operations, and (if done wrong) provide a nice open window for cybercriminals to crawl through.

We’ve compiled a list of questions to help you ensure your custom software is not a cyber-liability. No technical degree required; you just need to know what to listen for.

Q1: Do you follow a Secure Software Development Life Cycle (SDLC)?

This is software lingo for “Do you think about security from the beginning, or only after something breaks?”

What you’re listening for:
You want to hear that they have a structured process that integrates security into every phase of the SLDC. Things like “security by design” or “DevSecOps”, meaning security is built in, from planning to deployment and not bolted on at the end.

🚩 Red flag: “We do security testing near the end, before launch.” This is like making sure a boat floats after you’ve left the dock.

Q2: Can you tell me your approach to secure coding?

What you’re listening for:

The phrase you want to hear is “OWASP Top 10.” If they also mention frameworks like NIST’s Secure Software Development Framework (SSDF), OWASP’s Software Assurance Maturity Model (SAMM), or SANS-CWE Top 25 you are in good hands

🚩 Red flag: If they can’t name any of these, they may be reinventing the wheel—or worse, ignoring it.

Why it matters:

OWASP is the industry standard list of the most common (and dangerous) coding mistakes, like injection attacks, broken authentication, and insecure APIs. Cybercriminals know this list, and so should your development team.

Q3: How do you handle open-source components?

What you’re listening for:
You want to hear that they are using tools like Dependabot, Snyk, or OWASP Dependency-Check to track vulnerabilities in third-party components and libraries.

🚩 Red flag: “We’ll check for updates periodically.”

Most modern software relies heavily on open-source code, like Lego, it’s assembled instead of created from scratch. The problem? Some of those blocks may have cracks. If the vendor is not managing this risk during development, they are leaving you vulnerable. If you need clarification on their process don’t be afraid to push back, this is your software and your budget after all.

Why it matters:

Unpatched open-source dependencies are one of the most common entry points for attackers. The Synopsys Open Source Security and Risk Analysis Report, 2024 showed that open source vulnerabilities grew from 48% in 2022 to 74% in 2024, that’s a lot of opportunity for folks with malicious intent.

Q4: How do you handle data at rest and in transit?

Your answers here are all about encryption, which is basically scrambling data so it’s unreadable to intruders.

What you’re listening for:

• “We use TLS 1.2 or 1.3 for data in transit.”
• “We use AES-256 for data at rest.”

🚩 Red flag: If they respond with vague phrases like “military-grade encryption,” or “we’ll use strong encryption”, those are marketing terms, not technical terms. Encryption should be measurable, not mysterious.

Why it matters:
These are foundational controls. If your software deals with sensitive or regulated data (finance, healthcare, personal information, payment information), you need confidence knowing they understand secure data handling.

F or more information on these protocols we recommend reviewing The Digital Identity Guidelines provided by the NIST.

Q5: How will you handle authentication and user access?

Cyber criminal’s number one intent is to gain unauthorised access to a system, poorly handled authentication is like leaving the door open.

Authentication = proving who someone is.
Authorization = deciding what they’re allowed to do (user access).

What you’re listening for:

You want to hear industry standards like OAuth 2.0, OpenID Connect, or SAML for secure login systems. They may also mention multi-factor authentication (MFA) and strong password hashing methods (like bcrypt or Argon2). Role-based access control (RBAC) and Attribute-Based Access Control (ABAC) are terms you want to hear related to authorization.

🚩 Red flag: “We just check if someone is an Admin.” or “We built our own login system.” If it is a proprietary login system, then you need to ask how they manage passwords. You want to hear words like “salted” and “hashed.” Checking only some users or reinventing authentication is like juggling swords, it seldom ends well.

Q6: How do you test for security vulnerabilities?

Security isn’t just about prevention it’s about detection. Testing isn’t optional.

What you’re listening for:

• Static Application Security Testing (SAST): automated code scanning.
• Dynamic Application Security Testing (DAST): tests the running app.
• Code Reviews: every major feature should have a second pair of eyes.
• Penetration testing: ethical hackers try to break in before criminals do.

🚩 Red flag: Be wary of answers like “Our QA team looks it over,” or “We test before deploying to UAT” or “Penetration testing is only necessary for big companies.” Security testing shouldn’t be an afterthought. Regular, layered testing is a hallmark of mature software development practices.

Why it matters: In software (and security), timing is everything. Fixing a bug in design costs pennies; fixing it after launch costs rent money.

Escalating cybersecurity threats and increasing attack sophistication have been on CIO and CTO radars for years, this threat is not decreasing.

Q7: Tell me about your development, testing, and production environments?

What you’re listening for:

• Separate environments for development, staging, and production. Professional firms maintain separate, access-controlled environments for each.
• Infrastructure-as-Code (IaC) with secure configurations.

Mature vendors may also mention things like: Cloud security frameworks (AWS Well-Architected, Azure Security Benchmark), environment segregation (dev/test/prod), secrets management (Vault, AWS Secrets Manager), and hardened infrastructure practices. These are all green flags.

🚩 Red flag: “We deploy right to Prod” or “It’s cheaper to have an all-in-one dev environment.” Development environments are not like a 3 in 1 shampoo, you want and should expect separate environments for each.

Why it matters:
Even well-written software can be compromised if deployed carelessly. Misconfiguration is one of the top 3 factors in data breaches according to the Verizon’s 2024 Data Breach Investigations Report. Secure environments reduce risk from configuration errors

Q8: How do you manage security incidents?

Even the best software can face attacks. What matters is how quickly a vendor detects it and how competently they respond when it does.

What you’re listening for:

• Centralized logging (Splunk, Datadog or other log monitoring tools).
• Alerts for suspicious login attempts or privilege escalations.
• A documented Incident Response Plan (IRP) defining roles, timelines, and escalation paths.

🚩 Red flag: If they say, “we’ll check the logs if something happens,” be skeptical, that’s like saying you’ll install a smoke alarm after the fire.

If you are looking for some “light” reading the NIST SP 800-61r3 – Computer Security Incident Handling Guide can be helpful in equipping you with the information needed to determine the necessary response expectations for your company.

Q9: How do ensure compliance with privacy & data protection laws?

If your software handles personal or customer data, compliance is not optional. Ask how they align with GDPR, PIPEDA, CCPA, or other relevant local privacy laws.

What you’re listening for:

You should hear about data minimization, encryption, and deletion policies. You should here reference to the standards they are complying with and why.

🚩 Red flag: Vague reassurances like “we’re compliant with everything” are not answers they are vulnerabilities.

Why it matters: Regulators don’t fine vendors; they fine you, and these fines are significant.

Q10: What happens after the software is deployed to production?

What you’re listening for:

• Details on how they handle ongoing maintenance, security patching, and after deployment support.You should have a minimum expectation of what you require once the software is live.
• A Service Level Agreement (SLA) should be part of your minimum requirements. It defines how fast they’ll fix critical vulnerabilities and who is responsible for what, when.

🚩 Red flag: If they disappear after delivery and you’re left maintaining something you didn’t build; budget for problems. You know how your furnace only ever breaks on a holiday? This is that in software.

Bonus Tip: Documentation Is Security’s Silent Partner

Before signing a contract, ask how they document their code and security procedures. Clear, well-maintained documentation ensures your internal IT team (or a future vendor) can maintain and secure the system without guesswork. Poor documentation is one of the main reasons legacy systems become security nightmares.

The Bottom Line:

Cybersecurity isn’t just a technical checkbox, it’s a business survival issue. By asking the right questions up front, you’re protecting your software investment, safeguarding your company’s reputation and ensuring your customers’ trust.

Good vendors will welcome these questions and expect you to ask for references. Great ones will already have the answers ready. The best ones will help you understand what those answers mean without jargon, finger wagging, or “trust us” statements.

When it comes to custom software, security isn’t just a feature. It’s the foundation.