What P1.1 privacy notice asks for when a SOC 2 includes privacy
If your SOC 2 includes the privacy category, criterion P1.1 asks whether your organization gives data subjects notice of its privacy practices and updates that notice promptly when those practices change, including when the way personal information is used changes. The criterion is the only one in the P1 notice group, and it is tested only when privacy is in scope. The risk it addresses is simple: a customer or individual agrees to one set of practices, and the organization quietly runs another. The reader's immediate question is whether the published notice still describes what the systems actually do with personal information today.
In practice, the difficulty is that notices are usually written once, by legal or marketing, and then never revisited. Product teams add analytics, connect a new subprocessor, train a model on support tickets or retain logs longer for debugging, and nobody routes that change back to the notice. An assessor will look for a current notice that is easy to find, covers the entities and activities involved, and is reviewed on a set schedule. They will also look for evidence that changes to use trigger a review before release, that the notice was communicated to affected parties, and that prior versions were kept. Confirm with your auditor which evidence they expect for your notice and which change triggers they will sample.
A practical first step is to compare the published notice against a current data inventory, then list every new use since the last review. Keep the notice in a version-controlled wiki or document system so each revision records what changed, when and by whom, and restrict edit rights to a named owner through role-based permissions. Set a recurring review, and add a checkpoint to the change process so that any proposed new use of personal information is assessed against the notice before deployment. Ask your CPA firm whether the review evidence and the version history will satisfy the criterion for the period under examination.
Which systems, data and teams fall under the P1.1 privacy notice
Before writing or testing a privacy notice, the organization has to decide where personal information lives, which notices describe it, and who changes them. Each of the cards below is a scoping decision that changes how much work P1.1 creates and how an auditor will sample it.
Services and data stores holding personal information
Start with an inventory of every production service, database, log store, backup and analytics pipeline that holds personal information, including data collected from customers' end users. The notice must describe the entities and activities involved, so an incomplete inventory produces a notice that omits real processing. Check the inventory against data flows, not only against the architecture diagram, and record which systems are in the SOC 2 system boundary.
Public-facing notices across every channel
List each place a data subject meets a privacy statement: the public website, the web and mobile apps, sign-up and onboarding flows, in-product consent prompts, order forms and master service agreements. A notice that is current on the website but outdated in the app is a common finding. Assign each notice an owner and confirm which versions are live at the audit date.
Teams that publish and change notices
Identify who drafts, approves, publishes and retires each notice, usually legal or privacy, product, marketing and engineering. Product teams often introduce new uses of personal information, such as model training or new analytics, without routing them to the notice owner. Write down the trigger for a notice update and the sign-off path, because P1.1 depends on changes being communicated promptly.
Subservice organizations that process personal information
Map each subprocessor, such as a hosting provider, payment processor, email platform or support tool, that handles personal information for the organization. The notice should cover the categories of these third parties and the activities they perform, so a new or replaced subprocessor is a change that may require an update. Confirm how the organization learns of subprocessor changes and how those changes reach the notice.
Self-hosted platforms that store notice history
When notices and their revision history are kept in a self-hosted wiki or documentation platform, confirm that prior versions are retained and that changes are attributable to a person and a date. Version history supports the criterion's expectation to retain prior notices. Test restoring an earlier version and confirm access permissions limit who can publish, so the record stays trustworthy during an examination.
How an assessor tests the privacy notice
This table sets out how a SOC 2 assessor typically tests P1.1, step by step, with the evidence requested and the findings that most often lead to exceptions. Read it as a checklist for what your notice, change records and version history must show before fieldwork begins.
| Test step | What the assessor does | Evidence requested | Common finding |
|---|---|---|---|
| Read the published notice | Compares the notice text against the system description and the data flows the examination covers | Current published privacy notice, system description, data inventory | Notice describes a product or data flow that the system no longer uses |
| Check entity and activity coverage | Confirms the notice names the entities, services and data activities in scope, including subservice organizations where relevant | Notice text mapped to in-scope services, list of entities and activities | Notice omits a service added after the notice was last reviewed |
| Check clarity and findability | Judges whether the notice is written in clear language and is easy for data subjects to locate | Location of the notice on the website or in-product, review record for wording | Notice is buried in a footer link or written only in legal jargon |
| Sample change events | Selects a sample of changes to data use, categories or recipients and traces each to a notice update and communication | Change log, product or data-use change tickets, notice revision dates, communication copies such as emails or banners | Change in data use shipped with no matching notice revision |
| Test promptness of updates | Compares the date a practice changed with the date the notice was updated and communicated | Dated change tickets alongside dated notice versions and notification records | Gap between change and notice update with no documented reason |
| Check undocumented changes in use | Looks for new uses of personal information, such as analytics or model training, that appear in engineering records but not in the notice | Engineering changelogs, data processing records, vendor onboarding records | New data use by a third party with no review by the privacy owner |
| Check retention of prior notices | Confirms earlier notice versions are kept so the organization can show what data subjects were told at each point | Archived prior versions with effective dates, version history showing who approved each change | Only the current notice exists, so past versions cannot be reconstructed |
| Review version history | Checks that revisions record what changed, when and by whom, and that the approval trail is complete | Version history export, approval records, reviewer sign-offs | Revisions overwritten in place, or approvals recorded only in chat |
How a change in data use triggers a notice update
P1.1 is about timeliness and communication, so the notice has to move when the way personal information is handled moves. A change in practice is any change that alters what the notice says: a new purpose for using personal information, a new recipient or category of recipient, a new category of personal data collected, or a new or shortened retention period. Product changes often carry these changes without anyone calling them privacy changes. A new analytics vendor, a model trained on customer records, a new integration that sends profile fields to a partner, or a shift in log retention can each change the notice, so the trigger should sit in the change process rather than in a privacy team's memory. Product, engineering and operations owners should flag any proposed change that touches personal information, and the organization should decide in advance which changes always require a review.
Someone accountable must decide whether the notice needs updating, and that decision should be written down. In most organizations this is the privacy or compliance owner, with legal counsel confirming wording where jurisdiction requires it. The organization owns the notice and its legal accuracy; an implementation partner or auditor can help build the workflow and test it, but neither decides what the notice must say. Record each trigger with the change ticket, the date, the reviewer, the decision (update or no update, with reasons), and the date the revised notice was published. Keep prior versions of the notice so the auditor can see what applied at each point in time. Confirm how your wiki or document tool stores version history and who can approve edits before you rely on it as evidence.
The points of focus for P1.1 cover reviewing the notice and communicating changes, but the criterion does not prescribe a fixed review cycle. An annual review that misses a mid-year change does not satisfy the criterion, and a quarterly review does not help if changes reach customers weeks late. Test the trigger by picking recent product or vendor changes and tracing each one to a notice decision and, where an update was made, to the date it was communicated. Discuss with your auditor how they will sample these changes before fieldwork, because gaps in the trigger record are the most common reason a notice finding becomes an exception.
How to implement P1.1 in a SOC 2 program
This sequence turns P1.1 from a policy statement into a notice that matches real data flows, has a named owner, is published where data subjects can find it, and leaves a dated trail of every change that an auditor can sample.
Inventory personal information flows
Start by mapping where personal information enters the system, where it is stored, which processes use it, and which third parties receive it. The engineering lead and product owner usually do this work with the data owner, and the output is a flow inventory that lists each category of personal information, its source, its purpose and its recipients. Treat the inventory as complete only when someone outside the working group has checked it against the production data stores and integration list. Illustrative example: a support tool that stores customer email addresses may appear in the inventory only after the team confirms it receives copies from the billing system.
Draft the notice against the system description
Write the privacy notice so that it matches the system description management prepares for the SOC 2 examination. Compare each statement in the draft with the flow inventory and the system boundary, covering the entities and activities involved, and remove any claim the system does not support. Legal or privacy counsel typically reviews the wording, while the security or compliance lead confirms that the description is consistent with the controls. Ask counsel to confirm the notice meets any law that applies to your customers. The output is a reviewed draft with a record of who approved which statements.
Assign an owner and change triggers
Name one accountable owner for the notice and write down the events that require a review, such as a new data category, a new subprocessor, a new purpose for existing data, or a change in where data is stored. Connect these triggers to your change management and vendor onboarding workflows so that a change to a flow cannot ship without reaching the notice owner. The output is a short ownership record and a trigger list that the team can show an auditor when asked how changes to practices reach the notice.
Publish and link the notice
Publish the approved notice on a stable, public page and link it from the product, the sign-up flow and the contracts that describe data use. Check that the language is clear, the page is current and the link works from each entry point. Keep the published version and its publication date in your document system so you can show what was live on a given day. The output is the live notice, a list of the places that link to it, and a dated screenshot or export of the published version.
Record each revision with its change history
Each time the notice changes, record what changed, when the change took effect and who approved it. A document platform with version control, such as the wiki or knowledge base your team already runs, can hold this history if you configure page ownership and edit rights correctly. Use the diff between versions as the change record, and write a short summary for anyone reading the log later. The output is a revision log that answers what changed, when and by whom for every edit.
Communicate changes and retain prior notices
When practices change, communicate the updated notice to affected data subjects in the way your contracts and the notice itself describe, and keep every prior version so the organization can show which notice applied during each period. Restrict who can publish or roll back the notice through role-based permissions, and check that only the owner or delegates can change the live page. The output is a notice archive with dated versions and a record of how each change was communicated.
Run a periodic review and sample the evidence
Review the notice on a schedule you set in the policy and whenever a change trigger fires, comparing it with the current flow inventory and system description. Sample a few past changes to confirm the revision log, approvals and communications are complete. Confirm with your auditor which review cadence and sample sizes they expect before fieldwork, because those expectations shape how much history you need to retain. The output is a dated review record that shows the notice still matches practice, or a corrective change if it does not.
Which evidence passes P1.1 and how to keep it current
The auditor's first question is whether the notice a data subject sees today describes what the organization actually does. Evidence here is the live notice, captured with its publication date and the location where data subjects find it. The notice should name the entities and activities it covers, use plain language, and be linked from places where people provide personal information, such as sign-up forms, account settings and the public website footer. Confirm with your counsel and auditor which locations they will accept as the canonical notice before the observation period starts.
- Dated capture: Keep a dated copy or screenshot of the published notice at each review, so the auditor can see the version in force on a given day.
- Stated scope: Confirm the notice names the entities, products and data flows it covers, including any self-hosted or customer-deployed component.
- Findable placement: Record the links from sign-up, account and footer pages, and recheck them after each site release.
- Plain language: Have a reviewer who is not on the privacy team confirm the notice reads clearly to a typical user.
Before each audit, compare the live notice against the current system description and check that every link still resolves.
A revision history shows when the notice changed, what changed, why, and who approved it. Auditors use it to match notice dates against the dates practices changed, so gaps in the history become exceptions. A wiki or document system with version control can hold this record if edits are restricted to approved roles and every version is retained. XWiki, for example, keeps each change under version control, recording what changed, when and by whom, and lets users compare versions and roll back. Versioning alone does not prove approval, so the approval step needs its own record.
- Change log entries: Record the date, the editor, a short summary of the change and the reason it was made.
- Approval record: Store the sign-off from privacy, legal or the accountable owner next to each version.
- Restricted editing: Limit who can publish notice changes, and keep that list in your access review evidence.
- Diff capture: Keep the comparison between consecutive versions so the auditor can see exactly what changed.
- Quarterly check: Confirm that every production change to personal information handling has a corresponding log entry.
Before each audit, sample two or three recent changes and trace each one from the product change to the log entry to the approval.
P1.1 requires the organization to communicate changes to the notice promptly, so the record of communication is evidence in its own right. The record should show which audiences were told, when, through which channel, and what the message said. Channels may include email to account holders, in-product banners, release notes or notices to customers who self-host the software and must pass changes to their own users. Ask counsel which channels and lead times your contracts and applicable law require, and document the answer rather than assuming it.
- Audience list: Record who received each notice, such as all account holders, enterprise administrators or self-hosting customers.
- Timing record: Store the send date or publication date and compare it with the effective date of the change.
- Message copy: Keep the text or template of each communication, not only the fact that one was sent.
- Delivery evidence: Retain email logs, banner configuration or release note links that show the message reached its audience.
- Customer flow-down: For self-hosted deployments, keep the notice you provided to customers so they can show their own users were informed.
Before each audit, confirm the communication log covers every change in the revision history, including changes that were minor in your view.
Retaining prior notices lets an auditor check what data subjects were told during the observation period, not only what they are told today. A test over a Type 2 period may ask for the notice in force on a date several months earlier. Keep every published version, its effective dates and the period it applied to. Retention should follow your own retention policy for records, and the policy should say how long prior notices are kept and where they sit. Store them in a location that is backed up and access controlled, because a missing version is difficult to explain after the fact.
- Version index: Maintain a table listing each notice version, its effective start and end dates and its location.
- Immutable copies: Store exported copies with a checksum or write-once setting so that later edits cannot alter them.
- Matching to contracts: Note which customer contracts referenced which notice version, where that matters.
- Restoration test: Periodically confirm you can retrieve an archived version and open it.
- Retention rule: Write the retention period into the policy set and check it against your records schedule.
Before each audit, pick one date inside the observation period and confirm you can produce the notice in force on that day within a short time.
The most common P1.1 gap is a product change that alters how personal information is used but never reaches the notice. Change-trigger records close that gap by linking product, data and vendor changes to a notice review. Examples include a new analytics tool, a new data field collected at sign-up, a new purpose for existing data, a new subprocessor or a change in where a self-hosted deployment sends telemetry. Each trigger should produce a recorded decision: the notice needs an update, or it does not, with the reason. Illustrative example: a team adds a session replay tool, opens a review ticket, and records that the notice must name the tool before release.
- Trigger list: Define the change types that require a privacy review, and include them in change management procedures.
- Linked tickets: Connect each review ticket to the change ticket and to the revision history entry.
- Recorded decisions: Keep a written conclusion for every review, including reviews that found no update was needed.
- Vendor intake: Route new vendors and subprocessors through the same review before onboarding.
- Periodic reconciliation: Compare the list of recent changes against the review log at least once per audit period.
Before each audit, check that every change in the change management system affecting personal information has a matching review record.
What meeting P1.1 costs in money and effort
This table breaks down the cost components of keeping a P1.1 privacy notice current, who is paid for each one, and whether it is one-time or recurring. Read the drivers column to see which choices raise or lower the total, and use the quote column to ask providers for the same breakdown. No dollar figures are given because none are supplied for this criterion.
| Cost component | Who is paid or who does the work | One-time or recurring | Main drivers and what to ask for in a quote |
|---|---|---|---|
| Privacy counsel time to draft and review the notice | External privacy or legal counsel, or internal legal staff | One-time to draft, recurring to review | Number of products and jurisdictions covered. Ask for the hours assumed per review cycle and what triggers a new review. |
| Mapping data flows and identifying change triggers | Engineering, product and data owners, sometimes with an implementation partner | Mostly one-time, with recurring updates | Number of systems that collect or use personal information. Ask who maintains the data inventory after handover. |
| Versioning and publishing the notice | Internal staff, or the vendor of an existing wiki or documentation platform | Recurring licence or hosting cost, if any | Whether an existing self-hosted wiki already keeps version history. Open-source options can remove licence spend but still need hosting and administration. |
| Evidence upkeep for each change | Compliance lead or privacy owner, with input from engineering | Recurring | Frequency of data-use change. Each change needs a record of what changed, when, why and who approved it. |
| Customer and user communication of changes | Product marketing, legal or support teams | Recurring per change | Volume of notice changes and whether customer contracts require advance notice. Ask how changes are communicated and archived. |
| Auditor testing of sampled changes | Independent CPA firm performing the SOC 2 examination | Recurring each examination period | Number of changes in the period and how well change records are organized. Ask the CPA firm how it samples and what it requests. |
| Implementation partner work to set up the process | Implementation partner, if engaged under a written, fixed scope | One-time setup, with optional retainer for upkeep | Scope of platforms and integrations. Ask for deliverables, assumptions and what the organization must still own. |
Which self-hosted tools keep privacy notice history
XWiki is a self-hosted wiki that keeps every change to a page under version control. For P1.1, the privacy notice can live on a dedicated page, and each edit becomes a stored revision. The point to test is whether the record answers the questions an assessor asks: what changed in the notice, when it changed, and who made the change. Because XWiki lets users compare any two versions and roll back to an earlier one, the team can show exactly how the notice evolved between review cycles.
- Change records: Each revision records what changed, when and by whom, which supports showing the sequence of notice updates.
- Version comparison: Reviewers can compare any two versions to confirm which privacy practices were added, removed or reworded.
- Rollback: Rolling back to an earlier version is possible, but it should itself be a recorded, approved action, not a silent edit.
- Retention of prior notices: Earlier versions remain available in history, which helps with the P1.1 expectation to keep prior notices.
- Approval workflow: Version control records authorship, not sign-off. Pair the wiki with a documented approval step, such as a ticket or sign-off form, and confirm how XWiki's own features support that step in your deployment.
Confirm that the revision metadata and retention settings in your deployment meet your auditor's sampling needs before relying on them.
BookStack organizes content into shelves, books, chapters and pages, and gives users abilities through the roles assigned to them. Permissions can be overridden per role at the shelf, book, chapter or page level. For a privacy notice, this means the team can restrict who may edit the notice page while allowing broader read access for customers, staff or regulators who need to see the current text. The model supports the separation between people who draft changes and people who approve and publish them.
- Role-based abilities: Users receive abilities from their assigned roles, so editing rights can follow job function rather than individual accounts.
- Granular overrides: Permissions can be set at shelf, book, chapter or page level, so the privacy notice page can have tighter controls than surrounding documentation.
- Separation of drafting and publishing: A drafting role can prepare changes while a separate approver role controls publication, which supports a documented approval workflow.
- Read access for evidence: Limiting edit rights while keeping the current notice readable helps demonstrate that the notice is easy to find and cannot be changed by anyone without authority.
- Limits to confirm: BookStack's page history and its handling of earlier versions should be checked against your notice retention requirements before you adopt it as the system of record.
Confirm the role configuration in your own instance and export the permission settings as evidence that edit rights were restricted during the examination period.
Both tools are open source, which allows self-hosting inside the organization's own infrastructure, a common requirement when privacy notices and their drafts must stay within controlled environments. XWiki is released under the LGPL-2.1-or-later license, and BookStack is released under the MIT license. The license terms govern how you may use, modify and redistribute the software, and they do not by themselves make either tool compliant. Your organization owns the control, and the tool only holds the record of it.
- XWiki license: LGPL-2.1-or-later, which carries copyleft obligations on modifications to the library itself. Review those terms with counsel if you plan to modify core components.
- BookStack license: MIT, a permissive license with fewer redistribution conditions. Confirm the license terms that apply to the version you deploy.
- Hosting location: Self-hosting keeps notice drafts and history in the organization's own environment, which matters when the notice reflects data flows the organization treats as sensitive.
- Backups and continuity: Notice history is only evidence if it survives restores. Include both tools in backup and restore testing.
- Access logging: Confirm whether your deployment logs who viewed or changed the notice, as a separate record beyond page history.
Ask your implementation partner and your auditor to confirm which license obligations, if any, apply to your planned customizations before deployment.
An assessor testing P1.1 typically asks for the current notice, the prior notices, and evidence that changes were communicated when practices changed. Tool history answers only part of that. The auditor will sample changes across the examination period and check that each one matches a real change in data use, that the notice was updated promptly, and that the change was communicated. A tool can show the mechanics; the organization must show the reasoning and the timing.
- Sample traceability: For each sampled change, be able to link the revision to the business change that caused it and to the communication that followed.
- Timing evidence: Revision timestamps should line up with the dates the underlying practice changed and with the date the notice was published.
- Communication records: Keep the notice of change sent to data subjects or customers, separate from the wiki, and reference it from the revision.
- Completeness: Confirm that no revisions were deleted or hidden and that the history covers the full examination period.
- Auditor agreement: Agree the evidence format, export method and sampling approach with your CPA firm early, before fieldwork begins.
Confirm with your auditor that the version records, role exports and communication logs together meet their sampling needs for your examination period.
Where organizations fall short on privacy notice updates
Most P1.1 findings do not come from a missing notice. They come from a notice that drifted away from what the organization actually does with personal information. The gaps below share one root cause: no single owner checks the notice against practice each time something changes.
Notice describes a previous product
The notice was written for the product as it looked at launch, and new features, data fields or analytics tools were added without anyone revisiting it. An assessor compares the notice against system descriptions, data flow diagrams and release notes for the examination period. To close the gap, tie a notice review to each release that changes how personal information is collected or used, and record the review in the change ticket.
Changes made without a notice review
Engineering or marketing starts using personal information for a new purpose, such as model training or cross-selling, and the change ships before privacy staff know about it. P1.1 expects communication of changes that affect how data is used, so the gap is a process failure rather than a drafting error. Add a privacy impact question to the change management workflow so that any new use of personal information triggers a notice check before deployment.
No retained prior versions
Teams overwrite the published notice when they update it, so no one can show what customers were told on a given date. This matters when a data subject or an assessor asks what the notice said during the period under review. Keep every published version with its effective date, and store it under version control so changes are attributable to a person and a time. Confirm the retention period for prior notices with counsel.
Notice omits subservice organizations
The notice names the company but not the hosting provider, analytics vendor, payment processor or support tool that handles personal information on its behalf. When a vendor is added or swapped, the notice still describes the old set of entities. Maintain a list of subservice organizations that is reconciled against the notice each quarter and whenever a vendor contract changes.
Unclear notice ownership
Legal drafts the notice, product owns the features it describes, and security owns the systems that hold the data, yet no one is accountable for keeping the three aligned. Reviews slip because each function assumes another will raise a change. Name one accountable owner for the notice, document who must confirm accuracy before each review sign-off, and record that approval as evidence.
Questions buyers ask about the P1.1 privacy notice
How much effort does P1.1 add to a SOC 2 examination?
For most organizations, P1.1 adds modest effort on its own, because it is a single criterion, but the effort sits in the privacy category, which must first be included in scope. The work is mostly drafting and maintaining one accurate notice, then keeping a record of its changes. The larger cost is usually the mapping exercise: confirming which entities, data flows and purposes the notice covers, and whether those match what the system actually does. Effort rises when personal information flows through many products, subprocessors or regions, and falls when the data handling is simple and well documented. Ask any consultant or auditor to state in writing which privacy criteria are in scope and what evidence they expect for P1.1 before you accept a quote.
Does a privacy notice need legal review for SOC 2?
SOC 2 does not require a lawyer to approve the notice, but the criterion asks for clear, accurate notice of your practices, and a wrong statement is a finding waiting to happen. Legal review is most valuable where the notice must also satisfy laws such as GDPR, which carries its own transparency duties. Keep the two questions separate: the auditor tests whether the notice matches actual practice and was communicated, while counsel tests whether it meets legal obligations in each jurisdiction. Ask your counsel to review the notice against your documented data flows, and ask your auditor which version they will treat as the controlling notice.
How often should a privacy notice be reviewed?
P1.1 does not set a fixed review interval, so the answer comes from your own policy and your change triggers. Review the notice on a schedule you can defend, and also whenever practices change, including new purposes for personal information, new third parties, new regions or new product features. The points of focus for P1.1 include reviewing the notice and communicating changes, so the auditor will look for both a review process and evidence that changes were communicated. Document the schedule in your policies, then record each review, even when the notice is unchanged.
What will the auditor sample for P1.1?
Auditors typically test the current notice, prior versions, and evidence that changes were communicated. They will ask you to show the notice as published, confirm that it covers the entities and activities in your system description, and compare it against actual data handling. For a Type 2 report, expect samples drawn across the observation period, so each change in the window needs a matching record. Prepare a change log that links each notice version to its approval date, the reason for the change and how data subjects were told. Confirm the sample size and period with your auditor in writing, since those details depend on the engagement.
Is a wiki enough to keep version history for the notice?
A wiki can be enough if it gives you a reliable record of what changed, when, and by whom, and if prior versions remain retrievable. The P1.1 points of focus include retaining prior notices, so the test is whether you can show any historical version as published. XWiki keeps every change under version control and lets users compare and roll back versions. BookStack lets you set roles and permissions per shelf, book, chapter or page, which helps restrict who can edit the notice. Confirm that your chosen tool preserves published snapshots, not only drafts, and that approvals are recorded somewhere auditors can read.
Can we do the P1.1 work in-house?
Yes, in most organizations the notice is owned internally, because the organization is responsible for its own privacy practices. What usually needs outside help is the cross-functional mapping, the change-trigger process, and the evidence trail. An implementation partner such as DeployOpen can prepare a self-hosted documentation platform, set up version control and role-based editing inside your own environment, and prepare the evidence for the auditor. An independent CPA firm issues the report. Before deciding, estimate internal time for mapping data flows, drafting, legal review and approvals, and ask any outside party to state in writing what they will deliver and what remains yours.
How DeployOpen prepares P1.1 evidence for your SOC 2
DeployOpen works on the systems and documentation that show your privacy notice is current, communicated and retained across changes to how personal information is used. We prepare the evidence inside your own infrastructure, while your organization owns the notice and the independent CPA firm issues the report.
How we scope
- Confirm which systems, websites and documents hold the privacy notice and its version history for the SOC 2 scope.
- Agree in writing which P1.1 points of focus the engagement addresses and who approves each notice change.
- Define the engagement as fixed-scope, with deliverables and timelines set out before work starts.
How we build
- Set up a versioned wiki or documentation platform so each notice revision records what changed, when and by whom.
- Configure role-based permissions so only designated owners can publish or edit the privacy notice.
- Document the process for reviewing the notice and communicating material changes to data subjects.
How we hand over
- Deliver the notice history, change log and approval records as evidence the CPA firm can sample.
- Provide runbooks describing how the notice is updated, published and kept current after each practice change.
- Walk your control owners through the evidence so they can answer the auditor's requests without us.
How we support
- Offer ongoing support and periodic reviews as a retainer so notice evidence stays current between audits.
- Help your team prepare for the examination period, including responses to the CPA firm's evidence requests.
- Confirm with your CPA firm which format and retention period they expect for notice records before fieldwork.
