P6.4 Third-party privacy commitments: SOC 2 evidence

What P6.4 third-party privacy commitments require in a SOC 2

If vendors, subprocessors or other third parties touch the personal information your system handles, P6.4 asks you to show three things: you obtained privacy commitments from them, you assess whether they keep those commitments periodically and whenever something changes, and you take corrective action when they do not. The auditor will look for a working cycle, not a one-time contract clause. A compliance lead should be able to point to the vendor list, the commitments each vendor made, the most recent assessment of each one and the tickets that followed any gap.

The risk is concrete. A processor that stores or analyzes your users' personal information under weaker handling rules can disclose it, keep it longer than you allow or use it for its own purposes, and your SOC 2 report will still describe your system as protected. In practice, three things make P6.4 hard. First, inventorying vendors is harder than it sounds, because analytics tools, support desks, logging services and CI integrations can all receive personal information without anyone listing them as processors. Second, the contract language often says less than the criterion needs, so you may have to negotiate privacy terms, including what a vendor must tell you about misuse. Third, assessments go stale quickly, so the review of a vendor's SOC report or questionnaire must be repeated and tied to changes in that vendor's services.

CC9.2 carries privacy points of focus that cover the same ground, so one vendor program can often satisfy both. Confirm with your CPA firm how it will test the two together and which evidence it expects for each. Before the examination window opens, check that every vendor handling personal information has a documented commitment, that each assessment names a reviewer and a date, and that corrective actions are recorded with an owner. Dedicated handling of this is covered in the vendor management guidance elsewhere in this pillar. The AICPA 2017 Trust Services Criteria are the primary text to read alongside your own vendor records.

Which vendors and third parties fall under P6.4

P6.4 reaches any party that touches personal information on the organization's behalf, but the workload differs sharply depending on how that party gets access and who controls the data. The cards below separate the decisions that change the work, so the scope can be agreed with the auditor before evidence collection starts.

Vendors that store, process or access personal information

This is the core population. Any vendor that stores, processes or can reach personal information in the service should have a privacy commitment on file, and the organization should be able to show how that commitment is checked over time. Build the list from the data inventory and data flow records, not from the procurement list, because shadow SaaS often holds personal information without a contract review. Ask the auditor how they expect the population to be defined and sampled. Confirm the scope with your auditor before testing begins.

Subservice organizations versus other third parties

A subservice organization is one whose controls the service organization relies on, such as a cloud hosting provider, and it is usually carved out or included in the report under a defined method. Other third parties may be vendors or partners that receive personal information but do not run part of your system. The distinction changes the evidence: for subservice organizations you may rely on their SOC reports and complementary controls, while for other third parties you typically need your own commitments and compliance checks. Confirm with your auditor which treatment applies to each party.

Vendors with incidental access

Support desks, analytics tags, error trackers and hosting providers may not need routine access to personal information, but they can receive it through logs, screenshots or misconfigured fields. Incidental access still creates a P6.4 question if the vendor could reasonably see personal information. The practical check is to confirm what data reaches each tool, whether it is filtered before transmission, and what the contract says about use. Document the reasoning for each exclusion so an assessor can follow it.

Self-hosted software where the customer holds the data

When the organization runs open-source software in its own cloud account or data center, the vendor usually never receives the data. The vendor relationship then covers support access, licensing and remote maintenance, not storage. If the implementation partner or software maintainer can reach production systems during support, treat that access as third-party access and bring it within P6.4. If there is no access, document that the party is outside the data flow and retain the reasoning. Confirm this boundary with your auditor, since a remote support session can change the answer.

Third parties that receive data for their own purposes

Some recipients use personal information for their own ends, such as advertising networks, data brokers or certain analytics providers. These carry the highest privacy risk because the organization's notice and consent commitments must be reflected in the recipient's own use. The workload includes reviewing their contract restrictions, confirming purpose limits, and checking how they report misuse. Ask your auditor and counsel whether any such recipient is in scope before deciding whether to exclude it.

How P6.4 commitments move from contract to corrective action

This sequence turns a privacy promise in a vendor contract into a checked, recorded outcome. Each step produces a record an assessor can sample, so the organization can show that third parties with access to personal information keep their commitments and that gaps get fixed.

Build the third-party inventory with personal information flags
List every vendor and other third party that receives, stores, processes or can reach personal information, including subservice providers that sit beneath your own vendors. For each entry, record the service, the categories of personal information involved, the data locations and the business owner who answers for the relationship. The output is an inventory where every entry carries a personal information flag, reviewed by the privacy lead and the system owners. Ask whether the inventory draws on procurement records, access logs and data maps, because a list built only from contracts usually misses tools that teams adopted without review.
Obtain written privacy commitments in contracts
For each flagged third party, put privacy obligations in writing before personal information flows to it. These usually sit in the master agreement or a data processing addendum and cover permitted uses, confidentiality, security measures, the duty to report unauthorized disclosures, and how the third party handles requests and deletion. The signed commitment, with the version and date, is stored against the inventory entry. Confirm the wording with counsel, since the language that satisfies your own privacy objectives is set by your organization, not by the criterion.
Set the assessment schedule and ad hoc trigger rules
Decide how often each third party is assessed for compliance with its privacy commitments, with higher-risk or higher-volume relationships reviewed more closely. Write down the events that force an unscheduled review, such as a reported incident at the vendor, a change of subprocessor, a new category of personal information, or a change in the service's location. The output is a documented schedule and trigger list approved by the risk owner. Your own risk assessment under CC3 and vendor management under CC9.2 should set these frequencies, so the schedule matches the risk you have identified.
Collect and review vendor evidence
At each scheduled point or trigger, request evidence that the third party is meeting its commitments. Common evidence includes a current SOC 2 or equivalent report with its scope and exceptions reviewed, completed questionnaires, statements of subprocessors, records of data deletion, and confirmation of any incidents. A reviewer compares the evidence against each commitment in the contract, notes which commitments are covered, and flags gaps where the evidence is missing or stale. The output is a signed assessment record for that vendor and period. Confirm which evidence the vendor is able to provide before you rely on it, since a report that excludes the privacy category may not test the commitments you care about.
Record exceptions and assess their impact
Each gap or deviation found in the assessment becomes a documented exception. The record states the commitment affected, the evidence that shows the gap, the personal information involved, and an initial view of the risk. The privacy lead and the business owner decide whether the exception is accepted for a defined period, requires remediation, or justifies ending the relationship. The output is an exception log entry with an owner and a decision. Where a third party has misused personal information or disclosed it without authority, route the matter into the unauthorized disclosure record and incident process so it is not handled only as a vendor ticket.
Run corrective action through a remediation ticket
Open a remediation ticket for every exception that needs action. It names the corrective steps the third party must take, such as deleting data, changing a subprocessor, tightening access, or sending a written explanation, with a responsible owner and a status. Follow up with the vendor until the step is verified by evidence rather than a verbal assurance. If the vendor does not correct the problem, escalate through the contract remedies or move the data. The output is a ticket trail showing what was found, what was done and who verified it.
Close the loop with a closure record
When corrective action is verified, record the closure with the date, the evidence reviewed, the approving owner and any residual risk accepted. Update the inventory entry and the assessment schedule if the risk profile has changed. Feed recurring exceptions into the risk assessment and the next contract renewal so the same gap does not return unnoticed. The output is a closure record linked to the original exception, which an external assessor can trace from the contract through to the final outcome. Confirm with your assessor how many closure records they expect to sample for the period under review.

How an assessor tests P6.4 third-party privacy commitments

This table compares what a SOC 2 assessor typically does for each part of P6.4, the evidence they ask for, and the findings they most often raise. Read each row as a question the assessor will put to your vendor management records, then check whether your evidence answers it for the full period of the report.

Test area	What the assessor does	Evidence requested	Common findings
Vendor inventory and completeness	Compares the vendor list against payment records, access grants, data flow diagrams and subservice lists to find third parties that handle personal information but are missing from the register.	Vendor register with data categories, access scope and owner; access provisioning records; data flow diagrams; accounts payable extracts (illustrative).	Vendors that process personal information but are absent from the register, or entries with no recorded data category.
Contract sampling for privacy commitments	Selects a sample of vendor agreements that involve personal information and checks for written privacy obligations covering use limits, safeguards and return or deletion.	Signed data processing terms, master agreements with privacy schedules, and any exceptions approved by the organization.	Agreements with no privacy terms, terms that predate current data use, or signed contracts not located when requested.
Periodic and event-driven assessments	Reviews whether vendor compliance with privacy commitments was assessed at the frequency the organization set, and whether events such as incidents, scope changes or renewals triggered a reassessment.	Assessment schedule, completed questionnaires or vendor reports, reviewer sign-off, and records of triggered reassessments.	Assessments overdue against the organization's own schedule, or no reassessment after a material change in the vendor's processing.
Corrective action follow-through	Traces findings from vendor assessments to remediation tickets and checks whether actions were completed, verified and accepted by a named owner.	Remediation log, due dates, closure evidence, risk acceptance records and escalation notes.	Findings left open past their due dates, closed without verification, or accepted without documented approval.
Vendor-reported unauthorized disclosures	Checks that notices from vendors about misuse or unauthorized disclosure reached incident handling, were assessed, and led to documented corrective steps.	Vendor notices, incident tickets, root cause analysis, communications to affected parties where required, and correction records.	Vendor notices received by a mailbox with no ticket, or incidents closed without confirming the vendor's remediation.
Commitments to report disclosures	Confirms that contracts require vendors to report unauthorized disclosures and that the organization can match those obligations to its own notification process.	Reporting clauses, named contacts at each vendor, and the notification path used in the incident plan.	Reporting obligations missing from contracts with vendors that were later involved in an incident.
Consistency with the system description	Compares the vendors and privacy practices described in the system description and management's assertion with the vendor records the assessor has sampled.	System description draft, management assertion, and the vendor register as at the report date.	Vendors named in the system description but not in the register, or the reverse.

Evidence that satisfies P6.4 and how to keep it current

P6.4 is proven by a chain of records, not a single document: who has access to personal information, what each one promised, what they returned when assessed, and what was done when they fell short. The cards below cover each link in that chain. Each one needs an owner and a refresh rhythm between audits, because an assessor will sample across the whole period, not just the most recent review.

Vendor register with personal information flags

This is the inventory of every third party that receives, stores or can reach personal information, with a flag showing which data categories each one handles. It is the starting point for P6.4 because you cannot assess commitments you have not identified. Check that the register is reconciled against accounts payable, production access lists and data flow diagrams, not only against procurement tickets. Engineering or the data owner updates entries when a new integration or sub-processor appears, and the privacy or compliance lead signs off the register at least once a year and at each vendor onboarding.

Executed privacy commitments and data processing terms

These are the signed contract terms, data processing agreements or privacy addenda that set out what a third party may do with personal information and what it must report. An assessor will look for a signed version dated before the vendor received data, and for terms that cover use limits, retention, deletion and notice of unauthorized disclosure. Store the executed copy with the register entry and record the renewal or expiry date. Legal or procurement owns the signature, and the privacy lead confirms the terms match the data flagged in the register.

Assessment questionnaires and returned vendor evidence

Questionnaires show how each vendor was checked against your privacy commitments before and during the relationship. The returned evidence, such as a vendor's SOC 2 report, bridge letter or security attestation, is what proves the check was real. Confirm that the report period covers the period you need, that the scope includes the service you buy, and that you have reviewed the exceptions and complementary user entity controls. Your team owns the review, and the reviewer records a dated sign-off next to each returned document.

Assessment decisions and risk ratings

A decision record states whether each vendor was approved, approved with conditions or rejected, and why. The risk rating should follow from the data categories, volume and the quality of the returned evidence, so an assessor can trace the rating to its inputs. Record the reassessment trigger, such as a new data category, an acquisition or a reported incident, along with the next scheduled review date. The business owner accepts the risk, and the security or privacy lead signs the rating.

Corrective action tickets with closure proof

When an assessment finds a gap, such as a missing deletion commitment or an unclear disclosure notice, a corrective action ticket records the finding, the agreed fix, the owner and the due date. P6.4 expects corrective action where needed, so the ticket must end with proof of closure, such as an amended contract, a remediated configuration or a re-test result. Tickets left open past their due date are a common exception in sampling, so review the open list at each monthly risk meeting. The vendor owner or security lead closes the ticket, and the reviewer checks the closure proof.

Records of vendor-reported disclosures

When a third party reports an actual or suspected unauthorized disclosure of personal information, the notice and your response must be recorded together. This record links the vendor's notice to the incident process, the scope assessment and any notice to affected data subjects. Keep the vendor's original message, the time it was received and the decision taken. Incident response owns the record, and the privacy lead reviews each entry to confirm it was logged completely and within the timeline in your own commitments.

What meeting P6.4 costs in money and effort

This table lists the cost components of running P6.4 third-party privacy commitments, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since no fees or durations for this criterion have been published in the sources. The main takeaway is that the recurring cost sits in vendor review and evidence upkeep, so the vendor count and contract volume matter more than the initial setup.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Tooling or licenses	Software vendor or internal platform team	Recurring (subscription) or one-time (self-hosted setup)	Commercial GRC licenses scale with users and vendor records; self-hosted open-source tools remove license spend but still need hosting and administration
Inventory and assessment workflow build	Internal compliance and engineering staff, optionally an implementation partner under a written scope	One-time, with later updates	Number of systems that process personal information, how many data flows exist, and whether vendor data already sits in a procurement system
Vendor privacy commitment review	Legal, procurement and compliance staff	Recurring with each new contract or renewal	Contract volume, how many vendors touch personal information, and whether a standard data processing addendum is used
Periodic and as-needed vendor assessments	Compliance staff, sometimes the vendor's own team	Recurring	Vendor count, data sensitivity, and how often the organization re-assesses each vendor against its commitments
External review of high-risk vendors	Independent assessor or consultant chosen by the organization	Recurring for high-risk vendors only	Data sensitivity, vendor concentration, and whether the vendor already provides a current SOC 2 or similar report that can be reviewed instead
Corrective action and remediation tracking	Vendor management, privacy and engineering staff	Recurring, driven by findings	Frequency of misuse or unauthorized disclosure findings and the strength of notification terms in contracts
Evidence upkeep	Compliance staff who keep records current	Recurring	Retention periods, how evidence is collected, and whether vendor records are linked to the inventory
Auditor sampling and testing	Independent CPA firm, under its engagement letter	Recurring with each examination period	Number of vendors in scope, the sample sizes the auditor selects, and how cleanly records are kept before fieldwork

Who does what for P6.4: your team, a partner and the auditor

Your organization owns P6.4 in full. The criterion asks the organization to obtain privacy commitments from vendors and other third parties that touch personal information, to assess their compliance periodically and as needed, and to take corrective action when they fall short. Those decisions belong to people accountable for the risk, usually a privacy or compliance lead working with the business owner of each vendor relationship. A partner can organize the work, but it cannot accept risk on your behalf or sign a contract for you.

Vendor decisions: Deciding which third parties may receive or access personal information, and whether a vendor's assurance is sufficient for that access.
Contract terms: Negotiating and signing the privacy commitments, including how the vendor will report unauthorized disclosures and how it will handle misuse.
Risk acceptance: Approving exceptions, residual risk and any decision to continue with a vendor that has open findings.
Corrective action: Requiring remediation, setting deadlines, and ending the relationship or restricting data flows when a vendor does not comply.
Ongoing monitoring: Owning the periodic and event-driven reassessment, including reviewing vendor SOC 2 reports and bridge letters.

Before the audit starts, confirm that a named owner can show a current list of vendors with personal information access, signed commitments for each, and dated records of every corrective action.

Which self-hosted open-source tools can hold P6.4 evidence

A workable P6.4 program needs a system that holds the vendor register, the privacy commitments each third party has made, the periodic assessments of their compliance, and the corrective action records that follow. CISO Assistant, which is licensed under AGPL-3.0-only, is one open-source candidate for this role. Its published README states that it ships more than 200 frameworks, including SOC 2, and that it runs audits and compliance assessments against them with automatic mapping between frameworks (see the CISO Assistant README on GitHub). That mapping matters for P6.4 because the same vendor assessment often also supports CC9.2 and other vendor-related criteria, so one record can serve more than one audit question.

Before you rely on it, confirm the specific workflows you need. Check that the tool can model each third party with the personal information it handles, record the privacy commitments it has signed, schedule reassessments both periodically and after triggering events such as a vendor incident or a change in its processing, and link findings to corrective actions with owners and closure dates. Ask your SOC 2 auditor which evidence format they expect, such as exported assessment reports, dated attachments or screenshots, and confirm that the tool can produce it without manual reconstruction. Treat the README as a starting point, not as proof of fit for your program.

Because CISO Assistant is licensed under AGPL-3.0-only, your obligations depend on how you use it. Internal use within your organization may carry different duties from modifying the code or offering it to others as a hosted service, and the answer can change with the version and the way you deploy it. Have counsel review the license terms before you modify the software, customize it for a client, or host it for a third party, and keep a record of that review as part of your vendor governance evidence.

Where P6.4 programs usually fall short

Most P6.4 weaknesses are not missing policies. They are gaps between what the organization believes about its vendors and what its records show. The cards below cover the five places where vendor privacy oversight usually breaks down, from the inventory that never reaches security to the corrective action that never gets closed.

Vendors missing from the inventory

A P6.4 program can only cover third parties it knows about. When procurement signs a tool that handles customer personal information and security never hears about it, that vendor sits outside every assessment cycle. Close the gap by requiring a privacy and data-access review before any purchase order is approved, and by reconciling accounts-payable vendor lists and SaaS single sign-on records against the register each quarter. Ask who can connect a new data processor to production without a ticket.

Commitments that exist only in sales paperwork

A privacy commitment matters for P6.4 only if the organization can point to it in an enforceable document. Promises made in a sales call, a questionnaire response or a marketing page often never reach the contract. Check each processor with access to personal information for a signed data processing agreement that states permitted purposes, confidentiality duties and restrictions on onward sharing. Store the signed copy beside the vendor record so the auditor can trace the commitment to the vendor.

Assessments done once at onboarding

Many programs review a vendor's privacy posture during procurement and never look again. A vendor's ownership, hosting location, subprocessors and security reports can change long after the contract is signed. Set a review frequency by risk tier, typically annual for vendors with high volumes of personal information, and add event triggers such as an acquisition, a new subprocessor or a reported incident. Ask each vendor for a current SOC 2 report or a bridge letter when the prior report period ends.

Corrective actions with no closure evidence

When a vendor misuses personal information or fails a review, teams often record the finding and move on without proof that the fix happened. An auditor testing P6.4 will ask what was corrected and how the organization confirmed it. Log each finding with an owner, a due date and the evidence required to close it, such as a revised contract clause, a deleted data set with a deletion certificate, or a retested configuration. Escalate findings that stay open past their due date to the risk committee.

Data flows changing without reassessment

A vendor approved for one purpose can quietly receive new categories of personal information when a team adds a feature, a new integration or a data export. The original assessment then no longer describes reality. Tie the vendor register to data flow records, and require a privacy review whenever a team changes the fields, volume or purpose of data sent to a third party. Confirm that engineering change tickets for integrations include a field that asks whether third-party data flows are affected.

Questions buyers ask about P6.4 cost, effort and outside help

How much effort does P6.4 take for a small SaaS with few vendors?

For a small SaaS with a handful of vendors that touch personal information, the work is mostly a bounded inventory and a repeatable review. You list each vendor that receives personal information, record what contract or data processing terms already say about privacy, collect any missing commitments, and set a review rhythm. Effort rises with the number of vendors, how sensitive the data is, and how many of them have contracts that never mention personal information. A large platform adds volume, ownership across business units, subprocessor chains and more frequent reassessment. The main cost drivers are vendor count, data sensitivity, contract negotiation and how much evidence already exists. Ask any partner to size the work from your vendor list in a written scope rather than from a generic estimate.

Can we run P6.4 in-house without outside help?

Yes, most organizations can run P6.4 in-house if someone owns the vendor inventory, the privacy terms and the periodic reviews. Outside help is most useful for building the first version of the process, mapping vendor terms to the privacy commitments your auditor will test, or setting up tooling that keeps records current. Keep ownership of decisions inside the organization: deciding which vendors are acceptable, accepting residual risk and approving corrective action. An implementation partner can prepare systems, records and evidence, but only an independent CPA firm issues the SOC 2 report. Confirm with your auditor early which evidence they expect, since that determines how much structure the in-house process needs.

What does P6.4 need from engineering and legal?

The work splits between legal and engineering, and it fails when either side assumes the other owns it. Legal typically:

Negotiates or confirms privacy commitments in vendor contracts and data processing terms
Tracks which terms apply to which vendor and when they change
Approves corrective actions that involve contract remedies or termination

Engineering typically:

Maintains the list of systems and integrations that send personal information to third parties
Collects vendor assurance evidence and checks data flows against what the vendor is allowed to do
Implements technical corrective actions such as revoking access or changing configurations

Both teams should agree on who owns the inventory and the review calendar in writing before the first audit window opens.

How long does it take to build the P6.4 program before an audit window?

The time depends on how much of the program already exists, so there is no reliable duration without a scoped review of your vendors and contracts. Organizations that already keep a vendor register and standard data processing terms usually need less time than those that must start the inventory from scratch. Plan for at least one full cycle of vendor reviews to run before the auditor samples evidence, because a Type 2 report tests operation over a period, not a single moment. Ask your auditor which period they will cover and whether they expect the review cadence to have operated during it. Use that date to work backward to the start of the program.

What should we ask a partner for in a fixed-scope P6.4 quote?

A fixed-scope quote should state exactly what is included, what the client provides and what is excluded. Ask for:

The list of vendors and systems in scope, and how the inventory will be validated
The contract and privacy terms to be reviewed, and which deliverables are templates versus negotiated amendments
The evidence set prepared for the auditor, including review records and corrective action logs
The number of review cycles and workshops covered, and the handover of ownership at the end
What is excluded, such as contract negotiation with vendors, legal opinions or the auditor's own testing

DeployOpen works from a written scope agreed before work starts, and does not publish a price list, so the quote follows from that scope.

How do P6.4, CC9.2 and P6.5 relate to each other?

P6.4 is the privacy criterion for obtaining commitments from third parties with access to personal information, assessing their compliance periodically and as needed, and taking corrective action. CC9.2 is the common criterion for managing risks from vendors and business partners, and it carries privacy points of focus on obtaining vendors' privacy commitments and assessing compliance with them, so the same evidence often supports both. P6.5 covers obtaining commitments that vendors will notify you of actual or suspected unauthorized disclosures, and routing those notices into incident response. In practice, one vendor register and one review record can satisfy all three, but the notification clauses under P6.5 need their own tracking. Confirm the mapping with your auditor, since the assessor decides how evidence is credited.

How DeployOpen prepares P6.4 vendor evidence

DeployOpen works on P6.4 by preparing the systems and records that show how your organization obtains privacy commitments from vendors and other third parties, checks their compliance and acts on gaps. Your organization owns the criterion, and an independent CPA firm decides whether the controls meet it.

How we scope

We agree in writing which third parties with access to personal information fall inside the P6.4 scope.
We list the privacy commitments each vendor category must give, such as use limits and disclosure reporting.
Engagements are fixed-scope, so deliverables and timelines are confirmed before any work starts.

How we build

We configure a vendor register that records each third party, its personal information access and its commitments.
We set up periodic and event-driven reassessment workflows so compliance reviews and corrective actions are logged.
We document the procedures for remediating third-party misuse and routing reported unauthorized disclosures to incident response.

How we hand over

We deliver the vendor register, assessment records and corrective action logs in formats your auditor can sample.
We write procedure documentation that names owners, review frequency and the evidence each control produces.
We walk your compliance and procurement staff through the evidence so they can answer auditor questions themselves.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
We can refresh vendor reviews and evidence between audit periods when your vendor base changes.
Questions about whether a specific report satisfies P6.4 should be confirmed with your independent CPA firm.