PI1.5 SOC 2 storage controls: requirements and evidence

What PI1.5 SOC 2 asks you to prove about stored data

When a SOC 2 auditor asks how stored inputs, items in processing and outputs stay complete and accurate, the answer has to show that data a customer relies on is not lost, corrupted or made unavailable late. PI1.5 asks the organization to store these items completely, accurately and on time, in line with its own system specifications. The risk it targets is silent failure: a storage layer that drops records, a restore that returns altered files, or an archive that cannot be read when a customer asks for history. PI1 applies only when processing integrity is in scope for the examination, so confirm that scope decision with your auditor before you build evidence for this criterion.

The criterion is hard in practice because stored data rarely sits in one place. Production databases, object storage, file shares, caches, backup sets and long-term archives each hold a different copy of a customer's data, and each has its own retention and write path. The points of focus name four areas to cover: protecting stored items, archiving and protecting system records, storing data completely and accurately, and keeping records of storage activity. Start by writing down, for each store, what enters it, what the system specification says about it, and who can change it. That inventory is the scope the auditor will sample from.

For the evidence, a backup platform such as Bareos can show scheduled backup, verify and archive jobs and a SQL catalog of what was backed up. restic's check command with --read-data or --read-data-subset reads pack files back to confirm stored data is unmodified, which is the kind of test an assessor will ask to see run on a schedule. Audit logs from applications such as Nextcloud's admin_audit app, or from a secrets service such as OpenBao, can record storage-related activity. Confirm with your own platform owners which logs capture writes, deletions and restores, how long they are kept, and whether they are protected from the administrators whose actions they record. The AICPA Trust Services Criteria document sets out the points of focus in full.

Which stores and records fall under PI1.5 in a SOC 2

PI1.5 applies to wherever inputs, items in processing and outputs sit between capture and delivery. The scoping choices below decide which of those stores the auditor tests, who owns them, and what evidence the examination will need.

Customer uploads and input stores

Files, form submissions and API payloads that customers send in are the first stored inputs under PI1.5. Map every landing point, including object storage buckets, temporary upload directories and mail or message queues, because each is a place where input can be stored completely or lost. Confirm whether rejected inputs are kept, for how long, and who can read them. The upload path is often missed when teams list only the primary database.

Queues and working tables

Message queues, job tables and intermediate datasets hold items while processing is underway. Decide whether they fall inside the system description, since an item that is dropped or duplicated here may never appear in an output. Ask what the system does with stalled or dead-letter items and whether those states are recorded. Auditors commonly ask how an item in flight is confirmed to reach its destination.

Reports, exports and delivered outputs

Reports, data exports, generated documents and files pushed to customers are outputs under PI1.5 and often sit in shared drives, email attachments or download links. Decide which output stores belong to the system and which are created by customers after download, since the second group usually falls outside your controls. Check that generated outputs keep their expiry and access settings, and that you can show what was stored and when.

Third-party storage as subservice organizations

When a cloud object store, managed database or hosted queue holds your inputs, processing items or outputs, the provider is usually a subservice organization. Decide whether to carve it out and rely on its own SOC report, or include it in the system description with your own controls over it. Ask the provider for its current report and confirm which storage features your configuration relies on, because a report covers only the services it names.

Backups and archives as storage

Backups and archives hold complete copies of inputs and outputs, so an auditor may treat them as part of storage rather than as a separate disaster recovery topic. Decide whether backup repositories sit inside the system boundary, how their integrity is checked, and how long archived records are retained. Confirm that restores are tested and that the backup catalog itself is protected. Tools such as Bareos and restic can produce job and verification records for this purpose.

Logs and audit records of storage activity

Logs that record writes, reads, deletions and exports are the evidence for PI1.5's storage activity points of focus, so the choice to include them changes the testing burden. Decide which logs are in scope, where they are kept, who can change them, and how long they are retained. Logs that contain personal or confidential data may themselves need protection. Confirm that the audit trail covers the stores you decided to include above.

How an assessor tests PI1.5 in a SOC 2 examination

This table compares the five test areas an assessor typically applies to PI1.5, the evidence each one requests and the findings that most often appear. Read each row as a question the auditor will ask of your storage environment, then check whether your records answer it for the full examination period.

Test area	Evidence requested	Common findings
Inspection of storage design and retention settings	Documented storage specification, retention configuration exports, data classification records and the system description of where inputs, processing items and outputs are held	Retention settings in the platform differ from the documented specification, or the specification does not name every storage location for outputs such as exports and reports
Sampling of stored records against source inputs	A sample of records selected from source systems, matched to their stored copies, with reconciliation or hash comparison results	Stored records are incomplete or differ from source values, and the organization has no reconciliation control that would have detected the gap
Review of backup and restore job results over the period (Type 2)	Backup job logs for the full observation period, restore test records with dates and scope, and verification output such as restic check results or Bareos verify job reports	Restores were never tested, or test restores covered only a small subset of data, so the organization cannot show stored items are recoverable and unmodified
Review of access and deletion controls on stored items	Access listings for storage locations, approval records for privileged access, deletion logs and disposal approvals tied to the retention schedule	Deletion happens without approval or outside the retention schedule, or former staff keep access to storage buckets, volumes or backup repositories
Review of storage activity logs	Audit log exports for storage platforms and applications, log retention settings, and evidence that log review occurs	Administrative access to storage is not logged, logs are overwritten before the period ends, or no one reviews the logs that do exist
Confirmation of retention and archiving records	Archive inventories, retention rule configurations and records of archived data retrieved during the period	Archived records cannot be retrieved within the time the specification states, or archive contents do not match the retention rules in force

Steps to implement PI1.5 controls before the audit window opens

This sequence turns PI1.5 from a policy statement into working storage controls, each with a record an auditor can sample. Work through it in order so that every store has an owner, protection, a backup job, logging and a tested restore before the observation period begins.

Define storage specifications for each data class
Start by listing the inputs, items in processing and outputs your system handles, then group them into data classes such as customer records, transaction files, reports and system logs. For each class, write a storage specification that states where it is stored, what completeness and accuracy mean for it, how quickly it must be available, and what the system is expected to do if storage fails. Engineering and the process owners sign off. The output is a storage specification document that the control matrix can cite.
Map each store to an owner and retention rule
Build a register that lists every storage location for each data class, such as object storage buckets, databases, file shares, backup repositories and log stores. Assign a named owner to each location and attach a retention and disposal rule drawn from the storage specification and any contractual or regulatory obligations you carry. The register should show who approves changes to retention. The output is a store register with owners and retention rules, reviewed by management.
Configure protected and versioned storage
Apply the protections the specification calls for to each store: access restricted to the roles named in the register, encryption at rest, versioning or immutability where the specification requires it, and deletion protection on critical buckets or volumes. Configuration should live in infrastructure as code so the settings can be exported and compared over time. Confirm each setting against the platform's own documentation, since feature names and defaults differ between products. The output is a configuration export per store, plus a short note of any exceptions and their approvals.
Schedule backup, verify and archive jobs
Set up backup jobs for each store at the frequency the specification states. Bareos can schedule backup, restore, verify and archive jobs from its Director and keeps a SQL catalog of what was backed up, which gives you a searchable record. For repositories you manage directly, restic's check command can confirm structural consistency, and its read-data options can read pack files back to confirm the stored data is unmodified. Export the job schedules and verification settings. The output is a job schedule export and a verification configuration linked to the register.
Set up logging of storage activity
Turn on logs that show who accessed, changed, deleted or restored stored items. Nextcloud's admin_audit app writes additional event information to audit.log, or to a path you set with logfile_audit. For secrets and key material held in OpenBao, audit devices record a JSON log of every API request and response, with most sensitive values hashed using HMAC-SHA256. Confirm that logs are shipped to a location the storage administrators cannot edit. The output is a log source list with sample entries showing storage events, reviewed for coverage against the register.
Run and record a documented restore test
Choose a representative set of stored items from at least one data class and restore them to an isolated environment. Compare the restored items with the originals for completeness and accuracy, and measure whether the restore met the availability target in the specification. Record who ran the test, the date, the items selected, the job used, the results and any defects found. Track each defect to closure. The output is a signed restore test record that the auditor can sample, along with the ticket trail for any follow-up.
Document the control matrix row and review cadence
Write the PI1.5 row in your control matrix, linking the storage specification, the store register, the configuration exports, the job schedules, the log samples and the restore test record. State who performs each activity and how often, and how exceptions are raised and resolved. Ask the auditor which evidence and sample sizes they expect before the observation period begins, because requirements differ by engagement. The output is a complete control matrix row with its evidence list, approved by management.

How to show stored data is still unmodified

An auditor wants proof that stored data has not changed since it was written, not just a belief that it has. For PI1.5, the question is whether the backups and archives an organization relies on can be trusted to restore the inputs, items in processing and outputs it stored. A structural check and a read-back check answer different questions. restic check verifies the structural consistency of snapshots, trees and pack files, which shows that the repository's metadata hangs together. By itself, that does not show that the bytes inside a pack file are the bytes that were written. With its --read-data or --read-data-subset options, restic reads pack files back so the stored backup data can be confirmed as unmodified. Confirm the exact behavior, output and flags against the restic version you run, using the restic documentation on working with repositories.

The organization owns two decisions that a tool cannot make for it: how deep each read-back goes and how often it runs. A full read of every pack file gives the strongest evidence but takes longer and reads more data, while a subset read covers less but can run more often. Set the depth and schedule in writing, tie them to the repositories that hold PI1.5 data, and record each run with its date, the command used, the result and who reviewed it. Keep the logs as evidence, because an auditor will ask for a sample of them across the period. Decide ahead of time what happens on a failure: who is notified, how the affected repository is restored or rebuilt from a clean copy, and how the incident is written up.

A passing check is only useful if a failure is acted on. Record every error reported by a check, including those that are later resolved, and link each one to the corrective action taken. This is the same pattern an auditor expects for any control that detects a problem: detection, a record, and a response. Confirm with your implementation partner or your own administrators how the read-back jobs are scheduled, where their output is stored, and how access to those logs is restricted, so that the record of integrity checks cannot be quietly edited.

Evidence that passes PI1.5 and how to keep it current

An assessor testing PI1.5 looks for records that show stored items stayed complete, accurate and retrievable on time, and that someone checked them. The cards below describe parallel artifacts that cover the design, the routine activity, the proof of recovery and the access that governs storage. Each one needs a named owner and a review cadence so it is current when the auditor samples it.

Storage specification

This is the document that defines what must be stored, where, in what form, for how long and to what completeness and timeliness standard. It is the yardstick the auditor uses to judge every other artifact, so it must match the system as it actually runs. Check that it names each store holding inputs, items in processing and outputs, and that changes to it go through change management. Review it at least annually and after any platform change, and have the system owner approve each version.

Retention and disposal schedule

The schedule states how long each class of stored item is kept and how it is destroyed or archived at the end of that period. Auditors compare it against the backup catalog and storage logs to confirm that items are neither removed early nor kept without reason. Confirm the schedule with the data owners and legal or compliance staff who set the periods, since those periods come from customer contracts and applicable law rather than from SOC 2 itself. Record each approval with a date.

Backup and archive job reports

Job reports show that scheduled backup, archive and verify jobs ran, what they covered and whether they succeeded. With Bareos, the Director schedules and supervises these jobs and keeps a SQL catalog of backed-up files, so the catalog and job history can be exported as evidence. Look for failed jobs, missed windows and jobs that quietly stopped covering a new system. Someone on the operations team should review failures weekly and document the follow-up.

Restore test records

A backup has no value until a restore has been proven, so this card covers dated restore tests with the scope, the source backup, the target and the result. Bareos can restore files from the current backup or from one before a chosen date and time, and tests should cover both recent and older points. Record who ran the test, what was compared and any discrepancy with its resolution. Schedule tests on a cadence the organization sets and sign off by the service owner.

Integrity check outputs

Integrity checks show that stored data has not been silently corrupted or altered. restic check verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored backup data is unmodified. Keep the command, its version, the date and the output, and treat any error as an incident to track. Confirm with your own team how often the full read is run, since a subset check covers only part of the repository each time.

Storage activity audit trails

Audit logs record who touched stored items and when, which is the record PI1.5 expects for storage activity. Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit, so confirm where the file lives and that it is shipped to protected storage. OpenBao audit devices keep a JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. Verify that logs are complete, retained for the agreed period and reviewed by someone other than the administrator being logged.

Storage administrator access reviews

Anyone who can read, delete or restore stored items is a risk to their integrity, so this card covers periodic reviews of storage administrator accounts, backup operator roles and encryption key access. Each review should list the accounts, the justification, the last activity and the reviewer's decision. Compare the list with the audit trails above to catch access that was never used or used outside a change. Management or the data owner should sign off each review, and the signed record should be retained for the auditor.

What meeting PI1.5 costs in money and effort

This table breaks down the money and effort behind meeting PI1.5 storage controls, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a quote request, since no price or duration is stated here and the real figures depend on your scope, data volumes and environment.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Recurring where paid	Bareos, restic, Nextcloud and OpenBao are open source, so license spend can be zero; support contracts, hosting and any commercial add-ons still cost money	Confirm the license of each component in your scope and ask whether support is needed at all
Storage hardware or cloud storage	Recurring	Volume of backed-up inputs, processing items and outputs, retention periods, copies kept off-site and storage tiers	Set retention by documented requirement, tier cold archives and remove data that no longer needs to be stored
Engineering time to design storage and jobs	One-time, with later changes	Number of data stores, backup schedules, catalog and audit log configuration, and integration with access controls	Write the storage specification once, reuse configuration as code and ask for a fixed-scope design with written deliverables
Evidence upkeep (restore tests, log review)	Recurring	Frequency of restore tests and checksum verification, number of systems, and time spent reviewing audit logs and job reports	Automate job reports and verification runs, and agree a review cadence that matches the period the auditor will sample
External restore testing or review	Optional, periodic	Whether an outside party is asked to validate restore procedures or review the storage design, and how many systems are in scope	Limit external work to systems the auditor will test and ask for scoped, itemized deliverables
Auditor sampling effort	Recurring with each examination	Number of storage events and restore records the auditor selects, quality of the records, and how many exceptions must be explained	Keep job logs, restore tickets and audit logs in one searchable place so samples can be produced quickly

Who owns PI1.5 and what a partner can take on

Your own team owns PI1.5 in the sense that the controls, the decisions behind them and the resulting report belong to you. The people who answer for storage are usually a control owner in security or operations, a system owner for each store of customer data, and a leader who can accept residual risk. They define what must be stored, for how long, in which location and under which protections, and they review whether the controls keep working between audits.

Retention decisions: Set how long inputs, processing items and outputs are kept, and document the basis for each period, including any contractual or legal duties your customers impose.
Risk acceptance: Decide which storage risks remain after controls are applied, such as recovery point limits, and record who signed off.
Data ownership: Name an owner for each dataset who approves access, changes to storage locations and disposal.
Restore test review: Read the results of restore tests and decide whether failures trigger corrective action.
Evidence review: Confirm that exported logs, backup reports and job records are complete before they go to the auditor.

Check that each storage decision has a named owner and a written rationale that an auditor can read without your team present.

Where PI1.5 controls usually fall short

Most PI1.5 findings do not come from missing tools. They come from storage controls that run without anyone checking whether they work, whether they are written down, or whether they cover the people with the most access. The cards below cover the gaps assessors most often find and the practical step that closes each one.

Backups that are never restored

A backup job reporting success proves that data was written, not that it can be read back in a usable state. Assessors look for evidence that restores were tested, so a PI1.5 file should show when a restore was run, which system or dataset was used, and whether the result matched the source. Schedule a restore test of a sample of inputs and outputs, record the outcome, and log any failure as a finding. Bareos can restore files from the current backup or one from before a given date and time, which makes it practical to test point-in-time recovery as well as the latest copy.

Retention rules held by one team

When retention periods live in one engineer's head or in a spreadsheet nobody maintains, stored items are kept too long or deleted too early, and neither outcome is easy to defend. Write a retention schedule that names each category of input, processing item and output, its retention period, the system where it lives and the disposal method. Confirm the schedule with the business owners who set the requirements, and show that backup and archive jobs apply it. Ask the auditor which period they expect to see tested before the review starts.

Archives without integrity checks

An archive that cannot be read, or has been altered without anyone noticing, fails the requirement to store items accurately. Integrity checking should be scheduled and recorded rather than run once at setup. With restic, restic check verifies the structure of snapshots, trees and pack files, and the --read-data or --read-data-subset options read pack files back to confirm the stored data is unmodified. Keep the output of each run, include the repository and date, and treat a failed check as an incident with its own follow-up.

Logging for applications, not administrators

Storage activity is often logged well for the application, such as file uploads and downloads in a collaboration tool, while changes made by administrators through a console, a backup catalog or an API go unrecorded. Administrators can change retention, delete stored items or export data, so their actions need the same record. Enable the audit logging each platform offers, send it to a location administrators cannot silently edit, and review administrator activity on a set cadence. In Nextcloud, the admin_audit app writes additional event information to audit.log, which is a starting point for this check.

Secrets access with no audit trail

Stored credentials for backup targets, archive repositories and encryption keys are often read by automation with no record of which client asked for them. If a stored item can be decrypted or restored only with a secret, the secret store's access log is part of the storage evidence. Confirm that the secret store writes an audit device log of each request and response, and check how sensitive values are handled in that log. OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. Keep the log in a location separate from the systems it records.

Outputs with no delivery record

Outputs such as reports, exports and statements can leave the organization without a record of who received them, when, or whether a copy was later deleted. Under PI1.5, the storage record should show what was stored, where, for how long, and what happened at disposal, so keep a register that links each output to its recipients and its disposal date. Where outputs are delivered through a file share, enable the access log for that share and reconcile it against the register at each review. Ask whether recipients are required to confirm receipt, since that decision changes what evidence exists.

Questions buyers ask about PI1.5 cost, effort and scope

Can a team meet PI1.5 without outside help?

Yes, in principle. The organization owns its controls, so an internal team can design the storage controls, run them and collect the evidence without an outside partner. The harder question is whether the team has the time and skills to do it consistently. PI1.5 asks for stored inputs, items in processing and outputs to be complete, accurate and on time to system specifications, so the team must first write those specifications. Outside help is usually useful for the setup work: mapping storage flows, configuring backup and logging tools, and preparing evidence the auditor will request. An independent CPA firm still performs the examination and issues any report.

How much effort does PI1.5 take, and what drives it?

The effort depends mainly on how many systems store customer or processing data, how many storage locations exist, and how mature the existing documentation is. Effort rises when storage is spread across cloud accounts, databases, file shares and third-party services, and when no one has written down what the system is supposed to store and for how long. Effort falls when storage is consolidated, backup jobs are already scheduled and reported, and audit logs go to a central place. We do not supply a duration or headcount here. Ask any provider, including us, to break the effort into inventory, control design, configuration, evidence collection and ongoing operation, with an estimate for each.

How long before an audit do the storage controls need to run?

A Type 1 report examines whether controls are suitably designed as of a specific date, so the controls must exist and be documented before that date. A Type 2 report tests operating effectiveness over an observation period, so the controls must run throughout that period, with evidence generated along the way. The exact observation window and the sample sizes are set between the organization and its CPA firm, so confirm them in the engagement letter. Starting the storage controls early gives the team time to correct gaps before the auditor samples them.

What does PI1.5 need from engineering and compliance teams?

Each group has a distinct role:

Engineering configures storage, backup, restore testing and audit logging, and keeps the configuration under version control.
Compliance defines the storage requirements, retention rules and evidence the auditor expects, and reviews the records.
Data owners confirm what each system must keep, for how long, and who may access archived records.
Management approves the system specifications and the description of storage activity that the report relies on.

Agree these responsibilities in writing before the observation period starts, so that no evidence depends on one person's memory.

Do backups alone satisfy PI1.5?

No. Backups address recoverability, which is part of the criterion, but PI1.5 also asks that stored items be protected, that records of storage activity be kept, and that stored data be complete and accurate. A backup job that completes does not prove the data is unmodified. Tools such as Bareos schedule and catalog backup and restore jobs, and restic can read pack files back to confirm stored data is unmodified, which supports the accuracy point. You still need access controls on stored data, logs of storage activity and a documented retention and archiving process. Confirm the full set of points of focus with your CPA firm.

How does a Type 2 report test storage over a period?

A Type 2 report tests whether storage controls operated effectively across the observation period. The auditor typically selects samples of storage and backup events, requests the matching logs, restore test results and integrity check output, and compares them with the documented specifications. Gaps such as failed backup jobs without follow-up, or restore tests that were skipped, can become exceptions in the report. Keep evidence generated continuously rather than assembled at the end. Ask your CPA firm how many samples it expects and which records it will request, because those choices drive the workload.

Which parts of PI1.5 are usually outsourced?

Organizations commonly outsource the setup of backup, logging and integrity tooling, the mapping of storage flows, and the preparation of evidence packs. DeployOpen plans, implements, configures, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, which covers much of this setup work under a written, fixed scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or attestations. Retaining ownership of the policies, approvals and day-to-day operation remains with the organization. Request a written scope that lists each deliverable before work starts.

Where should I confirm the cost of a PI1.5 engagement?

No public figure for SOC 2 preparation costs applies to PI1.5 specifically, so treat any number you see with caution and ask for a written quote. Confirm with your CPA firm the scope of the examination, whether PI1 is included, and the observation period. Confirm with any implementation partner the systems in scope, the tools to configure, the evidence to produce and the recurring operation after go-live. Ask which costs are one-time, such as configuration, and which recur, such as log retention, restore testing and periodic review.

How DeployOpen prepares PI1.5 storage controls and evidence

DeployOpen plans and implements self-hosted open-source platforms that store inputs, items in processing and outputs inside your own infrastructure. We prepare the storage controls, protection settings and records that PI1.5 expects, then hand over documented evidence for your independent auditor, who alone issues the report.

How we scope

Engagements are fixed-scope, with the storage systems, data stores and archives in scope agreed in writing before work starts.
The written scope lists which inputs, processing items and outputs are stored, where, and for how long, per system.
Scope also names the backup, archive and audit log sources that will be treated as PI1.5 evidence.
Out-of-scope systems, and any control your organization keeps for itself, are stated explicitly in the scope document.

How we build

We configure backup and archive jobs with Bareos, including scheduled backups, restores and verify jobs with a SQL catalog of backed-up files.
We set integrity checks with restic, using structural checks and read-data verification to confirm stored backup data is unmodified.
We enable audit logging for stored content, such as the Nextcloud admin_audit app, and route audit devices for secrets to OpenBao.
We test restores against the documented recovery steps and record the results for the evidence file.

How we hand over

You receive written configuration, runbooks and a control description mapping each PI1.5 point of focus to a system setting.
Evidence packs include backup job reports, verification results, restore test records and retained audit log samples.
We document how each record is collected, where it is stored and who reviews it, so your auditor can request it directly.
We hand over the material to your team, and your auditor receives it from you, not from DeployOpen.

How we support

Ongoing support, upgrades and continuous testing of storage controls are available as a retainer, agreed separately.
Retainers can cover periodic restore tests and review of backup and audit log configurations between audit periods.
Before your auditor's fieldwork, confirm with them which samples and time periods the evidence must cover.
Ask your auditor to confirm the evidence format they accept, since the report itself is issued only by them.