APP-015 Processing Integrity
Description
A documented processing specification states, for each service that transforms customer data, the expected inputs, the transformation rules and the required outputs with their delivery timing. Inputs are validated against that specification for completeness and accuracy before processing. Records that fail validation are rejected or quarantined rather than processed. Processing and delivery failures are detected, logged with enough context to identify the affected records and corrected under a defined process that records what was corrected and when. Stored inputs and outputs are protected against undetected alteration. They are reconciled against each other at defined intervals, with every exception investigated to a recorded outcome.
Rationale
Nothing in the library said that a system produces complete, accurate and timely output, so the entire SOC 2 processing integrity category sat unmapped while most service-provider audit reports include it. APP-011 holds input validation at the API boundary as a security control and the prohibition on sensitive data in error responses; APP-015 holds completeness and accuracy of the processing itself, which is a different test on the same request. APP-012 holds the integrity of the software artefacts that do the processing, not of the data passing through them. AIG-027 asks the same question of a probabilistic system through confidence thresholds and fallbacks. Record counts, control totals and checksums are the usual mechanism; the specification is what the counts are tested against, which is why a control without one cannot fail.
Applicability (9 profiles)
The processing specification covers the input pipelines the deployer controls, which is where Art.26.3 input data relevance is tested.
The processing specification covers the input pipelines the deployer controls, which is where Art.26.3 input data relevance is tested.
164.312(c) makes an integrity standard and a detection mechanism explicit obligations over the data itself. APP-015's reconciliation is the mechanism; its gap under this overlay is improper destruction, which the standard names alongside alteration.
Framework Mappings (10)
| HIPAA-164.312.c.1 | Integrity | partial |
| HIPAA-164.312.c.2 | Mechanism to Authenticate Electronic Protected Health Information | full |
| HIPAA-164.312.e.2.i | Integrity Controls | informative |
| SI-11 | Error Handling | informative |
| SI-15 | Information Output Filtering | full |
| PI1.1 | Preparation of Complete and Accurate Information | partial |
| PI1.2 | System Processing Completeness and Accuracy | full |
| PI1.3 | System Processing Outputs | full |
| PI1.4 | Error Outputs | full |
| PI1.5 | Stores Inputs and Outputs | full |
Evidence (3)
Processing specification for a service that transforms customer data, stating the expected inputs and their validation rules, the transformation rules and the required outputs with their delivery timing.
Example: Billing run processing specification v2.4, approved 2026-05-18, defining the input file format, the per-field validation rules, the rating logic and the delivery window for each output.
Test: Request the processing specification for a sampled service. Verify: (1) it states the expected inputs and the validation rule applied to each, (2) it states what the service does to those inputs, (3) it states the outputs, their format and the time by which they are delivered, (4) it names an owner and an approval date, (5) the validation rules in the specification are the rules the running service applies on a sampled record.
Processing log for the period showing the records rejected or quarantined at validation, the processing and delivery failures and the identifiers of the records each event affected.
Example: Pipeline exception log, August 2026, with 1,412 quarantined records and 6 delivery failures, each carrying the batch identifier and the failing rule.
Test: Obtain the processing log for the period. Verify: (1) records that failed validation were rejected or quarantined rather than processed, (2) each failure event identifies the records affected, (3) delivery failures against the specified timing are recorded, (4) every event in the period reconciles to an entry in the correction record or to a documented reason for no action, (5) a deliberately malformed test record is rejected and appears in the log.
Reconciliation and correction record showing the periodic comparison of inputs against outputs, the exceptions found and the correction applied to each.
Example: Monthly reconciliation record for the billing pipeline, August 2026, with input and output control totals per batch, four exceptions and the correction and re-run for each.
Test: Request the reconciliation and correction records for the period. Verify: (1) reconciliation ran at the defined interval for every service in scope, (2) it compares a control total or count between input and output rather than confirming the job finished, (3) each exception has an investigation outcome and, where a correction was made, what was corrected and when, (4) no exception is open beyond the defined period without a recorded reason.
Questions (3)
Is there a documented processing specification for each service that transforms customer data?
The specification is what an integrity check is tested against. Without one, a completeness check can only confirm that the job ran.
Which processing integrity controls are in place?
Quarantine and correction are the pair that matters: a pipeline that drops bad records silently passes a completeness check on what it kept.
How are processing exceptions handled?
Options run from strongest to weakest. This measures whether an exception reaches a conclusion, not whether it is visible.