Organizations that operate managed services portfolios depend on vendors at every level. Cloud providers, penetration testing firms, hardware manufacturers, and specialized technology partners all touch production systems and sensitive data. Each vendor relationship is a risk that must be assessed, monitored, and controlled.
Most organizations handle vendor risk with a questionnaire sent once during onboarding and never revisited. This approach fails for three reasons. Vendors change their security posture over time. New regulations introduce requirements that existing contracts do not cover. The threat landscape shifts faster than annual review cycles can track.
The Locked-Down Vendor Problem
At Solutions by stc, we managed a diverse portfolio that included cloud hosting, managed connectivity, IoT and smart city solutions, CCTV, and enterprise IT services. Some of these services ran on systems with locked-down custom OS images provided by the vendor. We were not allowed to modify these systems. Applying security patches, remediating findings, or hardening configurations meant raising a ticket to the vendor and waiting.
For mainstream vendors, this process was manageable. For niche services like satellite connectivity, it was a serious problem. The number of vendors worldwide that provide satellite connectivity infrastructure is extremely small. You cannot shop around. You cannot threaten to switch providers. These vendors knew their position and operated accordingly.
The result was consistent SLA breaches on remediation timelines. We would identify a critical security finding during an audit or vulnerability scan. We would raise a ticket. The vendor would acknowledge it. Weeks would pass. The finding would remain open. Our audit evidence showed an unresolved critical finding, and the remediation was entirely outside our control.
Solving It Through Contract Renegotiation
Accepting the status quo was not an option. Open critical findings put certifications at risk. We escalated the issue to upper management and built a case for contract modification.
The argument was straightforward. Our existing contracts did not impose meaningful consequences for remediation delays. The vendors had no contractual obligation to resolve critical findings within a specific timeframe. Without that obligation, there was no leverage.
We initiated a series of meetings with these vendors to renegotiate the agreements. The goal was to impose strict remediation deadlines for critical findings, with defined escalation paths and consequences for non-compliance. This was not a quick process. Niche vendors with few competitors are not eager to accept stricter terms. It required multiple rounds of negotiation and executive involvement on both sides.
We achieved the contract modifications. The revised agreements included specific SLAs for remediation of critical and high findings, escalation procedures when deadlines were missed, and reporting requirements that gave us visibility into the vendor's remediation pipeline.
Structuring the Assessment Process
Beyond the niche vendor challenge, our broader vendor risk management program used a tiered model based on data access and operational impact.
Tier 1 vendors had direct access to production systems or sensitive data. Penetration testing firms, cloud infrastructure providers, and managed SOC partners required full security assessments before onboarding, including evidence of their own certifications, detailed architecture reviews, and contractual security obligations. Reassessment happened every 6 months.
Tier 2 vendors had indirect access or processed non-sensitive operational data. Software development partners, IT staffing agencies, and training providers required a standardized questionnaire with evidence requests. Reassessment happened annually.
Tier 3 vendors had no access to systems or sensitive data. Basic due diligence only.
The tier classification happened before procurement began. We integrated it into the vendor request form. The requesting team answered five questions about data access and system connectivity. The answers automatically determined the tier and triggered the appropriate assessment workflow.
Penetration Testing Vendors
Penetration testing vendors deserve special attention because you are deliberately giving an external party permission to attack your systems. Before engagement, verify the firm's credentials and methodology. CREST certification, OSCP-certified testers, and a documented methodology aligned with OWASP or PTES are the baseline. Request CVs of the specific testers who will perform the work, not generic company credentials.
During engagement, define the scope precisely. Which systems are in scope? What testing methods are approved? What is the escalation process if a critical vulnerability is discovered mid-test? All of this must be documented before the first scan.
After engagement, track every finding to closure. Each finding needs an owner, a remediation plan, a target date, and a verification step. We built a findings tracker that automatically assigned owners based on the affected system and escalated overdue items weekly.
Continuous Monitoring
Vendor risk does not end at onboarding. Track vendor security ratings through services that monitor external attack surfaces. Require vendors to report security incidents that affect their environment, regardless of whether your data was directly impacted. Conduct periodic access reviews to ensure vendor accounts and permissions match current business needs.
The goal is not to eliminate all vendor risk. That is impossible. The goal is to understand, quantify, and manage it so that every vendor relationship operates within acceptable risk boundaries. When it does not, you need the contractual leverage to force change.