Tessa Okafor found the discrepancy on a Tuesday morning, in the worst possible way: a customer found it first.
Tessa was VP of Platform Engineering at Brightferry Commerce, a 140-person order-orchestration platform that sat between mid-market retailers' storefronts and their fulfillment centers, warehouses, and payment processors. On a normal day, Brightferry's system ingested order data from a dozen storefront platforms, validated inventory and pricing, routed orders to the correct warehouse, triggered payment capture, and reconciled the results back into each retailer's finance system. It was unglamorous, high-volume, invisible infrastructure — right up until it wasn't.
The email came from the controller at Fennimore & Vance, a housewares retailer and one of Brightferry's largest customers at $1.1 million in annual recurring revenue. Her finance team's month-end reconciliation showed $180,000 in captured payments that didn't match a single order in Brightferry's order ledger. Somewhere between a schema migration Brightferry's data team had run three weeks earlier and the nightly reconciliation batch job, 1,140 orders had been captured for payment, then silently dropped from the processing pipeline before they reached the order-fulfillment and reporting tables. The money had moved. The records hadn't kept up. Nobody at Brightferry had noticed, because nothing had technically crashed — the batch job finished, logged "success," and moved on to the next run.
Fennimore & Vance's controller was polite, but the message underneath was not: "We need to understand how a six-figure gap exists in a system we're paying you to trust with our money, and we need to know it can't happen again." The renewal — a three-year, $3.2 million extension already sitting in legal review — was suddenly not moving until Brightferry could answer both questions credibly, in writing, ideally with an independent auditor's signature attached to the answer.
Tessa's CEO had one instinct: get to Security. Lock down access, double-check encryption, review the incident logs. All reasonable instincts, and Brightferry's SOC 2 report already covered Security well — that wasn't the gap. Nobody had broken in. Nothing had been stolen. The problem was that Brightferry's own processing pipeline had eaten 1,140 transactions mid-flight, and nothing in the control environment had been built to catch it. That's a different SOC 2 conversation entirely: Processing Integrity — the Trust Services Criteria category that exists specifically to answer whether a system's processing is complete, valid, accurate, timely, and authorized, independent of whether the system was ever attacked at all.
This article is the walkthrough Tessa's team needed: what Processing Integrity actually covers (and, just as importantly, what it doesn't), the five PI1 criteria in plain language, the input/processing/output control model auditors expect to see, how error handling and reconciliation fit into the picture, and how to build the evidence trail before your own six-figure email arrives.
Who this is for, and what you'll walk away with
This is for engineering leaders, compliance managers, and founders at companies whose systems calculate, transform, route, or aggregate data that customers rely on being right — payment processors, e-commerce and order-management platforms, payroll and billing systems, claims processors, financial data aggregators, logistics and EDI platforms, and usage-metering SaaS. You'll leave able to explain why Processing Integrity is optional and how to decide whether you need it; map the PI1.1–PI1.5 criteria to concrete input, processing, and output controls; design error-handling and reconciliation processes an auditor can actually test; and draw a hard line between Processing Integrity and a data-quality problem you don't and shouldn't own. We'll use Brightferry and two other fictional organizations as quantified, illustrative case studies throughout — the numbers are illustrative, tied to the narrative, not published research.
What Processing Integrity actually means
Processing Integrity is the Trust Services Criteria category that addresses one narrow, specific question: once data enters your system, does your system process it completely, validly, accurately, in a timely way, and only with proper authorization? It is not a general statement about data being "good." It is a statement about your processing — the calculations, transformations, routing, matching, and aggregation logic your system performs — doing exactly what it was designed and represented to do, every time, on every record, and leaving evidence that it did.
Five words carry the entire weight of the criteria, and auditors test against all five: complete (nothing that should have been processed was dropped, duplicated, or left in limbo), valid (the data conforms to defined business rules before it's acted on), accurate (calculations, conversions, and transformations produce correct results), timely (processing happens within the window the system committed to), and authorized (only approved transactions, users, or triggers can initiate processing). Brightferry's 1,140 missing orders were a completeness failure, full stop — the transactions existed, were valid, were accurate at the point of capture, and were authorized. They simply vanished between two processing stages, and nothing detected the gap.
"The five words are a checklist, not poetry. When I walk a client through a processing failure, I make them tell me which of the five broke — complete, valid, accurate, timely, or authorized — before we talk about a fix. Half the time, naming it correctly is most of the fix, because it tells you which control layer failed." — Nina Cho, CPA, Partner, Ridgeline Assurance Group
Table 1: The Five Processing Integrity Attributes
Attribute | Plain-language question | Example failure | Example control that catches it |
|---|---|---|---|
Complete | Was every record that should have been processed actually processed, once? | A batch job silently drops 1,140 orders during a schema migration | Record-count reconciliation between source and target at every pipeline stage |
Valid | Does the data conform to defined business rules before processing acts on it? | An order with a negative quantity is accepted and processed | Schema and business-rule validation at ingestion, rejecting out-of-bounds values |
Accurate | Do calculations, conversions, and transformations produce correct results? | A currency-conversion rounding error understates invoice totals by 2% | Automated recalculation checks and tolerance-threshold alerts |
Timely | Does processing complete within the committed window? | End-of-day settlement finishes 14 hours late, missing a bank cutoff | SLA monitoring on batch and stream processing jobs with alerting |
Authorized | Can only approved transactions, users, or triggers initiate processing? | A test script with production credentials fires duplicate payment captures | Role-based execution permissions and change-controlled deployment gates |
What Processing Integrity does not mean
This is the distinction that trips up more teams than any other part of the category, and it's worth stating plainly before going further: Processing Integrity is not a guarantee about the quality of data your users or customers supply to your system. If a customer's finance team keys in the wrong purchase order number, or a retailer's storefront sends you a product SKU that doesn't exist in your catalog because their catalog is stale, that is a source-data-quality problem — not a Processing Integrity failure. Your system's job under PI is to handle whatever it receives correctly according to its own defined rules, which includes validating and rejecting bad input where appropriate, not to somehow know that a syntactically valid input is semantically wrong in the real world.
The AICPA's own guidance draws this line explicitly: Processing Integrity addresses whether the entity's processing is complete, valid, accurate, timely, and authorized — it does not extend to a warranty that inputs originating outside the system's control are themselves correct. Brightferry cannot promise Fennimore & Vance that every SKU submitted by Fennimore's storefront is a real, in-stock item; Brightferry can and must promise that once a syntactically valid order arrives, it will be captured, priced, routed, and reconciled correctly, and that an order failing validation will be rejected and reported — not silently dropped or silently miscalculated.
"I've had engineering teams push back hard on Processing Integrity because they think we're asking them to certify that every customer never fat-fingers a number. We're not. We're asking whether your system catches the fat-finger, rejects it cleanly, and doesn't quietly do something wrong with it instead." — Nina Cho, CPA, Partner, Ridgeline Assurance Group
Table 2: Processing Integrity vs. Source Data Quality
Scenario | In scope for Processing Integrity? | Why |
|---|---|---|
Customer enters an incorrect shipping address | No | The system correctly processes whatever valid address format it received; the address's real-world accuracy is the customer's responsibility |
System accepts an order with a negative unit price and processes payment on it | Yes | The system failed to validate input against a defined business rule before processing |
A currency-conversion routine rounds incorrectly, understating totals by 2% across all transactions | Yes | A processing/calculation accuracy failure inside the system's own logic |
An upstream storefront sends a discontinued SKU that no longer exists in the catalog | No (for the SKU's validity) / Yes (for how the system handles it) | The SKU's staleness is a source-data issue; whether the system rejects it cleanly and reports the rejection is a PI control |
A batch reconciliation job silently drops 1,140 orders during a schema migration | Yes | A completeness failure inside the entity's own processing pipeline |
A user uploads a spreadsheet with a typo in a customer name field | No | Free-text field accuracy supplied by the user is outside processing control scope |
A payroll engine calculates overtime using an outdated multiplier after a policy change | Yes | An accuracy failure in the entity's own processing/calculation logic |
Why Processing Integrity is optional — and how to decide if you need it
Every SOC 2 examination is anchored to the Common Criteria — the Security category, CC1 through CC9 — which is mandatory in every single report regardless of industry or business model. Processing Integrity, like Availability, Confidentiality, and Privacy, is one of four additive categories a service organization chooses to include only when it's relevant to the commitments made to customers — the full picture of how these five categories fit together is covered in SOC 2 Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy. There is no rule requiring every company to add it, and adding a category you don't need inflates audit scope, cost, and fieldwork time for no customer-facing benefit. Notably, this optional-category structure is a SOC 2-specific concept — organizations mapping their program against ISO 27001 won't find a direct equivalent, since ISO 27001's Annex A controls don't carve out a distinct "processing integrity" domain the way the AICPA's TSC does.
The deciding question is simple, even if the answer sometimes isn't: does your system perform processing — calculation, transformation, matching, routing, or aggregation — that a customer relies on being complete and correct, where an error would have a material financial, operational, or contractual consequence for them? A static file-storage service that simply stores and returns whatever bytes a customer uploads has very little Processing Integrity surface area; nothing is being calculated or transformed. A payment processor, an order-management platform, a payroll engine, or a usage-based billing system is almost pure Processing Integrity surface area, because the entire value proposition is "we will process your numbers correctly."
"I ask one question in the scoping call: 'If your system got the math wrong for one day, would a customer notice it in their bank account, their invoice, or their inventory count?' If the answer is yes, Processing Integrity belongs in scope, full stop. If the answer is 'they might notice a UI glitch,' it probably doesn't." — Nina Cho, CPA, Partner, Ridgeline Assurance Group
Table 3: When Processing Integrity Applies — a Decision Guide
Signal | Favors including Processing Integrity | Favors leaving it out |
|---|---|---|
Core function | System calculates, transforms, matches, or routes customer data/money | System stores or transmits data unchanged, with no transformation logic |
Financial impact | Errors would misstate a customer's money, inventory, or billed amounts | Errors would be cosmetic or easily self-correctable by the customer |
Customer commitments | Marketing or contracts promise accuracy, completeness, or specific SLAs on processing | No explicit promises made about processing correctness |
Industry pattern | Payments, e-commerce, payroll, claims, billing, trading, logistics/EDI, data aggregation | Pure infrastructure hosting, static content delivery, internal productivity tools |
Customer procurement pressure | Enterprise customers specifically ask for Processing Integrity in security questionnaires | No customer has ever asked; category has never come up |
Regulatory/contractual overlap | SLAs or contracts specify accuracy/completeness thresholds (e.g., "99.9% transaction accuracy") | No processing-specific SLAs exist in customer contracts |
Table 4: Industries and Use Cases Where Processing Integrity Is Most Relevant
Industry / use case | Why Processing Integrity matters here | Typical processing at risk |
|---|---|---|
Payment processing and payouts | Money moves based on system calculations; errors are directly financial | Transaction capture, settlement, payout batching |
E-commerce / order orchestration | Orders, inventory, and pricing must reconcile across systems | Order routing, pricing engines, inventory sync |
Payroll and benefits administration | Employees are paid based on system-calculated hours, rates, and deductions | Overtime calculation, tax withholding, benefits deduction |
Healthcare claims processing | Claims adjudication determines what providers and patients are billed | Claims matching, adjudication rules, reimbursement calculation |
Usage-based / metered SaaS billing | Customers are billed based on system-recorded usage | Usage metering, aggregation, invoice generation |
Financial data aggregation | Downstream financial decisions depend on aggregated data being complete | Account matching, balance aggregation, reconciliation |
Logistics and EDI processing | Shipment and invoicing data must match across trading partners | EDI transaction parsing, shipment/invoice matching |
Trading and market-data platforms | Trade execution and reporting must be accurate and timely | Order matching, trade confirmation, market-data feeds |
Pure infrastructure / hosting (contrast case) | Little to no transformation of customer data occurs | Typically out of scope for Processing Integrity |
The PI1 series: five criteria, deliberately compact
Unlike the nine-category Common Criteria, Processing Integrity is a tight, five-criterion series — PI1.1 through PI1.5 — and every one of the five maps to a stage in the data's lifecycle through your system: define it, take it in, process it, put it out, and store it. There's a reason the AICPA kept this category small: Processing Integrity leans on the Common Criteria's existing change-management, monitoring, and access-control infrastructure (particularly CC7 system operations and CC8 change management) rather than reinventing a separate control layer from scratch. What PI1.1–PI1.5 add is a specific, testable lens on correctness — not a whole new control universe.
"Clients are always relieved when I tell them Processing Integrity is five criteria, not nine. Then I tell them the five criteria touch every table in their database and every line of their calculation logic, and the relief doesn't last long." — Nina Cho, CPA, Partner, Ridgeline Assurance Group
Table 5: PI1.1–PI1.5 at a Glance
Criterion | Lifecycle stage | One-line summary |
|---|---|---|
PI1.1 | Definition | The entity defines processing objectives and data specifications so "correct" is a testable standard, not a guess |
PI1.2 | Input | System inputs are complete and accurate before processing acts on them |
PI1.3 | Processing | Processing itself is complete, valid, accurate, timely, and authorized |
PI1.4 | Output | Outputs are complete and accurate, and delivered to the intended recipients |
PI1.5 | Storage | Inputs, in-process data, and outputs are stored completely, accurately, and in a timely manner |
PI1.1 — Defining processing and data
PI1.1 is the foundation criterion, and it's the one teams most often skip because it produces no code and no dashboard — just documentation. It requires the entity to define, in writing, what its processing objectives actually are: what data it processes, what the processing is supposed to do to that data, and what "correct" output looks like. Without this definition, there is nothing for an auditor — or for your own engineers — to test processing against. You cannot prove a calculation is accurate if nobody has written down what the correct calculation is supposed to produce.
In practice, PI1.1 evidence looks like data dictionaries, defined business rules and calculation specifications, system/data-flow diagrams showing what happens to data at each stage, and product/service specifications that state processing commitments (e.g., "orders are priced using the catalog price in effect at the time of order submission, plus applicable tax and shipping"). Brightferry's team, going through this exercise for the first time, discovered that their pricing logic existed only as tribal knowledge spread across three engineers' heads — nobody had ever written down the actual rule for how promotional discounts stacked with tax calculation, which turned out to be a second, unrelated source of processing errors once they went looking.
"PI1.1 is where I find out whether a company actually understands its own system, or whether it's been running on inherited logic nobody's fully mapped. Half the 'processing bugs' I see aren't bugs — they're the system doing exactly what the code says, and the code disagreeing with what three different people assumed the code did." — Dana Whitfield, Director of Data Engineering, Brightferry Commerce
PI1.2 — Inputs are complete and accurate
PI1.2 governs the front door: before your system acts on data, does it verify that the data is complete and accurate against the specifications defined in PI1.1? This is where input validation lives — format checks, range checks, required-field checks, referential-integrity checks (does this SKU actually exist?), duplicate detection, and authorization checks on the source of the input itself.
The key operational distinction from ordinary application input validation is scope: PI1.2 isn't only about a web form rejecting a malformed email address. It covers every input channel into the processing pipeline — API calls from partner systems, batch file uploads, EDI transactions, webhook events, and internal system-to-system calls. Brightferry's 1,140-order failure happened downstream of input validation — the orders were valid when they arrived — but a mature PI1.2 control set would still have included input reconciliation counts (how many records arrived vs. how many were acknowledged) that could have flagged the discrepancy far earlier than a customer's finance team did.
"The teams that get PI1.2 right treat every input channel like a border crossing — count what comes in, log where it came from, and reject or quarantine anything that doesn't match the manifest. The teams that get it wrong treat input validation as 'the form has required fields.'" — Nina Cho, CPA, Partner, Ridgeline Assurance Group
Table 6: Input Control Matrix
Input control | What it checks | Example implementation | Example evidence |
|---|---|---|---|
Schema/format validation | Data conforms to expected structure and type | API request schema validation; file-format checks on batch uploads | Validation error logs; rejected-record reports |
Required-field and range checks | Mandatory fields present; values within defined bounds | Order quantity must be a positive integer under a configured ceiling | Business-rule configuration; sample rejected transactions |
Referential-integrity checks | Referenced entities actually exist | SKU lookup against product catalog before order acceptance | Catalog-match failure logs |
Duplicate detection | The same transaction isn't submitted or ingested twice | Idempotency keys on API submissions; hash-based duplicate checks on batch files | Deduplication logs; idempotency key audit trail |
Record-count reconciliation | The number of records received matches the number acknowledged | Source system sends a manifest count; ingestion pipeline confirms match | Manifest vs. ingest count reports |
Source authentication/authorization | Only approved systems or users can submit input | API keys/mTLS on partner integrations; signed webhook payloads | Access logs; API key rotation records |
Quarantine/rejection handling | Invalid input is isolated, not silently dropped or silently processed | Dead-letter queues for failed validations; rejection notification to source | Dead-letter queue contents; rejection notification logs |
PI1.3 — Processing is complete, valid, accurate, timely, and authorized
PI1.3 is the largest and most heavily tested criterion in the series, because it's where the actual work happens — the calculations, transformations, matching logic, and routing decisions that turn validated input into correct output. This is also the criterion Brightferry's incident landed squarely inside: the orders passed PI1.2 (they were valid on arrival) and would have produced correct PI1.4 output (had they arrived there), but the processing stage itself — the schema migration and its interaction with the batch job — silently dropped them. A completeness failure, inside processing, invisible until someone downstream went looking.
PI1.3 controls typically fall into a few families: completeness controls (record counts and control totals carried through every processing stage, so a drop anywhere is detectable), accuracy controls (automated recalculation, dual calculation paths for high-risk logic, checksum or hash validation on data as it moves between stages), timeliness controls (SLA monitoring on batch windows and stream-processing latency, with alerting on breach), and authorization controls (role-based execution permissions, change-controlled deployment so processing logic itself can't be altered without approval — this is where PI1.3 leans directly on change management controls inherited from the Common Criteria). A schema migration like the one that broke Brightferry's pipeline is, in control terms, a change — and it should have gone through the same change-approval and post-deployment validation gate as any other production change.
"Every processing failure I've ever investigated traces back to one of two things: a control total that existed but nobody monitored, or a control total that never existed at all. Build the control total first. Everything else — the dashboards, the alerts, the reconciliation reports — is downstream of having a number to compare against." — Dana Whitfield, Director of Data Engineering, Brightferry Commerce
Table 7: Processing Control Matrix
Processing control | Attribute addressed | Example implementation | Example evidence |
|---|---|---|---|
End-to-end record-count reconciliation | Completeness | Control totals compared at every pipeline stage (ingest, transform, load) | Stage-by-stage count reconciliation reports |
Automated recalculation / dual-path validation | Accuracy | High-risk calculations (tax, currency conversion, payout amounts) computed twice via independent logic and compared | Recalculation exception reports |
Checksum / hash validation between stages | Completeness, accuracy | Hash of record set computed before and after transformation | Hash comparison logs |
Business-rule enforcement engine | Validity | Centralized rules engine rejects transactions violating defined logic | Rules engine configuration; rejected-transaction logs |
SLA / latency monitoring | Timeliness | Batch job runtime and stream-processing lag tracked against defined thresholds | SLA dashboards; breach alert tickets |
Change-controlled deployment gates | Authorized | Processing logic changes require peer review and approval before production release | Change-management tickets; deployment approval records |
Role-based execution permissions | Authorized | Only specific service accounts/roles can trigger processing jobs | IAM role configuration; access review logs |
Idempotent processing design | Completeness, accuracy | Reprocessing a batch after failure doesn't create duplicates | Idempotency test results; reprocessing logs |
PI1.4 — Outputs are complete, accurate, and reach the right recipients
PI1.4 shifts the lens to the far end of the pipeline: once processing is done, is the output complete and accurate, and does it actually reach the intended recipient, in the intended format, on time? This criterion catches a category of failure that's easy to overlook because processing itself worked perfectly — the calculation was right, the record wasn't dropped — but the output never made it where it needed to go, or went to the wrong place, or arrived in a format the recipient's system couldn't consume.
Concretely, PI1.4 covers report-generation accuracy (does the monthly invoice report match the underlying transaction data?), delivery-completeness (did every record intended for export actually get exported?), recipient-authorization (is the output going only to the customer, system, or user entitled to receive it — a control that overlaps meaningfully with access-control and confidentiality concerns), and format/timing conformance (does the output match the agreed schema and arrive within the committed SLA?). A reconciliation file that's technically complete and accurate but gets delivered to the wrong SFTP folder, or delivered nine hours late and missed a downstream batch window, is a PI1.4 failure just as surely as a miscalculated total would be.
"I've seen more Processing Integrity findings tied to output delivery than to the actual math. The calculation engine gets all the engineering attention because it's interesting. Nobody stress-tests the export job that pushes the result to the customer's SFTP server at 2 a.m. — until it silently fails one night and nobody notices for a week." — Sam Ilori, Director of Engineering, Kestrel Pay
Table 8: Output Control Matrix
Output control | What it checks | Example implementation | Example evidence |
|---|---|---|---|
Output-vs-source reconciliation | Output totals match the underlying processed data | Automated comparison of report totals against source ledger before release | Reconciliation reports; sign-off records |
Delivery-completeness verification | Every intended record was actually exported/delivered | File-count and checksum verification post-delivery | Delivery confirmation logs; checksum match reports |
Recipient authorization checks | Output is delivered only to entitled recipients | Access-controlled delivery endpoints; recipient allow-lists | Delivery access logs; recipient configuration records |
Format/schema conformance | Output matches the agreed schema the recipient expects | Automated schema validation before transmission | Schema validation logs; failed-transmission alerts |
Delivery SLA monitoring | Output reaches the recipient within the committed window | Monitoring on export/delivery job completion times | SLA dashboards; late-delivery incident tickets |
Failed-delivery alerting and retry | Delivery failures are detected and remediated, not silently lost | Automated retry with escalation after N failures | Retry logs; escalation tickets |
PI1.5 — Storage of inputs, in-process data, and outputs
PI1.5 closes the loop: once data has been received, processed, and output, is it stored completely, accurately, and in a timely manner — so that the record persists correctly and can be retrieved, reconciled, or reproduced later? This criterion covers database write integrity, backup completeness for processing-relevant data, archival accuracy, and the timeliness of storage operations themselves (a write that eventually succeeds three hours after the transaction is often just as problematic as a write that fails outright, if downstream systems needed it sooner).
PI1.5 is where Brightferry's incident technically resolved — the 1,140 orders were captured and stored in the payment system, just never propagated to storage in the order-fulfillment and reporting tables. A mature PI1.5 control set includes storage-completeness reconciliation (does the number of records written match the number expected?), write-integrity verification (transaction/commit confirmation, not just a fire-and-forget write), and storage-timeliness monitoring (is data landing in downstream stores within an acceptable lag window?). This criterion also overlaps with backup integrity — a backup that captures a corrupted or incomplete state is a PI1.5 problem wearing a disaster-recovery costume.
"PI1.5 is the boring cousin of the five criteria, and that's exactly why it's dangerous. Nobody gets excited about verifying that a write actually committed. But that's precisely the gap that let Brightferry's numbers drift for three weeks before anyone noticed." — Dana Whitfield, Director of Data Engineering, Brightferry Commerce
PI1.1–PI1.5: the full controls-and-evidence map
Pulling the five criteria together into one reference table is the single most useful artifact I hand clients at the start of a Processing Integrity scoping engagement — it becomes the backbone of the control matrix the auditor will eventually test against.
Table 9: PI1.1–PI1.5 — Controls and Evidence Summary
Criterion | Requirement (plain language) | Representative controls | Representative audit evidence |
|---|---|---|---|
PI1.1 | Define processing objectives and data specifications | Data dictionaries; documented business rules; system/data-flow diagrams; product specifications | Data dictionary documents; approved business-rule specs; architecture/data-flow diagrams |
PI1.2 | Inputs are complete and accurate before processing | Schema/format validation; referential-integrity checks; duplicate detection; record-count reconciliation at ingest | Validation error logs; rejected-record reports; manifest-vs-ingest count reports |
PI1.3 | Processing is complete, valid, accurate, timely, and authorized | Control totals across pipeline stages; automated recalculation; SLA/latency monitoring; change-controlled deployment; role-based execution permissions | Stage reconciliation reports; recalculation exception reports; SLA dashboards; change-management tickets |
PI1.4 | Outputs are complete, accurate, and reach the right recipients | Output-vs-source reconciliation; delivery-completeness checks; recipient authorization; format/schema validation | Reconciliation sign-offs; delivery confirmation logs; recipient access configuration |
PI1.5 | Inputs, in-process data, and outputs are stored completely, accurately, and timely | Storage-completeness reconciliation; write-integrity/commit verification; backup integrity checks; storage-lag monitoring | Storage reconciliation reports; backup verification logs; storage-lag alert history |
The integrity flow: input, processing, output, with checkpoints at every stage
The cleanest way to internalize how PI1.2 through PI1.5 fit together operationally is to picture data moving through your system as a pipeline with a validation gate at every junction, not just at the front door. Brightferry's failure happened precisely because there was a gate at input and (eventually) correct behavior at output, but nothing in between — no checkpoint verifying that what left the input stage was the same count that entered the processing stage, and what left processing was the same count that reached storage and output.
flowchart LR
A[Data Source<br/>customer, partner, device] -->|submit| B[Input Validation<br/>PI1.2]
B -->|reject/quarantine invalid| B1[Dead-Letter Queue<br/>+ notification]
B -->|valid records| C[Processing Engine<br/>PI1.3]
C -->|control totals in = control totals out?| C1{Reconciliation<br/>Checkpoint}
C1 -->|mismatch| C2[Exception Queue<br/>+ alert]
C1 -->|match| D[Output Generation<br/>PI1.4]
D -->|output vs source reconciliation| D1{Reconciliation<br/>Checkpoint}
D1 -->|mismatch| D2[Delivery Held<br/>+ alert]
D1 -->|match| E[Delivery to Authorized Recipient]
C -.-> F[Storage<br/>PI1.5]
D -.-> F
F -->|write/commit verification| F1{Storage<br/>Reconciliation}
F1 -->|mismatch| F2[Storage Exception<br/>+ alert]
G[Audit Trail Logging] -.captures every stage.- B
G -.-> C
G -.-> D
G -.-> FEvery arrow into a reconciliation checkpoint in that diagram represents a control total: a number generated at the start of a stage that gets compared against a number generated at the end of it. That comparison — not the processing logic itself — is what turns "the job finished" into "the job finished correctly." Brightferry's nightly batch job had no equivalent of the C1 checkpoint in the diagram above; it moved data from processing toward storage with no reconciliation gate in between, which is exactly how 1,140 records disappeared without triggering a single alert.
Error handling and exception management
No processing system runs error-free, and Processing Integrity doesn't require perfection — it requires that errors are caught, logged, and resolved through a defined process rather than silently swallowed or manually patched with no trail. This is one of the more counterintuitive things I tell clients early in scoping: an auditor is not alarmed by evidence that errors occurred. An auditor is alarmed by the absence of evidence that errors were detected and handled.
A mature error-handling program for Processing Integrity purposes has a few consistent features: exceptions are routed to a defined queue or ticketing system rather than logged and forgotten; every exception has an owner and a resolution SLA; exceptions are categorized (validation failure, processing failure, timeout, authorization failure) so patterns are visible over time; and — critically — reprocessing or manual correction of an exception is itself logged and, where it touches financial or customer-facing data, requires a second-person review before it's applied. Brightferry's post-incident rebuild included exactly this: a dedicated exception queue for any record that failed a reconciliation checkpoint, with a same-business-day SLA and a mandatory second reviewer for any manual data correction.
"The failure mode I see most often isn't 'no error handling.' It's error handling that exists but dead-ends into a Slack channel nobody's assigned to monitor. A queue with no owner is functionally the same as no queue." — Sam Ilori, Director of Engineering, Kestrel Pay
Table 10: Error-Handling Control Matrix
Error-handling control | Purpose | Example implementation | Example evidence |
|---|---|---|---|
Defined exception categories | Distinguish failure types for trend analysis | Taxonomy: validation, processing, timeout, authorization, delivery failures | Exception category configuration; category-tagged tickets |
Exception queue with assigned ownership | Prevent errors from being silently dropped | Dead-letter queue routed to a monitored ticketing system with an on-call owner | Ticket assignment records; on-call rotation schedule |
Resolution SLA | Ensure timely remediation of exceptions | Same-business-day SLA for financial/customer-facing exceptions | SLA policy document; ticket resolution-time reports |
Second-person review on manual correction | Prevent unauthorized or erroneous manual data changes | Manual correction requires approval from a second engineer or analyst | Approval workflow logs; correction audit trail |
Root-cause tracking | Prevent recurrence of the same failure class | Post-incident review logged against each exception category | Root-cause analysis records; recurring-issue trend reports |
Exception volume monitoring | Detect systemic issues before they become material | Dashboards tracking exception rate over time, with threshold alerts | Exception-rate dashboards; threshold-breach alerts |
Reconciliation: the control that actually catches what everything else misses
If there's one control category that separates a Processing Integrity program that works from one that exists only on paper, it's reconciliation. Reconciliation is the disciplined practice of comparing two independent representations of the same data — a source count against a destination count, a calculated total against an expected total, a system-of-record against a downstream copy — and treating any mismatch as a signal requiring investigation, not an anomaly to be quietly explained away.
Reconciliation operates at multiple altitudes. Record-level reconciliation compares individual transactions across systems (does this specific order ID exist, with matching values, in both the order system and the payment system?). Batch-level reconciliation compares control totals for an entire processing run (did the sum of amounts processed in tonight's batch match the sum of amounts submitted?). Period-level reconciliation compares aggregate totals over a longer window (does this month's revenue-recognition total match the sum of daily settlement totals?) and is often the layer finance teams run independently of engineering — which is precisely how Fennimore & Vance caught Brightferry's gap before Brightferry did. The lesson embedded in that fact is one of the most important in this entire article: if your customer's reconciliation catches your processing error before your own does, you don't have a Processing Integrity program — you have a customer doing your quality assurance for you, for free, at the cost of your relationship.
"I tell every client the same uncomfortable truth: your customer's finance team is running a reconciliation whether you built one or not. The only question is whether you find the gap first, or they do." — Nina Cho, CPA, Partner, Ridgeline Assurance Group
Table 11: Reconciliation Control Matrix
Reconciliation type | What's compared | Frequency | Example evidence |
|---|---|---|---|
Record-level reconciliation | Individual transaction IDs and values across systems | Real-time or per-batch | Match/mismatch reports; exception tickets for unmatched records |
Batch-level reconciliation | Control totals for an entire processing run | Per batch (e.g., nightly) | Batch reconciliation reports with sign-off |
Period-level reconciliation | Aggregate totals over a billing/reporting period | Monthly/quarterly | Period-end reconciliation reports; finance sign-off |
Cross-system reconciliation | Same data represented in two independent systems (e.g., order system vs. payment gateway) | Daily or per-batch | Cross-system variance reports |
Source-to-report reconciliation | Underlying transactional data vs. generated customer-facing reports | Per report generation | Report-vs-source variance checks; release sign-off |
Reconciliation exception follow-up | Every flagged mismatch is investigated and closed | Ongoing, SLA-bound | Exception resolution log with root cause noted |
Audit trails and traceability
Every control described so far depends on one underlying capability: the ability to reconstruct, after the fact, exactly what happened to a given piece of data — when it entered the system, what validation it passed or failed, what transformations were applied, what output it produced, and who or what triggered each step. That capability is the audit trail, and for Processing Integrity purposes it needs to be more granular than typical security logging. A security log answers "who accessed what, when." A Processing Integrity audit trail answers "what happened to this specific transaction, end to end" — which usually means correlating logs across multiple systems using a consistent transaction or correlation ID.
Practically, this means every transaction should carry an identifier that persists across every system boundary it crosses — ingestion, validation, processing, storage, and output — so that when an auditor (or your own engineer at 2 a.m.) needs to trace order #48291 from arrival to delivery, the trail doesn't have five different IDs across five different systems with no mapping between them. Brightferry's rebuild included exactly this: a single correlation ID assigned at ingestion and threaded through every downstream table, log entry, and export file, which turned a future version of the same incident from a three-week mystery into a fifteen-minute lookup.
"An audit trail that can't answer 'what happened to this one transaction' in under a few minutes isn't an audit trail — it's a pile of logs you're hoping someone can correlate manually under deadline pressure. That's not a control, that's a prayer." — Dana Whitfield, Director of Data Engineering, Brightferry Commerce
Automated vs. manual processing controls
Not every Processing Integrity control needs to be automated, but auditors — and, frankly, reality — favor automation for anything that runs at volume or frequency, because manual controls degrade under fatigue and staff turnover in ways automated controls don't. The right mix depends on transaction volume, the criticality of the specific control point, and how much lead time you have before the audit period starts. A useful rule of thumb: automate anything that runs more than daily or touches more than a handful of records per instance, and reserve manual controls for genuinely judgment-based decisions — like reviewing a flagged high-value exception before it's released.
Table 12: Automated vs. Manual Processing Controls
Dimension | Automated controls | Manual controls |
|---|---|---|
Best suited for | High-volume, high-frequency processing (every transaction, every batch) | Low-volume, judgment-based decisions (exception review, high-value approvals) |
Consistency | High — applies identically every time | Variable — depends on the individual performing it |
Auditor confidence | Generally higher, given tamper-evident logging | Requires stronger secondary evidence (sign-offs, checklists) to be persuasive |
Cost to implement | Higher upfront (engineering time) | Lower upfront, but higher ongoing labor cost at scale |
Failure mode | Silent failure if the automation itself breaks and isn't monitored | Human error, fatigue, inconsistent application under time pressure |
Example | Automated record-count reconciliation on every batch run | Analyst reviewing a flagged $50,000+ payout exception before release |
Evidence style | System-generated logs, dashboards, automated reports | Signed checklists, approval tickets, review notes |
Batch processing vs. real-time processing: different integrity playbooks
The controls that keep a nightly batch job honest look meaningfully different from the controls that keep a real-time, transaction-by-transaction pipeline honest, and conflating the two is a common early mistake. Batch processing gives you a natural checkpoint — the batch has a defined start and end, so reconciliation can happen once per run, comparing a clean "before" count to a clean "after" count. Real-time processing has no such checkpoint; by the time you'd notice a problem with a single transaction, thousands more may have already flowed through the same code path, so the control emphasis shifts toward per-transaction validation, circuit breakers, and continuous sampling rather than end-of-run reconciliation.
Brightferry's failure was, not coincidentally, a batch-processing failure — the kind that hides well precisely because reconciliation only happens once a day, giving a defect three weeks of runway before a control totaled it up. A real-time payment processor like Kestrel Pay faces the opposite risk profile: a defect in real-time logic can replicate across thousands of transactions in minutes, which is why real-time systems lean harder on pre-deployment testing, canary releases, and automatic circuit breakers that halt processing the moment an anomaly rate crosses a threshold.
Table 13: Batch vs. Real-Time Processing Integrity Considerations
Consideration | Batch processing | Real-time processing |
|---|---|---|
Natural reconciliation point | Yes — start/end of each batch run | No — requires continuous or sampled checks |
Detection lag if a control is missing | Can be long (hours to weeks) | Can be very short but blast radius grows fast |
Primary integrity control | Control-total reconciliation per run | Per-transaction validation, circuit breakers, anomaly detection |
Rollback/reprocessing | Often straightforward — rerun the batch | Harder — transactions may have already triggered downstream effects |
Deployment risk | Changes tested against a full batch before go-live | Canary releases and gradual rollout reduce blast radius |
Monitoring cadence | Post-run reconciliation reports | Real-time dashboards with threshold alerting |
Example failure mode | Silent record drop during a schema migration | A pricing bug replicating across thousands of live transactions in minutes |
Processing Integrity and Security: related, but not the same control set
It's worth being explicit about where Processing Integrity ends and Security begins, because the two categories share infrastructure without being interchangeable — a mistake I see almost as often as the source-data-quality confusion covered earlier. Security's Common Criteria establish the baseline control environment: access control, change management, system monitoring, incident response. Processing Integrity depends on that baseline being solid — you cannot have trustworthy processing on top of an access-control model that lets anyone modify calculation logic — but it then asks a narrower, more specific question about correctness that Security alone never addresses. A system can be extremely secure (nobody unauthorized can touch it) and still process data incorrectly (authorized processes calculate the wrong number). Brightferry's incident is the textbook illustration: their Security controls were sound, and the failure happened entirely within authorized, correctly-accessed processing.
"Security and Processing Integrity ask different questions of the same system. Security asks, 'can the wrong person get in?' Processing Integrity asks, 'even when only the right people and the right code are running, is the math correct?' You need both answers, and one doesn't substitute for the other." — Tobias Lindqvist, CISO, Fennbrook Financial
Table 14: Processing Integrity vs. Security — Where They Overlap and Where They Diverge
Question | Security (Common Criteria) | Processing Integrity |
|---|---|---|
Core question | Is the system protected against unauthorized access and change? | Is authorized processing complete, valid, accurate, timely, and authorized? |
Mandatory in every SOC 2? | Yes | No — optional, added when processing correctness is a customer commitment |
Criteria series | CC1–CC9 | PI1.1–PI1.5 |
Shared control foundation | Change management, access control, system monitoring | Inherits and builds on the same change-management and access-control controls |
Distinct focus | Confidentiality/availability of the environment broadly | Correctness of calculations, transformations, and data flow specifically |
Example finding unique to each | Unpatched vulnerability allowing unauthorized access | Currency-conversion rounding error understating totals |
Typical evidence overlap | Change tickets, access logs, deployment approvals also support PI1.3 | Reconciliation reports and control totals are unique to Processing Integrity |
Building your Processing Integrity control matrix
Once you've decided Processing Integrity belongs in scope, the practical next step is building a control matrix — a working document that maps each PI1 criterion to the specific controls your organization already has, the gaps that remain, and who owns closing them. This is the artifact your auditor will eventually want to see, and it's also the single most useful internal tool for keeping the program from drifting once the audit is over. I recommend structuring it exactly the way you'll eventually need to present it: criterion, control description, control owner, implementation status, and evidence location.
Table 15: Processing Integrity Control Matrix Worksheet (Template Structure)
Criterion | Control description | Control owner | Implementation status | Evidence location |
|---|---|---|---|---|
PI1.1 | Data dictionary and business-rule specifications maintained and reviewed annually | Data Engineering Lead | Example: Implemented | Confluence/wiki data dictionary page |
PI1.2 | Input schema validation and referential-integrity checks on all ingestion channels | Platform Engineering | Example: Partially implemented | Validation service config repo; rejected-record dashboard |
PI1.3 | Control-total reconciliation at every pipeline stage | Data Engineering | Example: Gap — planned Q3 | Reconciliation service (planned) |
PI1.4 | Output-vs-source reconciliation before customer-facing report release | Reporting/Analytics team | Example: Implemented | Report release checklist; reconciliation logs |
PI1.5 | Storage write-confirmation and backup completeness checks | Infrastructure/SRE | Example: Implemented | Storage monitoring dashboard; backup verification logs |
Filling in this table honestly — including the gaps, not just the wins — is what turns a control matrix into something useful rather than a document written to look good in an auditor meeting. The gaps are also your project plan: each "planned" or "gap" row becomes a remediation ticket with an owner and a target date, which is exactly what a SOC 2 Trust Services Criteria Mapping Template is built to help you organize across all five TSC categories at once, not just Processing Integrity.
Evidence collection during the audit period
Designing the controls is half the work; the other half is making sure evidence of those controls operating accumulates automatically across the audit period, rather than being reconstructed under deadline pressure the week before fieldwork starts. Processing Integrity evidence tends to be higher-volume and more granular than Security evidence, because auditors will sample reconciliation results and exception handling across the entire period, not review a handful of point-in-time artifacts.
Table 16: Evidence Collection Cadence for Processing Integrity
Evidence type | Collection frequency | Who generates it | Sampling likelihood in fieldwork |
|---|---|---|---|
Input validation/rejection logs | Continuous (per transaction/batch) | Automated system logging | High — auditors sample across the full period |
Control-total reconciliation reports | Per batch run or daily | Automated reconciliation service | High |
Exception tickets and resolution records | Per exception, ongoing | Exception-handling queue/ticketing system | High |
Output-vs-source reconciliation sign-offs | Per report/output cycle | Reporting team, with sign-off | Medium-high |
Change-management tickets for processing logic | Per change | Engineering, via change-management process | High |
SLA/timeliness monitoring reports | Continuous, reviewed periodically | Monitoring/observability tooling | Medium |
Storage/backup verification logs | Daily or per backup cycle | Infrastructure/SRE | Medium |
Data dictionary and business-rule review sign-off | Annually or upon material change | Data Engineering / GRC | Low-medium |
"Processing Integrity evidence punishes teams that only think about audits once a year. Security evidence can sometimes be reconstructed retroactively from system configuration. Reconciliation evidence can't — if you didn't run the comparison in March, there's no way to prove in October that March's numbers matched." — Nina Cho, CPA, Partner, Ridgeline Assurance Group
Common pitfalls when implementing Processing Integrity
Across the engagements I've advised on, the same handful of mistakes show up again and again — often from teams with genuinely strong engineering practices who simply hadn't framed their existing controls through a Processing Integrity lens before the audit conversation started.
Table 17: Common Processing Integrity Implementation Pitfalls
Pitfall | Why it happens | Consequence | Fix |
|---|---|---|---|
Treating input validation as the whole control set | Teams equate "we validate forms" with full PI1.2–PI1.3 coverage | Processing-stage failures (like Brightferry's) go undetected | Add control-total reconciliation at every pipeline stage, not just at intake |
No documented business rules (PI1.1 skipped) | Logic lives in engineers' heads or in undocumented code | Nothing for the auditor — or the team — to test correctness against | Write and maintain data dictionaries and business-rule specifications |
Reconciliation exists but nobody monitors it | A report gets generated but sits unread | Discrepancies accumulate silently for weeks or months | Assign an owner and an SLA to every reconciliation report |
Manual corrections applied without a trail | Engineers "just fix it in the database" during an incident | No audit trail; potential unauthorized-change finding | Require ticketed, second-reviewed manual correction processes |
Confusing Processing Integrity with data-quality guarantees | Teams assume PI means promising customer input is always correct | Scope creep, unrealistic customer expectations, difficult audit conversations | Explicitly document what's in scope (system processing) vs. out of scope (source data accuracy) |
Only testing the happy path before go-live | Deployment testing focuses on expected inputs, not edge cases or failure modes | Undetected gaps surface only under real production volume | Include reconciliation and exception-handling testing in pre-deployment validation |
Evidence collected only near audit time | Teams "catch up" on documentation right before fieldwork | Evidence doesn't cover the full period; backdating risk | Automate evidence generation so it accumulates continuously across the period |
What it costs and how long it takes to add Processing Integrity
Adding Processing Integrity to an existing SOC 2 scope is rarely a from-scratch project — most of the underlying infrastructure (logging, change management, monitoring) already exists as part of Security controls. The incremental work is mostly in reconciliation tooling, documentation (PI1.1), and closing gaps in error-handling and evidence generation. Timelines and cost vary by how much reconciliation infrastructure already exists versus needs to be built.
Table 18: Illustrative Cost and Timeline to Add Processing Integrity Scope
Starting point | Typical timeline to readiness | Typical incremental cost driver | Illustrative example |
|---|---|---|---|
Strong reconciliation/monitoring already exists; mostly documentation gaps | 4–8 weeks | Analyst/GRC time to document PI1.1 specifications and build the control matrix | A billing platform with existing reconciliation tooling, missing only PI1.1 documentation |
Partial reconciliation exists; some pipeline stages uncovered | 2–4 months | Engineering time to build missing control-total reconciliation and exception queues | Brightferry's rebuild — reconciliation existed at intake and output, not mid-pipeline |
No reconciliation infrastructure; building from scratch | 4–6 months | Significant engineering investment in reconciliation services, audit trail correlation IDs, and monitoring | An early-stage payment platform adding Processing Integrity ahead of its first Type II |
Incremental audit fee impact | N/A | Additional auditor sampling/testing hours for the added TSC category | Typically a moderate percentage increase over Security-only audit fees, varying by transaction volume and auditor |
A SOC 2 Gap Analysis Tool is the fastest way to get a rough read on which bucket your organization falls into before committing to a timeline with a customer, and pairing it with a broader SOC 2 Readiness Assessment: Pre-Audit Preparation Checklist helps you see how Processing Integrity gaps stack up against everything else on your pre-audit punch list.
Case study 1: Brightferry Commerce — closing the mid-pipeline gap
Brightferry's response to the $180,000 discrepancy started with a full pipeline audit, mapped stage by stage against the flow described earlier in this article. Tessa's team found exactly one structural gap: reconciliation existed at input (PI1.2 was solid) and, once records made it that far, output reconciliation was solid too (PI1.4). Nothing existed to verify that what left processing matched what entered it — the exact mid-pipeline blind spot the schema migration had exploited.
Over ten weeks, Brightferry's data engineering team built a control-total reconciliation service that ran after every processing stage, comparing record counts and value totals against the prior stage and raising an exception the moment a mismatch appeared. They added a correlation ID threaded through every table and log entry so any single order could be traced end to end in minutes rather than days. They formalized PI1.1 by documenting pricing, tax, and discount-stacking logic that had previously lived only in three engineers' heads, which — as a side benefit — caught and fixed the unrelated discount-stacking bug Dana Whitfield had flagged during the review. And they instituted a mandatory second-reviewer approval on any manual data correction, closing the gap that had let the original incident go uninvestigated for three weeks.
Brightferry's next Type II report included Processing Integrity in scope for the first time, with zero exceptions noted on the PI1 criteria. Fennimore & Vance's controller received the report, ran her own reconciliation against the new quarter's data, and found a variance of under $1,900 against a stated tolerance threshold — down from $180,000. The $3.2 million renewal closed six weeks later. Tessa's team now runs the same reconciliation dashboard as a standing weekly review, independent of the audit cycle.
Table 19: Case Study Outcomes at a Glance
Organization | Core Processing Integrity gap | Remediation | Quantified outcome |
|---|---|---|---|
Brightferry Commerce (e-commerce order orchestration) | No mid-pipeline reconciliation between processing and storage stages | Control-total reconciliation service; correlation IDs; documented business rules; second-reviewer approval on manual corrections | Discrepancy reduced from $180,000 to under $1,900/quarter; $3.2M renewal closed |
Kestrel Pay (marketplace payments and payouts) | Duplicate payout risk from non-idempotent retry logic | Idempotency keys on all payout requests; automated duplicate-detection reconciliation | Prevented an estimated $420,000 in duplicate payouts over the following two quarters |
Anchorline Freight (logistics/EDI invoicing) | Dropped EDI records causing incomplete invoicing to trading partners | EDI manifest-count reconciliation; exception queue with same-day SLA; partner-facing delivery confirmation | Recovered approximately $95,000/month in previously unbilled freight revenue |
Case study 2: Kestrel Pay — the duplicate-payout near-miss
Kestrel Pay processed payouts for a marketplace of independent sellers, and its payout engine included a retry mechanism designed to handle transient failures in its banking partner's API. During a routine load-testing exercise, Sam Ilori's engineering team discovered that under specific timeout conditions, a retried payout request could execute twice against the banking partner's API without the system recognizing it as a duplicate — a PI1.3 authorization and accuracy risk hiding inside what looked, on the surface, like solid reliability engineering.
The retry logic had no idempotency safeguard: each retry generated a fresh request rather than referencing the original attempt, so a payout that timed out on Kestrel's side but had actually succeeded on the banking partner's side could be paid twice. Modeling the exposure against Kestrel's transaction volume, the team estimated that if the defect had triggered at its worst-case rate across a typical processing month, duplicate payouts could have reached $420,000 before detection — money that, once paid out to a marketplace seller's bank account, is materially harder and slower to claw back than it was to prevent.
Kestrel's fix added idempotency keys to every payout request, so a retried request referencing the same key would be recognized and safely deduplicated rather than re-executed, paired with a reconciliation job comparing payout requests initiated against payouts confirmed by the banking partner. The defect was caught in load testing, before it reached production at scale — but the incident became the trigger for adding Processing Integrity to Kestrel's SOC 2 scope, since the near-miss made clear that authorization and accuracy risk existed in code that had passed every Security-focused review it had ever had.
"Our Security review never would have caught this, because nothing about it was a security problem — no unauthorized person did anything. It was authorized code doing the wrong thing under a specific, narrow condition. That's the entire reason Processing Integrity exists as its own category." — Sam Ilori, Director of Engineering, Kestrel Pay
Case study 3: Anchorline Freight — the invoices that never got sent
Anchorline Freight processed EDI transactions between shippers and carriers, matching shipment confirmations to generate invoices. Raj Subramaniam, Head of GRC, discovered during a routine internal audit prep exercise that Anchorline's EDI parser silently discarded any transaction that arrived with a minor formatting variant outside its expected schema — rather than rejecting it visibly or routing it to an exception queue, the parser simply skipped the record and moved on, logging nothing that would flag the drop.
Because several of Anchorline's smaller trading partners used slightly non-standard EDI formatting, a meaningful share of legitimate shipment confirmations were being silently dropped every month — shipments that had actually occurred, for which Anchorline was contractually entitled to invoice, but for which no invoice was ever generated. Raj's team estimated the unbilled revenue at roughly $95,000 per month once they reconciled a sample of dropped transactions against the shippers' own shipment records — money Anchorline had simply never asked for, because its own system had no way of knowing it was owed.
The fix combined a PI1.2 improvement (accepting and normalizing minor formatting variants instead of silently discarding them) with a PI1.3 exception queue (anything that still failed parsing was routed for manual review with a same-day SLA rather than dropped) and a PI1.4 control (a manifest-count reconciliation confirming that every shipment confirmation received produced either an invoice or a logged exception, with no third outcome possible). Within the first full quarter after the fix, Anchorline recovered the full $95,000 in previously unbilled monthly revenue and used the reconciliation data to renegotiate two trading-partner integrations that had been silently costing them money for over a year.
"The worst part wasn't the lost revenue. It was that the system had been telling us, every single month, that everything processed successfully — because as far as the code was concerned, silently dropping a record it couldn't parse was success." — Raj Subramaniam, Head of GRC, Anchorline Freight
Processing Integrity as a business opportunity, not just an audit line item
It's easy to frame Processing Integrity purely as defensive work — the thing you build so a customer's finance team doesn't find your bugs before you do. That framing isn't wrong, but it undersells what's actually on offer. For any company whose product touches money, inventory, claims, or usage-based billing, "we can prove our processing is complete and accurate, independently verified" is a sales asset, not just an audit checkbox. Enterprise procurement teams in payments, healthcare, and logistics increasingly ask for Processing Integrity by name, precisely because they've been burned by a vendor whose Security controls were fine and whose numbers were wrong.
The Brightferry story is the version of this that shows up in board decks and renewal negotiations across the industry, with different company names attached: a processing gap nobody built a control for, discovered by a customer instead of by the vendor, threatening a deal that dwarfs the cost of the fix many times over. The inverse is just as real, and less discussed — a vendor that can put a clean Processing Integrity report in front of a prospect during the first security review, before a competitor even gets asked the question, wins procurement cycles faster and with fewer follow-up rounds. Compliance work rarely pays for itself this directly, but Processing Integrity, for the right kind of company, genuinely does.
There's also a durable internal payoff independent of any specific customer or audit: the reconciliation infrastructure, exception queues, and audit trails built to satisfy PI1.1–PI1.5 are the same tools that catch revenue leakage, prevent duplicate payments, and shorten incident response for reasons that have nothing to do with SOC 2. Anchorline Freight didn't just pass an audit — it found $95,000 a month it had been leaving on the table for over a year. That's not a compliance story. That's an operations story that happened to be discovered because someone asked a compliance question.
Organizations running both frameworks side by side get an added benefit: our guide to Running ISO 27001 and SOC 2 Together shows how the operational-resilience and data-handling controls ISO 27001 already requires can be re-used as supporting evidence for several PI1.3 and PI1.5 controls, cutting duplicate effort for teams pursuing both.