PI1.1 Processing objectives and specifications: SOC 2 evidence

What PI1.1 asks a SOC 2 service to prove about its processing objectives

If processing integrity is in scope for your SOC 2, PI1.1 is the criterion that asks whether your processing objectives are defined, recorded and communicated. In plain terms, the assessor wants to see that you have written down what your system is supposed to do, what data it works with and what your products and services promise, and that the people who depend on those promises can find them. PI1.1 does not test the processing itself. That work sits in PI1.2 to PI1.5, which look at inputs, processing activity, outputs and storage. PI1.1 is the reference point those criteria are measured against, so an auditor who finds no defined specification has nothing to check the later controls against.

The risk is simple: if a specification exists only in an engineer's head, a Slack thread or a closed ticket, the team cannot tell whether a given result is correct, and customers cannot tell what they are relying on. Ambiguous data definitions cause the most damage. A field called "active customer" or "completed transaction" can mean different things to product, finance and support, and processing errors then look like defects when they are really disagreements. For a SOC 2 Type 2, this gap is hard to close late, because the assessor will ask for the specification that was in force throughout the observation period, not the one written at audit time.

To prepare, ask the owners of each product or service to name the processing objectives and the data definitions they rely on, then confirm where those statements live and who approves changes to them. Check that the wording given to customers in contracts, documentation and service descriptions matches the internal definitions. Confirm with your auditor which evidence they expect for this criterion, since the expected form of a specification and its approval record varies by organization and engagement. A versioned, access-controlled documentation space, such as a wiki or knowledge base, can hold these records, but the organization still owns the content and its approval.

Which systems, documents and teams fall inside PI1.1 scope

PI1.1 only applies when processing integrity is in the report scope, and the boundary is set by what the organization has promised. The cards below separate the decisions that determine how much definition work the examination will test, and where those definitions must live.

Processing integrity in report scope

PI1.1 is tested only when processing integrity is one of the categories named in the examination. Confirm this with the CPA firm before any definition work starts, because adding the category later changes the control matrix, the system description and the evidence set. Check whether the report covers the whole platform or only the products customers actually buy, since the scope decision sets which processing objectives must be written down.

Products and services with processing commitments

List each product, module, API or service where the organization promises that data will be processed correctly, completely or on time. Internal tooling that never touches customer outputs usually sits outside PI1.1, but any feature that transforms, calculates, routes or reports customer data needs a stated objective. Record the owner of each item so that its specification can be traced to a person who can approve changes.

Data definitions the platform depends on

Identify the data elements the platform processes, such as account identifiers, transaction amounts, timestamps, currency codes and status fields, and write down what each one means and its allowed values. Definitions that exist only in code or in one engineer's head will not satisfy an assessor asking how quality is defined. Include formats, units, required fields and what the system does when a value falls outside the definition.

Customer contracts and order forms

Contracts, order forms and service level language often state processing commitments in plain terms, such as accuracy of calculations or delivery windows. Each such promise becomes a processing objective that the organization must define and operate against. Review sales templates and statements of work for the first time and flag any commitment that cannot yet be traced to a documented specification.

Public documentation and product specifications

Product pages, API references, help center articles and release notes describe what the product does for customers, and assessors compare them with internal specifications. Where documentation says one thing and the internal design says another, the gap becomes an exception to explain. Keep a single owner for each public specification and a record of who changed it and when, so that the version a customer relied on can be shown.

Teams that own specifications

Product management usually owns functional and nonfunctional requirements, engineering owns the data definitions and their implementation, and customer success or support owns the commitments made in onboarding and tickets. Name one accountable owner per specification and confirm how changes are approved between them. Unclear ownership is one of the most common reasons a specification exists on paper but does not drive day-to-day work.

How an assessor tests PI1.1 and what they ask to see

This table sets out how a service auditor typically tests PI1.1, the evidence they request for each step, and the findings that come up most often. Read it as a preparation checklist: for each test, confirm that the evidence exists, is current and can be produced without rework. The main takeaway is that a processing objective is only as strong as the specification trail behind it, and auditors test that trail as well as the statement itself.

Test step	What the assessor does	Evidence they ask to see	Common finding
Walkthrough of objective setting	Asks management how processing objectives for each product or service are set, who agrees them and how they are linked to customer commitments.	Documented processing objectives, the meeting or approval record that set them, and the customer agreements or service descriptions they trace to.	Objectives exist in sales material but no internal owner or approval record can be produced.
Sample of specifications against system behavior	Selects a sample of specifications and traces each to configuration, code or procedure to confirm the system does what the specification says.	Specification documents, configuration exports, release notes or test results that show the stated behavior.	A specification describes a calculation, retention period or data field that the system does not implement as written.
Review of data definitions	Checks that the data processed is defined, including field meanings, formats, owners and permitted values, and that definitions match what the system stores.	Data dictionary or schema documentation with version history, and records of who approved each definition.	Definitions were written at launch and never updated when a field was added or reused for a new purpose.
Check of functional and nonfunctional requirements	Confirms that requirements such as performance, accuracy, timeliness and availability targets are identified and recorded, not only features.	Requirements register, acceptance criteria, and evidence that targets were measured or tested.	Nonfunctional targets are stated in marketing pages but have no measurement behind them.
Evidence that definitions are approved	Looks for proof that the people accountable for product and service specifications reviewed and approved them before release.	Approval records with dates, reviewer names and version identifiers, such as tickets, signed change requests or wiki page history.	Approvals are verbal or exist only as a comment in a chat thread that is not retained.
Evidence that definitions are communicated	Confirms that customers, internal teams and other parties who rely on the specifications received them and can find the current version.	Published customer documentation, internal notices, access records for the specification repository, and distribution lists.	Customers rely on a specification version that has been superseded internally, with no notice given.
Review after a product change	Compares the specification history with recent change records to see whether specifications were revisited when processing changed.	Change tickets linked to specification updates, and a sample showing a specification review after a material release.	Specifications conflict with each other, for example two documents giving different cut-off times, and neither was reviewed after a product change.

Implementing PI1.1 step by step, with the output of each step

This sequence turns PI1.1 from a statement of intent into a set of approved processing objectives, data definitions and product specifications that staff use and customers can see. Each step produces a record an auditor can read, so the evidence builds as the work progresses.

Inventory processing objectives and commitments
Start by listing what the service is meant to do for customers: the processing it performs, the outcomes it promises, and the commitments written into contracts, order forms and service descriptions. Product, legal and engineering leads usually own this list, and each entry should name the service and the customer-facing promise it supports. The step is complete when every objective traces to a source document, such as a contract clause, a product page or an internal requirement. The output is a processing objectives inventory, which becomes the starting point for every later step.
Define data elements and their meaning
For each objective, identify the data the service needs to produce the outcome, then define each element: its name, its meaning, its format, its allowed values, its source and the system that owns it. Data engineering and product owners should draft these definitions, and the review should check that the same term means the same thing across the product, the reports and the customer documentation. The step closes when every element used in processing has a definition and an owner. The output is a data dictionary under version control, so changes to a definition leave a traceable history.
Write functional and nonfunctional specifications
Turn each objective into a product or service specification that states what the system must do (functional requirements, such as the calculations, validations and transformations it performs) and the qualities it must have (nonfunctional requirements, such as accuracy tolerances, timeliness, performance and availability targets). The PI1.1 points of focus ask for information specifications and the information needed to use the product, so include the documentation a customer needs to use the output correctly. The output is a specification register that links each requirement to its objective and its data elements.
Approve specifications with named owners
Route each specification to the person accountable for the outcome, usually a product owner, with review by engineering and by whoever answers for customer commitments. Approval should record who approved what, on what date and against which version of the specification, and any open questions should be logged rather than left implicit. The step is complete when every specification in the register shows an approver and an approval date. The output is an approval record, which shows an auditor that management, not only the engineering team, accepted the processing objectives.
Communicate specifications to staff and customers
Publish the approved specifications where the people who need them can find them. Internal staff need the version that governs builds, testing and support, while customers need the subset that describes what the service does and how to use its outputs, with the same terms as the contract. Record who received each version and where it was posted, and confirm that support and sales teams work from the approved wording. The output is a communication record that links each published version to its audience and channel.
Set review triggers and keep the register current
Define the events that require a specification to be reviewed again: a change to the product, a new data element, a change in a customer commitment, an incident that exposed an unclear requirement, or a change in a regulation the customer relies on. Assign an owner to watch for each trigger and schedule a periodic check so that unchanged specifications are confirmed rather than forgotten. The step is complete when the triggers are written down and tied to the change process. The output is a review schedule and trigger list, and each review adds a dated entry to the approval record.

Evidence that satisfies PI1.1 and how to keep it current

PI1.1 is tested by looking at what the organization has written down about its processing objectives and how that material changes over time. The artifacts below are the records an auditor will ask to see, and each one needs an owner and a routine that keeps it accurate between examinations.

Approved product and service specifications

These documents state the functional and nonfunctional requirements a product or service must meet, such as accuracy targets, supported formats, latency expectations and processing limits. Each specification should carry an approver, an approval date and a version number. Check that the specification in force is the one the engineering team builds against, and that retired versions are kept and marked as superseded. Ask the owner to confirm which specification governed processing during the examination period.

Data definitions and information specifications

A data dictionary records each data element the system processes, its meaning, its permitted values, its source and its format. It shows the information needed to support a product or service and to use its outputs correctly. Keep it in the same place as the specifications so both can be reviewed together. Each change to a field definition should trigger a review of the code, interfaces and customer documentation that depend on it.

Version history and approval records

Version control shows what changed in a specification or definition, when, and who approved it. Wiki and documentation tools with page history can serve this purpose if edits are attributed to named users and the history cannot be silently cleared. Check that every approved change links to the review that authorized it. Ask whether the tool allows roll-back to an earlier version and whether anyone other than the author can approve a change.

Tying specification changes to change tickets

The most reliable way to keep specifications current between audits is to make a specification change part of the change management workflow. A ticket that alters processing logic should reference the specification version it implements and require the specification to be updated before deployment. Sample tickets during the observation period and confirm that each one points to an approved specification. Gaps here often produce exceptions because the code moved and the document did not.

Customer-facing product documentation

Customer documentation describes the processing objectives and service behavior that customers rely on, including supported inputs, expected outputs and service limits. Its statements should match the internal specification, and a review should follow every release that changes them. Assign a named owner and set a review cadence tied to the release calendar. Confirm that customers were told about material changes and that older documentation versions are archived.

Records of communication with customers and staff

Evidence of communication shows that the specifications and their changes reached the people who need them. Keep release notes, customer notices, internal announcements and training acknowledgments with dates and recipients. Access to the documentation should be role-based so that editors and readers have the rights they need and no more. Ask staff who build and operate the system to confirm they can find the current specification without help.

How versioned documentation keeps specifications provable

A specification that exists only as the latest text on a page gives an assessor nothing to test against. What matters for PI1.1 is that the organization can show how its data definitions and product specifications changed over time, who changed them and when. Wiki platforms with built-in version control address this directly, because each edit is kept as a retrievable revision rather than overwritten. XWiki, an LGPL-2.1-or-later platform, keeps every change under version control, records what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. These features allow the team to show the specification as it stood on a given date, which is useful when a processing objective is challenged or when an auditor samples a change from the period under review.

Revision history: Every saved change is retained with its author and timestamp, so the record of a specification is not replaced by its latest wording.
Version comparison: Reviewers can compare two revisions to see which data definitions or service requirements were added, removed or reworded.
Rollback with a trail: Restoring an earlier version should itself create a new recorded revision, so the restoration is visible rather than silent.
Dated releases of specifications: Teams can tie a stable revision to a release or change ticket so that the specification in force for a given launch can be identified.
Export and backup: Confirm that revision history survives exports, migrations and backups, since a wiki that loses its history during an upgrade weakens the evidence.

Before relying on any platform, confirm with your own deployment how revision retention, export of history and audit logging are configured, because these settings depend on how the instance is installed and maintained.

What meeting PI1.1 costs in money and effort

This table breaks down the cost and effort components of evidencing PI1.1, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No fees or durations are stated because none were supplied, so use the questions in the final rows to request a written quote and compare like with like.

Cost component	Who carries it	One-time or recurring	What drives it
Internal time to define processing objectives and product specifications	Product, engineering and operations staff	One-time to set up, recurring when specifications change	Number of products and services in scope, and how many data definitions already exist in writing
Documentation tooling for specifications and definitions	Organization, or self-hosted wiki platform it runs	Recurring hosting and upkeep, one-time migration	Whether a self-hosted wiki such as XWiki or BookStack is already running, which can remove license spend
Engineering and legal review of specifications	Engineering leads and counsel, internal or external	Recurring at each specification revision	Frequency of product changes and whether contracts reference service specifications
Auditor testing and sampling effort	Independent CPA firm, billed against the engagement letter	Recurring with each examination period	Number of specification changes in the period and how many samples the auditor selects
External review or readiness support	Implementation partner or consultant, if engaged	One-time for readiness, optional recurring	Scope agreed in writing, and whether the partner prepares evidence only or also drafts specifications
Version history and change evidence	Organization, through its document platform	Recurring as specifications change	How much retention the platform provides and whether the team keeps history without manual copies
Quote questions to ask	Procurement and compliance leads	Not applicable	Ask each provider to itemize one-time and recurring fees, the hours assumed for specification work, which artifacts they deliver, and which tools they require or license

Who owns, prepares and reports on PI1.1

PI1.1 is about the organization's own processing objectives and specifications, so the definitions and approvals must come from inside the company. Management decides what the service promises, which data elements it processes, what each product or service must do, and what information a customer needs to use it. These decisions belong to named owners, typically product, engineering and customer-facing leads, who sign off on them and revisit them when the product changes.

Processing objectives: management states what the service is meant to do and for whom.
Data definitions: the owner names each data type processed, its source and its meaning.
Functional and nonfunctional requirements: owners set requirements such as accuracy, timeliness and performance targets.
Approval records: approvals are dated and attributable to a named person.
Customer-facing information: owners decide what product documentation is communicated and keep it accurate.

Before the examination, confirm that each objective has a named owner and an approval trail that an auditor can sample.

Where organizations usually fall short on PI1.1

Processing objectives only hold up under audit when the definitions and specifications behind them are written down, approved and kept current. The gaps below tend to appear together, because each one breaks the chain from a documented specification to what the product actually does and what customers are told.

Specifications that live only in tickets

Requirements often sit in issue trackers, chat threads and sprint notes, where they are hard to find, easy to lose and rarely versioned. An assessor asking how the organization defines the processing it commits to will expect a stable, authoritative statement. To close this gap, name one controlled location for product and service specifications, move accepted requirements there, and link tickets back to the specification section they implement. Wiki platforms such as XWiki keep page history that records what changed, when and by whom.

Unapproved data definitions

Data definitions such as what counts as a transaction, a record, an active user or a completed job are often decided by whoever writes the code. When those definitions are never reviewed by the people accountable for the service, processing objectives drift without anyone noticing. Check that each definition has a named owner, a stated approval step and a date. Confirm with the owner that the approved definition matches what the system computes, and keep the approval record as evidence.

No link between product changes and specifications

Teams ship features that change how data is processed, but the specification document stays at the previous version. This is a change management problem as much as a documentation problem. Require that any change affecting processing logic, inputs, outputs or data meaning includes a specification update in the same change record. Review a sample of recent releases and confirm that each one either updated the specification or recorded why no update was needed.

Customer documentation that contradicts internal specs

Public help articles, API references, contracts and sales decks sometimes describe processing differently from the internal specification, especially after a quick fix or a custom deal. Where customers rely on these statements, the mismatch becomes a commitment the organization cannot evidence. Build a list of customer-facing documents that describe processing, assign an owner for each, and compare them to the specification at every release. Record any correction together with the reason for it.

Specifications no one has reviewed since launch

A specification written at launch may describe a product that has since gained integrations, new data sources or new customer segments. Without periodic review, the document becomes a historical artifact rather than a statement of current objectives. Set a review cadence, assign the review to a named role such as the product owner, and capture the reviewer's sign-off. Confirm the review interval with your own governance policy, since the criteria do not prescribe one.

Questions buyers ask about PI1.1

How much effort does PI1.1 take to document?

PI1.1 is usually one of the lighter processing integrity criteria because it asks for documented definitions rather than running new technical machinery. The work is to identify the processing objectives, write down the data the product processes and the specifications customers rely on, and show that those definitions are kept current. Effort rises with the number of products, data types and integrations in scope, and with how much of the definition already lives in tickets, code comments or people's heads. Ask any provider to estimate effort from a written list of products and data flows, not from a generic package.

How long does it take to get PI1.1 documentation ready?

The duration depends on how many products are in scope and how much existing material can be reused, so no fixed timeline applies to every organization. Most of the time goes to interviews with product owners, reconciling conflicting specifications and getting sign-off on definitions. Plan for the documentation to be drafted, reviewed by product and engineering, approved by management and then stable for the examination period. Ask your auditor when they expect to sample these records, because a Type 2 examination tests whether the definitions were in place and followed over the period, not only on the day they were written.

What does PI1.1 need from engineering and product teams?

PI1.1 depends on product and engineering staff more than on security staff. Product owners need to state the functional and nonfunctional requirements for each service and the information customers need in order to use it. Engineers need to describe the data each system processes, its formats, its validation rules and the limits it promises. Both teams need a way to change those definitions when the product changes, which ties the criterion to change management. Name a single owner for each product specification before the work starts, because unowned specifications are the most common gap an assessor finds.

Can an in-house team prepare PI1.1 without outside help?

Yes, an in-house team can prepare PI1.1 if it has product ownership, access to engineering records and someone who understands what an examination tests. Many organizations struggle less with writing the definitions than with agreeing on them across teams, keeping them in version control and proving that they were used. Outside help is most useful when the team has no one who has prepared a SOC 2 before, when several products share data flows, or when the timeline is tight. Whatever you decide, the organization remains responsible for its own controls and definitions.

What does an implementation partner handle for PI1.1?

An implementation partner can help structure the work, draft the specification templates, map where each definition lives, set up version-controlled documentation and collect the evidence the auditor will request. DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure and prepares systems, controls and evidence for compliance assessments. It does not decide the organization's specifications, approve them or issue any report. The CPA firm that performs the examination issues the opinion. Confirm in writing which tasks are in the fixed scope and which remain with your staff.

What drives the cost of PI1.1 documentation?

The cost of PI1.1 comes from the people and tools that produce the definitions, not from a separate fee for the criterion. Main drivers are the number of products and data types in scope, how many teams must agree on each definition, how well current records are organized and how often specifications change. Costs are typically one-time for the initial definitions and recurring for upkeep, review and sampling during the examination period. When you request a quote, ask the provider to separate the initial documentation work, the platform setup, the evidence collection and any ongoing support, and to state which assumptions the price depends on.

How do I keep PI1.1 definitions current after the examination?

Definitions go stale when products change without anyone updating the record, so PI1.1 needs a review step tied to releases and change requests. Store specifications in a system that keeps version history, so you can show what changed, when and who approved it. Assign each specification an owner who reviews it on a schedule and after material changes. Self-hosted wiki platforms such as XWiki keep every page change under version control and allow comparison and rollback, and BookStack lets you restrict edit rights by role. Confirm with your auditor that the tool and approval steps you choose satisfy their sampling requests.

How DeployOpen prepares PI1.1 documentation and evidence

DeployOpen starts with a written scope that names the processing objectives, the product and service specifications, the data definitions and the systems that will hold them. The scope also names who in your organization approves each specification and who maintains it afterward. Because PI1.1 is about the organization obtaining, using and communicating its own information, the objectives, the specifications and their approval remain owned by your organization. DeployOpen does not set your processing objectives and does not issue audit reports, attestations or certifications. Those come only from your independent CPA firm after its examination.

Within your infrastructure, DeployOpen can configure a self-hosted wiki or documentation platform so that each specification has a single owner, a version history and a clear approval record. XWiki, for example, keeps every page change under version control, showing what changed, when and by whom, and allows any two versions to be compared or rolled back. BookStack assigns abilities through roles that can be overridden at the shelf, book, chapter or page level, which lets you restrict editing of approved specifications to named owners. Confirm both behaviors against the version you intend to run before you rely on them in the control description.

DeployOpen then helps prepare the evidence an auditor will ask for: a register of processing objectives mapped to the specification pages that define them, the data definition for each data element, the approval dates and reviewer names, and the change history showing that specifications were revised deliberately. A useful test is to pick one service commitment and confirm that the auditor can trace it from the objective to the approved specification and then to the recorded change. Ask any implementation partner to show this trail in a working example from your own environment before work is accepted.

PI1.1 Processing objectives and specifications