The TPSA Problem
Third-party security assessments (TPSA) are required by regulators, demanded by enterprise customers, and genuinely necessary for understanding vendor risk. They're also often theater—checkbox exercises that produce reports nobody reads and findings nobody acts on.
The fundamental issue is that TPSA processes are designed for compliance, not for risk reduction. Vendors fill out questionnaires, provide attestations, maybe submit a SOC 2 report. Security teams review these documents, assign a risk score, and file everything away. Then the vendor gets access to your production environment with the same level of scrutiny as if you'd done nothing.
Real TPSA governance means translating vendor security posture into concrete engineering controls. It's not about trust—it's about verification, isolation, and blast radius reduction. If a vendor claims they encrypt data at rest, your controls should ensure they can only access encrypted data. If they claim they follow least privilege, your architecture should enforce that they can't access anything they don't need.
From Questionnaire to Architecture
Traditional TPSA relies on vendor self-attestation. They tell you their security practices, and you decide whether to trust them. This works poorly because vendors have incentive to overstate their capabilities, security practices drift over time, and even honest vendors may not understand the nuances of your risk model.
Architectural TPSA starts with the assumption that vendor claims are aspirational. Instead of asking "are you secure," you design your integration so that their security posture doesn't matter as much. Vendor compromise should trigger your monitoring, not your incident response plan.
The practical steps: Identify what data and capabilities the vendor needs. Design the integration to provide exactly that and nothing more. Build monitoring and verification into the integration. Treat the vendor as an untrusted component in your threat model.
This doesn't mean you skip the questionnaire—it's still useful for baseline assessment and due diligence. But the questionnaire informs your architecture decisions; it doesn't replace them.
Isolation and Blast Radius
Every third-party integration increases your attack surface. The question is whether it increases your blast radius proportionally. Isolation patterns let you use vendors without giving them the keys to your castle.
Network isolation means vendor integrations happen through dedicated network segments with strict firewall rules. They can't access your internal services directly. They can't probe your infrastructure. They connect to integration endpoints and nothing else.
Data isolation means vendors see only the data they need, in the form they need it. If a vendor needs to process customer orders, they get order data—not customer profiles, payment histories, or internal notes. If they need aggregated analytics, they get anonymized summaries—not raw event streams.
Credential isolation means vendor integrations use dedicated service accounts with scoped permissions. If the vendor is compromised, the attacker gets access to whatever that service account can reach—which should be narrowly defined. Rotate these credentials regularly, ideally automatically.
Runtime isolation using containers or sandboxes provides defense in depth. If you're running vendor code in your environment (plugins, webhooks, custom integrations), it should run in an isolated runtime with limited system access, network policies that prevent lateral movement, and resource limits that prevent denial-of-service.
Monitoring Vendor Behavior
You can't prevent vendor compromise, but you can detect it. Monitoring vendor integrations means establishing baseline behavior and alerting on deviations.
Log all vendor API calls—what endpoints they hit, what data they request, when they make requests. Anomalies like sudden volume increases, unusual access patterns, or requests for data they don't normally need should trigger investigation.
Track data flow across vendor boundaries. What data goes to the vendor, what comes back, and whether the integration is behaving as designed. If a vendor suddenly starts exfiltrating more data than expected, that's a signal.
Monitor authentication and authorization events. Failed authentication attempts from vendor systems, requests for escalated permissions, or attempts to access resources outside their scope are all potential indicators of compromise.
Rate limiting and usage quotas provide both security and cost control. If a vendor integration suddenly makes 10x more API calls, either they're compromised or their integration is broken. Either way, you want to know.
Contractual and Technical Alignment
TPSA governance requires both contracts and controls. Contracts define obligations—what the vendor must do, what they must not do, and what happens if they fail. Controls ensure obligations are met regardless of vendor cooperation.
Security requirements in vendor contracts should be specific and measurable. "Follow industry best practices" is meaningless. "Encrypt data at rest using AES-256, rotate credentials every 90 days, and provide incident notification within 4 hours" is enforceable.
Right to audit clauses let you verify vendor claims. But audits are expensive and infrequent. Technical controls provide continuous verification. If your architecture enforces data encryption, you don't need to audit the vendor's encryption practices—you know data is encrypted because you control the encryption.
Data processing agreements (DPAs) and terms of service define what vendors can do with your data. But legal language alone doesn't prevent misuse. Technical controls that prevent data from being stored, logged, or processed outside defined parameters provide real protection.
Incident response requirements in contracts should match your technical capabilities. If your contract requires 1-hour incident notification, your monitoring should detect vendor compromise within that window. If you can't detect it, you can't hold the vendor accountable.
Operationalizing TPSA
Governance frameworks fail when they're not integrated into development and operations. TPSA shouldn't be a gate that blocks shipping—it should be a process that makes shipping safer.
Vendor security checklists for engineering teams provide practical guidance. Before integrating a new vendor: What data will they access? What credentials do they need? What network access is required? Can we scope their permissions further? What monitoring should we add?
Automated security reviews during vendor onboarding ensure nothing gets missed. Configuration checks verify isolation is correctly implemented. Permission audits ensure least privilege is enforced. Monitoring setup confirms detection capabilities are in place.
Regular vendor access reviews catch drift. Vendor permissions expand over time as integrations evolve. Quarterly reviews should verify that each vendor still needs the access they have, that credentials have been rotated, and that monitoring is still working.
Incident response playbooks for vendor compromise should be documented and tested. If a vendor is breached, what do you do? Disable their access immediately? Rotate credentials? Review logs for signs of abuse? Having the plan ready means you can execute quickly when it matters.
Practical Patterns
Vendor API gateways provide a centralized control and monitoring point. All vendor integrations go through the gateway, which enforces authentication, authorization, rate limiting, logging, and data transformation. This gives you a single place to implement and update vendor security controls.
Just-in-time access for vendors means credentials are issued only when needed and revoked immediately after use. Instead of permanent vendor access, you provision temporary credentials on demand, with scoped permissions and short time-to-live. This reduces standing privileged access and limits the window for potential abuse.
Vendor data sandboxes let you test integrations with synthetic data before exposing real customer data. Build a sandbox environment that mimics production but contains no sensitive information. Vendors integrate against the sandbox first, and you verify their behavior before promoting to production.
Contractual + technical defense in depth means neither one alone is sufficient, but together they provide strong assurance. Contracts define expectations and consequences. Technical controls enforce reality. When both are aligned, you have defensible, auditable, and effective third-party risk management.