What PI1.2 system inputs asks for in a SOC 2
When an auditor asks how inputs are controlled under processing integrity, the short answer is that PI1.2 requires your organization to implement policies and procedures over system inputs, including controls over their completeness and accuracy. The auditor is checking whether the data entering your system is defined, checked and recorded well enough that processing can be trusted. This section applies only when processing integrity is in scope for your report. If your customers have not asked for it, PI1.2 is not in your examination, although the input thinking often shows up in other criteria.
The Trust Services Criteria points of focus for PI1.2 break the requirement into three practical jobs. The first is defining the characteristics of processing inputs: what a valid order, record, file, API call or sensor reading looks like, including format, required fields, value ranges and who may submit it. The second is evaluating inputs against those characteristics before processing, so that incomplete or inaccurate items are rejected, flagged or routed for correction. The third is creating and maintaining records of system inputs, so you can show later what came in, when, from where and what happened to it. The risk is simple to state: bad or missing input flows into processing and produces wrong results that look correct.
This is hard to evidence because inputs arrive from many sources, including customer uploads, partner feeds, internal users, scheduled jobs and integrations, and each source needs its own definition. In a Type 2 report, the auditor also needs to see the input controls operating across the whole observation period, so an rule written in the last month will not satisfy a sample drawn from the first. Confirm with your auditor early which input sources and processing flows are in scope, and decide which records, such as validation logs and rejection queues, you will keep to prove the control ran.
Which inputs and systems PI1.2 covers in scope
PI1.2 only reaches the inputs your examination actually includes, so scope starts with a list of every path data takes into the system. The cards below cover the input paths that most often decide how much control work lands on the organization, the subservice organizations and customers that own part of it, and the condition that makes PI1.2 apply at all.
Scope gate: processing integrity in the examination
PI1.2 is part of the processing integrity category, so it applies only when processing integrity is included in the SOC 2 examination. If the report covers security alone, the input controls described here are not tested, though many of them still help with CC criteria. Confirm the category list with the CPA firm in the engagement letter before writing any input procedures, because adding the category later changes the control matrix, the system description and the sampling plan.
User-entered data
Data typed into forms, admin consoles and customer portals is the input path most exposed to error and to unauthorized change. Define the field-level characteristics the system accepts, such as format, length, required fields and allowed values, and record which validation runs in the browser and which runs on the server. Server-side validation is the control an auditor can test, since client-side checks can be bypassed. Ask the product owner which fields feed billing, access decisions or regulated records, because those fields need stricter rules and evidence.
API and integration feeds
Inputs arriving through APIs and integrations often bypass the user interface and carry their own authentication, schema and rate rules. Inventory each endpoint that accepts data, the system or team that owns the calling integration, and the schema version it expects. Check that malformed or incomplete payloads are rejected and logged rather than silently stored. Integration credentials belong in the secrets controls, and the owner of each integration should be named in the input inventory so changes to the sending side trigger a review.
File uploads and batch imports
Uploads and bulk imports move many records at once, so completeness and accuracy controls matter more than for single entries. Define accepted file types, size limits, required headers, and how the system reports rows it rejects. Keep a record of each import with its source, timestamp, row count and outcome so the batch can be reconciled against the source file. Confirm who may run imports in production, because a manual batch run by an administrator is a common finding when it sits outside the change process.
Third-party data feeds
Market data, identity attributes, credit or sanctions lists and similar feeds come from outside the organization, so the organization may not control their accuracy. Document each feed's provider, delivery method, expected format and refresh frequency, then decide what checks run on arrival, such as record counts, totals or checksums. Where a provider's controls are relevant, review its own SOC report and note any complementary user entity controls the provider expects the organization to perform. Treat a feed as a subservice relationship only where the provider's processing is part of the system.
Configuration and subservice inputs
Configuration changes, such as rule sets, feature flags, pricing tables and infrastructure definitions, are inputs that change how the system processes data. Include them in scope when they alter processing outcomes, and assign an owner who approves each change. Subservice organizations, including cloud hosts and managed database providers, can supply inputs or infrastructure the system depends on. Where customers supply the data, the examination may rely on complementary user entity controls, so the customer-side responsibilities should be written down and shared with them before fieldwork.
How a SOC 2 auditor tests input completeness and accuracy
An auditor testing PI1.2 starts with the system description, because that document defines what the system takes in and which inputs are in scope. The auditor reads how management describes each input flow, from the customer or upstream system that originates the data, through the interface that receives it, to the application or database where it is recorded. Each flow is then walked end to end with the control owner, who shows where the input characteristics are defined, such as required fields, accepted formats, permitted value ranges and the rules that reject a record. The auditor is checking whether those characteristics exist and are written down before testing begins, because a control cannot be evaluated against criteria that were never set. Points of focus under the criterion help the auditor and the organization think about these characteristics, but they are aids for designing and evaluating controls, not separate requirements that each must be shown.
In a Type 1 examination, the auditor evaluates design as of a specific date. The test is whether the input controls, as described, would reasonably achieve completeness and accuracy if they operated as written. This usually means reviewing validation rules in configuration or code, reading the procedures for rejected or flagged inputs, and confirming that records of inputs are created and retained. In a Type 2 examination over an observation period, the auditor also tests operating effectiveness. The auditor selects a sample of inputs across that period, traces each one from source to the system record, and compares the record to the source and to the defined characteristics. Sample size and selection are the auditor's decisions, so the organization should confirm the expected population and the log sources it can produce before fieldwork. Logs that capture inputs and rejections, such as the Nextcloud admin_audit app writing to audit.log (path set through logfile_audit) or OpenBao audit device entries, are only useful if they are complete for the period and retained long enough to be sampled. Teams should confirm with their auditor which log sources they will accept as evidence.
What the assessor asks for and where findings come from
This table sets out what an assessor typically does for each input control under PI1.2, the evidence they request and the findings that most often appear. Read it as a checklist for your own evidence: if a row has no record behind it, expect that gap to surface in fieldwork. The main takeaway is that input definitions, validation settings and exception records must exist before the observation period starts, because they are tested across the whole period.
| Test area | Evidence the assessor typically requests | Common findings |
|---|---|---|
| Defining input characteristics | Approved input definitions, data format and field rules, owner sign-off and the review history for each input type | Input definitions exist only in developers' heads or code comments, with no approved version or owner |
| Validation rules configuration | Configuration exports or code under version control, the rule inventory, and proof of who approved each rule and when it took effect | Validation rules changed in production without a change ticket, approval or record of the prior setting |
| Sampling of inputs for accuracy and completeness | Population of inputs for the period, the sample selected, and reconciliation of sampled records to source data and to processed totals | Population is incomplete or cannot be generated, so the sample cannot be shown to be representative |
| Rejected or corrected input records | Logs of rejected inputs, the reason codes, who corrected them, and evidence that corrections were re-validated before processing | Rejections are dropped silently with no log, or corrections are made directly in the database without an audit trail |
| Reconciliation and exception logs | Scheduled reconciliation results, exception queues, the investigation notes and the closure evidence for each exception | Exceptions are recorded but never reviewed or closed, and no owner is named for the queue |
| Audit logging of input activity | Log settings showing which input and admin events are captured, log retention, and samples of entries for the period | Logging is disabled for some input paths or logs are overwritten before the audit period ends |
How to implement PI1.2 input controls step by step
This sequence moves from knowing every path that brings data into your system to a tested, owned and recorded set of input controls that an examiner can sample. Each step produces a named artifact that feeds the next.
Inventory every input path
Start by listing each route by which data or instructions enter the system in scope: user forms, API endpoints, file uploads, batch imports, message queues, integrations with other services and administrative consoles. Engineering and product owners should walk the architecture diagram and confirm the list against real traffic logs, not memory. The output is an input register that names each path, its owner, the data it carries and the system it feeds. You know the step is done when someone outside the project can trace any production input back to a listed path.
Define characteristics for each input
For every path in the register, write down what a valid input looks like: required fields, data types, formats, value ranges, size limits, allowed sources and expected volumes or frequencies. Compliance and engineering should agree these definitions together, because PI1.2 expects the organization to define input characteristics that matter to processing. The output is a validation rule specification, versioned and approved by the control owner. The step closes when each rule can be checked against code or configuration.
Implement validation and reconciliation controls
Build the checks that enforce those rules at the point of entry, such as schema validation at the API gateway, field-level checks in the application, checksums or record counts for batch files, and reconciliation of totals between the source and the receiving system. Where a check cannot run automatically, document the manual procedure and who performs it. The output is a set of configured controls with change records in version control. Confirm each control by submitting a deliberately invalid and a deliberately incomplete input in a test environment and recording the result.
Configure logging of accepted and rejected inputs
Turn on logging so that accepted inputs, rejected inputs and the reason for rejection are recorded with timestamps and actor identities. Self-hosted platforms can help here. For example, Nextcloud's admin_audit app writes additional event information to audit.log in the data directory or to a path set with logfile_audit, and OpenBao audit devices keep a JSON log of every API request and response, with most sensitive values hashed. Confirm your platform's exact capabilities and retention settings before relying on them. The output is a documented logging configuration and a sample log extract showing a rejected input.
Assign owners and set the review cadence
Name an accountable owner for each input path and for the validation rules, and define how often the owner reviews rejected-input logs, rule changes and exceptions. Record who receives alerts when rejection rates change unexpectedly. The output is a control matrix entry per input path showing the owner, the review frequency you have chosen and the evidence each review produces. The step is complete when every row has a named person and a documented cadence that the team has accepted in writing.
Run a pilot evidence collection
Before the examination window opens, select a few input paths and collect the evidence an examiner would request: the register entry, the rule specification, a change record, test results for invalid inputs, a log extract and a completed owner review. Check whether a stranger could follow the trail from control to evidence without help. Note any gaps and fix them. The output is a short pilot report listing what was collected, what was missing and the corrective actions taken. Your independent CPA firm will decide what sampling and testing it performs, so confirm expectations with them before the pilot.
Using application and API logs as input evidence
Application and API logs are one of the most practical ways to show an assessor how system inputs were recorded, because they capture what arrived, when, from whom and what the system did with it. For PI1.2, the question is whether the organization can point to a record of each input path it has defined under PI1.1 and show that the records are complete. Logs help with that, but only for the paths they actually cover, so the first job is to map every input channel (web forms, file uploads, API endpoints, integrations and administrative changes) and confirm which of them write to a log at all.
In a self-hosted Nextcloud deployment, the admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit in the server configuration. The team should confirm that the app is enabled, that the chosen path sits on storage with appropriate permissions and capacity, and that the events it records match the input and administrative actions they need to evidence. OpenBao's audit devices take a different approach: they keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. That gives strong coverage of secrets-related API inputs, but the hashing means the log proves that a request was made and what shape it had, not the plaintext value that was supplied.
Logs alone do not prove that inputs were accurate or complete. An assessor will expect the organization to show what the logs are checked against, such as validation rules, reconciliation to source records and the exceptions process for rejected inputs, and to confirm log retention and integrity controls for the period under examination. Treat the logging configuration as something to verify in your own environment, including retention periods, rotation, access to the log files and whether logs are shipped to a central store. The AICPA 2017 Trust Services Criteria describe the points of focus for input records, and that is the reference to test your design against before an assessor does.
Evidence that passes a PI1.2 test
An auditor testing PI1.2 wants to see that input rules were defined, that they operated throughout the period, and that rejected or exceptional inputs were recorded and resolved. The cards below cover the artifacts that prove each step, and each one needs an owner who reviews it on a schedule rather than only before fieldwork.
Input specifications
A written definition of what each input must look like: required fields, data types, value ranges, formats, permitted sources and the business meaning of each field. Auditors use it as the yardstick for every other artifact, so it must match what the system actually accepts. Keep it in version control with a dated change history. The product owner or data owner approves it, and engineering confirms it against the current code or schema at each quarterly review. Ask whether the specification is kept with the code that enforces it or in a separate document that can drift.
Validation rule configuration exports
Exports or snapshots of the rules that enforce the specification, such as schema definitions, form validators, database constraints, API request validation and gateway policies. These show the control is configured, not just described. Export them on a schedule, store the files with a timestamp, and diff them against the previous export. The platform owner signs off on each export, and a second engineer reviews any change that loosens a rule.
Sample input traces
Log extracts that show individual inputs passing or failing validation, including timestamp, source, user or service identity, and the outcome. Auditors select samples across the period, so traces must exist for ordinary days, not only for the incident you want to show. Confirm which fields your audit logs capture, and whether sensitive values are masked. Retention must cover the full observation period. The security or operations lead reviews a sample set monthly and records that the review happened.
Rejected-input and exception records
A register of inputs that failed validation, were overridden, or were accepted by exception, with the reason, the person who decided and the resolution. A clean record with no rejections is unusual enough to draw questions, so confirm that rejections are logged at all. Each exception should carry an approver who is not the requester. Review the register weekly and close aged items. The data operations owner signs off on exceptions, and the risk owner reviews any that recur.
Reconciliation reports
Comparisons between what was submitted and what the system recorded, such as record counts, control totals or hash totals from a source file against the processed batch. Reconciliation is how an organization shows that inputs are complete, not only that bad inputs were rejected. Define the tolerance for each reconciliation in advance and document what happens when it is breached. Operations runs the reconciliation on the agreed cadence, and a second person reviews breaks before they are closed.
Change records for validation rules
Tickets, pull requests and approvals showing who changed an input rule, why, what was tested, and who approved the release. Auditors compare these against the configuration exports to confirm no rule changed outside the approved process. Emergency changes need a record too, with after-the-fact review. Link each change to its ticket and retain the approval evidence. The engineering manager approves standard changes, and the change board or security reviewer approves changes that relax validation.
What meeting PI1.2 costs in money and effort
This table compares the cost components of meeting PI1.2, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read it to decide which parts your own engineers can absorb and which parts to scope and quote with an outside party. No price or duration is stated because none is supplied for this topic, so ask each party for a written estimate tied to your input paths.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Defining input characteristics | Internal engineers and product owners, sometimes a consultant | One-time, revisited when inputs change | Number of input paths, data types and documented formats |
| Building validation and completeness checks | Internal developers or an implementation partner | One-time build, then recurring maintenance | Number of integrations, complexity of rules, and how many systems share them |
| Logging and audit tooling | Software vendor or open-source project, plus the team that hosts and configures it | Licence spend for commercial tools, hosting and storage recurring | Log volume, retention period and whether logs must be sent to a central store |
| Open-source tooling licences | No licence fee for open-source components; hosting and staff time still apply | Hosting and maintenance recurring | Choice of self-hosted components, which removes per-seat or per-event licence spend but not operating effort |
| Evidence collection and upkeep | Internal compliance or operations staff | Recurring across the observation period | How much evidence is captured automatically versus gathered by hand |
| External review of input design | Independent consultant or the auditor's readiness support, if purchased separately | One-time, plus periodic re-review | Scope of the review, number of systems and the depth of the written design |
| Auditor sampling and testing | The CPA firm, paid under its engagement letter | Recurring each examination period | Number of input controls tested, sample sizes set by the auditor and number of exceptions raised |
| Remediation of exceptions | Internal teams, sometimes with a partner | One-time per exception, plus recurring if a control fails repeatedly | Quality of control design at the start and how quickly owners respond to findings |
Who owns PI1.2 and what a partner can take on
Your organization owns PI1.2. Management must decide which inputs the system accepts, what a valid input looks like, how invalid inputs are rejected or flagged, and who approves changes to those rules. These decisions are business and risk decisions, and they belong to the people accountable for the service. A partner can draft the input specifications, but the approval, the ownership and the answers to the auditor's questions must come from your staff, because the auditor will ask them to explain the rules in their own words.
- Input definitions: Document the fields, formats, ranges and required values for each input channel, and name the owner of each definition.
- Control decisions: Decide which completeness and accuracy checks run, which failures stop processing, and which are logged for review.
- Exception handling: Assign who investigates rejected or unusual inputs and how fast they respond.
- Approval records: Keep signed or ticketed approvals for every change to input rules.
- Ongoing review: Schedule periodic reviews of the input specifications against actual customer and system use.
Before the examination, confirm that each named owner can explain their control and point to the records it produces.
An implementation partner can prepare the technical side of PI1.2. For self-hosted platforms, this usually means configuring the application and infrastructure so that input events are recorded, retained and protected, then turning those records into evidence the auditor can sample. The partner works inside your environment and under a written scope. The partner does not decide what counts as a valid input and does not sign off on whether the control operated effectively.
- Logging configuration: Enable and tune audit logging in the platform, for example the admin_audit app for Nextcloud, which writes additional event information to
audit.login the data directory or to a path set withlogfile_audit. - Audit devices: For secrets and API traffic, configure audit devices such as those in OpenBao, which keep a detailed JSON log of API requests and responses with most sensitive values hashed.
- Evidence pipelines: Set up log forwarding, retention and access controls so records cannot be altered by the people they describe.
- Testing support: Run test inputs against the platform to show that completeness and accuracy checks behave as the documented rules say.
- Documentation: Write runbooks and configuration records that show how each control is built and operated.
Ask the partner to state in writing which outputs they produce and which decisions remain with your team.
The CPA firm performing the SOC 2 examination must be independent of the organization it examines. It selects samples, tests the design and, for a Type 2 report, the operating effectiveness of the PI1.2 controls over the observation period. It then issues the report and its opinion. Because the auditor forms the conclusion, a partner cannot write the conclusion, approve test results on the auditor's behalf or present its own work as the auditor's testing. The line is drawn by who forms and signs the opinion, not by who helped prepare the evidence.
- Independent testing: The auditor chooses which inputs to sample and tests them directly from source records.
- Engagement terms: Agree in writing what the partner may and may not do during the examination, and confirm this with the audit firm before work starts.
- Management representations: Management, not the partner, signs the assertion and representation letter for the system and its controls.
- Independence checks: Ask the audit firm whether its independence rules restrict any service you plan to buy from the same provider.
- Scope of report: The auditor decides the final wording, exceptions and opinion.
Before engaging anyone, confirm the independence rules with your chosen CPA firm, since they vary by firm.
Where PI1.2 controls usually fall short
Most PI1.2 weaknesses are not missing policies. They sit in places where input rules live only in code, where rejected data leaves no trace, and where evidence is assembled late. Each card below names one gap, why it matters to an assessor, and the check to run before fieldwork.
Input rules that exist only in code
Validation logic, accepted formats and value ranges are often defined only inside application code, so no one outside engineering can state what the system accepts. PI1.2 expects the organization to define the characteristics of its inputs, so an assessor will ask for a document or configuration that states them. Check that each critical input has a written specification, that the specification matches the running code, and that an owner signs off on changes to it.
No record of rejected inputs
Systems often log accepted transactions but discard the ones they refuse, which leaves no proof that invalid data was caught. Records of rejections, with timestamp, source and reason, are what show that evaluation of inputs actually happened. For a self-hosted application, confirm which audit events are written, where they are stored and whether validation failures are among them. Nextcloud's admin_audit app, for example, can write additional event detail to a dedicated audit log that you should verify is enabled.
Validation changed without change tickets
Teams tighten or relax input checks during incidents or feature work and merge the change without a ticket, review or test record. The assessor later finds an input rule that differs from what the control narrative describes. Route validation rules through the same change process as other production code, and check that the change history shows who approved each modification and when it went live.
Integration feeds with no completeness check
Files and API feeds from partners, payment processors or internal systems are often loaded on the assumption that they arrive whole. When a batch is truncated or a record count is off, nobody notices until downstream reports disagree. Completeness controls compare expected and received counts or control totals and record exceptions. Confirm that each recurring feed has a documented expected count, a reconciliation step and a named owner who reviews mismatches.
Input secrets and credentials left unmanaged
Integration credentials used to pull or push inputs are sometimes stored in configuration files or shared accounts, which makes it hard to show who submitted a given input. Each feed should authenticate with its own identity, and those credentials should be stored and rotated under a managed secrets process. Ask whether a secrets manager such as OpenBao keeps an audit device enabled so that access to these credentials leaves a record that ties each input to a source.
Evidence gathered only for the audit window
Teams often pull logs, reconciliation reports and rejection records together in the weeks before fieldwork, which leaves gaps for the months when nothing was captured. A Type 2 examination tests operating effectiveness over a period, so the samples must come from that period. Set retention for input logs and reconciliation outputs to cover the whole observation window, and schedule a periodic check that the records exist for each month.
PI1.2 questions buyers ask before hiring help
What does PI1.2 input control work cost, and what drives the price up?
The cost comes mostly from labor: the time needed to define input characteristics for each system that accepts data, document how those inputs are checked, and collect records that show the checks ran. Costs rise with the number of input paths (user forms, APIs, file uploads, integrations, batch imports), how many systems are in scope, how mature the existing logging is, and whether the team must build validation logic or only document and configure it. Costs also recur, because inputs change as products change and each new integration needs review. Ask any provider for a written scope listing the systems, input paths and evidence deliverables, then compare quotes against that same list. DeployOpen does not publish prices; a quote follows from the agreed scope.
How long does PI1.2 take to implement before the auditor starts fieldwork?
The duration depends on how many input paths exist and how many already have documented validation and logging. Teams that already validate inputs and keep logs usually spend most of the time writing down characteristics, reviewing exceptions and proving the controls operated consistently. Teams starting from little documentation spend longer defining what a valid input is for each system. For a Type 1 report, the controls must be designed and in place at a point in time, so the work should finish before that date. For a Type 2 report, the controls must run across the observation period, so they need to be stable for months before the examination window opens. Confirm the timeline with your auditor and provider in writing, since neither can responsibly promise a duration before the system and input paths are known.
What does the internal team need to provide for PI1.2 work?
The work needs people who know the system well enough to describe it accurately. Typically this means:
- An engineering owner who can explain each input path, its data format and its expected values.
- A product or business owner who decides what counts as an acceptable input and who approves changes.
- A security or compliance lead who maps the controls to the criteria and collects evidence.
- Operations staff who can pull logs and confirm that records are retained.
The organization owns its controls. A provider can prepare configurations, logging and documentation, but it cannot decide business rules on the organization's behalf. Plan for those owners' time from the start, because delays usually come from waiting for answers about input rules rather than from the technical setup.
Can we run PI1.2 controls in-house without outside help?
Yes, many organizations do. In-house work is realistic when the team already has engineers who can document input rules, a logging pipeline that captures the relevant events, and someone who understands what an assessor will test. Outside help is most useful when the team lacks experience with SOC 2 evidence, when many systems accept input, or when the internal team cannot spare the time. Whichever path you choose, the organization remains responsible for the controls. Ask any firm to separate preparation work (documentation, configuration, evidence collection) from attestation, which only an independent CPA firm can perform.
Can the CPA firm prepare our PI1.2 controls for us?
Usually not. A CPA firm performing a SOC 2 examination must remain independent of the organization, so it cannot design and implement the controls it will then test. Many firms will explain what evidence they expect, review drafts and comment on the control matrix, but building the controls is normally a separate engagement with a consultant or implementation partner. Check your auditor's engagement letter and independence policy before assigning preparation work to the same firm. An implementation partner such as DeployOpen can prepare systems, logs and documentation for the organization, but only the independent auditor issues the report.
How does PI1.2 differ between a Type 1 and a Type 2 report?
A Type 1 report describes the system and assesses whether the input controls are suitably designed as of a specific date. The evidence focuses on the written input definitions, the validation design and a walkthrough showing the control exists. A Type 2 report adds an opinion on whether those controls operated effectively over a period. For PI1.2 this means the auditor will sample real inputs and records across the observation window and look for consistent execution and handled exceptions. Type 2 work therefore needs continuous logging, retained records and a process for reviewing rejected or corrected inputs throughout the period, not only a finished design. Confirm the observation period and sample expectations with your auditor before the window opens.
What evidence will the auditor ask for to show PI1.2 is working?
Auditors typically ask for the documented definition of valid inputs for each system, the validation or review procedure, and records showing the procedure ran. In practice that means validation rules or configuration exports, application or API logs that record accepted and rejected inputs, and tickets or exception reports showing how errors were corrected. For self-hosted platforms, audit logs can supply much of this. Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Confirm with your auditor which records they accept and how long they must be retained before you rely on any tool's output.
How DeployOpen prepares PI1.2 input controls and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so input controls and their records live where your systems run. We prepare the systems, controls and evidence that a SOC 2 auditor will test for PI1.2 System inputs, while your organization keeps ownership of the controls and an independent CPA firm issues the report.
How we scope
- We agree a written scope listing which systems accept inputs and which input types fall under PI1.2.
- We confirm with you which input characteristics your policies must define, such as format, required fields and acceptable ranges.
- We identify with your auditor which records of inputs must be retained and which teams own each control.
How we build
- We configure audit logging on the in-scope platforms, such as Nextcloud admin_audit output and OpenBao audit devices.
- We set up validation and reconciliation checks where your platform allows them, and document any gaps as open items.
- We test these controls in a staging environment and record the results so the evidence trail starts before fieldwork.
How we hand over
- We deliver a control description, configuration records and a sample evidence package mapped to PI1.2 points of focus.
- We document log locations, retention settings and access to log stores so your team can run the controls after handover.
- We provide a walkthrough so your staff and your auditor can see how an input moves from entry to record.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so input controls keep working after each platform update.
- We can review log samples with your team ahead of the observation period so gaps surface early.
- Changes to input handling are documented and re-tested as part of the same retainer scope.
