What PI1.3 system processing requires in a SOC 2 examination
When a SOC 2 scope includes the processing integrity category, criterion PI1.3 asks the organization to implement policies and procedures over system processing so that its products, services and reporting meet its objectives. Teams often read this as a logging requirement, but logging is only one piece. The criterion covers whether the system does what it was designed to do, whether the organization notices when it does not, and whether there is a record of what happened. The points of focus under PI1.3 describe how that works: defining processing specifications and activities, detecting and correcting processing errors, recording system processing activities, and recording processing inputs. These points of focus are characteristics that can help an organization design and evaluate its controls. They are not separate requirements, and an assessor does not expect every one to be addressed in the same way.
The hard part is that PI1.3 cannot be satisfied until the organization has defined what correct processing means. Before any error detection or log review can be meaningful, someone must document the processing specifications: what the system should calculate, transform, route or report, to what accuracy, within what timeframe, and what counts as a failed run. Without that baseline, a team can produce pages of logs and still have no way to say whether a batch job, a billing calculation or a report was right. Confirm with your own stakeholders which products and reports are in scope and who owns each specification, since the auditor will ask how those definitions were approved and how they changed over the examination period.
Once the specifications exist, the controls become concrete. Ask which processing errors can occur, how they are detected (validation failures, reconciliations, job failure alerts, customer-reported defects), who reviews them, and how corrections are authorized and recorded. Keep the records that show each step: the specification version in force, the error or exception raised, the investigation, the correction and the sign-off. An auditor testing operating effectiveness across a period will sample those records, so the question to answer early is whether your tooling keeps them retrievable without manual reconstruction. Confirm with your auditor how much processing detail it expects in the system description and which evidence it will sample, because those choices determine how much of this work must be documented before fieldwork begins.
Which systems, jobs and teams fall under PI1.3 scope
PI1.3 only enters the examination when the organization includes processing integrity in scope, and then it applies to the processing pipelines the system description actually covers. The cards below set out the decisions that determine which jobs, outputs, teams and third parties the processing controls must reach.
Whether processing integrity is in scope
Processing integrity is optional. The common criteria CC1 to CC9 apply to every SOC 2, and the processing integrity category adds PI1 criteria only when the organization chooses to include it. Decide this with the customers and contracts that drive the report, because adding the category later changes the system description, the control matrix and the auditor's testing. Ask the auditor to confirm in writing which categories the engagement covers before control design starts.
Production pipelines and batch jobs
Any automated pipeline that transforms, calculates, routes or enriches customer data is a candidate for the system description. Include scheduled jobs, message queues, ETL flows and background workers that run without a person watching them. For each one, record its inputs, expected outputs, owner and failure behavior, since PI1.3 asks whether processing meets defined specifications and whether errors are detected and corrected.
Reporting outputs and data transformations
Dashboards, billing statements, exports, regulatory reports and customer-facing calculations are where processing errors become visible to customers. List every report that leaves the system and every transformation that shapes its numbers, including spreadsheet steps and manual adjustments. Reconciliation logic and rounding rules belong in scope because an error there can pass unnoticed through correct-looking infrastructure.
Teams that own processing logic
Name the engineering, data and operations teams that write, change and run processing logic, along with the product owners who approve its specifications. The examination looks for clear accountability over processing specifications and error handling, so ownership should be documented in the system description and reflected in access and change records. Shared ownership between platform and product teams is a common gap to resolve before fieldwork.
Subservice organizations that process data
Hosting providers, payment processors, analytics services and other vendors that process data on the organization's behalf may fall under subservice organization treatment. Decide whether to use the carve-out method, which excludes the vendor's controls and relies on its own report, or the inclusive method, which tests vendor controls directly. Obtain each vendor's current SOC report and map which processing steps it performs, so gaps between the two parties' controls are visible.
Self-hosted platforms inside the boundary
Self-hosted applications, job schedulers and monitoring stacks that run in the organization's own cloud accounts or data centers sit inside the system boundary. Their configuration, logs and access paths are evidence for PI1.3, so the boundary should name each component and the environment it runs in. Confirm with your tooling vendors which logs they produce and how long those logs remain available for the audit period.
How an assessor tests PI1.3 across Type 1 and Type 2
In a Type 1 examination, the assessor looks at whether the organization's processing specifications, error detection and correction, and processing records are designed to meet PI1.3 as of a single date. The assessor reads the system description, the written processing specifications, and the control matrix, then walks through the design with the people who run the system. Testing is mainly inquiry, inspection of documents, and observation of one or a few live examples. No sample across time is needed, so the assessor is asking whether the controls would work as described, not whether they did.
- Processing specifications: The assessor expects documented definitions of what the system must process, how long it may take, and what counts as a correct result, tied to the commitments in the system description.
- Error detection design: Look for validation rules, reconciliation checks, failed job alerts and exception queues, with an owner and a defined response path.
- Recording design: The assessor checks that processing activity is logged in a form that can later be reviewed, including job identifiers, timestamps and outcomes.
- Walkthrough evidence: Expect the assessor to trace one processing item from input to output and ask who reviews each exception.
- Common findings: Specifications that exist only in code, alerts with no named owner, and logs that are written but never reviewed.
Before the examination, confirm that each design statement in your control matrix points to a document or configuration an assessor can open on the as-of date.
A Type 2 examination tests whether PI1.3 controls operated effectively over the observation period. The assessor selects a sample of processing runs, error events and log entries across that period and inspects the evidence for each item. For every sampled error, the assessor expects to see that it was detected, that it was investigated, and that it was corrected or formally accepted. The number of items sampled depends on the assessor's judgment and the frequency of the control, so confirm the expected sample approach with your auditor early.
- Run sampling: Expect requests for batch or scheduled job records, with start and end times, status, and the reviewer's sign-off where a manual review is part of the control.
- Error log review: Expect the assessor to ask for the error log extract for the period, then to choose errors and trace each to a ticket or corrective action.
- Exception closure: Check that each exception has a documented cause, a correction, and a retest or confirmation that the output is now correct.
- Log integrity: Be ready to show that processing logs were not altered, for example by restricting write access and retaining logs for the agreed period.
- Common findings: Gaps in the log for part of the period, exceptions closed without evidence, and reviews performed late or not at all.
Before fieldwork, pull the full population of error events for the period and confirm that every one has a traceable closure record.
Implementing PI1.3 processing controls in sequence
This sequence turns PI1.3 from a policy statement into working processing controls: defined specifications, instrumented jobs, alerting, documented corrections and periodic review. Each step leaves an artifact an auditor can sample.
Inventory in-scope processing jobs and transformations
Start by listing every job, pipeline, batch process or transformation that changes data in a system within the SOC 2 boundary. The control owner, usually the product or platform lead with input from engineering, records what each job takes in, what it produces and which customer-facing commitments depend on it. Done means the list is reviewed against the system description so nothing in scope is missing. The output is a processing inventory that feeds every later step.
Write processing specifications for each job
For each item in the inventory, write a short specification covering the intended function, the data definitions it relies on, the expected outputs and the owner who approves changes. Engineering drafts it and the control owner approves it, with the approval recorded in version control or the ticketing system. The output is a specification register, versioned and referenced from the system description so that the team and the auditor can compare actual processing against what was promised.
Define expected outputs and tolerances
For each specification, state the expected outputs, the acceptable tolerance for deviation (for example, record counts, totals, timing or value ranges) and what counts as an out-of-tolerance result. Where tolerances depend on business rules, the owner should document the reasoning. Done means every job has measurable expectations that a monitoring rule can test. The output is a tolerance table linked to the specification register.
Instrument jobs to record activity and errors
Configure each in-scope job to write structured logs of its runs, inputs, outputs, errors and retries. Where the platform is self-hosted, the logging can draw on native audit capabilities. Nextcloud's admin_audit app, for example, writes additional event information to an audit.log file, and OpenBao audit devices record detailed JSON entries for every API request and response, including errors. Prometheus can scrape job metrics such as run counts and failure totals. Confirm each platform's exact logging behavior in its documentation before relying on it. Done means a test run produces the expected records.
Set alert rules and a triage path
Build alert rules that fire when a job fails, produces an output outside tolerance or stops reporting. Grafana Alerting can build rules from queries across several data sources and combine metrics and logs in one view, so a single rule can flag an error spike alongside a missing output. Each alert routes to a named on-call owner with a triage path: confirm the failure, assess affected customers or records, and open an exception ticket. The output is a tested alert catalog and a triage runbook.
Document correction and reprocessing approval
When processing errors occur, the team records the exception, the root cause, the affected records and the corrective action. Reprocessing or manual correction requires documented approval by someone other than the person performing it, and the approval, rerun results and reconciliation are attached to the ticket. Engineering should confirm that reprocessing does not duplicate or corrupt outputs. The output is a closed exception record for each event, which is the evidence an auditor samples most often.
Run a periodic review of specifications and exceptions
At a frequency the organization defines and documents, the control owner reviews the specification register, the tolerance table, alert coverage and the population of closed exceptions. The review checks whether new jobs have been added to the inventory, whether specifications still match behavior and whether recurring errors point to a design problem. Done means the review is minuted with findings and actions assigned. The output is a signed review record that shows the control operated over the period, which matters most for a Type 2 report.
Which evidence passes a PI1.3 test and how to keep it current
An assessor testing PI1.3 looks for records that show processing ran as specified, errors were found and fixed, and every change was reviewed. The cards below cover the artifacts most often sampled, and how to keep each one retained and tied to a control description between audits.
Processing specifications and version history
Written processing specifications define what the system should do with each input and output, and the assessor will ask which version applied during the examination period. Keep each specification under version control with approval records, so a sampled job can be matched to the rule that governed it on that date. Check that the change history shows who approved each revision and when it took effect.
Job run logs and activity records
Scheduled and batch processing produces run logs that show what executed, when, against which inputs, and with what result. Assessors sample these to confirm processing matched the specification over the period. Confirm that logs are retained for the full observation window, cannot be edited by the operators whose work they record, and can be retrieved for any sampled date.
Error and exception logs
Error and exception logs show where processing failed, rejected records or produced unexpected results, which is the evidence PI1.3 expects the organization to detect. Use audit logging for administrative and data actions where it is available. For example, Nextcloud's admin_audit app writes additional event information to audit.log, and OpenBao's audit devices record every API request and response, including errors, with most sensitive values hashed. Confirm which events each platform logs before relying on it.
Alert configurations and alert history
Alert rules show how the organization detects processing failures, such as failed jobs, stalled queues or metric thresholds that drift. Export the rule definitions and keep the history of fired alerts, since an assessor may ask for proof that an alert fired and was acted on. Grafana Alerting can combine metrics and logs in one rule set, and Prometheus stores the metrics those rules query on local storage, so confirm retention settings cover the full audit period.
Tickets showing investigation and correction
When an error or alert occurs, the ticket is the record that shows it was investigated, root cause was identified and the correction was verified. Assessors sample tickets to test whether detection leads to correction. Require each processing ticket to link to the triggering alert or log entry, the fix, and the verification step, and confirm that closed tickets are retained and searchable.
Reprocessing approvals and periodic review sign-offs
Reprocessing a batch or rerunning a corrected job changes data the organization has already reported, so it needs a recorded approval that names the requester, the reason and the approver. Periodic reviews of processing results, with dated sign-offs, show that management checked processing over time. Keep both in the same system as the tickets they relate to, and schedule exports so the records survive platform changes between audits.
What meeting PI1.3 costs in money and effort
This table lists the cost components of running PI1.3 system processing controls, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to shape a quote request and to see where open-source tooling removes license spend while engineering and retention costs remain. No figures are given because none were supplied for this topic; ask for them in your own environment.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it |
|---|---|---|---|
| Processing specification writing | Internal engineering and product owners, sometimes an external reviewer | One-time to create, recurring to maintain | Number of pipelines and reports, and how often definitions and expected outputs change |
| Error detection and correction design | Internal platform or data engineers | One-time build, recurring tuning | Number of processing paths, known failure modes and tolerance for reprocessing |
| Instrumentation and alert rules | Platform engineers, often with an implementation partner for setup | One-time build, recurring tuning | Count of metrics and logs covered, and the noise level of alerts |
| Logging and audit record storage | Infrastructure team or cloud provider, depending on hosting | Recurring | Data volume per processing run, retention period set by policy and contract |
| Tooling and licenses | Software vendor, or none for self-hosted open source | Recurring where commercial | Choice of platform, number of users and data sources, support tier |
| Operations triage time | Operations and on-call staff | Recurring | Alert volume, incident frequency and quality of runbooks |
| Auditor sampling and evidence requests | Auditor fees and internal staff who pull records | Recurring each examination period | Number of processing activities in scope, sample sizes and how easily records are located |
| External review of specifications | Independent consultant or auditor (auditor reviews remain independent of design work) | Optional, usually one-time or per change cycle | Complexity of processing, number of customer-facing outputs and internal capacity |
Who does what for PI1.3: your team, a partner and the auditor
Your organization owns the control. Processing specifications, the definition of what a correct result looks like, the decisions about how processing errors are corrected, and the sign-off on exceptions all sit with management. These are judgments about your products and your customers' reliance on reporting, so they cannot be delegated to a vendor or an implementation partner.
- Processing specifications: Management defines the expected behavior of each processing activity, including the rules, thresholds and reconciliation targets that the system is measured against.
- Error correction decisions: Your team decides which errors are corrected automatically, which go to a person, and who approves a reprocessing or a correcting entry.
- Sign-offs and approvals: Named owners approve alert thresholds, review exception logs and document why each exception was closed.
- Policy and procedure: Written procedures state who reviews processing reports, how often, and what happens when a review finds a problem.
- Operating records: Staff perform and record the reviews over the period, because the auditor tests whether the control operated, not whether it was designed on paper.
Before the audit, check that each specification has a named owner, that the approvals are dated, and that the people in those roles can explain a sample of exceptions without help.",
An implementation partner such as DeployOpen can prepare the technical side of the control on self-hosted open-source platforms running in your own cloud accounts, data centers or air-gapped networks. The partner builds the mechanisms that generate and keep the records. It does not decide what the specifications are, and it does not attest that the control works.
- Instrumentation: Configure metrics collection and application logs so processing activity is recorded, for example with Prometheus scraping instrumented jobs and Nextcloud's admin_audit app writing to audit.log.
- Alert rules: Build Grafana Alerting rules from the thresholds your team approved, and document how alerts route to the people who act on them.
- Log retention: Set retention and protection for audit logs so the records survive the full examination period.
- Evidence exports: Script or schedule exports of alert history, configuration and log extracts that the CPA firm can sample.
- Documentation: Write runbooks that show how each mechanism is configured and how a reviewer reads its output.
Confirm with the partner in writing which items are fixed-scope deliverables, who holds administrative credentials, and that the client retains ownership of all logs and configuration.",
The independent CPA firm performs the examination under the AICPA attestation standards. It evaluates the design of the control, tests whether it operated over the period for a Type 2 report, and issues the report. Its independence is the reason a customer or regulator can rely on the result, so the firm cannot prepare the evidence it later tests.
- Design evaluation: The auditor checks that the processing controls, as described, would detect and correct errors in the way management states.
- Operating effectiveness testing: The auditor samples alerts, reviews and error records across the period and checks each one against the approved procedure.
- Evidence evaluation: The auditor decides whether exports and logs are complete, accurate and protected from change, which is why it may ask how they were produced.
- Exceptions and opinion: Any deviation is reported as an exception, and the auditor forms the opinion, not the partner or your team.
- Independence boundary: Ask the firm which preparation work it can do without impairing independence, and keep that line in its engagement letter.
Before engaging the firm, confirm which tasks you have assigned to the partner, which to internal staff, and which the firm will test directly.
Where PI1.3 programs usually fall short
Most PI1.3 weaknesses are not missing tools. They are gaps between what the system does, what is written down, and what can be shown to an auditor over the observation period. The cards below cover the gaps we see most often and the checks that close each one.
Processing specifications live in code
When the rules for how data is calculated, transformed or routed exist only in source code, in a runbook nobody updates or in one engineer's memory, the organization cannot show what the system was designed to do. Write the processing specification as a controlled document that names inputs, transformations, expected outputs and tolerances, and link each version to the code release that implemented it. Check that someone outside the build team can explain each rule from the document alone.
Error alerts with no triage record
Monitoring can fire on processing failures every day, yet the program fails if nobody can show who reviewed each alert, what they decided and whether the item was closed. Route alerts into a ticketing workflow that records the reviewer, timestamp, root cause and resolution. Sample a few alerts from the period and confirm each one has a complete trail from detection to closure.
Corrections without approval
Reprocessing a batch, editing a record or rerunning a job to fix an error changes processing outcomes, so the correction itself needs authorization. Require a documented approver, a stated reason and a before and after record for every manual correction, and separate the person who requests a fix from the person who approves it where staffing allows. Confirm that emergency corrections are reviewed afterward rather than left unexamined.
Log retention shorter than the period
Processing logs are evidence only if they still exist when the auditor samples them. If application or audit logs roll over before the end of the observation period, the organization cannot show operation across the whole window. Set retention for processing and audit logs to cover the full observation period and any sampling lookback, and test a restore from archive. Ask your CPA firm which periods they expect you to cover before you set the policy.
Logs that skip input records
PI1.3 covers the processing of inputs, so a log that records job completion but not what came in leaves a gap. Record input identifiers, counts, checksums or validation results alongside processing events so that each output can be traced back to the input that produced it. Test this by picking one output at random and tracing it to its source input and the processing run that handled it.
Specifications not revisited after change
A processing specification that was accurate at launch can drift after a schema change, a new data source or a patched dependency. Tie specification review to the change management process so that any change affecting processing triggers a documented check of the specification and its tests. Look for change tickets that touch processing logic with no corresponding specification update or review sign-off.
PI1.3 questions buyers ask before they hire help
How much extra effort does PI1.3 add to a SOC 2 with processing integrity in scope?
PI1.3 adds a set of processing controls on top of the common criteria, so the effort depends on how many processing workflows the system runs and how well they are already documented. The main drivers are the number of processing specifications that must be written down, how many error-handling and reconciliation routines exist, and whether processing logs already exist and are retained. A team with defined workflows and centralized logs has less to build than one where processing rules live only in code. Ask any partner to size the work by listing the workflows in scope before quoting.
Can our team prepare PI1.3 evidence without outside help?
Yes, many teams do this internally, provided they have an owner for each processing control and time to build and test the evidence. Outside help is most useful for mapping the controls to the Trust Services Criteria, designing the monitoring and alerting, and running a readiness review before the CPA firm arrives. Be clear about roles: your organization owns its controls, an implementation partner prepares systems and evidence, and only the independent CPA firm examines the controls and issues the report.
How long must processing evidence be kept for a Type 2 observation period?
Evidence must cover the full observation period of a Type 2 report, so it has to be retained at least until the auditor has tested it and the report is issued. The exact retention period is set by your own policy and the auditor's sampling requests, not by a fixed number in the criteria. Confirm with your CPA firm which logs and reports they will sample, how far back they will look, and whether your retention settings cover that window. Retention settings that delete logs early are a common cause of exceptions.
Does logging alone satisfy PI1.3?
No. Logs show that processing happened and provide a record for review, but PI1.3 also expects defined processing specifications, checks that detect and correct processing errors, and evidence that someone reviews the results. Logs become useful evidence when they are tied to a documented control, such as a reconciliation that runs on a schedule, an alert on failed jobs, and a recorded follow-up for each exception. Ask the auditor which combination they expect for your system.
What does the PI1.3 work need from engineering and operations?
Engineering and operations supply the technical facts that the control narrative depends on: how jobs are scheduled, what errors look like, where logs are stored, and who responds to alerts. Expect to ask them for the following:
- Written processing specifications for each workflow in scope
- Log sources, retention settings and access controls for those logs
- Alert rules for failed or delayed processing and the on-call path for them
- Records of how past processing errors were detected, corrected and reviewed
Keeping these items current is an ongoing task, not a one-time project.
Can an implementation partner issue the SOC 2 report?
No. Only an independent CPA firm can perform the SOC 2 examination and issue the report. An implementation partner can prepare systems, configure logging and monitoring, document controls and organize evidence so the auditor can test it. The CPA firm then evaluates management's description and the controls, and decides what opinion to issue. Treat any partner that promises the report or a particular opinion as a warning sign.
What should we ask a partner to include in a written scope for PI1.3?
A written scope should name the systems and processing workflows covered, the PI1.3 controls to be built or reviewed, the tools that will produce evidence, and the deliverables. Ask for the following items to be stated explicitly:
- The list of processing workflows and systems in scope
- Which controls the partner will configure and which your staff will own
- The evidence set delivered for the auditor, with an owner for each item
- Dependencies on your cloud accounts, data centers or network access
- Acceptance criteria and the timeline agreed before work starts
DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides a quote that follows from that scope.
How to decide whether to build PI1.3 in-house or bring in a partner
The build-or-partner decision for PI1.3 turns on whether your engineers already own the pipelines that process customer data. If they do, an in-house team can usually write the processing specifications, define the error-handling rules and set up the alerts itself, because the people who understand the jobs are the people who can prove them. The work is mostly documentation and configuration, and it stays with the staff who will run it after the examination. If your processing runs through a batch scheduler, a reconciliation job or a third-party integration that nobody has instrumented, the first task is discovery, not writing policy. That is where an outside team with a fixed scope can save the most time, because it can map the flows, list every point where a record can be rejected, dropped or corrected, and show you the gaps before the observation period starts.
A self-hosted stack adds a second question. Tools such as Prometheus, Grafana Alerting and OpenBao's audit devices each need to be deployed, retained and configured inside your own environment, and their logs have to be kept in a form the CPA firm can sample. Ask whether your team has the time and skills to configure those components, keep their versions current and test that a failed job actually raises an alert. If the answer is no, a fixed-scope engagement that covers instrumentation, alert rules and evidence exports is a reasonable option, provided the written scope names the deliverables and who keeps them running after handover. The size of the scope matters as much as the skills. A narrow processing environment with one pipeline needs far less help than a multi-tenant platform with many customer-specific workflows. Before you commit either way, confirm with your CPA firm exactly what evidence it expects for PI1.3, including how far back it will look, which systems it will sample, and what format it needs the records in. Firms differ in how they test processing controls, and changing the evidence design after the observation period has begun is costly. Put that confirmation in writing, then decide whether to build, buy or split the work between the two.
