Confidentiality / Privacy
Personal information and customer confidential information are collected and used only for approved business, security, service delivery, support, legal, or contractual purposes.
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
The company collects and uses personal and customer-confidential information only for an approved, explained purpose and limits fields, access, sharing, and duration to what that purpose reasonably needs.
First SOC 2 program
For each feature, form, integration, telemetry event, and support process, list the data collected, why it is needed, who uses it, and how long it remains. Remove speculative fields and high-volume telemetry that have no current owner or purpose.
As the company scales
Maintain a processing inventory and make collection and use review part of product design, event-schema approval, data-warehouse governance, and third-party onboarding. Detect new sensitive fields and purpose drift through catalog, query, access, and integration review.
Identify form fields, APIs, SDKs, logs, telemetry events, imports, support intake, integrations, and derived data that collect personal or customer-confidential information.
You should end up with: A collection-point inventory with fields, source, system, and owner.
For each data element or coherent data set, state the current business, security, service, support, legal, or contractual purpose and intended users.
You should end up with: A processing record linking data to a specific approved purpose and owner.
Ask whether each field, precision level, event, recipient, and retention period is necessary for the stated purpose and remove or reduce what is not justified.
You should end up with: A minimization review with retained decisions and product changes.
Configure field validation, event filtering, access groups, purpose-specific views, masking, export controls, and retention appropriate to the approved use.
You should end up with: Configuration or code changes showing the collection and use boundaries.
Require review before reusing data for a new feature, audience, model, analysis, sharing arrangement, or materially different purpose.
You should end up with: A product or data review with approval, conditions, or rejection.
Periodically compare schemas, warehouse tables, dashboards, exports, access, and integrations with the approved processing inventory.
You should end up with: A drift review with unexplained collections or uses assigned for remediation.
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 each material personal or customer-confidential data path from collection through internal use, storage, integration, and recipient, making excess collection or unapproved reuse visible.
Include this context
data category and collection point
Include this context
source and destination systems
Include this context
processing purpose
Include this context
internal users and external recipients
Include this context
retention reference
Include this context
owner and review date
Weak evidence to avoid
A high-level product diagram that does not name fields, purposes, analytics, support uses, recipients, or retention.
Confirm what the record proves
Shows the approved inventory of processing activities and links specific data, purposes, uses, systems, recipients, retention, and accountable owners.
Include this context
processing activity
Include this context
data categories and data subjects or customers
Include this context
specific purpose and use
Include this context
systems and recipients
Include this context
retention
Include this context
owner and approval date
Weak evidence to avoid
A vendor spreadsheet that says business purpose for every row and omits internal processing, data fields, recipients, and owners.
Confirm what the record proves
Shows that a concrete feature, report, query, export, model, support activity, or integration used the data for a reviewed purpose and within the approved scope.
Include this context
use case and requestor
Include this context
data set and fields
Include this context
stated purpose
Include this context
intended users or recipient
Include this context
approval and conditions
Include this context
effective or execution date
Weak evidence to avoid
A request for all customer data for analytics with no defined question, field limit, recipient, retention, or approval.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Shows that reviewers challenged field necessity, precision, event volume, access, sharing, and retention and removed or reduced data not needed for the stated purpose.
Include this context
feature, schema, or processing scope
Include this context
fields and stated purposes
Include this context
necessity decision
Include this context
reviewer and date
Include this context
changes or restrictions
Include this context
completion status
Weak evidence to avoid
A checked privacy review box with no field-level scope, necessity analysis, reviewer reasoning, or resulting product change.
Type 1
The current data map, processing inventory, approved purposes, and unresolved minimization findings for all active material personal and customer-confidential processing on the examination date.
Type 2
Every new or materially changed form field, API input, SDK collection, log or telemetry event, import, support intake, warehouse data set, model use, export, recipient, or integration involving personal or customer-confidential information during the review period, plus each scheduled minimization review.
Compare period schema migrations, telemetry registrations, product releases, warehouse additions, new integrations, and support-form changes with the processing inventory and minimization reviews; resolve every new field or use that lacks an approved purpose and owner.
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: The company collects and uses personal and customer-confidential information only for an approved, explained purpose and limits fields, access, sharing, and duration to what that purpose reasonably needs.
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.
Compare period schema migrations, telemetry registrations, product releases, warehouse additions, new integrations, and support-form changes with the processing inventory and minimization reviews; resolve every new field or use that lacks an approved purpose and owner.
The current data map, processing inventory, approved purposes, and unresolved minimization findings for all active material personal and customer-confidential processing on the examination date.
Every new or materially changed form field, API input, SDK collection, log or telemetry event, import, support intake, warehouse data set, model use, export, recipient, or integration involving personal or customer-confidential information during the review period, plus each scheduled minimization review.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Shows each material personal or customer-confidential data path from collection through internal use, storage, integration, and recipient, making excess collection or unapproved reuse visible.
For each selected record, confirm it demonstrates Shows the approved inventory of processing activities and links specific data, purposes, uses, systems, recipients, retention, and accountable owners.
For each selected record, confirm it demonstrates Shows that a concrete feature, report, query, export, model, support activity, or integration used the data for a reviewed purpose and within the approved scope.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Shows that reviewers challenged field necessity, precision, event volume, access, sharing, and retention and removed or reduced data not needed for the stated purpose.
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.