What PT-4 consent requires before PII is collected
PT-4 requires the organization to define the tools or mechanisms that let individuals consent to the processing of their PII before it is collected, and those mechanisms must support informed decisions. If you are preparing a privacy baseline assessment, the first question is not whether a consent banner exists but whether your organization has documented which mechanisms it uses, where they appear in each collection path, and how they explain what the individual is agreeing to. PT-4 sits only in the privacy control baseline described in SP 800-53B. SP 800-53B does not allocate it to the low, moderate or high security baselines, so it applies to a system regardless of its impact level. The three enhancements, which cover tailored consent, just-in-time consent and revocation, are not allocated to any SP 800-53B baseline. Your assessment scope should still record whether you have chosen to implement them, because an assessor will ask why a given mechanism does or does not offer them.
The risk this control addresses is that individuals lose informed choice over their own data. When a system collects PII through web forms, mobile apps, call center scripts, partner APIs and batch imports, a consent statement shown in one channel may never reach the others, and a person may agree to a purpose they never saw. The difficulty grows with each new intake point, which is why consent is often inconsistent across a platform even when the policy text is sound. Before the assessment, inventory every collection point that touches PII and note which ones rely on consent at all. For each one, confirm which consent mechanism applies, who maintains its wording, and how a change to the purpose is communicated. Confirm these details with your privacy office and system owners rather than assuming the answers from the policy alone.
Your implementation partner can help prepare the evidence, such as consent screen captures, configuration exports and records of how consent is captured and stored, but the organization owns the decision about which consent model fits its legal and business obligations. Only an independent assessor can report on whether PT-4 is met. Ask any partner to describe, in writing, which collection paths they will document and which evidence they will produce for each.
Which systems and data PT-4 consent applies to
PT-4 only matters where individuals are asked to agree to processing of their PII. The scoping work is deciding which systems collect PII directly, which collect it through third parties or embedded components, which receive it from other systems, and where consent is not the legal basis at all.
Systems that collect PII directly
Start with every system that presents a form, sign-up flow, app screen or intake portal to an individual. Each one is a candidate consent point, and each needs a documented decision on whether consent is the mechanism for the processing that follows. Record the data elements collected at each point, because consent wording and options must match what is actually gathered. Assessors will expect the consent presentation to be traceable to a specific collection path.
Third-party and embedded collection points
Analytics scripts, payment widgets, chat tools, identity providers and embedded forms often collect PII on your behalf without appearing in your application code. Inventory them, confirm which party controls the collection and the consent interface, and decide who presents the consent. Where a vendor runs the interface, the contract and configuration must still support PT-4 outcomes, and you should confirm this with the vendor rather than assume it.
PII received from other systems
Many systems hold PII that was never collected from the individual directly, such as records imported from a partner, a data warehouse or a legacy platform. Consent presented at the original collection point may not cover the new processing. Map these data flows, identify the consent record that governs each one, and flag flows where no individual-facing consent exists so they can be routed to another control or authority decision.
Where consent is not the legal basis
Where processing relies on a legal obligation, a contract, a public task or another authority, a consent prompt can mislead individuals into thinking they can withdraw agreement that does not exist. Document the authority for each processing activity first, using the PT-2 analysis. Where consent is not the basis, the consent mechanism may be the wrong control, and the work shifts to notices and purpose limits under PT-5 and PT-3.
Privacy baseline applies at every impact level
SP 800-53B does not allocate PT controls to the low, moderate or high baselines. PT-4 sits in the privacy baseline, which applies regardless of the system's security impact level. A low-impact system holding PII is still in PT-4 scope, so confirm the privacy baseline for each system rather than relying on its security categorization.
Related controls that shape scope
AC-16, PT-2 and PT-5 change what PT-4 must cover. AC-16 governs security and privacy attribute handling, PT-2 determines the authority that permits each processing activity, and PT-5 requires privacy notices that must be consistent with the consent presented. Confirm these boundaries with your assessor early, since a gap in PT-2 or PT-5 often surfaces as a PT-4 finding.
How an assessor tests PT-4 consent
The examine method has the assessor review documents, mechanisms and displays against the PT-4 determination statement. SP 800-53A, available at NIST SP 800-53A Rev. 5, lists three kinds of assessment objects to examine: consent policies and procedures, consent tools and mechanisms, and consent presentation or display. The assessor compares what the organization says it does with the artifacts that show it happens.
- Consent policies and procedures: the written rules that state when consent is required, who may grant it, how decisions are recorded and how individuals withdraw them.
- Consent tools and mechanisms: the configured forms, preference stores, consent interfaces or APIs that capture a decision and link it to a record.
- Consent presentation: rendered pages, screenshots and the exact wording shown to individuals, including whether choices appear before any PII is collected.
- Version history: dated copies of consent text showing which wording was live during each collection period.
Check that every document the policy names exists, is approved, and matches what the interface actually displays.
The interview method has the assessor talk with personnel who hold PT responsibilities for the system. For PT-4, SP 800-53A points to organizational personnel with personally identifiable information processing and transparency responsibilities. Interviews test whether people understand the consent process well enough to run it, and whether their accounts match the written procedures and the configured system.
- Privacy office: explains which processing activities depend on consent and which rely on another authority.
- Product and engineering owners: describe how a consent decision reaches downstream systems and how a change to consent wording is approved.
- Support and operations staff: describe how withdrawal requests arrive, who acts on them and how quickly the organization records that action.
- Consistency of answers: assessors compare responses across roles and against the documents, so gaps between them often become follow-up questions.
Before the interviews, confirm that each interviewee can name their PT responsibilities and show where consent records are stored.
The test method has the assessor exercise the organizational processes for collecting PII and observe the outcome. SP 800-53A lists organizational processes for the collection of personally identifiable information as the assessment object for testing. The assessor is looking for proof that consent is obtained before collection and that the organization's own rules hold when someone declines.
- Walkthrough of a collection path: following a form or integration from the first screen to the point where data is stored.
- Pre-collection ordering: confirming that the consent decision is captured before any PII is written to a database, queue or log.
- Decision handling: confirming that declining consent stops or changes collection in the way the procedures describe.
- Recorded decisions: checking that each decision is stored with a timestamp and the consent text version in effect.
Illustrative example: an assessor submits a test profile in a non-production environment and checks that the consent prompt appears first, that a refusal blocks storage, and that the decision appears in the record. Confirm in advance whether the assessor will test in production or in a copy of it.
Assessment is divided between two parties. The organization owns PT-4 and supplies the evidence. The assessor decides whether the determination statement is satisfied and issues findings. An implementation partner such as DeployOpen can prepare the systems, configuration and evidence collection, but it does not issue assessment reports, findings or certifications.
- Assessor role: reviews the evidence, runs the examine, interview and test steps, and reports whether the objective is met.
- Organization role: supplies policies, configuration exports, screenshots, logs, version histories and access to the people who run consent processes.
- Implementation partner role: can set up consent mechanisms, document them and organize evidence, while the organization remains accountable for the control.
- Unmet objectives: a gap becomes a finding. Under the organization's risk management program it is usually tracked in a plan of action and milestones, and the assessor should confirm how it will be recorded.
Ask the assessor, before work starts, which evidence formats and sampling approach they expect for consent records.
Implementing PT-4 consent in a self-hosted system
This sequence takes PT-4 Consent from an inventory of PII collection points to a documented, tested consent mechanism that runs inside the client's own infrastructure. Each step produces an artifact an assessor can examine, interview against and test.
Inventory PII collection points
The organization, with DeployOpen supporting the technical discovery, lists every system, form, API, batch feed and mobile or web interface that collects personally identifiable information from individuals. For each point, record the data elements, the purpose, the data subjects and whether collection is voluntary. The step closes when the inventory is reviewed by the privacy office and system owners and each entry has a named owner. Confirm the scope of the inventory with your privacy office before technical work begins, since it defines what the rest of the sequence covers.
Define consent decisions and informed-choice content
For each collection point, the privacy office decides which processing activities need consent, which rely on another authority, and which choices an individual can make, such as opting in to optional uses or declining marketing. The team then drafts the plain-language text that tells the individual what is being processed, why, who receives it, how to withdraw, and what happens if they decline. The output is a consent specification that lists each decision, its wording, its version identifier and its link to the privacy notice. The step is done when the specification is approved and each decision maps to a documented purpose.
Select or build the consent mechanism
The team chooses between a self-hosted consent management component, an extension of an existing identity or customer platform, or a small internal service, and deploys it inside the client's cloud account, data center or air-gapped network. Requirements include storing consent records in the organization's own database, supporting per-purpose decisions, and exposing an interface for collection flows. The output is an architecture decision record and a deployed, hardened instance with access controls and logging enabled. Confirm with the vendor or project maintainer exactly which consent features the chosen component supports before committing to it.
Wire consent into collection flows before storage
Engineers connect each collection point to the consent mechanism so that the consent decision is captured and checked before personal data is written to any store. The configuration ensures that a decision not yet recorded blocks the write, and that the consent version presented is the one stored with the record. Engineers also confirm that downstream jobs and integrations honor the recorded decision. The output is a set of configuration files, code changes and an integration map kept under version control. The step closes when a reviewer can trace each stored PII field back to a consent decision.
Record consent and revocation events
The mechanism logs each grant, refusal, change and revocation with a timestamp, the individual's identifier, the decision, the consent text version and the collection point. Revocation must propagate to the systems that rely on the consent, so engineers define how each downstream store is stopped or restricted. The output is an event schema, a retention rule for consent records, and a documented revocation workflow. The step is complete when a test revocation reaches every dependent system and appears in the audit trail.
Test consent presentation, capture and revocation
An independent tester, either a DeployOpen engineer on a separate environment or the client's internal assessment team, runs scripted scenarios covering informed decisions, declined consent, withdrawal, changed notice versions and failed writes. The tester checks the user interface text against the consent specification and confirms that no PII is stored without a valid decision. The output is a dated test record with scenarios, expected and actual results, screenshots and defects with remediation status. The step closes when all high-impact defects are fixed and retested.
Document the consent procedure
The privacy office and engineering leads write the procedure that describes how consent is requested, recorded, changed, revoked and reviewed, including roles, escalation paths and review intervals set by the organization. The procedure references the inventory, the consent specification, the architecture record and the test records so an assessor can follow the chain of evidence. The output is an approved procedure document with version history and an owner. Ask the auditor or assessor early which documents they expect to examine for PT-4, since the assessment procedure lists consent policies, tools, presentation and process testing as examine and test items.
Evidence that passes a PT-4 consent test
An assessor testing PT-4 looks for proof that consent mechanisms exist, that they are presented before collection, and that they work as written. The cards below list the artifacts that show this, and how to keep them accurate as collection points change between assessments.
Consent policy and procedure
The written policy defines which processing activities require consent, who owns the consent mechanisms, and how individuals are informed before they decide. Assessors examine it against the consent tools actually deployed, so every stated mechanism should map to a live screen, form or workflow. Check that the document names a review owner and a review cycle, and that its version history matches the last change to any collection point.
Captured consent presentations
Keep a dated screenshot or captured text of every consent prompt, checkbox, banner and form wording the system shows before collection. The capture should show the full information the individual sees, including the purpose statement and any link to the privacy notice. Store each capture with the release or page version it came from, so an assessor can match what was displayed to the processing that followed.
Consent records with notice version
Each consent decision should create a record containing the individual's identifier or pseudonym, the processing purpose consented to, the choice made, a timestamp and the version of the notice shown. Records without a notice version make it impossible to prove what the person was told. Ask the platform owner to confirm which fields the consent store writes and how long records are retained.
Revocation test records
Test that withdrawing consent stops the associated processing and is reflected in downstream systems. Record the test steps, the date, the tester, the system state before and after revocation, and any processing that continued and needed correction. Repeat the test whenever a new downstream system receives the data, because a revocation that reaches one store but not another fails in practice.
Interview notes from PT staff
Assessors interview personnel with privacy and transparency responsibilities about how consent is obtained and handled. Keep dated notes of who was interviewed, their role, and the answers that confirm the documented process. Compare the answers with the captured presentations and records, since a gap between what staff describe and what the system does is a common finding.
Change log for collection points
Maintain a register of every collection point, such as web forms, mobile screens, call scripts and API intake, with its owner and the date of its last consent review. Each new or changed collection point should trigger a re-capture of the presentation and an update to the register. This keeps the evidence current between assessments without rebuilding it from memory at audit time.
What meeting PT-4 consent costs in money and effort
This table breaks down the cost components of meeting PT-4 Consent, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to shape a written scope and to ask providers and assessors specific questions before work starts. No fixed figures are given because none are supplied for this control, so the main takeaway is that open-source platforms remove license spend but not the engineering, legal and evidence effort.
| Cost component | Who is paid and for what | One-time or recurring, and what drives it |
|---|---|---|
| Consent design and legal review | Privacy counsel and privacy staff define consent purposes, wording and choices | One-time for initial design, recurring when processing changes. Drivers: number of processing purposes, jurisdictions and sensitivity of PII |
| Engineering to build or configure mechanisms | Platform engineers or an implementation partner configure consent capture, storage and presentation in the self-hosted platform | Mostly one-time, with recurring changes. Drivers: number of collection points, custom user interfaces and integrations with existing identity systems |
| Tailored and just-in-time consent build-out | Engineers and designers implement the enhancements the organization selects | One-time per collection point. Drivers: how many forms, apps or data flows need contextual prompts |
| Consent record storage | Infrastructure and database administrators run and back up the consent record store | Recurring. Drivers: volume of users, retention period set by policy, and backup and encryption requirements |
| Evidence upkeep | Compliance or privacy staff collect consent policies, screenshots of displayed consent and configuration exports | Recurring. Drivers: how often consent text changes and how many systems must be evidenced |
| Testing of revocation and consent presentation | Internal testers or a security testing provider verify that withdrawal of consent stops processing | Initial test plus recurring retests after changes. Drivers: number of processing paths that must honor revocation |
| Assessor effort | Independent assessor examines consent policies, tools and interviews staff, billed under their own engagement terms | Recurring at each assessment cycle. Drivers: system scope, documentation quality and number of interviews |
| Open-source license spend | Usually none for the platform itself, but support subscriptions or hosting may still apply | Recurring if support is purchased. Ask providers to separate license, hosting and labor lines in the quote |
Who owns PT-4 consent and what partners can take on
The organization owns PT-4 because the consent decisions are its decisions. It determines what individuals are asked to agree to, why, and under which legal or other authority, and it is accountable to individuals and regulators for how those choices are honored. Privacy counsel, the privacy office and the business owner of each processing activity usually shape the consent wording, while the security and engineering teams are responsible for making the mechanism work as written.
- Consent policy and procedures: Document when consent is the basis for processing, when it is not, and who approves changes to consent text.
- Consent wording: Own the language presented to individuals, including the purposes and the consequences of agreeing or declining.
- Legal basis: Confirm with counsel that consent is the correct authority for each activity, since PT-2 and PT-3 may point to a different basis.
- Revocation rules: Decide how withdrawal is handled and how long downstream processing may continue after it.
- Sign-off records: Keep approvals for each consent version so an assessor can trace a presented notice to an approved decision.
Before relying on the tab, confirm with privacy counsel which laws and contracts apply to your consent obligations, because the NIST control states the outcome but does not supply the legal test.
An implementation partner can build and configure the systems that present consent, record decisions and enforce revocation, and it can assemble the evidence that shows those systems behave as the organization's policy describes. DeployOpen works this way: it prepares systems and evidence inside the client's own infrastructure under a written scope. It does not decide the consent wording, approve the legal basis or issue any assessment result.
- Mechanism build: Configure self-hosted consent or preference components in the client's environment, with consent presentation in the user interface.
- Decision records: Store each individual's choice, the consent version shown and the time of the decision in a tamper-resistant log.
- Revocation testing: Test that withdrawal stops the relevant processing and propagates to connected systems, and keep the test results.
- Evidence packs: Export configuration, screenshots of each consent variant, test logs and change history for the assessor.
- Gap reports: Report where the mechanism cannot yet match the approved policy so the organization can decide how to close the gap.
Before engaging a partner, ask for the written scope, the evidence list and who receives the test results, and confirm that the partner will not sign or attest to control effectiveness on the organization's behalf.
The independent assessor examines the PT-4 implementation against the assessment procedure in SP 800-53A and reports findings. The assessor is independent of the people who built and operate the system, which is what gives its conclusions weight. Depending on the authorization or contract, the assessor may be an internal independent team, an external firm or an approved third party, and the organization should confirm which one its requirement accepts.
- Examine: Review the consent policies, the consent tools and mechanisms, and the consent presentation in the user interface.
- Interview: Speak with the personnel who hold PII processing and transparency responsibilities to confirm they understand the consent process.
- Test: Observe the organizational process for collecting PII, including the consent step and a revocation request.
- Findings: Record satisfied or not satisfied results and the basis for each, which the organization then tracks in its plan of action and milestones.
- Independence: Keep assessment work separate from the implementation work so the results are not shaped by the team that configured the system.
Before accepting an assessor, confirm the report format the authorizing body expects and whether that assessor's results are recognized for the contract or regulation in question.
Where PT-4 consent programs usually fall short
Most PT-4 consent gaps are not missing checkboxes. They are records that cannot show which notice a person saw, consent that covers more than the person could reasonably understand, and revocation or testing that exists only on paper. The cards below cover six gaps an assessor is likely to probe, each with a closing action your team can check before the assessment starts.
Consent recorded without the notice version
The consent log stores a timestamp and a user identifier, but not the version of the notice or consent text the person actually saw. When the wording changes, the organization cannot show what a given person agreed to. Check that each consent record stores the notice version, the presentation channel and the purposes listed at the time of consent, and that old versions remain retrievable. Close the gap by versioning every consent text and writing its identifier into each record.
Bundled consent that is not informed
A single acceptance button covers marketing, analytics, sharing with third parties and core service use. PT-4 expects individuals to make informed decisions, and a bundled choice removes the option to refuse one purpose while accepting another. Review each consent screen and ask whether a person could decline a single purpose and still use the service. Close the gap by separating optional purposes into individual choices and keeping required processing out of the consent request.
No working revocation path
Consent can be given in the app but can only be withdrawn by emailing support, and the withdrawal is applied in a nightly batch that nobody monitors. The control expects a defined mechanism for individuals to change their decisions, so a withdrawal that does not reach downstream systems leaves processing continuing without authority. Test withdrawal end to end, including the systems that received the data. Close the gap by documenting one revocation mechanism, timing its propagation and testing that downstream processing stops.
Consent tied to one form while PII flows through APIs
The consent capture lives in a web form, but personal data also arrives through mobile SDKs, partner APIs, batch imports and call center tools. Processing that never passes the form has no recorded consent, even when the purpose is the same. Map every intake path that collects PII, then confirm each one checks the consent state before processing. Close the gap by inventorying all collection paths and enforcing the consent check at the API layer, not only in the front end.
Just-in-time prompts missing for new purposes
The organization obtains consent at sign-up for the purposes it knew then, and later starts using the same data for a new analytics or model-training purpose without asking again. Tailored and just-in-time consent exist as enhancements because purposes change after collection. Review whether any new processing purpose in the past year triggered a new consent request. Close the gap by linking every new processing purpose to a consent decision before the purpose goes live.
No tests or evidence that consent works
The consent policy and screens exist, but no one has tested whether consent is captured, enforced and withdrawn as described. Assessors examine consent tools and mechanisms, interview the people who run them and test the collection processes, so untested claims are weak evidence. Keep test cases, dated results and defect tickets for each consent path. Close the gap by running scripted consent tests on every release and retaining the results as assessment evidence.
PT-4 consent questions buyers ask
What does PT-4 consent cost to implement?
No public figure exists for PT-4, and the cost depends on how much consent machinery your systems need, not on the control label itself. Cost comes from four components: internal staff time for defining consent purposes and wording, engineering time to build or configure consent capture and storage, legal or privacy counsel review of notices and consent language, and independent assessment fees paid to an assessor who tests the control. Most of the spend is one-time build work. Recurring costs include reviewing consent wording when processing changes, maintaining the consent record store, and retesting after releases. Ask any partner for a quote that separates these components and states which items are one-time and which recur.
What drives the effort for PT-4 consent work?
Effort rises with the number of distinct PII processing purposes, the number of systems that collect PII, and how many of those systems already have a consent interface. A system that collects one data type for one purpose needs a single consent point. A system that serves many purposes, shares data with third parties, or changes its processing often needs per-purpose choices, a way to record each decision with a timestamp and version, and a way to honor withdrawals across downstream systems. Enhancements such as tailored consent and revocation add build and test work. Organizations with a clear inventory of PII flows usually scope faster because they know which consent points are needed.
How long does PT-4 consent implementation take?
Timing depends on scope, so confirm it in the written scope before work starts. A fixed-scope engagement from DeployOpen states its deliverables and timeline in writing before work begins, and that document is the reliable source for dates. The duration is driven by how many systems need consent mechanisms, whether the consent interface already exists, how long your legal team takes to approve wording, and how quickly test evidence can be produced for the assessor. Plan for the consent wording review to run in parallel with engineering, since approval of text is often the longest external dependency.
What does my team need to provide for PT-4?
Your team owns the control, so it must supply the decisions and the facts that an implementation partner cannot invent. That includes the list of PII processing purposes, the legal basis or authority for each purpose, the consent wording approved by privacy or legal counsel, and the systems and data flows that collect PII. You also need named owners for the consent policy and for consent records, access to the systems being changed, and staff available to answer questions during testing. Assessors will interview personnel with PII processing responsibilities, so those people must be identified and available. Missing inputs are the most common cause of delay.
Can we implement PT-4 consent in-house?
Yes, an organization can implement PT-4 with its own staff, provided it has privacy, engineering and assessment skills in place. The control itself is a requirement for defined consent tools or mechanisms that support informed decisions, so the work is largely configuration, interface design and records management rather than specialized tooling. In-house teams often struggle with independence, because the people who build the consent flow are also the people who would test it. An outside implementation partner can prepare systems and evidence, but only an independent assessor can test the control and issue findings. Decide early which parts your staff will own and which you will outsource.
Does PT-4 apply to a low-impact system?
Yes, if the system processes PII, because PT-4 sits in the privacy control baseline and that baseline applies regardless of impact level. The SP 800-53B baselines for low, moderate and high systems do not allocate PII Processing and Transparency controls, so a low-impact system that processes PII is still expected to address PT-4 through the privacy baseline. Confirm the baseline selection with your authorizing official or compliance lead, and document the reasoning in the system's privacy artifacts. A system that processes no PII has no consent obligation under this control.
How does PT-4 consent differ from PT-5 privacy notice?
PT-4 requires mechanisms that let individuals consent before collection and make informed decisions, while PT-5 requires notices that inform individuals about how their PII is processed. A privacy notice is a document or disclosure, and it may support consent, but it does not by itself capture a decision. PT-4 asks for a working consent tool or process that records the individual's choice. Both controls draw on the same purposes and authority, so the consent text and the notice should be written from one approved source. Assessors examine them separately, with consent presentation and records for PT-4 and notice content and availability for PT-5.
What evidence shows PT-4 consent is working?
Evidence should show the consent mechanism exists, presents information clearly, and records each decision. Useful artifacts include the consent policy and procedures, screenshots or exports of the consent interface, a sample of consent records with timestamps and versions, and test results showing a withdrawal takes effect. Assessors examine consent tools and presentation, interview personnel responsible for PII processing, and test the organizational process for collecting PII. Keep the evidence tied to specific systems and dates so that it remains usable at reassessment. Confirm the exact artifacts your assessor expects before building the evidence package.
How DeployOpen scopes PT-4 consent work
DeployOpen scopes PT-4 work in writing before any build starts. The scope names the systems that collect PII, the consent points each one exposes (sign-up forms, account settings, mobile prompts, API intake), the consent policy the organization already owns, and the mechanisms that will record and enforce a choice. Deliverables and timelines are agreed in the same document, and changes to scope are handled by written amendment. Because PT-4 sits in the privacy baseline, the first decision is usually whether the privacy program owner, not the platform team alone, signs off on which processing activities need consent at all. Confirm that owner and their sign-off step before the scope is finalized.
Implementation happens inside the client's own cloud accounts, data center or air-gapped network. DeployOpen configures the consent capture and storage components on self-hosted open-source platforms, wires them to the identity and data stores that hold the PII, and tests that a withdrawal of consent actually stops downstream processing rather than only updating a flag. The evidence package is prepared alongside the build: the consent policy and procedures, configuration exports, screenshots or rendered text of each consent display, test records for collection and revocation, and a mapping from each artifact to the assessment objects in SP 800-53A. Ask the platform owner which of these artifacts they can export directly and which must be captured manually, since that choice drives the effort on both sides.
Handover covers runbooks, configuration documentation and the evidence index, so the organization's staff can answer an assessor's questions without DeployOpen present. Ongoing support, upgrades and periodic re-testing of consent flows are available as a retainer, which is usually the right model when consent text or processing purposes change often. DeployOpen does not issue assessment reports or attestations. The organization's independent assessor decides whether PT-4 is met, and the organization owns the control, its policy and the decision to accept any residual gap. Before signing, ask the assessor which evidence formats they accept so that the package is built to their expectations.
