What SOC 2 P8.1 asks for when a data subject complains
P8.1 requires a process to receive, address and resolve privacy inquiries, complaints and disputes from data subjects and others, to communicate the outcome, and to run periodic compliance monitoring with timely correction of any deficiencies. It is the only criterion in the P8 group on monitoring and enforcement, so an examiner reads it as the closing loop for the privacy criteria: the organization must not only handle privacy requests but also show that it checks whether it is handling them correctly and fixes what it finds. P8.1 is distinct from P5.1 and P5.2, which cover letting individuals access and correct their own data, and from P6.6, which covers notifying affected parties of breaches. P8.1 covers the wider stream of questions, objections and disagreements that arrive through any channel, including the ones that fit none of those specific criteria. The risk it addresses is a complaint that is lost in an inbox, answered inconsistently, or never closed, which leaves a data subject without recourse and leaves management unaware that a control is failing.
P8.1 is hard for a different reason than most criteria. The control is rarely a single policy. It is a working queue, and the auditor tests it over the examination period by sampling complaints and tracing each one from receipt to documented resolution, outcome notice and any corrective action. Your evidence therefore lives in records: intake timestamps, assignment, the reasoning behind each decision, the message sent back, and the monitoring reviews that show trends were examined. Confirm with your CPA firm how many periods and which samples it expects, since that depends on your system and the examination type. A tool such as GLPI's Assistance module or Zammad can hold these ticket histories, but the tool only produces evidence if the team uses it consistently for every privacy contact.
Before the examination window opens, decide three things: which channels count as privacy inquiries, who owns each stage and the escalation path for disputes, and how often management reviews the complaint log for recurring causes. Then test the process on real volume so the first sampled ticket does not reveal a gap. Ask your auditor which dispute recourse steps and monitoring cadence it will expect to see, and confirm how privacy complaints relate to your incident response records, so the same event is not documented twice with different outcomes.
Which channels, teams and third parties P8.1 covers
Before any complaint process is designed, the organization must decide whether the privacy category is in the examination at all, since P8.1 applies only when it is. The cards below cover the decisions that define what the process must catch: inbound channels, the controller or processor role, the teams involved, and the third parties that receive complaints on the organization's behalf.
Confirm the privacy category is in scope
P8.1 is tested only when the privacy category is included in the examination. The privacy criteria are additional to the common criteria, so an organization that covers only security, or security with availability, has no P8.1 obligation. Confirm the category decision with the CPA firm in writing before mapping channels or teams, and revisit it when the service adds new personal information flows. If the category is later added, the complaint process must already exist and have operated for the examination period.
Inventory every inbound channel
List every route by which a data subject, customer or regulator can raise a privacy matter: email aliases, web forms, support tickets, social media, telephone lines and chat. Include complaints that arrive indirectly, such as a customer forwarding a data subject's message or a partner passing on a regulator's letter. Each channel that is not logged into the same record system is a place where a complaint can be lost, so the inventory should name the owner and the system of record for each one.
Set the controller or processor role
The organization's role under the applicable privacy law changes who must answer a complaint. A controller decides the purposes of processing and typically answers data subjects directly. A processor usually routes data subject matters to the controller under contract and must still record them and report back. Write the role down for each data set in scope, because the same service can act as a controller for account data and a processor for customer content. Ask counsel to confirm the role for each data set before the process is documented.
Assign the teams that touch complaints
Complaints usually reach support first, but resolution depends on privacy, legal and engineering. Support triages and logs, privacy owns the response and the dispute decision, legal reviews regulator contact and recourse wording, and engineering confirms what data was affected and whether a fix or deletion took place. Document a hand-off rule for each team and a named owner for the overall process. Gaps between these teams are the most common reason a complaint is marked closed without evidence.
Map subservice organizations and vendors
Where a vendor, such as an outsourced support desk or a hosted ticketing platform, receives complaints, its handling is part of the organization's process and must be addressed in its vendor management. Confirm which vendors see personal information in complaint content, how they forward matters back, and how long they keep them. Carve-out vendors may be reported separately in the SOC 2 report, so the scope decision should state how each one is treated. Obtain their privacy and notification commitments in writing before they receive complaints.
Decide where complaints are recorded
The system used to record complaints determines what evidence the auditor can sample. Options range from a general helpdesk to a dedicated privacy request tool, and an open-source ticketing system can serve this role if it captures timestamps, owners, resolution notes and reporting outcomes. GLPI's Assistance module, for example, provides ticket processing and statistics. Confirm that the chosen tool keeps an audit trail of changes and that its retention settings match the organization's disposal commitments.
How to build a complaint process an auditor can test
This sequence turns P8.1 into a documented, repeatable process: one place where inquiries and complaints arrive, clear ownership, resolutions that are communicated back, recorded recourse, and periodic reviews that fix what they find. Each step ends with an artifact an auditor can sample.
Define intake channels and one system of record
List every route by which a data subject or data controller can raise a privacy inquiry, complaint or dispute, such as a privacy mailbox, web form, support desk or contract contact. Route all of them into a single ticketing system so that every item has one owner, one history and one status. Open-source options such as GLPI, whose Assistance module tracks tickets, problems and changes under ITIL practices, and Zammad, which gathers email, chat, telephone and social media into one ticket system, are two examples to evaluate against your channels. Done when the intake list is approved and a test submission from each channel produces a ticket in the system of record.
Write triage and ownership rules
Define how each new ticket is classified (inquiry, complaint, dispute, possible privacy breach), which team or named role owns each class, and when a ticket must be escalated to legal, the privacy officer or incident response. Record the rules in a written procedure approved by management. Done when the procedure exists, every class has a named owner, and the auditor can see that a sample of tickets was classified and routed according to it.
Set how complaints are investigated and resolved
Describe the investigation steps for each class: confirming the requester's identity where needed, pulling the relevant records, deciding on the facts, and recording the reasoning and the decision. Link related items such as access requests, disclosure records or incidents so the investigation is traceable. Done when closed tickets show the evidence reviewed, the decision made and who approved it, and the records are retained with the rest of the privacy evidence.
Define how outcomes are communicated back
Write standard response templates for each outcome, including resolution, partial resolution, denial and referral to another party. Each response should explain what was done, the reason for any denial and how the requester can take the matter further. Where a data controller raised the matter, the response goes to that controller under the contract terms. Done when a sample of closed tickets shows a documented response that matches the outcome and went through the approved channel.
Record disputes and recourse options
Keep a separate register for disputes that are not resolved at first response. Record the requester's position, the organization's position, every recourse option offered (such as internal review, escalation or an external dispute mechanism named in your notice or contract), and the final outcome. Confirm with counsel which external mechanisms apply to your customers and jurisdictions. Done when the register is complete for the period under review and each dispute shows the recourse offered and the reason it was closed.
Schedule periodic compliance reviews
Set a recurring review, at an interval your management approves, of the ticket population for volume, aging, repeat issues, unresolved disputes and adherence to the triage and response rules. Document each review's scope, sample, findings and the people who signed off on it. Ask your auditor which evidence and sample sizes they expect for the period. Done when review records exist for each scheduled cycle and report results and instances of noncompliance to management.
Document how deficiencies are corrected
Log each deficiency found in a review, in an intake, or in a complaint investigation as a corrective action with an owner, a description of the root cause, the fix and the date it was verified closed. Track open items until verification, and feed recurring patterns back into the procedure, templates or system configuration. Done when each deficiency has a traceable corrective action record and the auditor can follow it from detection through verification.
How an assessor tests P8.1 across the examination period
This table lists the test steps a service auditor typically performs on P8.1 and the evidence each step requests, with the findings that most often appear. Read it as a checklist of what the process must be able to show, and note that a Type 1 report tests design as of a date while a Type 2 report also tests whether the process operated across the observation period.
| Test approach | Evidence requested | Common findings |
|---|---|---|
| Walkthrough of the inquiry and complaint process | Written procedure for privacy inquiries, complaints and disputes, owner assignments, and a walkthrough of one item from receipt to closure | Procedure exists but roles are unclear, or staff describe a different process than the document states |
| Inspection of intake channels and system of record | List of channels (email aliases, web forms, phone lines), ticketing system configuration, and access rights to the queue | Requests arrive through an undocumented channel such as a personal mailbox, so they never reach the system of record |
| Sampling of inquiries, complaints and disputes across the period | Complete population report for the period, reconciled to the ticket system, from which the auditor selects items | Population is incomplete because some items were closed outside the tool or never logged, which undermines the sample |
| Checking acknowledgement for each sampled item | Timestamped acknowledgement to the data subject or data controller and the first response recorded in the ticket | Acknowledgement missing or sent late, or no record showing when the request was received |
| Checking resolution and communication of outcome for each sampled item | Resolution notes, approval records for any refusal or dispute decision, and copies of the outcome communication | Closure recorded without evidence of the message sent to the requester, or disputes closed without documented recourse |
| Review of monitoring reports and compliance review results | Periodic compliance review reports, trend or statistics reports on complaint volumes and themes, and evidence of management review | Reviews happen irregularly or do not cover privacy complaints, or findings are noted without an assigned owner |
| Tracing identified deficiencies to corrective action | Issue or remediation log linking each deficiency to an action, owner, due date and closure evidence | Deficiencies recorded but corrective action is not tracked to completion, or closure is asserted without testing |
Which evidence passes P8.1 and how to keep it current
An auditor testing P8.1 looks for proof that complaints were received, worked and closed, and that the program checks itself and fixes what it finds. The cards below cover the records that show this, and how to keep each one current between examinations so the observation period is not reconstructed at the end.
Written inquiry and complaint procedure
The procedure defines how a privacy inquiry, complaint or dispute enters the organization, who owns each step, how it is triaged, and when it goes to legal or the privacy lead. Name an owner for intake, investigation and sign-off, and state how data subjects and data controllers are told the outcome. Between audits, review the procedure on a fixed schedule and record the review date and approver. Confirm that the version in force matches what staff actually do.
Complaint and inquiry ticket records
A ticket trail shows each inquiry moving from intake through investigation, resolution and communication of the outcome. Auditors look for timestamps, assigned owners and a closing note that matches the reply sent to the requester. Helpdesk tools such as GLPI or Zammad can hold this trail when they are configured for privacy requests. Export tickets on a regular schedule into a locked evidence folder, so the record survives a change of tool.
Dispute and recourse documentation
Where a complaint cannot be resolved informally, the file should show the options offered to the complainant, any escalation, external recourse and the final position taken. Keep the written decision, the correspondence and any legal review in one case file. Confirm with counsel which recourse routes your contracts and jurisdictions require you to describe. Review open disputes at each monitoring cycle so none stall without a recorded reason.
Monitoring and compliance review reports
Periodic reviews test whether inquiries are handled on time, whether outcomes were communicated, and whether recurring complaint themes were analyzed. Each report should state its period, the reviewer, the sample or population examined and the findings, including instances of noncompliance. Sign-off by a named manager is what turns a review into evidence. Schedule reviews in advance and keep the signed copies with the ticket exports they tested.
Corrective action records
Each deficiency found in a complaint, a review or a dispute needs a tracked fix with an owner, a due date and a closure check. Auditors test whether deficiencies were corrected in a timely way and whether the fix addressed the root cause. Link each corrective action to the review finding or ticket that triggered it. Between audits, review open actions at every monitoring meeting and record when each one was verified.
Staff training and awareness records
Staff who answer complaints, route inquiries or decide disputes need to know the procedure and the escalation path. Keep attendance or completion records, the training content version and the date each person was trained or reminded. Add a refresher when the procedure changes or a review finds a handling error. Confirm that new joiners who will handle inquiries are trained before they take their first case.
Which open-source helpdesks can hold the complaint record
P8.1 asks for a process that receives, addresses and resolves privacy inquiries, complaints and disputes, and that reports the outcome back. An assessor will want to see one traceable record for each item, showing who received it, what was decided, who acted, when the outcome was communicated and whether recourse was offered. A ticketing system is the usual place to keep that record, because it gives each case a single identifier, an owner, a status history and a closure reason. Spreadsheets and shared mailboxes can work for a very small volume, but they make it hard to prove that every complaint was handled and not only the ones someone remembered to log.
GLPI (GPL-3.0-or-later) is a candidate for organizations that already run IT service management. Its Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, and it includes plannings, statistics, recurrent tickets and a Kanban view. For P8.1, the tickets can carry the privacy category, the data subject reference, the disposition and the communication sent, while the statistics help with the periodic monitoring the criterion expects. Check the GLPI Assistance documentation against the fields your privacy team needs before relying on them.
Zammad (AGPL-3.0-only) is a web-based helpdesk that gathers customer communication from email, chat, telephone and social media into one ticket system. That suits organizations where complaints arrive through several channels and must be answered from one place. Whichever tool you choose, the software only produces the trail. You still have to write the complaint procedure, assign named owners for intake, investigation and dispute resolution, set review cadences, and show through closed tickets that the process runs. Confirm the licensing obligations of AGPL-3.0 and GPL-3.0 with counsel before deployment, particularly if you modify the code or offer it to users over a network.
What meeting P8.1 costs in money and effort
This table breaks down the cost and effort of running a P8.1 complaint and inquiry process, row by row, showing who is paid, whether the cost is one-time or recurring, and what moves it up or down. No figures are given because none were supplied, so use the rows to structure a quote request and compare written scopes. Open-source helpdesk software can bring license spend to zero, but the remaining costs are real.
| Cost component | One-time or recurring, and who is paid | What drives it up or down |
|---|---|---|
| Helpdesk tooling or licenses | Recurring hosting and support; open-source licenses such as GLPI (GPL-3.0-or-later) or Zammad (AGPL-3.0-only) carry no license fee, but hosting, backup and support are paid to your team or a provider | Number of intake channels, number of controllers served, hosting model and whether you buy paid support |
| Engineering or operations time to configure intake and reporting | One-time for setup of ticket categories, forms and reports, then recurring for upkeep; paid to internal staff or an implementation partner | Number of channels to connect (email, web form, chat, telephone), integration with existing ticketing, and how many reports you must produce |
| Staff time to handle and record complaints | Recurring; paid to privacy, support or operations staff who triage, respond and record outcomes | Complaint and inquiry volume, complexity of disputes, clarity of routing rules and quality of templates |
| Periodic compliance review effort | Recurring; paid to internal compliance or privacy staff who review complaint trends, reported noncompliance and corrective actions | Review frequency set in your monitoring plan, number of processes covered and how well ticket data is structured |
| Legal review of the complaint procedure | Mostly one-time, with updates when laws or practices change; paid to counsel | Number of jurisdictions, sector rules, how often recourse and dispute steps change |
| External testing or review | Periodic; paid to a tester or reviewer if you choose independent review of the process or its ticket records | Scope of review, whether it covers only the process or also the tooling and access controls around it |
| Auditor sampling effort | Recurring with each SOC 2 examination; paid to your staff to produce samples, and to the independent CPA firm for testing | Number of complaints in the period, how cleanly each ticket shows receipt, resolution and communication of outcome |
Who owns P8.1, what a partner prepares and what the auditor tests
Your organization owns P8.1. Privacy and legal staff decide how inquiries, complaints and disputes are judged, what outcome is communicated, and what recourse a data subject or data controller has. Support operations handle daily intake and routing, and leadership reviews the monitoring results and decides how deficiencies are corrected. None of these roles can be handed to a vendor, because the people accountable for the outcome must be the ones who set it.
- Procedure ownership: Privacy or legal approves the written procedure for receiving, addressing, resolving and reporting back on inquiries, complaints and disputes.
- Dispositions: Named staff decide outcomes, document the reasoning and approve any recourse offered to the requester.
- Intake operations: Support staff log every request, assign it, and track it to closure within the timelines your own policy sets.
- Leadership review: Management reviews periodic compliance monitoring results, including any instances of noncompliance, and approves corrective actions with owners and due dates.
- Evidence of performance: Your team keeps the records that show the procedure ran as written during the observation period.
Before the examination, confirm that each role has a named individual, a backup, and documented authority to act.
An implementation partner prepares the systems, configuration and documentation that let your team run P8.1 consistently and show that it did. Work is typically scoped in writing before it starts. The partner does not decide outcomes, approve dispositions or certify the control. If you use a self-hosted helpdesk such as GLPI or Zammad, the partner can configure it to match your procedure and produce the records an auditor will sample.
- Helpdesk configuration: Set up ticket categories, queues, statuses and escalation paths for privacy inquiries, complaints and disputes, following your approved procedure.
- Reporting and exports: Build reports and evidence exports that show intake volume, time to resolution, outcomes and reported back to requesters.
- Monitoring cadence: Prepare a review schedule and templates for periodic compliance checks and the tracking of deficiencies to correction.
- Process documentation: Write runbooks and the control narrative that describe how the process operates, for your review and approval.
- Access and records: Restrict who can change tickets and keep configuration history so the records remain reliable.
Ask the partner to state in the written scope which deliverables are configuration and documentation, and which remain your responsibility.
An independent CPA firm performs the SOC 2 examination. For P8.1, the auditor tests whether the procedure is designed to meet the criterion and whether it operated effectively across the period covered by a Type 2 report. The auditor samples inquiries, complaints and disputes, traces them through your records, and checks the monitoring and correction steps. Only the CPA firm issues the report and its opinion.
- Design testing: The auditor reviews the procedure and related points of focus to judge whether it addresses communication, resolution, documented recourse and reporting.
- Operating effectiveness: For a Type 2 report, the auditor samples items across the observation period and checks timeliness, documentation and outcome communication.
- Monitoring evidence: The auditor examines periodic reviews, identified noncompliance and the timeliness of corrections.
- Management representations: Your management provides written representations about the system and the controls, which the auditor relies on.
- Independence: The auditor cannot design the controls it tests. Consultants or partners who prepare your evidence cannot also issue the opinion.
Confirm with your CPA firm which samples and evidence it will request for P8.1 before you finalize the configuration.
Where organizations fall short on P8.1 and how to close each gap
P8.1 is easy to describe and hard to evidence. The gaps below share a pattern: the process exists in someone's head or in a policy, but no system of record, signed review or closed corrective action shows it running. Each fix names the record an auditor would ask to see.
Complaints sit in personal inboxes
When privacy inquiries arrive by email to individuals, nothing guarantees each one is logged, assigned, or timed. Route every privacy inquiry, complaint and dispute into one ticketing system with a dedicated queue, a unique reference, and a defined owner. GLPI's Assistance module or Zammad can serve this role if they are self-hosted and access-controlled. Check that the queue captures requests from every intake channel, including phone and social media, since P8.1 covers inquiries from data subjects and others.
Outcomes never reach the requester
P8.1 expects the organization to communicate how each inquiry, complaint or dispute was resolved. Many teams close tickets internally without sending a response, so the auditor finds resolutions that the data subject never saw. Add a required closure step with a templated outcome notice, the date sent, and the channel used. Sample tickets should show both the resolution and the message that delivered it.
No documented recourse path for disputes
A dispute the organization cannot resolve needs a written path onward: escalation to a privacy lead, independent review, or the external recourse the organization offers. Without it, staff improvise, and different requesters receive different answers. Document the escalation steps, the decision owner, and the information given to the requester about further options. Confirm the wording against your privacy notice and any contractual commitments to customers.
Monitoring reviews leave no signed record
Periodic compliance reviews of complaint handling are often discussed in meetings but not written down. P8.1 covers monitoring and reporting compliance review results, so the auditor will ask for the review itself. Set a review cadence, use a standard checklist covering open items, response times and recurring themes, and retain the signed minutes or approval. Name the reviewer and make sure they are not the only person who handles the complaints being reviewed.
Deficiencies logged but not closed
A complaint review may find that a notice was late or a dispute stalled, and the finding is recorded but never fixed. The gap between identifying a deficiency and correcting it is where P8.1 is most often tested. Link each finding to a corrective action with an owner, a due date, and a closure check. Track overdue items in the same system as the complaints, so the auditor can follow one deficiency from detection through verified correction.
Process exists, but no complaints recorded
A documented process with an empty complaint log gives an assessor nothing to test. Operating effectiveness over the audit period needs real records, and an empty log raises the question of whether intake works at all. Before the observation window opens, test the intake channels with controlled inquiries that your team logs and closes. Label those test records clearly so they are not confused with genuine data subject requests, and confirm with your auditor how they plan to treat a period with few or no complaints.
Questions buyers ask about P8.1 cost, effort and outside help
How much effort does P8.1 take to run?
The effort depends on how many inquiries, complaints and disputes the organization receives and how many parties are involved in resolving them. P8.1 is a single criterion, but it needs a working intake channel, a defined owner, a documented resolution path, a way to tell data subjects the outcome, and recurring compliance reviews. The one-time work is designing the process and the records. The recurring work is triage, responding, logging outcomes, reviewing trends and fixing deficiencies on time. Ask any partner to size the effort against your actual volume and the number of systems that feed complaints into the process, rather than accepting a generic estimate.
Can we run P8.1 without outside help?
Many organizations can run P8.1 in house, provided they have a named owner, a written procedure and enough people to answer requests on time. Outside help is most useful when the process has to be built from nothing, when privacy requests arrive through several channels, or when the team lacks someone who can judge dispute resolution and recourse. Whatever you decide, the organization owns the process and its outcomes. An implementation partner can configure a ticketing system and prepare records, but it cannot decide how your organization resolves a dispute.
What does the work need from our team?
The work needs input from several roles. Privacy or legal staff define what counts as an inquiry, complaint or dispute and what recourse is offered. Support or operations staff handle intake and triage. Engineering supplies system data needed to answer questions and confirms how corrections reach downstream systems. Management reviews compliance results and approves corrective actions. Expect to name these owners before the process is documented, because an auditor will ask who performs each step and how they are trained.
How long does a Type 2 report take to show P8.1 operating history?
The operating history comes from the observation period, and the length of that period is set in the examination engagement, not by the criterion itself. What drives how much history you can show is whether the process ran consistently throughout the period. Auditors look for complete records of inquiries, the actions taken, the outcomes communicated, and evidence of periodic monitoring and timely correction of deficiencies. A process that was live only shortly before the period starts will show little history. Confirm the observation period and the sampling approach with your CPA firm before you finalize the process.
Can the auditor design our P8.1 process?
No. An independent CPA firm performs the examination and issues the report, so it cannot design the controls it tests without compromising its independence. The auditor can explain what it will test and what evidence it expects. Design work belongs to the organization, possibly with a consultant or implementation partner who prepares systems, records and documentation. Ask your CPA firm in writing what it can and cannot do for you during preparation, and confirm that any help you buy is documented in the engagement scope.
What should we ask a partner for in a fixed-scope quote?
A fixed-scope quote should list the deliverables, the systems in scope, the channels covered, and the responsibilities on each side. Ask for the intake channels to be configured, the ticket workflow and escalation rules documented, the record templates provided, and the knowledge of how outcomes are communicated and reported. Also ask what is excluded, such as legal review of notices or the examination itself, how changes to scope are priced, what support follows delivery, and what the organization must supply. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and its quote follows from that written scope.
How does P8.1 differ from breach notification under P6.6?
P8.1 covers how the organization receives, addresses, resolves and reports back on privacy inquiries, complaints and disputes, and how it monitors compliance and corrects deficiencies. P6.6 covers notifying affected data subjects, regulators and others of breaches and incidents, based on identified reporting requirements. The two criteria can meet at a point, for example when a complaint reveals a breach, but they answer different questions. Your records for P8.1 should show how each complaint was handled, while your P6.6 evidence shows the notification decisions and timing for incidents. Confirm with your auditor where the boundary sits in your own process.
How DeployOpen prepares P8.1 evidence in your environment
DeployOpen plans, implements and documents the self-hosted open-source systems that run your P8.1 inquiry, complaint and dispute process inside your own infrastructure. We prepare the systems and evidence for your assessment, while your organization owns the controls and an independent CPA firm issues the report.
How we scope
- Agree in writing which privacy inquiry and complaint channels, queues and owners fall inside the engagement before work starts.
- Define how data subject requests, disputes and recourse steps are logged, routed, escalated and closed in the chosen platform.
- Record which monitoring reviews, reporting outputs and deficiency correction steps the written scope includes and excludes.
How we build
- Configure a self-hosted helpdesk such as Zammad or GLPI so inquiries and complaints are captured as tickets with timestamps and owners.
- Set up categories, SLA-style response fields and escalation rules that match the documented dispute resolution procedure.
- Test the workflow end to end with sample tickets so the team can show each step from receipt through communicated outcome.
How we hand over
- Deliver written procedures describing how inquiries are received, resolved, communicated and reported back to the requester.
- Provide exported ticket records, configuration documentation and a monitoring review template your assessor can sample against.
- Walk your staff through operating the workflow so ownership stays with your organization after the engagement closes.
How we support
- Support is available as a retainer for ongoing platform upgrades, configuration changes and periodic monitoring of the workflow.
- Review the ticket process between audit periods so deficiencies are logged and corrected in a timely way.
- Ask your CPA firm to confirm which P8.1 evidence samples they will request and how far back the period of review extends.

