You are about to hand an outside team access to your production database, your cloud account, and your customers' personal data. The contract is ready. The only thing standing between you and a signed deal is a nagging question: can you actually trust this vendor with your security?
A software vendor security review is how you answer that question before the ink dries, not after an incident. Most founders skip it because it feels bureaucratic or because the vendor "seems professional." That is exactly how supply-chain compromises start.
This guide gives you a concrete process you can run in a week, whether you are vetting a solo contractor or a fifty-person agency.
Key takeaways
- A vendor security review is an evidence exercise, not a vibe check. Ask for artifacts, not assurances.
- Prioritize the areas that actually hurt you: secrets management, access control, dependency hygiene, and incident response.
- Use a vendor security questionnaire for custom software as a starting script, then verify the answers with documents.
- Red flags are usually process gaps, not missing certifications. A vendor that cannot explain its own practices is the real risk.
- Security posture is a contract term. Bake remediation timelines and breach notification into the agreement.
Why a custom software vendor is a different kind of risk
Off-the-shelf SaaS vendors get assessed constantly. They have SOC 2 reports, security pages, and a standard questionnaire they can answer in their sleep. Custom development partners are different: they write code that lives inside your infrastructure, touch your secrets, and often retain access long after launch.
That means the blast radius is yours. A misconfigured deployment or a leaked API key in a vendor's repo becomes your breach. The review has to focus on how they build and operate, not just what certificates hang on their wall.
What you are really assessing
You are evaluating three things: their process discipline (do they have repeatable secure practices), their transparency (will they tell you when something goes wrong), and their contractual accountability (are they on the hook if they don't). Certifications inform the first, but they rarely cover the other two.
Step 1: Build your third party software security assessment checklist
Start with a checklist you apply to every vendor. Consistency is what makes the results comparable and defensible. A workable third party software security assessment checklist covers six domains:
- Access and identity. How do their engineers authenticate to your systems? Is MFA enforced? Are credentials personal or shared?
- Secrets management. Where do API keys, tokens, and database passwords live? Never in source control, ideally in a managed vault.
- Secure development lifecycle. Do they do code review, static analysis, and dependency scanning on every change?
- Data handling. What data do they copy into their own environments, and how is it protected and deleted?
- Incident response. Who do you call at 2 a.m., and how fast will they notify you?
- Offboarding. How is access revoked when the engagement ends or an engineer leaves?
Map each item to evidence you will request. "We take security seriously" is not evidence. A branch protection policy screenshot and a sample scan report is.
Step 2: How to vet a software development agency security with real evidence
This is where most reviews fall apart. Teams collect questionnaire answers, feel reassured, and move on. The discipline is to verify the highest-risk claims with artifacts.
Request these documents
- Their most recent penetration test summary or security assessment (redacted is fine, but the scope and date must be real).
- A sample threat model or architecture review from a comparable project.
- Their secure coding standards or engineering handbook.
- Their incident response plan, including notification SLAs.
- Evidence of dependency and container scanning in their CI pipeline.
Ask to see the pipeline, not just the policy
Policies describe intent; pipelines show reality. Ask whether they can walk you through a real CI/CD configuration: what gates a merge, what runs on every commit, and what happens when a critical vulnerability is detected in a dependency. A vendor that can show you this live is far more credible than one that sends a PDF.
Test their access model
Ask how they would access your environment during the engagement. You want to hear: least privilege, short-lived credentials, no shared logins, and a clear path to revoke everything at the end. If the answer involves a shared admin account or a long-lived key, that is a real finding.
Step 3: The vendor security questionnaire for custom software
A focused questionnaire beats a hundred generic questions. Here are the ones that consistently surface the truth:
- How do engineers authenticate to client systems, and is MFA mandatory?
- Where are secrets stored, and who can read them?
- Do you run automated dependency and static analysis scans? What blocks a merge?
- How do you handle a critical CVE in a library you depend on?
- What data leaves the client environment, and how is it protected?
- How quickly do you notify clients of a suspected breach?
- How is access revoked when an engineer leaves your team?
- Do you carry cyber liability insurance, and what does it cover?
Send the questionnaire before the commercial conversation gets serious. A vendor that treats security questions as an inconvenience is telling you something important about how they will treat your production incident.
Step 4: Security review questions to ask a dev vendor in the live call
Documents tell you what they claim. A conversation tells you how they think. Bring your security review questions to ask a dev vendor into a live session and listen for specifics.
- "Walk me through the last security incident you had. What happened, and what changed afterward?"
- "Show me how a secret gets from a developer's machine into production."
- "What is the most common security mistake you see in client codebases?"
- "If we asked you to ship tomorrow and a scan flagged a critical issue, what happens?"
- "Who owns security on your team, and how much of their time does it get?"
Vague answers to these are more informative than polished answers to the questionnaire. You want a partner who can name tradeoffs and admit gaps.
Red flags that should stop the deal
Some findings are fixable; others are structural. Walk away or demand remediation before signing if you see:
- Secrets or credentials committed to repositories, with no plan to rotate them.
- No MFA, or shared accounts used for client access.
- No dependency scanning, or no process for responding to a critical CVE.
- Refusal to sign a data processing agreement or breach notification clause.
- No incident response plan, or an owner who cannot describe it.
- Access that persists indefinitely after a project ends.
One isolated gap is a conversation. A pattern of gaps across access, secrets, and response is a signal that security is not part of how they operate.
Turning the review into contractual protection
The review is only useful if its findings become obligations. Before you sign, put the important parts in writing:
- A breach notification window with a specific number of hours.
- Least-privilege access requirements and a mandatory offboarding checklist.
- Remediation timelines for findings above an agreed severity threshold.
- Right to audit or request updated evidence annually.
- Clear ownership of code, secrets, and infrastructure at handover.
This is also the moment to confirm that the vendor can actually deliver on engineering quality, not just paperwork. If you want a partner who builds security into the process rather than bolting it on at the end, it helps to see how a team approaches the work itself, from architecture through deployment. You can review our software development services to see how we structure engagements, and browse past projects to judge the outcomes for yourself.
If you would rather pressure-test your current vendor list with a second opinion, talk to our team before you sign anything.
Frequently Asked Questions
How long should a software vendor security review take?
For a typical custom development engagement, plan on three to five business days if you send the questionnaire and document requests upfront. The live call and evidence verification usually take another day. Rushing it is a false economy when the vendor will hold production access.
Does a vendor need SOC 2 before I can work with them?
No. SOC 2 is useful evidence for larger vendors, but many excellent custom development partners are too small to justify the cost. What matters more is demonstrable process: enforced MFA, secrets management, dependency scanning, and a real incident response plan. Ask for artifacts instead of accepting a certificate as a substitute for practice.
What is the single most important thing to verify?
Access control. If you can confirm that the vendor uses least privilege, short-lived credentials, mandatory MFA, and a clear offboarding process, you have eliminated the most common path to a serious breach. Everything else matters, but access is where the damage usually starts.
Should I let a vendor use my cloud account or theirs?
Prefer your own account with scoped, revocable access. It keeps ownership clear, simplifies offboarding, and means you can audit activity directly. If the vendor must use their own environment for some work, agree in writing on what data can be copied there and how it will be deleted.
What if the vendor fails part of the review?
Treat it as a negotiation, not necessarily a disqualification. Minor gaps can be closed with contractual remediation timelines and follow-up evidence. Structural failures, such as no MFA or secrets in source control with no rotation plan, are usually a reason to walk away.
Cover: Photo by Towfiqu barbhuiya on Pexels