IPE Completeness and Accuracy at Scale: Testing Client-Produced Reports Across 40+ Concurrent SOC 2 Engagements

IPE — Information Produced by the Entity — is the specific artifact type that produces more SOC 2 peer review findings than any other category. It is a report the client generates for the auditor's use: an access review export, a change ticket count, an incident log, an SLA breach report. The auditor must test that the report is complete (captures the full population), accurate (reflects the underlying data correctly), and relevant (represents what the control activity requires). At one engagement per senior manager per quarter this is manageable; at forty concurrent engagements per practice per year, it becomes the scale problem that turns SOC 2 II into a margin-killing product line.

This is what IPE testing actually looks like at scale, why the per-engagement heroics that work at low volume stop working at high volume, and the specific tooling and workflow shifts that let a modern cyber-attest practice test IPE defensibly across a large book without doubling engagement hours.

What IPE actually is, and why the auditor must test it

Every SOC 2 II examination depends on artifacts the client produces to demonstrate control operation. A privileged access review requires a list of privileged accounts and evidence the review was performed. A change management control requires a ticket log with disposition. An incident response control requires an incident count with severity classifications. In each case, the client generates the artifact from a source system — an IAM tool, a ticketing system, a SIEM — by running a query or export.

The auditor cannot rely on the artifact's face value. Two failure modes drive the testing requirement. First, the extraction may be incomplete — the query filter may exclude records that should have been included (a WHERE clause that misses a category, a date range that clips the period, a permission set that hides records from the querying user). Second, the extraction may be inaccurate — the report may transform or aggregate the underlying data in ways that change the auditor's interpretation (a status field mapped incorrectly, a count field summing across the wrong dimension).

The AICPA's professional standards — specifically AT-C 205.36 — require the practitioner to evaluate the reliability of information used as audit evidence, including information produced by the entity. In practice this means three tests per IPE:

• Completeness — does the report capture the full population subject to the control?: For a privileged access review, the report must include every privileged account in scope. Completeness testing typically involves re-running the extraction with an independent parameterization (e.g., a broader query that the auditor filters down) and reconciling the difference. Zero difference is the target; any difference must be explained.
• Accuracy — does the report reflect the underlying data correctly?: For each record in the report, does the reported status, disposition, or classification match what the underlying system shows? Accuracy testing typically samples records and re-checks each against the source system directly. A material rate of accuracy discrepancies invalidates the report as audit evidence.
• Relevance — does the report cover the specific period, scope, and population the control activity requires?: A privileged access review report dated after the end of the covered period does not evidence a review performed within the period. A change ticket log filtered to production changes does not cover the pre-production change control if that is separately in scope. Relevance is the judgment layer — the auditor evaluates whether the report actually addresses the control activity being tested.

Where IPE testing breaks at scale

At one engagement per quarter, IPE testing is time-consuming but manageable. The senior manager sits with the client's IT lead, walks through the extraction, reruns the query, samples records, and documents the procedure in a walkthrough workpaper. Two to five hours per IPE, five to fifteen IPEs per engagement, all defensible.

At forty concurrent engagements the arithmetic breaks. Fifteen IPEs per engagement across forty engagements is six hundred IPE tests per year. At four hours per test that is 2,400 hours per year of senior manager time devoted to IPE testing — more than a full FTE across the practice, dedicated to reconciliation work that produces no substantive audit finding in the majority of cases. The margin does not support it, so one of three things happens:

The extraction-lineage approach

The biggest efficiency shift available in modern IPE testing is capturing the extraction itself as the primary IPE artifact, rather than treating a static report as the artifact and reconstructing the extraction after the fact. Extraction lineage means: for every IPE, the auditor's workpaper captures the source system, the query or extraction command, the filter parameters, a timestamp, and a reproducible re-run capability.

Concretely, for a privileged access review report, extraction lineage means the workpaper carries not just the report file but also:

• The source system identifier.: Which IAM tool, which tenant, which instance. Not "our IAM system" — the specific system with a version and configuration reference.
• The extraction query in verifiable form.: The exact query used to produce the report, in the source system's own query language (or the equivalent — an API call with parameters, a CLI command with flags). Not a paraphrase or a description. Enough to re-execute against the same source system and expect the same result.
• The filter parameters.: Date range, permission scope, category filter, exclude-list — every parameter that could affect the result set. Documented separately from the query so the auditor can evaluate each filter's completeness impact independently.
• A timestamp and an author attribution.: When the extraction ran and who ran it. Ideally the client's compliance owner runs the extraction in the auditor's presence during the walkthrough; the timestamp and the walkthrough note together establish the extraction's provenance.
• A reproducibility artifact.: Either a re-execution of the same query at a different time (with the auditor verifying the result set matches what the client provided), or a hash of the exact query text that the auditor can carry to future cycles for lineage comparison.

Once extraction lineage is captured, completeness testing collapses to a much smaller procedure: the auditor evaluates the filter parameters for the specific completeness risks (does the date range cover the period, does the scope filter capture the full population, does the exclude-list exclude only what should be excluded), samples records to test accuracy against the source system, and documents the judgment layer. The manual re-run of the entire extraction — the two-to-four hours per IPE that eats the margin — is not required for every IPE, because the extraction is reproducible on demand from the lineage.

The three IPE archetypes and how each is tested efficiently

Not every IPE is equivalent. Three archetypes recur across cyber-attest engagements, and each has a different efficient testing pattern:

How to document IPE testing in the workpapers

The workpaper documentation for IPE testing is where peer reviewers concentrate their scrutiny, and where the extraction-lineage approach earns its keep. A defensible IPE workpaper contains, at minimum:

• The IPE identifier and the control it supports.: Which report, produced for which control activity, satisfying which SOC 2 criterion. This links the IPE to the audit trail so a peer reviewer can trace from the trust services criterion down to the specific IPE and back up to the assertion.
• The completeness assessment.: The auditor's evaluation of whether the extraction captures the full population. If extraction lineage is captured, this section evaluates the query and filter parameters. If it is not, this section documents the manual reconciliation procedure the auditor performed.
• The accuracy testing.: The specific records sampled, the source-system-of-truth against which each was verified, and the exception count. If exceptions were found, the disposition of each and the auditor's evaluation of whether the exceptions materially affect the IPE's reliability.
• The relevance evaluation.: The auditor's judgment on whether the IPE addresses the specific control activity. Period coverage, scope, and population alignment — each briefly stated with the reasoning that supports the conclusion.
• The overall conclusion.: Whether the IPE is reliable enough to support the auditor's testing of the underlying control. Explicit conclusion with a brief supporting rationale. This is the sentence a peer reviewer looks for; without it, the peer review question "did the practitioner conclude on the IPE's reliability?" cannot be answered from the workpaper.

Peer review defense

The AICPA's 2024 peer review guidance is explicit about the elevated deficiency risk in SOC 2 examinations, and IPE testing appears prominently in the recurring themes. Practices that adopt extraction-lineage capture and structured IPE workpaper documentation are not merely more efficient — they are structurally more defensible under peer review. The workpaper answers the peer reviewer's questions in a shape the peer reviewer expects to see. That is worth more than the hour savings; it is worth the practice's inspection posture.

The bottom line

IPE testing at 40+ concurrent engagements is where the SOC 2 practice's margin either survives or evaporates. The per-engagement heroics of low-volume work do not scale, and the sampling-down and reliance-on-attestation shortcuts create peer review risk that eventually costs more than they save. The path that works is extraction-lineage capture — treat the extraction as the IPE artifact, verify the lineage, test the judgment layer, document defensibly. The tooling requirement is client-side capture of the extraction (not just the report) and audit-side workpaper structure that carries lineage as a first-class field.

Test IPE at scale without doubling engagement hours

vCISO Lite for Auditors captures extraction lineage as a first-class primitive. For every IPE, the platform records the source system, the extraction query, filter parameters, timestamp, and re-execution capability — captured client-side at the time the IPE is produced, carried into the auditor's workpapers with the artifact. Completeness testing collapses from a manual reconciliation procedure to a lineage evaluation plus a judgment-layer assessment. Built for CPA firms running high-volume cyber-attest work across SOC 2, ISO 27001, ISO 42001, PCI DSS, HITRUST, FedRAMP, and DORA.

If IPE testing is where your engagement hours run over budget, or if a recent peer review flagged your IPE documentation as insufficient, visit firm.vcisolite.com to see extraction lineage in the console.