Third-Party Surveillance Isn't a Dashboard You Install
I spent six months tracking a supply-chain compromise that started with a minor logging library nobody in the org cared about until the SIEM was already flooded with anomalous auth events. The third-party risk team had a perfectly filled-out questionnaire for that vendor. The questionnaire listed "no external telemetry" as a checkbox. The library was pinging a domain registered three weeks prior. The security awareness training for procurement never mentioned it. This is what I mean when I talk about tercera vigilancia — the quiet, systemic problem of assuming you can see what third parties are doing because they told you they wouldn't hide it. The core issue is simple enough to state and impossibly difficult to solve. Every organization now runs on a stack of third-party services — SaaS tools, CDN providers, payment processors, open-source dependencies, managed SOC offerings. Each of these represents a trust boundary you don't control but whose behavior affects your security posture. Traditional third-party risk management treats this as a periodic audit problem. Fill out the SIG questionnaire, review the SOC 2 report, renew annually. That model assumes third parties behave predictably and disclose their data practices proactively. They don't. In practice, third-party surveillance means building continuous visibility into what your vendors are actually doing — not what they claim they're doing — and correlating that behavior against your own security baselines. It shows up in four overlapping areas.
Software supply chain monitoring covers your dependency tree. This isn't just about known CVEs. It's about tracking when a package you rely on starts pulling in new transitive dependencies, when its build pipeline changes ownership, when its cryptographic signing keys rotate without notice. Tools like SCA scanners help, but they only catch what you've configured them to look for. I once found a compromised distribution pattern where a Go module was being rewritten at build time through an obscure Makefile override that no scanner would flag because the source itself was clean. The only reason I spotted it was because the binary checksum didn't match the reproducible build output from the upstream CI logs. Cloud and SaaS behavior monitoring is where most organizations bleed visibility. You sign a contract with a SaaS provider and assume the data flows exactly as described in the privacy policy. The reality is more complex. A collaboration platform might silently start routing metadata through a subsidiary in a different jurisdiction. A monitoring tool might begin aggregating environment variables from your production containers because the SDK has broader permissions than the sales deck suggested. Continuous third-party surveillance in this space means monitoring your actual data egress patterns and alerting when traffic deviates from established baselines. Network-level monitoring alone misses application-layer exfiltration. You need API call logging, DNS query analysis, and certificate transparency monitoring feeding into a system that flags anomalies against your known vendor communication profiles. Identity and access delegation tracking is the quietest and most dangerous area. OAuth tokens, service accounts, SSO configurations, delegated admin privileges — these are the plumbing that lets third parties act on your behalf. When you revoke access, the token might still be valid if the identity provider doesn't propagate the change fast enough. I dealt with a situation where a former contractor's personal account had been granted broad read access to our production database through a third-party BI tool's OAuth flow. The contractor left two months before the BI vendor's quarterly access review caught it. By then, they'd already exported over 40 GB of customer records. The workaround wasn't revoking at the application level — it was pulling the underlying database IAM role and replacing it with scoped-down credentials that even a compromised OAuth token couldn't fully exploit.
Open-source and dependency governance deserves its own section because the scale problem is real. An average large codebase pulls in thousands of transitive dependencies. Most organizations don't know the full depth of that tree. The SBOM movement is addressing this, but SBOMs are point-in-time snapshots. What matters is continuous monitoring of your dependency graph against threat intelligence feeds, package registry behavior changes, and maintainer activity signals. A package that hasn't been updated in two years might be fine. A package maintained by a single person who recently changed their commit email domain might not be.
Get the Full Details
Building a Third-Party Surveillance Capability
The approach that actually works is incremental and boring. It's not a tool purchase. It's an operational discipline built on existing infrastructure. Start with asset inventory. You can't monitor what you can't name. Map every third-party service that touches your data. This includes things people forget — embedded widgets, analytics pixels, A/B testing scripts, error-tracking SDKs. These are all third parties running code in your environment. An inventory should track what data each one receives, what permissions it holds, and how it communicates with external systems. If you don't have this mapped, you're flying blind by design. Implement continuous monitoring where it matters most. You don't need perfect visibility everywhere. Pick the highest-risk areas — the vendors with access to production data, the ones handling authentication, the ones with internet-facing attack surfaces. Deploy network monitoring for those relationships. Capture TLS certificates during communications. Log API destinations. Feed that into a detection system that compares against your baseline. The cost here is mostly in tuning. Initial false positive rates will be high. Budget for that.
Automate the questionnaire. Don't let third-party risk management be a manual document review process. Integrate vendor questionnaires with automated evidence collection. When a vendor claims they don't share data with affiliates, verify that claim by checking their actual network traffic and certificate validation chain, not just their word. This is where most programs fail — they accept self-reported compliance at face value and then act surprised when something goes wrong. Monitor the monitoring. Third-party surveillance tools themselves become third parties. Your SIEM, your SCA scanner, your cloud security posture management tool — these are all vendors with access to your security data. Audit them using the same standards you apply to everyone else. This creates a recursive problem that most teams ignore until an incident forces them to confront it.
Where This Approach Breaks Down
Third-party surveillance has real limitations that get glossed over in vendor marketing materials. The first is the visibility gap created by encryption. You can monitor network traffic, but TLS 1.3 means you can't inspect the payload without terminating encryption at your own infrastructure, which introduces its own risk. Most DNS-level monitoring misses encrypted DNS entirely unless you're also running DoH/DoT interception. The tradeoff between visibility and encryption is real and it means some third-party behavior will remain invisible to you. The second limitation is the economic one. Small and mid-market third parties often can't afford the kind of security instrumentation that makes continuous monitoring feasible. You'll get incomplete data from them regardless of how thorough your requirements are. In those cases, the best approach is contractual — requiring them to adopt specific monitoring standards as a condition of engagement, and accepting that compliance monitoring will be periodic rather than continuous for those vendors. The third is alert fatigue. Continuous surveillance generates noise. Without sophisticated correlation and prioritization, security teams drown in alerts and start ignoring them. I've seen this happen in three different organizations. The teams that succeed treat surveillance as a prioritization problem first, a technical problem second. They focus monitoring on the top 20 percent of third parties by risk exposure and accept lower coverage for the rest. A blanket approach covering everything equally produces more false positives than actionable findings.
There's also the legal dimension that gets underexplored. Monitoring third-party behavior raises questions about computer fraud statutes, data processing agreements, and whether your surveillance activities violate the terms of service of the platforms you're observing. I've seen security teams accidentally trigger abuse detection on a SaaS provider's end by running too aggressive a monitoring cadence. The workaround is to coordinate with legal and vendor management before deploying any monitoring that could be construed as intrusive. Document the business justification clearly. Most vendors will cooperate if they understand you're protecting shared data, not spying on their operations.
A Practical Starting Point
If you're building this from scratch, here's what I'd recommend for the first 90 days. Map your top 50 third parties by data access level. Deploy basic DNS and TLS certificate monitoring for those relationships. Integrate your SCA scanner with a vulnerability feed that alerts on new CVSS 9+ findings within 24 hours of publication. Run a quarterly access review for all privileged third-party accounts. Document everything. The goal isn't perfection on day one. It's establishing a baseline of what normal looks like so that when abnormal happens, you notice it instead of learning about it from a breach notification email. The organizations that treat third-party surveillance as a strategic capability rather than a compliance checkbox tend to find incidents earlier and contain them faster. The ones that treat it as a checkbox exercise learn about problems through news articles. The difference between those two outcomes usually comes down to whether leadership is willing to invest in continuous monitoring infrastructure or prefers the illusion of control that annual audits provide. The infrastructure cost is real but finite. The cost of missing a supply chain compromise isn't. I keep coming back to that six-month incident I mentioned at the beginning. We caught it because someone had bothered to check the reproducible build output against the actual deployed binary. The person who did that check wasn't following a requirement. They were following a habit — the habit of not trusting the answer you're given without verifying it against the evidence you can collect yourself. That's the operational culture third-party surveillance requires. It's not a tool. It's a skepticism you institutionalize.
