Confidentiality / Privacy
Third parties are authorized, contractually bound, and reviewed before receiving or processing confidential information.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
A third party receives or processes confidential information only after the company confirms the business need, reviews the risk, agrees suitable confidentiality and data terms, approves the exact access, and plans ongoing review and offboarding.
First SOC 2 program
List vendors and contractors that can receive customer content, credentials, support data, product designs, personnel information, or other confidential material. Before connection or transfer, document the need, review the provider, sign suitable terms, assign an owner, and limit access to the agreed data and purpose.
As the company scales
Use a governed vendor-intake workflow that blocks purchasing, integration, and account provisioning until risk, privacy, legal, and data-owner approvals are complete. Track subprocessors, data flows, access, contract changes, ongoing review, incidents, and confirmed deletion at termination.
Document the third party, service owner, business purpose, confidential data categories, users, systems, transfer method, locations, and whether less data or another design could meet the need.
You should end up with: A vendor data-use record with owner, scope, flow, and necessity decision.
Review security, privacy, service, incident, deletion, location, and subprocessor information in proportion to the data sensitivity and dependency.
You should end up with: A completed risk review with findings, conditions, and acceptance owner.
Have authorized legal or business reviewers confirm confidentiality, permitted use, safeguards, incident cooperation, subprocessor, return or deletion, and other applicable data terms before transfer.
You should end up with: An executed agreement linked to the approved service and data scope.
Obtain service and data-owner approval, provision only required accounts or integration permissions, enforce suitable transfer protection, and record who can access the data.
You should end up with: Access approval, configured permissions, user list, and connection record.
Review the provider based on risk and material changes, monitor access and incidents where available, and reassess new data categories, locations, or subprocessors.
You should end up with: Periodic review records, change decisions, and resolved findings.
Disable accounts and integrations, recover keys, stop transfers, return or delete confidential information as agreed, and retain confirmation of completion.
You should end up with: A completed offboarding record with revocation and return or deletion evidence.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
Shows that the third party is contractually limited in its use and disclosure of the confidential information and has relevant safeguarding, incident, return, or deletion duties.
Include this context
legal entities and service
Include this context
confidential information scope
Include this context
permitted use and disclosure
Include this context
safeguard and incident terms
Include this context
return or deletion terms
Include this context
execution and effective dates
Weak evidence to avoid
An unsigned order form referencing standard terms without the incorporated confidentiality language, data scope, parties, or effective date.
Confirm what the record proves
Shows the agreed processing scope, parties’ instructions and responsibilities, security and incident commitments, subprocessor treatment, locations where addressed, and return or deletion arrangements for personal information.
Include this context
parties and covered service
Include this context
processing subject matter and data categories
Include this context
instructions and responsibilities
Include this context
security, incident, and subprocessor terms
Include this context
return or deletion terms
Include this context
execution date and linked agreement
Weak evidence to avoid
A downloaded standard agreement that is not executed, does not identify the purchased service or parties, and is not linked to the governing contract.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Shows a risk-based evaluation of the provider’s security, privacy, service, incident, deletion, location, and subprocessor practices before access and after relevant changes.
Include this context
provider, service, and owner
Include this context
data categories and access
Include this context
review procedures and evidence date
Include this context
findings and risk rating
Include this context
conditions or remediation
Include this context
decision, reviewer, and date
Weak evidence to avoid
A vendor questionnaire stored without reviewer conclusions, data scope, findings, risk decision, or follow-up.
Confirm what the record proves
Shows that the service and data owners authorized the exact third-party accounts, integration permissions, data categories, purpose, duration, and transfer method before access began.
Include this context
provider and user or integration identity
Include this context
data and system scope
Include this context
purpose and permission level
Include this context
service and data-owner approvals
Include this context
activation and expiry dates
Include this context
transfer protection or connection
Weak evidence to avoid
A procurement approval that does not identify the integration identity, confidential data, permission scope, owner approval, or access duration.
Type 1
Every active third party with access to confidential information on the examination date, linked to current terms, risk status, approved accounts or integrations, data scope, subprocessors, and any open finding or termination action.
Type 2
Every third party newly approved to receive or process confidential information during the review period, every material change in service, data, location, subprocessor, contract, account, or integration access, every risk-based periodic review due, and every relationship termination or data-return and deletion event.
Reconcile procurement and accounts-payable vendors, SaaS discovery, third-party identities, integration credentials, cloud sharing, and data-map recipients to the approved vendor register; investigate every provider with confidential-data access that lacks current terms, review, owner approval, or completed offboarding.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: A third party receives or processes confidential information only after the company confirms the business need, reviews the risk, agrees suitable confidentiality and data terms, approves the exact access, and plans ongoing review and offboarding.
Compare the documented owner with the intended role (Privacy Owner / CISO / Data Owners), then compare dated records with the stated cadence: Ongoing; periodic review by privacy/data owner.
Reconcile procurement and accounts-payable vendors, SaaS discovery, third-party identities, integration credentials, cloud sharing, and data-map recipients to the approved vendor register; investigate every provider with confidential-data access that lacks current terms, review, owner approval, or completed offboarding.
Every active third party with access to confidential information on the examination date, linked to current terms, risk status, approved accounts or integrations, data scope, subprocessors, and any open finding or termination action.
Every third party newly approved to receive or process confidential information during the review period, every material change in service, data, location, subprocessor, contract, account, or integration access, every risk-based periodic review due, and every relationship termination or data-return and deletion event.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Shows that the third party is contractually limited in its use and disclosure of the confidential information and has relevant safeguarding, incident, return, or deletion duties.
For each selected record, confirm it demonstrates Shows the agreed processing scope, parties’ instructions and responsibilities, security and incident commitments, subprocessor treatment, locations where addressed, and return or deletion arrangements for personal information.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Shows a risk-based evaluation of the provider’s security, privacy, service, incident, deletion, location, and subprocessor practices before access and after relevant changes.
For each selected record, confirm it demonstrates Shows that the service and data owners authorized the exact third-party accounts, integration permissions, data categories, purpose, duration, and transfer method before access began.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.