What P6.1 disclosure to third parties asks for and why it is hard
If your SOC 2 privacy scope covers personal information that flows to processors, partners or systems operated for your customers, P6.1 is the criterion that governs whether that sharing is allowed at all. It requires the organization to disclose personal information to third parties only with the data subject's explicit consent, obtained before the disclosure takes place. It is the first of seven criteria in the P6 group on disclosure and notification, and the other six (the records of authorized and unauthorized disclosures, third-party commitments, third-party notification, breach notification and accounting) depend on the consent state you establish here being traceable.
The risk is straightforward to state and hard to rule out. Personal information reaches a third party without the data subject's consent, either because a team enabled a new integration, because a support engineer exported a dataset to a tool, or because a feature began sending fields to a vendor that the original notice never described. Under the points of focus for P6.1, the organization should communicate its privacy policies to third parties, disclose personal information only when appropriate and only to appropriate third parties, and handle disclosures for new purposes and uses deliberately. A new purpose is exactly where unconsented sharing tends to appear first, because the change is made by engineers who may not think of it as a disclosure.
The difficulty is that the consent state rarely lives in one place. It may sit in a consent management platform, a customer contract, a user preference table, a CRM field and a marketing tool, each with its own update path. Sharing happens through API integrations, webhooks, scheduled exports, analytics SDKs and ad hoc file transfers, and many of these were never entered into an inventory. Before your auditor tests P6.1, confirm which systems hold consent records, which flows send personal information out of your environment, and whether each outbound flow can be matched to a recorded consent. Where you cannot answer one of those questions, treat that gap as the first remediation item, because an auditor will ask for the evidence and an unmatched flow is difficult to explain in a Type 2 period.
Which systems, data flows and third parties fall under P6.1
P6.1 only applies when privacy is in scope and personal information leaves the organization. The cards below cover the decisions that determine how much of the environment the criterion reaches, and they connect because each one changes which disclosures an assessor will ask you to evidence.
Deciding whether privacy is in scope
P6.1 is a privacy category criterion, so it applies only when the organization has chosen the privacy category for its SOC 2 and the system processes personal information. Confirm the scope decision in writing with your CPA firm before fieldwork. If privacy is excluded, P6.1 is not tested, but customers may still ask how personal information leaves the system, so document the reasoning behind the exclusion.
Mapping personal information categories
List each category of personal information the system holds, such as contact details, account identifiers, payment-related data, employee records or support transcripts. For each category, record which ones ever leave the boundary. An assessor will sample disclosures, and a category missing from the inventory is the usual reason a disclosure goes unrecorded. Note any category that is disclosed only in aggregated or de-identified form, and confirm with counsel that it truly is.
Identifying processors and subprocessors
Hosting providers, email delivery, analytics, payment processors and managed support tools all receive personal information on your behalf. Each one is a third party for P6.1 purposes. Keep a current register that names the provider, the data categories it receives, the purpose and the region. Ask each provider to confirm the subprocessors it uses, since a disclosure chain often extends beyond the first vendor you contract with.
Tracing integrations and API data flows
Customer-facing integrations, webhooks, single sign-on connectors and data exports all move personal information outside the system. Trace each one from source to destination, including scheduled jobs and manual exports. Self-hosted platforms often expose export endpoints or connectors that teams enable without review, so check configuration against the approved list. Confirm which integrations customers authorize themselves and which the organization enables.
Handling government and legal requests
Disclosures required by a court order, subpoena or regulator are still disclosures under P6.1. Define who may receive such requests, how they are logged, how the legal basis is verified and when the data subject or customer is informed where the law permits. Ask counsel which requests may be refused or narrowed. Route each request into the disclosure record so that the authorized disclosure log stays complete.
Triggering disclosures across teams
Product, support, sales and data engineering each create disclosures without necessarily treating them as such. Support may send logs to a vendor for troubleshooting, sales may share a customer list with a partner, and data engineering may replicate tables to a new analytics store. Brief each team on what counts as a disclosure and require a review before a new one starts. Disclosures for new purposes also count, so a product change that adds a new use of existing data must go through the same review.
How an assessor tests disclosure consent before sharing data
This table walks through what an assessor reviews for P6.1, from the privacy notice and consent design through sampled disclosures traced back to prior explicit consent. Read each row as a test step with the evidence it produces and the findings that most often appear when the step fails.
| Assessment step | What the assessor does | Evidence requested | Common finding |
|---|---|---|---|
| Read the privacy notice and consent design | Checks whether the notice and consent flows say which third parties receive personal information and for what purpose | Current privacy notice, consent screens, consent wording by product and region | Notice names categories of recipients but not the specific purposes for sharing |
| Map disclosure paths | Confirms every route by which personal information leaves the system, including APIs, batch exports and support tooling | Data flow diagram, integration inventory, list of outbound connections and recipients | Integrations exist in engineering systems that were never added to the privacy inventory |
| Sample disclosures to third parties | Selects a sample of disclosure events and traces each one to a record of consent | Disclosure logs, transfer records, the consent record linked to each sampled individual | Sampled disclosures cannot be matched to any consent record |
| Confirm consent came before disclosure | Compares the timestamp of each consent record with the timestamp of the disclosure | Consent audit trail with timestamps, system logs for the transfer event | Consent recorded after the data was already sent, or consent captured in bulk after onboarding |
| Test disclosures for new purposes | Looks for changes in purpose or recipient and checks whether fresh explicit consent was requested | Change records for integrations, product release notes, re-consent campaigns and their results | A new analytics or AI vendor receives data under the original consent without a new consent step |
| Review undocumented integrations | Searches for transfers the organization did not record, such as embedded SDKs or ad hoc scripts | Code and configuration review results, vendor list reconciled to network and cloud logs | Third-party SDKs send data to recipients that are absent from the privacy notice and the vendor register |
| Check consent withdrawal and suppression | Tests whether disclosures stop once consent is withdrawn or refused | Withdrawal records, suppression lists, sampled transfers after withdrawal dates | Withdrawn individuals still appear in outbound data feeds |
How to implement consent-gated disclosure step by step
This sequence turns the P6.1 requirement into working controls: you find every recipient and data flow, decide which disclosures need explicit prior consent, enforce that consent in the systems that send data, and keep the notice and the record accurate. Each step ends with an artifact an auditor can inspect.
Inventory third-party recipients and data flows
Start by listing every party outside the organization that receives personal information, including processors, analytics and marketing vendors, payment and identity providers, and partners that receive files or API feeds. For each recipient, record which data elements move, the system that sends them, the trigger, and the business purpose. Engineering and the product owner usually complete this together, with the privacy lead reviewing it. The step is done when every outbound flow has an owner and a line in a disclosure register that the organization can produce for the auditor.
Classify which disclosures need explicit prior consent
Using the register, decide which disclosures require the data subject's explicit consent before they happen and which rest on another documented basis, such as a contract or a legal obligation. Privacy counsel or the privacy officer should approve the classification, and the reasoning should be written next to each flow. Flag any disclosure that would serve a purpose the data subject was not told about. The step is done when each flow carries a signed classification and consent-required flows are listed separately.
Build the consent record and the disclosure gate
Create a consent record for each data subject that captures what was agreed, to which recipient or category of recipient, the date, the notice version shown, and the collection channel. Then add a check in each sending system, so a disclosure runs only when a matching, current consent exists and the request fails closed otherwise. Engineering owns the gate and the data protection or privacy team owns the consent definitions. The step is done when a test account with no consent is blocked from the flow and a consented account passes, with both results logged.
Align the privacy notice with each recipient
Compare the privacy notice against the disclosure register and confirm that each consent-required recipient category is described in plain terms, along with the purposes and the choice the data subject has. Remove any statement that says a disclosure happens when the gate does not allow it. Legal review sets the final wording, and the notice version is recorded in the consent record. The step is done when a reviewer can trace every consent prompt to a notice section and every notice section to a live flow.
Add a review step for new purposes and recipients
Create a documented approval step that runs before any new recipient, new data element or new purpose is added to a flow. The requester describes the change, the privacy team checks whether existing consent covers it, and new consent collection or a notice update is scheduled before go-live. The change ticket should link to the updated register. The step is done when the change process cannot promote a new disclosure without a recorded privacy decision.
Test the gate and retain the evidence
Test each consent-gated flow with consented, unconsented and withdrawn-consent accounts, and confirm that withdrawal stops future disclosures. Keep the test scripts, results, configuration exports and review records together so an auditor can sample them across the period under examination. Repeat the tests after material changes and at the interval the organization sets in its own policy. The step is done when test evidence exists for each flow and each failure has a tracked fix.
Where consent gates sit in a self-hosted stack
Placing the check in the application means the code that calls a third-party processor first confirms that the data subject has given explicit consent to that disclosure. This is the most direct gate because the developer who writes the call also sees the consent state and the purpose. Its weakness is coverage: every service, script, background job and vendor SDK that touches personal information must carry the same check, and any call added later without it is a disclosure the control never saw.
- Clear decision point: The check sits right before the outbound API call, so the consent record and the request can be logged together.
- Purpose binding: The code can compare the stated purpose of the call against the purpose the person agreed to, which matters for disclosures for new purposes.
- Coverage gaps: Batch jobs, admin tools and third-party SDKs often bypass the shared request path and need their own checks.
- Effort: Each integration needs the check written and tested, so effort grows with the number of processors.
- Ongoing cost: Developers must keep the check in place as code changes, which needs code review and tests.
Before relying on this tab, confirm with your engineering team that every outbound client library routes through a shared function that enforces the check.
An integration layer, such as a self-hosted API gateway, egress proxy or middleware service, sits between internal systems and external processors. Outbound requests pass through it, and it can block any transfer that lacks a valid consent record. The advantage is that one control covers many applications, including ones written before the consent process existed. The cost is that it only sees traffic that actually crosses its boundary, so network routes that skip it must be closed off.
- Central enforcement: One policy applies to every application that uses the gateway, which simplifies evidence for an auditor.
- Egress restriction: Network rules can force outbound calls to processors through the proxy and deny direct connections.
- Consent lookup: The gateway checks a consent store on each request, so the store must be reliable and available or transfers stop.
- Limited context: The gateway sees endpoints and payloads but may not know the purpose of a call without metadata from the application.
- Build and run effort: The component needs deployment, policy authoring, monitoring and change control of its own.
Confirm which outbound paths your network design actually forces through the gateway, and test that a direct connection is blocked.
Exports, data warehouse loads and analytics feeds are often where personal information leaves the system in bulk. Controls at this stage filter records by consent status, remove fields a recipient has no basis to receive, and log each batch. This placement is well suited to recurring disclosures to analytics or reporting vendors, because it can apply a rule to a whole dataset at once. It is weaker for real-time calls, and a pipeline that is rebuilt without its filter can reopen the disclosure silently.
- Batch filtering: Consent status is applied to each record before the file or stream is released.
- Field minimization: Pipelines can drop identifiers that a recipient does not need for the stated purpose.
- Run logs: Each export records what was sent, to whom and under which rule, which supports the disclosure record P6.2 requires.
- Scheduling risk: Ad hoc exports run by staff outside the pipeline are a common route around the control.
- Testing burden: Filters need test data that covers withdrawn consent, expired consent and records with missing consent fields.
Check whether analysts can export data directly from the warehouse, since that path can bypass the pipeline filter entirely.
In most self-hosted stacks no single placement covers every disclosure, so the practical question is which combination closes the gaps that matter. An illustrative example: a team that sends user records to a payment processor through its application, sends nightly files to an analytics vendor, and runs an internal reporting tool may need an application check for the processor, a pipeline filter for the analytics feed, and a database permission or gateway rule for the reporting tool. The choice depends on how many processors exist, how often each receives data and who can move data outside approved routes.
- Map the paths first: List every route by which personal information leaves the system, including APIs, files, backups and support access.
- Layer the controls: Use the application check for real-time calls and pipeline filters for bulk transfers, with the gateway as a backstop.
- Shared consent record: All placements should read from the same consent store so that a withdrawal takes effect everywhere.
- Shared logs: Each placement should write to one disclosure log that supports P6.2.
- Design for change: New processors and new analytics jobs should trigger a review before they go live.
Ask your implementation partner or internal team to produce a written list of disclosure paths and the control that governs each one before the auditor's fieldwork begins.
Evidence that satisfies P6.1 and how to keep it current
P6.1 is tested through records that show each disclosure of personal information to a third party was preceded by the data subject's explicit consent. The cards below cover the artifacts an assessor usually asks for and the routines that keep them accurate between examination periods.
Disclosure inventory
A documented inventory of every third party that receives personal information, with the data categories sent, the purpose, the legal or contractual basis and the system that performs the transfer. This is the starting point for the assessor's sample, so an incomplete inventory undermines every other artifact. Check that it includes integrations added by engineering and analytics teams, not only the vendors procurement approved. Review it at each release that adds an integration.
Consent records with timestamps
Consent records should show consent captured before the first disclosure to each third party, tied to the specific recipient or category of recipient. Each record needs a timestamp, the version of the consent text shown, the identity of the data subject and a withdrawal state. Compare the consent timestamp against the earliest disclosure timestamp for each sampled subject. Gaps where disclosure precedes consent are the exceptions an assessor will write up.
Data flow diagrams
Data flow diagrams show where personal information leaves the organization's boundary, through which services, and under which credentials. They let an assessor trace a disclosure from source to recipient without relying on interviews. Keep diagrams tied to the system description and mark which flows are outbound to third parties. Regenerate or review them after infrastructure changes, since stale diagrams are a common reason a disclosure goes unrecorded.
Privacy notice version history
Keep every published version of the privacy notice with its effective date, the change log and the approval record. P6.1 points of focus expect third parties to be told about the organization's privacy policies, so the notice in force on the date of each disclosure matters. Store archived versions in a location that cannot be silently overwritten. Confirm with counsel which notice applies to customers under existing contracts when the notice changes.
Change records for new purposes
When an existing disclosure is extended to a new purpose or use, the change needs its own record: the request, the privacy review, the updated consent request and the approval. P6.1 specifically covers disclosures for new purposes, so an assessor will look for this trail whenever a product team adds a feature that sends data elsewhere. Link each change record to the ticket that implemented it so the evidence can be traced end to end.
Sampled disclosure tickets
Disclosure tickets or transfer logs for a sample of actual disclosures show that the process ran in practice. Each sampled ticket should point back to the consent record, the inventory entry and the approving owner. Ask your auditor which population and sample size they plan to use, and confirm that your logs can produce a complete population for the period. Gaps in the log population are often harder to explain than a single exception.
What meeting P6.1 costs in money and effort
This table breaks down the cost components of meeting P6.1 by who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to scope internal work against outside help and to frame questions for a quote. No supplied figures exist for these costs, so confirm amounts with each provider against your own third-party count and integrations.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Consent management tooling or licenses | Software vendor, or none if self-hosted open source is used | Often recurring (subscription); one-time for setup | Number of data subjects, consent purposes and jurisdictions; self-hosting shifts spend to infrastructure and staff |
| Data inventory and flow mapping | Internal staff or implementation partner | One-time, then recurring upkeep | Number of systems, integrations and third parties receiving personal information |
| Engineering time for consent gates and disclosure records | Internal engineering or implementation partner | One-time build, recurring maintenance | Number of disclosure paths, APIs and purposes that need a pre-disclosure check |
| Third-party disclosure register and approvals | Internal privacy and legal staff | Recurring | Number of third parties, how often they change, and whether new purposes need fresh consent |
| Evidence collection and upkeep | Internal compliance or security staff | Recurring across the audit period | Frequency of disclosures, sample size the auditor selects, and how automated the logs are |
| External review or readiness assessment | Independent consultant or implementation partner | Usually one-time or periodic | Scope of review, number of disclosure flows and whether gaps must be remediated first |
| Auditor testing of P6.1 in a SOC 2 examination | Independent CPA firm | Recurring with each examination | Sample sizes, number of disclosure populations and quality of records presented; ask the firm for its testing approach in the engagement letter |
Where organizations fall short on P6.1
P6.1 is tested by following personal information from the moment it leaves your systems to a third party. The gaps below tend to appear at the handoffs: when consent is captured, when a new integration starts sending data, and when staff share records outside the tools that were designed for it. Each card names one gap and the check that closes it.
Consent obtained after disclosure
Many teams collect a data subject's agreement after a record has already been sent, for example when a sales or onboarding workflow pushes contact details to a partner before the customer ticks a box. P6.1 requires explicit consent obtained before disclosure, so an assessor will compare disclosure timestamps with consent timestamps. Check that the sending job or API call cannot run until a consent status is confirmed in the source system.
Shadow integrations and exports
Engineers often connect a new analytics tool, webhook or data pipeline to production without a review, and the data flows out for months before anyone lists it. These undocumented flows are the hardest disclosures to defend because no consent record exists for them. Run a periodic inventory of outbound connections from your network egress, cloud audit logs and API keys, and compare the results with your list of approved recipients.
No record linking consent to recipient
A consent form that says customers agree to sharing data with partners does not show which partner received which person's data. P6.1 focuses on disclosure to appropriate third parties, so the evidence needs to connect each consent decision to a named recipient and a purpose. Confirm that your consent store records the recipient identifier and purpose, and that the disclosure log can be filtered by both.
Notice not updated for new purposes
When a team starts using existing personal information for a new purpose, such as training a model or sharing data with a marketing network, the published notice often stays the same. The P6.1 points of focus address disclosures for new purposes and uses, so a change in purpose should trigger a notice review before any new disclosure. Check that product and data teams must confirm the notice still matches the purpose before a new recipient is added.
Disclosures by support staff outside tooling
Support and account teams sometimes send customer records by email, shared spreadsheet or a personal messaging app to resolve a ticket or to talk to a vendor. These disclosures bypass the consent check entirely and rarely appear in any log. Restrict export permissions in the ticketing and CRM systems, route vendor requests through a logged workflow, and sample support correspondence during monitoring to find out whether the practice occurs.
Policy written but not enforced in systems
A third-party sharing policy can be approved and signed while the technical controls that enforce it are missing or disabled. Assessors look for the control behavior, not only the document, so a policy that says consent is required has to match what the system permits. Test the policy by attempting a disclosure without consent in a non-production environment and keep the result as evidence.
Who does what for P6.1: your team, a partner and the auditor
Your organization owns the criterion. P6.1 asks that personal information go to third parties only with the data subject's explicit consent, obtained beforehand, so the decisions about which disclosures are permitted, what consent wording is used and which third parties are appropriate belong to your management, privacy function and legal counsel. No outside party can make those decisions on your behalf, and the CPA firm will test whether you made them and followed them.
- Consent rules: Decide which disclosures require explicit consent, which rely on another lawful basis you have documented, and how a new purpose triggers a fresh consent request.
- Third-party list: Maintain the approved recipients of personal information and the purposes each one serves.
- Policy and notice wording: Approve the privacy notice text that tells data subjects who receives their data and why.
- Control ownership: Name an accountable owner for each control and make sure that person can explain it during fieldwork.
- Exception decisions: Authorize, document and review any disclosure made outside the standard process.
Before engaging anyone, confirm with your counsel which of these decisions are yours alone and which you intend to delegate in writing.
An implementation partner helps build the mechanisms that carry out your decisions and produces the records an examiner will sample. DeployOpen works in this role for self-hosted open-source platforms: it prepares systems, configurations, logs and documentation inside your own infrastructure. It does not decide what consent is required, and it does not attest that controls operated as described.
- Consent capture in systems: Configure the platform so that consent status is stored with the record and checked before a disclosure job or API export runs.
- Disclosure logging: Set up logging that records recipient, data category, purpose and timestamp for each transfer.
- Access and transfer controls: Restrict which service accounts and integrations can send personal information to external endpoints.
- Evidence packaging: Organize configuration exports, tickets and log extracts so that each control points to repeatable evidence.
- Documentation handover: Write runbooks so your staff can operate the controls after the engagement ends.
Ask any partner to state in writing which deliverables it produces, which decisions remain with you, and whether it will ever sign a statement on your behalf.
The CPA firm is the only party that tests P6.1 and issues the SOC 2 report. Under the attestation framework, the firm obtains written representations from management and then gathers its own evidence. Its independence is the reason a customer can rely on the report, so the firm cannot design the controls it later tests, and it cannot approve the consent decisions that feed them.
- Test design and operation: The firm selects samples of disclosures and checks whether consent was obtained before each one.
- Management representations: The firm requires management to confirm its description of the system and its control claims in writing.
- Exceptions: Any control that did not operate as described is reported as an exception, which the customer will read.
- Scope boundaries: The firm reports on the criteria and systems in scope, not on the wider privacy program.
- Engagement terms: Agree timing, sample expectations and the report type in an engagement letter before fieldwork.
Confirm with the firm which P6.1 evidence it will request, and whether any preparation work you commission could be seen as impairing its independence.
Most organizations outsource the build and evidence work, and keep the decisions and the accountability in house. The line between outsourcing and independence is drawn by who designs and who tests. A partner may configure a consent gate, but the CPA firm must test that gate without having written it for the audit.
- Usually outsourced: Configuration of consent checks, logging pipelines, documentation drafts and evidence collection support.
- Usually kept in house: Consent policy, the approved recipient list, exception approvals and the final privacy notice.
- Shared: Maintenance of the third-party register, which the partner can set up and your team must keep current.
- Never outsourced: Management's assertion about how the system operates, which you sign.
- Ongoing: Monitoring between audits, which can sit with your team, a retainer partner or both.
Ask for a responsibility matrix that lists each P6.1 control with one named owner on your side and one on the partner's side.
Common questions about P6.1 disclosure to third parties
How much extra effort does P6.1 add to a SOC 2 examination?
P6.1 adds a defined body of work only when the privacy category is in scope, because it sits among the 18 privacy criteria that apply only then. The effort depends mainly on how many third parties receive personal information, how many distinct disclosure paths exist, and whether consent is already captured in a system that can prove it. Organizations with one or two processors and a single consent flow usually have a lighter load than those sharing data with many partners across products. Ask any consultant or partner to break the work into an inventory of disclosures, a consent gate, a record of each consent, and the policy communication to third parties, and to price each part separately.
Can a company handle P6.1 in-house without outside help?
Yes, an organization can design and run P6.1 controls itself, and the criterion does not require an outside firm. The harder part is usually not writing the policy but proving, for each disclosure, that the data subject's explicit consent came before the transfer. Teams that lack engineering capacity or a clear owner for consent records often find the evidence gap is what slows them down. An independent CPA firm will test the controls, but it does not design them for you, so an in-house team still needs to confirm the design works before fieldwork begins.
What does P6.1 need from engineering and legal teams?
Legal defines which third parties may receive personal information, what the privacy notice says about them, and which purposes require explicit consent. Engineering turns those rules into enforcement: a consent check before data leaves the system, a record of the consent, and blocks on new integrations that have not been approved. Engineers should expect to build or configure the consent store, tag personal data fields, and log every outbound transfer to an external party. Both teams should agree on how new purposes trigger a fresh consent request, since the criterion's points of focus cover disclosures for new uses.
How does P6.1 differ from P6.4 and P6.5?
P6.1 governs whether personal information goes to a third party at all, and only after explicit consent. P6.4 concerns the privacy commitments a vendor makes and how the organization checks that vendor's compliance over time. P6.5 concerns the vendor's obligation to notify the organization of unauthorized disclosures so incident response can act. In practice, P6.1 is the gate at the point of transfer, while P6.4 and P6.5 apply to the relationship that follows. A vendor can pass a P6.4 review and still breach P6.1 if data was sent without consent, so each criterion needs its own evidence.
Can an implementation partner run the consent gate for us?
A partner can build, configure and document the consent gate on infrastructure the organization controls, and prepare the evidence that the gate works. DeployOpen plans, implements and integrates self-hosted open-source platforms in the client's own environment, so a consent service or data flow can be built there as part of a fixed-scope engagement. The organization still owns the control, the legal decisions about what needs consent, and the consent records. Only an independent auditor issues the SOC 2 report, so the partner's role ends at preparing systems and evidence. Ask for the written scope to name the components, the owners and the handover documents.
How does the auditor sample disclosures when testing P6.1?
The auditor selects a sample of disclosures to third parties during the examination period and checks each one against the consent record that should precede it. For a Type 2 report, the sample covers the observation window, so the organization must keep complete logs across that whole period. Auditors typically look for the consent, its timestamp, the recipient, and whether the transfer happened after consent. Any disclosure without a matching consent becomes an exception, which is why a gap found late in the period can affect the opinion. Confirm the sample size and selection method with your CPA firm in its engagement letter and planning discussions.
How the disclosure gate and consent record fit together
Every disclosure of personal information to a third party should pass through one checkpoint, which we call the disclosure gate. A request to share a data subject's information, whether it comes from a product feature, a support workflow, an integration or an internal team, arrives at the gate with at least three facts attached: the data subject, the recipient and the purpose. The gate does not decide anything on its own. It looks up the consent record for that exact data subject and recipient, and it refuses the disclosure unless a valid record shows that the data subject explicitly agreed before the disclosure happens. The diagram on this page shows each hop of that flow.
The consent record is the object the gate depends on, so its design matters more than its appearance. Each record should hold the data subject identifier, the named third party or category of recipient, the purpose the data subject agreed to, the wording or version of the notice shown at the time, the channel through which consent was given, and an expiry or withdrawal field. Organizations running self-hosted platforms often store these records in the same database as the user profile, which keeps the join simple but means that access to the profile also exposes consent history. Confirm with your architects where the record lives, who can write to it, and whether a withdrawal takes effect at the gate immediately.
Whatever the gate decides, it writes a log entry with the request, the decision, the reason code and a timestamp in a store that application administrators cannot edit. That log is the evidence an assessor will sample for P6.1, and it also feeds the authorized disclosure record covered under P6.2. Test the flow before the observation period starts: send a disclosure request with no consent, with withdrawn consent and with valid consent, then confirm that the first two are refused, that the third is logged, and that the timestamps order correctly against the consent event. Keep those test results as dated evidence.
How DeployOpen scopes and prepares P6.1 evidence
DeployOpen works on P6.1 as an implementation and readiness partner inside your own infrastructure. We prepare the systems, disclosure controls and records that show personal information goes to third parties only after explicit consent, while your organization owns the control and the independent auditor issues any report.
How we scope
- Agree in writing which systems, data flows and third-party recipients fall within the P6.1 boundary.
- Confirm which consent mechanisms and disclosure points the organization already operates today.
- Define deliverables, responsibilities and timelines before any work starts, since engagements are fixed-scope.
How we build
- Configure self-hosted platforms so disclosures are gated on a recorded, pre-disclosure consent state.
- Document the disclosure workflow, including how new purposes trigger a fresh consent request.
- Test the consent gate and disclosure logging against the scoped design before handover.
How we hand over
- Deliver the control design, configuration records and sample evidence for the auditor to review.
- Provide runbooks showing how staff approve, log and stop a third-party disclosure.
- Confirm with your auditor which evidence formats and sampling periods they expect for P6.1.
How we support
- Offer ongoing support and periodic review of consent and disclosure controls as a retainer.
- Update configurations and documentation when new third-party recipients or purposes are added.
- Support your team during fieldwork questions, while the auditor alone forms and issues the opinion.
