Skip to content

SOC 2® privacy: sharing data and reporting breaches

Unofficial plain-English guide. Not affiliated with or endorsed by the AICPA. Read the AICPA’s own criteria

An unofficial plain-English look at SOC 2 privacy criteria P6.1 to P6.6: sharing personal data with third parties, vendor commitments, and breach notification.

By Blank Slate Creative.

OrderFive custom security policies, $85 flat. Markdown, Word, and PDF.

Order the five policies

Who else gets personal data from you, and what happens if it leaks?

This group follows personal data out the door. It covers when you may share it, the records you keep of what went where, what you require of vendors that handle it, and what you do when it leaks.

It leans on the rest of your program. The vendor inventory from the vendor topic, and the incident plan from the response topic, are where most of the answers already live. The new part is the personal-data lens on each.

Where a small team starts

Take your vendor list and mark which vendors receive personal data. For each of those, check that there is a signed data agreement and that the vendor’s breach-notice terms are written down.

Then add a breach-notification step to your incident plan. Name who decides whether to notify, and who you call first. Notification rules vary by place, so that decision needs your lawyer, not this guide.

The criteria, P6.1 to P6.6

Below are our short labels, what the criteria are about, and examples of what a small team might do or keep. The examples are our own views, not requirements of the standard.

P6.1: Sharing only with permission

Handing personal data to an outside party should match what people were told and agreed to when they gave it.

In practice

  • A list of every third party that receives personal data, with the purpose for each.
  • A signed data agreement with each one.
  • A review step before a new integration or tracking library goes live.

P6.2: Recording approved disclosures

The company keeps a record of the disclosures it authorized, so it can say who received what.

In practice

  • A disclosure register with recipient, date, data, and purpose.
  • Logs for bulk exports and data shares.
  • An access log for partner API keys.

P6.3: Recording improper disclosures

When personal information gets out without authorization, the company records it, including cases reported by customers or outsiders.

In practice

  • An incident register with a field for personal data exposure.
  • An intake path for reports from customers and security researchers.
  • A tag that routes these incidents to whoever advises on legal questions.

P6.4: Holding vendors to privacy commitments

Vendors that handle personal information agree in writing to protect it, and the company checks that they do.

In practice

  • A signed data processing agreement with each vendor that touches personal data.
  • A yearly look at whether each vendor’s practice matches what it promised.
  • A list of subprocessors that matches what you told customers.

P6.5: Vendors must report incidents to you

Your vendors hold some of your data, so a problem on their side can quickly become yours. Reviewers look for contract language that obliges vendors to tell you, and a named person who would receive the notice.

In practice

  • A notice clause with a time limit in vendor contracts.
  • Current security contacts on file for each vendor.
  • A log of vendor notices and what was done about each.

P6.6: Telling affected parties about a breach

When an incident exposes personal information, the company tells affected people and others as required, and keeps copies of the notices.

In practice

  • A notification playbook with drafted templates.
  • A named legal contact to call before anything goes out.
  • A short list of the notification rules that apply, by where your customers live.
  • A tabletop exercise that includes the decision to notify.

Questions worth being able to answer

These are ours, not a list of what an examiner will ask. If you can answer each in a sentence, and show where the proof lives, you are in good shape for the conversation.

  • Which third parties receive personal data, and for what purpose?
  • Show me the agreement with one of them.
  • How would a vendor’s breach reach you, and who acts on it?
  • Who decides whether to notify people, and who do they call first?
  • Is there a log of what was disclosed, and to whom?

More topics in this guide

This page is one part of our unofficial guide to the SOC 2 Trust Services Criteria. Here are the others.

Related guides

About this guide and the study tool

Who we are, and aren’t

Blank Slate Creative, LLC is not affiliated with, endorsed by, or sponsored by the AICPA, CIMA, or the Association of International Certified Professional Accountants. We are not a CPA firm. Only a licensed CPA firm can perform a SOC 2 examination and issue a report.

What this is, and isn’t

This is an unofficial, plain-English explanation written by Blank Slate Creative, LLC. It is not the Trust Services Criteria, and it does not reproduce or replace them.

It is not legal, audit, or attestation advice.

Using this guide or the study tool does not mean you will pass an audit or satisfy any customer or auditor.

The “in practice” notes and examples are our own views, not requirements of the standard.

Written about the 2017 criteria with the 2022 revised points of focus. The AICPA may revise them.

Read the AICPA’s own publication for the authoritative wording. The PDF download asks for a free AICPA account.

Trademarks

AICPA and American Institute of CPAs are trademarks of the American Institute of Certified Public Accountants and are registered in the US, the EU and other countries.

SOC 1®, SOC 2® and SOC 3® trademarks are registered trademarks of the AICPA.

← All guides