Your organization’s cybersecurity posture is only as strong as the weakest link in your vendor ecosystem. For state and local governments, higher education institutions, financial organizations, and compliance-driven businesses, that statement carries significant weight. Implementing effective third-party risk management is essential because most organizations today rely heavily on third-party vendors and contractors to deliver core business functions. With that dependency comes risk that many security programs aren’t fully equipped to manage.
After conducting hundreds of third-party risk assessments annually, our team at nuHarbor has developed a clear picture of the risks that show up time and again across industries, organization sizes, and vendor types. These aren’t theoretical risks. They’re active vulnerabilities that can and do result in data breaches, compliance failures, and operational disruptions for the organizations we serve.
Here are the top security risks your third-party risk management program should be actively addressing.
1. Weak Secure Coding Practices
If a vendor builds or maintains custom software or applications on your behalf, the security of that code directly impacts your organization. This potential exposure is one of the most consistently identified risks in our assessment work, and it often catches clients off guard.
The challenge is many vendors are excellent at what their core product or service does, but their software development lifecycle (SDLC) may not include meaningful security controls. We frequently see vendors without formal secure coding standards, no code review process, no use of static or dynamic application security testing (SAST/DAST), and no requirement for developers to complete security training.
When you ask a vendor how they ensure the security of their custom code and they struggle to provide a coherent answer, that’s a significant red flag.
What to look for: Ask vendors whether they follow a recognized secure development framework (such as OWASP SAMM or NIST SP 800-218), whether they conduct code reviews or penetration testing, and how security requirements are integrated into their development process.
2. Inadequate Vulnerability Management and Patch Cadence
A vendor that isn’t patching their systems on a regular, defined cadence is a vendor that is accumulating risk on your behalf. Unpatched vulnerabilities remain one of the most common entry points for threat actors, yet this is still one of the top deficiencies we identify in vendor assessments.
The concern isn’t just about routine patching. It’s about whether the vendor has a formal vulnerability management program in place: one that includes regular scanning, prioritization of critical vulnerabilities, and defined timelines for remediation. Even more telling is how a vendor responds to zero-day vulnerabilities. When a critical CVE is published, how quickly does your vendor respond? Do they have a process for emergency patching, or do they wait for their next scheduled maintenance window?
This risk is particularly acute for vendors providing cloud-hosted applications or managed services, where vulnerabilities in the vendor’s infrastructure can create direct exposure for your data and systems.
What to look for: Request evidence of a formal vulnerability management policy, recent scan results or remediation timelines, and ask specifically how the vendor manages zero-day disclosures. Vendors with a mature program will have clear, documented answers.
3. Misunderstood Cloud Responsibility Models
This risk becomes increasingly common as more vendors migrate their services to cloud environments. The shared responsibility model in cloud computing is widely documented, yet it remains widely misunderstood by vendors and their clients alike.
The fundamental issue is this: many vendors assume that because they’re hosting on AWS, Azure, or Google Cloud, the cloud provider is responsible for far more of the security than it actually is. Cloud providers are generally responsible for the security of the cloud’s physical infrastructure, hypervisors, and networking. The vendor is responsible for security in their cloud including their application code, access controls, data encryption, configuration management, and identity management, etc.
When a vendor confuses these responsibilities, critical security gaps emerge. We have seen vendors with misconfigured storage buckets, insufficient access controls, unencrypted data at rest, and logging gaps all justified by an assumption that “the cloud provider handles that.” It doesn’t.
What to look for: Ask questions to understand your vendor’s cloud security architecture and specifically how they have implemented security controls within their cloud environment. Probe for who owns their cloud security configuration, whether they conduct regular cloud security posture assessments, and how they validate their CSP’s compliance with their own policies.
4. The Contractor Blind Spot
Organizations often apply rigorous third-party risk processes to software vendors and SaaS providers but apply far less scrutiny to individual contractors and consulting staff. This failure to probe further creates a risk blind spot.
Whether a party is a vendor or a contractor matters less than the question of what access they have to your data, systems, and business processes. A project manager engaged through a contracted staffing firm may have access to sensitive internal systems, financial data, or regulated information that’s equivalent to the access of a software vendor or greater. That individual and the firm employing them should be subject to the same risk evaluation criteria.
This evaluation is especially relevant for organizations with compliance requirements around data access, such as HIPAA, GLBA, or state-level data privacy regulations. If a contractor processes, stores, or has access to sensitive data, they need to be assessed accordingly.
What to look for: Build your vendor classification framework around data access and system access, not just vendor type. Any third party or individual contractor, staffing agency, or professional services firm that touches sensitive data or critical systems should go through your third-party risk process.
5. One-and-Done Assessments
One of the most operationally impactful risk patterns we observe isn’t a vendor deficiency at all, it’s a security program gap on the client side. Organizations conduct an initial vendor risk assessment, identify findings, document them, and then never follow up or ask for only a new SOC 2 report on an annual basis.
Cybersecurity risk isn’t static. A vendor’s environment, staff, business practices, and security posture change over time. An assessment completed 18 months ago may no longer reflect current reality. Equally important is the question of remediation: when an assessment surfaces security gaps that pose risk to your organization, what happens next? Are vendors held accountable for addressing those findings? Do you have a process to verify they have done so?
Best practice calls for establishing a risk register that tracks vendor findings over time, following up on remediation with documented evidence, and requesting vendor roadmaps for addressing significant gaps. If a vendor has no plan to address identified risks or gaps, that’s important for informing your ongoing relationship with them.
An underutilized practice is conducting a lightweight risk assessment as part of the procurement process itself. How a vendor responds to security questions before they formally have your business tells you a great deal about how they’ll respond afterward. If a prospective vendor can’t provide basic information about their cybersecurity program during the sales cycle, they’re unlikely to be a strong partner post-contract.
Bringing It Together
Third-party risk management isn’t a one-time compliance exercise. It’s an ongoing program that requires consistent processes, clear accountability, and a genuine understanding of how each vendor and contractor impacts your risk profile and business.
The risks outlined here such as insecure development practices, inadequate patching, cloud responsibility gaps, contractor blind spots, and point-in-time assessment programs aren’t hypothetical. They are patterns our team identifies repeatedly, across every industry sector we serve.
Reviewing your current vendor risk program against these areas is a practical first step. Where are the gaps? Which vendors or contractors in your portfolio have never been formally assessed? Which ones had findings that were never remediated?
If you’re looking to strengthen your third-party risk management program or conduct assessments tailored to your specific business environment and vendor dependencies, our team is here to help. nuHarbor’s approach is built around the specific ways your organization uses and depends on its vendors, because effective third-party risk management is never one-size-fits-all.
Every organization’s vendor ecosystem is different. If you’re looking to strengthen your third-party risk management program, connect with nuHarbor to discuss an approach tailored to your unique risks, vendors, and compliance requirements.
About the author
Brianna Blanchard is the Director of Information Assurance at nuHarbor where she leads a team of professionals. She has over 15 years of experience working in cybersecurity and information technology. Before joining nuHarbor, Brianna worked for government organizations helping them build their security compliance and governance programs from the ground up. Brianna currently is involved in co-leading the Women in Cybersecurity Council at Champlain College, with the goal of making cybersecurity more inclusive and Champlain College the best place for women in cyber.
