Know Your Third Party
To know your third party, you must check vendor identities and track their sessions. You set up strict accounts that limit what outside contractors can touch. Many teams start by giving vendors shared passwords or broad admin roles. They do this to help contractors fix urgent issues fast. Still, broad permissions let external users read or change sensitive tables by mistake. A shared key also makes it impossible to see who ran a bad command. How to set up a know your third party workflow A st
Third-Party Risk Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To know your third party, you must check vendor identities and track their sessions. You set up strict accounts that limit what outside contractors can touch. Many teams start by giving vendors shared passwords or broad admin roles. They do this to help contractors fix urgent issues fast. Still, broad permissions let external users read or change sensitive tables by mistake. A shared key also makes it impossible to see who ran a bad command.
How to set up a know your third party workflow
A strong vendor workflow starts before anyone logs in to your systems. First, your team registers the vendor firm and lists each contractor by name. You tie each person to a single user profile in your identity provider. This step ensures every contractor logs in with their own work email.
Next, you create a dedicated role for that specific vendor task. If a contractor only needs to read billing tables, you grant read permissions alone. You also set an expiration date on the vendor account from day one. When the contract ends, the system turns off their login rights right away.
Finally, you link their identity to your internal network rules and database roles. The contractor logs in through your identity tool and assumes the restricted role. Your system records the login time and ties it to that person.
What native vendor checks solve and what they miss
Native identity checks and role settings solve the first part of vendor risk. They prove who the contractor is before a session starts. They also block external users from opening servers or databases they do not need. When an auditor asks who has a login, you can show a clean list.
Yet this setup leaves a big gap once the session is active. Role settings decide who can log in, not what individual queries do in flight. A contractor with valid read permissions can still run a massive export query. That single query might return thousands of customer emails, phone numbers, or card numbers.
Third-Party Risk Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Standard role checks also cannot stop a contractor from running a bad update command. If their role allows writes to fix a bug, they can drop rows too. Static permissions cannot pause a risky command and ask a manager for approval. They also fail to rewrite sensitive fields like national IDs in query results.
How to close the gap during active vendor sessions
To control active sessions, teams must check every command as it runs. Instead of trusting a broad role for hours, you inspect each request in flight. You can set rules that block destructive commands while allowing safe reads to pass.
You can also apply data masking to the results of a vendor query. Masking rewrites matched fields like card numbers or emails before the contractor sees them. This lets external partners fix app issues without pulling raw customer records. Combining identity checks with live command controls gives you full visibility over vendor work.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What does know your third party mean for engineering teams?
It means checking who your vendors are and tracking what they do on your systems. Teams verify each contractor and limit the servers and databases they can use.
Why are shared vendor accounts a security risk?
Shared accounts hide which individual person ran a specific query or command. If a key leaks or someone makes a mistake, you cannot trace the action.
How can teams protect sensitive data during vendor support sessions?
Teams can limit vendors to read roles and apply masking to query results. Masking rewrites emails, phone numbers, and card numbers in the output.