What SOC 2 C1.1 asks you to do with confidential information
C1.1 asks the organization to identify its confidential information and maintain it in line with its own confidentiality objectives. When a customer or contract requires SOC 2 coverage of confidentiality, the auditor will want to see that you know what counts as confidential in your environment, that the label is applied consistently, and that the data stays protected while you keep it. The risk this addresses is simple to state: confidential data gets mislabeled, sits unprotected in a tool nobody reviewed, or is destroyed early because nobody recognized it as needed. The points of focus under C1.1 concentrate on two things, identifying confidential information and protecting it from destruction, so an examination will test both halves.
This is harder in practice than the wording suggests. Confidential data is spread across a ticketing system, a shared drive, a data warehouse, customer support exports and engineering logs, and rarely in one place. Nobody owns the classification, so product teams assume security labels it and security assumes the product team does. The definition also shifts from customer to customer: one bank's contract treats transaction metadata as confidential while another treats only account numbers as such. Start by writing a short classification scheme tied to your own confidentiality commitments, assign an owner for each data source, and record which systems hold each class. Confirm with your auditor how they expect that inventory to be evidenced before the observation period begins.
C1.1 is an additional criterion. It applies only when the confidentiality category is in scope for your examination, so confirm the category with the customer or contract before you design around it. Within that scope, C1.1 works with CC6.1, which covers restricting access to and use of confidential information for identified purposes, and with C1.2, which covers disposal once the data is no longer needed. Identification feeds both: the classes you define determine who may access each dataset and when it must be destroyed. Ask your CPA firm how it plans to test the link between the classification record, the access controls and the disposal records.
Which systems, data and teams fall under confidential information scope
Confidential information scope is set by a handful of decisions made before the auditor arrives: where the definition comes from, where the data lives, who touches it, and which third parties hold copies. Each choice widens or narrows the set of systems the auditor can select from during testing, so the decisions should be written down and matched to the system description.
Source of confidentiality definitions
Confidential information is defined by what the organization has committed to protect, and those commitments come from three places: customer contracts, the confidentiality commitments stated in the system description, and internal policy. A contract may name data types that internal policy never mentions, so the scope must cover the union of all three. Check that every confidentiality commitment in the system description has a matching classification rule and a named owner. If a contract promises more than the description states, the gap is a finding waiting to happen.
Primary and secondary storage locations
Confidential data rarely stays in one database. Production databases, object storage, backups, logs, support ticket systems, manual exports and analytics warehouses can each hold copies of the same record. Build an inventory that lists each location, its owner and whether it is in scope. Every location left out of the inventory is a gap an auditor can find by following a single record through the environment, so the inventory should be checked against actual data flows rather than architecture diagrams alone.
Teams that handle confidential data
Engineering, customer support and sales engineering often touch confidential information in different ways. Engineers may query production data for debugging, support staff may copy customer records into tickets, and sales engineers may build demo environments from customer files. Each group needs written handling rules and access limited to the work it actually does. Ask each team to list the places it reads or exports confidential data, because those answers usually expose locations that the formal inventory missed.
Backups, logs and exports
Backups, application logs and ad hoc exports are the copies most often forgotten in scope decisions. A log line that records a customer identifier or a payload fragment can carry confidential content into a log platform with broader access than the source system. Backups keep data after the production record is deleted. Decide whether each copy is in scope, how long it is kept, and who can restore or read it. Document the retention and disposal rules so that the same classification applies to every copy.
Third parties that hold copies
Subservice organizations, email providers and collaboration platforms may store confidential information on the organization's behalf. Each third party that receives or stores such data either falls inside the system boundary or is carved out and described as a subservice organization. The choice affects how much evidence the auditor reviews and which vendor reports must be collected. Confirm which vendors hold confidential data, which provide SOC reports, and how their reports map to the controls the organization relies on.
How scope choices change sampling
Scope decisions determine the population an auditor samples from. A narrow definition with a small set of storage locations gives a smaller population, so the auditor selects fewer items and tests a tighter set of controls. A broad definition that includes logs, exports and several teams gives a larger population and more samples to test. The practical lesson is to define scope deliberately, document the reasons for each exclusion, and make sure every included location has a control that the auditor can test.
How an assessor tests confidential information controls
This table walks through five test steps an assessor typically performs for C1.1, the evidence each step requests and the findings that often appear. Read each row as a question the assessor will ask, then check whether your records answer it before fieldwork begins.
| Test step | Evidence the assessor requests | Common finding |
|---|---|---|
| Review confidentiality commitments and classification scheme | Confidentiality commitments in customer contracts and the public terms, the written classification scheme with its levels and definitions, and approval records | Classification levels are defined in a policy but no owner approved them, or the scheme does not match the commitments made to customers |
| Walk through labeling and where labels are recorded | A sample of data stores with their assigned classification, the system of record that holds each label, and screenshots or exports showing labels in use | A system holds confidential data but carries no label, or labels exist only in a spreadsheet that is not kept current |
| Sample stored confidential data for protection controls | For selected datasets, evidence of encryption at rest, access restrictions and key management tied to the classification level | A labeled dataset is readable by a broad group, or encryption is enabled for some storage but not for the sampled location |
| Test that protection survives backups and copies | Backup configuration and retention settings, replication targets, restore test records and the inventory of non-production copies such as exports and analytics extracts | The classification scheme stops at the primary database, so backups, logs or test copies hold confidential data with no matching protection |
| Test change to classification | Change records for reclassification, approvals, the date each change took effect and evidence that protections were updated to match | Data is reclassified in the scheme without a record of who approved it, or downgraded data keeps protections that were never removed |
How to implement C1.1 in sequence
This sequence turns the C1.1 commitment into working artifacts: a defined scope for confidential information, a classification scheme, mapped protections, and evidence that the program runs before the auditor arrives.
Confirm commitments and the definition of confidential information
Start by reading the confidentiality commitments in your customer contracts, privacy notices and terms of service, and list what your organization has promised to protect. Agree a written definition of confidential information with legal and product leads, covering customer data, proprietary code, internal financials and any third-party data you hold under NDA. The output is a short confidentiality definition signed off by management, which becomes the reference point for every later step.
Build an inventory of confidential information
Identify every system, repository, bucket, database, mailbox, ticketing tool and backup location where the defined information lives or passes through. Engineering, support and finance owners usually know places that a central team does not, so interview them and pull exports from cloud accounts and self-hosted file stores. The output is an inventory export listing each location, its data owner and the categories of confidential information it holds.
Write the classification scheme and handling rules
Define a small number of classes, such as public, internal and confidential, with an additional restricted class if contracts demand it. For each class, write handling rules covering who may access it, where it may be stored, whether it may be shared externally, and how it is protected from destruction before its retention period ends. The output is a classification scheme document approved by management and published to staff.
Apply labels and record ownership
Apply the classes to the inventoried locations, using folder or file labels, repository tags, or metadata where your tools support them, and assign a named owner to each location. Where a tool cannot hold labels, record the class in the inventory itself. The output is a labeled inventory in which every confidential location has a class and an owner, which an auditor can sample.
Map protection controls to each class
For each class, define the protections that apply: access restriction tied to roles, encryption at rest and in transit, key management, and backup handling that keeps confidential copies protected and recoverable. Where the platform offers server-side encryption, confirm what it covers, since some configurations protect file contents but not file names or folder structure. Where application data needs encrypting without being stored, a secrets engine with versioned keys and rotation can help, and you should confirm each capability against current vendor documentation. The output is a control matrix with one row per class and per protection, naming the control owner and the evidence that proves it operates.
Set a review cadence and change triggers
Agree how often the inventory and classification scheme are reviewed, and list events that force an earlier review, such as a new product feature, a new subprocessor, an acquisition, a change in contract terms, or a new data category. Record who reviews each item and what they check. The output is a review procedure and a dated review log showing that the inventory was revisited and updated, not just created once.
Run a first internal check before the audit window
Before the examination period starts, sample several inventoried locations and confirm that the labels, owners, access lists, encryption settings and backup protections match the classification scheme and control matrix. Record every mismatch, assign a fix and retest it. The output is an internal check report with findings, remediation tickets and retest evidence, which gives management a clear picture of readiness and gives the auditor a documented starting point. Auditors, not your team or any implementation partner, issue the opinion on the control.
Which evidence shows confidential information is identified and protected
An auditor testing C1.1 looks for a chain of records: the commitments the organization made, the rules it set for handling information, a current view of where that information lives, and proof that controls are applied to it. Each card below is one link in that chain, with the habit that keeps it accurate between audit periods.
Approved confidentiality commitments
These are the promises the organization makes to customers about confidential information, usually in the master services agreement, order form, or a privacy and confidentiality statement. C1.1 is measured against these objectives, so the auditor will start here. Check that each commitment is approved by management, dated, and traceable to the controls that support it. Review them whenever a contract template changes, and keep a record of the approver and the review date.
Classification policy and handling standard
The classification policy defines the levels of information, such as public, internal, and confidential, and the handling rules for each level, including storage, sharing, and transfer. Without it, teams cannot apply protection consistently, and the auditor has no benchmark. Confirm the policy names owners, gives concrete examples for each label, and is acknowledged by staff. Review it at least annually and after any new product or data type is introduced.
Data inventory with owners
The inventory lists each system, database, bucket, backup, and file share that holds confidential information, with a named owner, its classification, and its location. It is the document that proves the organization knows where its confidential data is. Refresh it quarterly by comparing it against cloud account listings and infrastructure code, and require a change record whenever a new data store is added or an existing one is retired.
Encryption and access configuration
Configuration exports from storage, databases, and applications show that protection is applied to the data labeled as confidential, not just described in policy. For example, the server-side encryption setting in a Nextcloud deployment protects file contents at rest, but it does not hide file names or folder structure, so the configuration record should say what is and is not covered. Capture these settings as dated exports and compare them with the inventory each quarter.
Key management records
Key records show who can create, use, rotate, and retire the keys that protect confidential data, and when rotation last happened. Where a secrets service issues encryption keys for application data, such as the OpenBao transit secrets engine with versioned keys and rotation, keep audit logs of key creation and access, and a rotation schedule approved by the owner. Confirm that key custody is separated from the teams that use the data.
Periodic review records with sign-off
Periodic reviews confirm that the inventory, classifications, access lists, and key records still match reality. Each review should record the scope, the people who performed it, the exceptions found, the corrective actions, and a named approver's sign-off with a date. Auditors read these records to judge whether controls are operating over the period, so schedule the reviews on a calendar and keep the signed copies in the evidence repository.
What meeting C1.1 costs in money and effort
This table breaks down the main cost components of meeting C1.1 and who is paid for each one, separating one-time work from recurring spend. Read the driver column to see what makes each cost rise, and the last column for how to keep it down. No prices or durations are stated because none are supplied for this topic; ask for each component to be quoted separately.
| Cost component | One-time or recurring, and who is paid | Main sizing driver | How to keep it down |
|---|---|---|---|
| Classification and inventory of confidential information | One-time, mostly internal staff time plus any consultant hours for workshops and the data inventory | Number of data stores, systems and customer contracts that define confidential data differently | Start from the contract language and the data flows you already have; reuse one classification scheme across customers |
| Protection tooling and licenses | Recurring, paid to software vendors; can be near zero for open-source tools that meet the need | Number of systems that need encryption, key management and access logging, and whether vendor support is required | Choose self-hosted open-source platforms where they cover the need, such as Nextcloud server-side encryption or OpenBao for key management, and confirm each feature in your own environment |
| Engineering time to apply labels and controls | One-time for existing systems, then recurring for each new system or data store added; paid as internal salary or implementation partner fees | Count of systems to retrofit and how often new data stores are launched | Build labeling and encryption into the standard deployment template so new systems inherit controls by default |
| Periodic review and evidence upkeep | Recurring, internal staff time; evidence collection effort grows with the number of data stores and owners | Review frequency set by policy, number of data owners and number of systems producing evidence | Automate evidence export from logs and configuration, and assign one named owner per data store |
| External review or consultant support | Optional, either one-time readiness review or a retainer; paid to consultants or implementation partners | Team experience with SOC 2, the number of systems in scope and how much internal capacity exists | Ask for a fixed-scope quote covering named deliverables, and keep decisions about the control design internal |
| Auditor sampling effort during the examination | Recurring per examination, paid to the independent CPA firm; the auditor sets the sample | Number of confidential data stores, population sizes the auditor samples from and quality of the evidence provided | Keep a complete, dated inventory and disposal records so samples can be drawn quickly; confirm the auditor's sampling approach in the engagement letter |
Open-source tools that protect and evidence confidential information
Two open-source components can protect confidential information at rest and inside applications, and both produce records an auditor can sample. Each has a boundary: Nextcloud protects file contents but not the metadata around them, and OpenBao protects data only when applications call it. Confirm each fit against your own environment before writing it into the control matrix.
Nextcloud server-side encryption
Nextcloud's server-side encryption protects file contents at rest on local and external storage, with keys kept on the server. For C1.1, this is the protection layer for files classified as confidential. The evidence is the encryption configuration as it stood during the audit period: the module enabled, the storage locations it covers, and who may recover or rotate keys. Check that backups of the keys sit under the same controls as the data they open.
Metadata outside encryption
Server-side encryption does not cover file names and folder structure. A file named for a pending acquisition reveals its subject even when its contents are protected. Your classification scheme therefore has to govern what goes into names and paths, not only what goes into documents. Write that rule into the handling standard, sample folders at audit time, and record every exception. Illustrative: a folder called Project Falcon reveals little, while a folder named after a target company reveals a great deal.
Transit encryption for application data
The OpenBao transit secrets engine encrypts and decrypts application data without storing it. The application keeps the ciphertext in its own database and calls OpenBao for each operation. This suits fields your classification labels as confidential, such as account identifiers or customer records. The evidence is a mapping of each label to a named key, plus audit logs showing which service called encrypt and decrypt. Confirm that your application can absorb the extra call and that you know how it fails if OpenBao is unavailable.
Versioned keys and rotation
OpenBao supports versioned encryption keys with key rotation. For C1.1, the question is whether confidential data protected under an older key version stays readable and whether rotation happens on a schedule you can prove. Document the rotation interval in your key management policy, keep the version history, and test a decryption of data written under an earlier version. Confirm how your deployment handles re-encryption of existing ciphertext, since that depends on how your application stores it.
Signing and verifying labeled records
The transit engine also signs and verifies data. Signing can show that a record carrying a confidentiality label has not been altered after the label was applied, which supports the integrity side of protecting information while it is kept. Use it for records where tampering would matter to a customer or regulator, such as exported reports or disclosure logs. The evidence is the signing key inventory and the verification results. Confirm with your architect that signatures are applied when the label is set, not later in a batch job.
License terms that affect delivery
Nextcloud is licensed under AGPL-3.0-only and OpenBao under MPL-2.0. The AGPL's network clause can require offering source code when you modify Nextcloud and users interact with it over a network, which matters if you customize it for a client. MPL-2.0 is file-level copyleft, so modified files carry their own obligations. Running an unmodified copy for internal use raises fewer obligations, but the terms follow any changes your team or DeployOpen makes. Have counsel confirm the obligations before deployment.
Who owns C1.1 and what can be outsourced
Your team owns the decision about what counts as confidential and what the organization has promised customers about it. C1.1 is tested against your own confidentiality objectives, so those commitments must be written down before anyone can measure controls against them. The team also carries accountability for the outcome, which the auditor confirms through management's written representations.
- Confidentiality commitments: Agree which contract clauses, data processing terms and internal objectives define confidential information, and keep them consistent with your customer agreements and trust page.
- Classification scheme: Define labels such as confidential, internal and public, with examples drawn from your own systems, and decide who may reclassify data.
- Owner assignments: Name a data owner for each confidential data set, such as customer exports, source code or backup archives, and record who approves access to it.
- Retention and destruction rules: Decide how long each class is kept, and pass the disposal rules to the C1.2 owners so classification drives both protection and destruction.
- Management assertion: Sign the assertion and representation letter only after checking that the described controls exist and run as stated.
Check that every confidential data set has a named owner and a written classification before the auditor requests them.
An implementation partner performs the technical preparation that your team then owns. For self-hosted platforms running in your cloud accounts, data centers or air-gapped networks, a partner such as DeployOpen can map data locations, configure protections and assemble evidence. The partner does not decide what is confidential and does not issue any opinion on the controls it helped build.
- Data inventory: Map where confidential information sits, including file stores, databases, backups, logs and exports, and flag places where file names or folder structure may reveal content.
- Protection on self-hosted platforms: Configure encryption at rest where the platform supports it. Nextcloud server-side encryption, for example, protects file contents with keys kept on the server but does not encrypt file names or folder structure, so those gaps need access and handling controls and must be documented.
- Key and secret handling: Deploy a secrets engine such as the OpenBao transit engine, so applications can encrypt and decrypt data without storing it, and configure versioned keys and a rotation schedule.
- Evidence set: Produce configuration exports, access lists, rotation logs and inventory snapshots that show each control working across the period.
- Review records: Set up recurring reviews of the inventory and log findings, while the conclusions stay with your staff.
Ask the partner to state in writing which tasks it performs and which remain with your staff.
The independent CPA firm tests the controls and issues the SOC 2 report. Its value depends on independence, so the firm must be able to examine controls objectively, including controls it did not design or operate. For a Type 1 report, the auditor tests design as of a date. For a Type 2 report, it tests design and operating effectiveness over an observation period, using the AICPA 2017 Trust Services Criteria as the benchmark.
- Design testing: Reads the classification scheme, inventory and protection configuration to judge whether they would meet your confidentiality commitments if operated as described.
- Operating effectiveness: Samples records across the period, such as rotation logs, access approvals and destruction records, to test whether controls ran consistently.
- Written representations: Obtains management's representations before issuing an opinion, so the organization stays accountable for its description and controls.
- Independence line: A firm that configures your controls may help you prepare, but it cannot also examine and opine on those same controls. Confirm the split in the engagement letter.
- Report issuance: Only the CPA firm issues the report. No implementation partner or consultant can issue it.
Confirm early with the CPA firm which preparation tasks its independence policy permits.
Where organizations fall short on confidential information controls
Most C1.1 findings are not about missing technology. They come from definitions that never reached the systems, and inventories that stopped at the production database. The six gaps below are the ones that tend to surface when an assessor asks an organization to show how it identifies confidential information and keeps track of it.
No written definition in commitments
Confidentiality commitments in customer contracts and the security policy often say "confidential information" without defining it. Without a definition, staff cannot tell which data the commitments cover, and the auditor has no baseline to test against. Fix: write a short definition that names the data types the organization promises to protect, and tie it to the specific commitments in the master services agreement and the trust page. Check that the same definition appears in both places.
Classification scheme no one follows
Many organizations write a classification policy with labels such as confidential, internal and public, but no system enforces them and few staff apply them. A label that exists only in a document does not identify anything. Fix: assign each label a concrete handling rule, apply the label to the systems that hold the data (storage buckets, databases, document repositories), and sample a set of records to confirm the labels match the content.
Confidential data copied into side systems
Customer records and secrets often reach logs, analytics platforms, support tickets and debugging exports. These copies sit outside the classification scheme, so the protections on the source system do not follow them. Fix: list every destination that receives production data, mark which ones may hold confidential fields, and either mask those fields at the point of collection or bring the destination under the same handling rules.
Backups and exports missing from inventory
Inventories usually list the primary production systems, while backup sets, replicas, snapshots and ad hoc spreadsheets are left out. Retained copies keep confidential information for longer than the source system does, and they are harder to find when a retention or disposal decision is made. Fix: include backup and replica locations in the data inventory, record their retention period, and confirm that encryption and access controls cover them.
Secrets and keys outside the scheme
Encryption keys, API tokens and service credentials are sensitive, yet they often sit in configuration files or CI variables that no classification process covers. An assessor who asks where keys are held will expect a single answer. Fix: move keys and credentials into a secrets manager with versioning and rotation, and record which applications read which secret so the inventory shows the full path to protected data.
Single point-in-time evidence
Teams sometimes produce one inventory or classification review for the audit and never update it. Under a Type 2 examination, the auditor needs evidence that the controls operated across the observation period, not only that a document existed on one day. Fix: schedule a periodic review of the inventory and classification labels, record who performed it and what changed, and keep each review as a dated record.
Questions buyers ask about C1.1 cost, effort and outside help
How much more effort does C1.1 add compared with the rest of a SOC 2?
C1.1 adds less work than the common criteria but it only applies if you include the confidentiality category in scope, so the answer depends on your commitments. The common criteria CC1 to CC9 apply to every SOC 2 and carry most of the controls, evidence and sampling. C1.1 is one of two confidentiality criteria, and its extra effort comes from one task: deciding what counts as confidential in your contracts, then tracing that data through systems, backups and vendors. The effort rises quickly when confidential data is spread across many tools. Ask your examiner to confirm how many systems the confidentiality scope touches before you estimate the work.
Can a small team do the C1.1 classification in-house?
Usually yes, if one person owns the scheme and the team can finish the data inventory without outside tools. A small team needs a short classification policy, a list of confidential data types tied to customer contracts, and named owners for each system holding that data. The harder part is consistency: engineers must label new data correctly and reviewers must check that labels match the policy. Outside help is most useful when the team cannot agree on what the contracts actually promise, or when no one has time to trace data through backups and logs. Ask a partner to show how the scheme will be maintained after the first cycle, not only how it will be built.
What does C1.1 need from the engineering and legal teams?
Legal defines what confidential means for your customers, and engineering proves where that information lives and how it is protected. Legal reviews customer agreements, non-disclosure terms and any regulatory duties to confirm which commitments the confidentiality criteria must meet. Engineering maps data stores, applies labels or tags, sets access and encryption expectations, and keeps the inventory current as systems change. Both teams sign off on the classification scheme. Ask who on each team holds the approval rights before work starts, because unclear ownership is the most common reason the inventory stalls.
How long does building the confidential information inventory take, and what drives that time?
The time depends mainly on how many systems hold customer data and how well those systems are documented. Build time rises with the number of databases, file stores, log pipelines, backups, analytics tools and vendor platforms, because each one needs an owner and a data type. It also rises when contracts use vague definitions of confidential information, since legal must resolve them first. Work falls when infrastructure is defined as code and cloud accounts are already tagged. No duration is set by the standard, so ask any partner for a written scope that lists the systems in scope and the milestones for review, then compare those milestones with your own environment.
Can an auditor write our classification scheme for us?
No. An auditor may test your scheme but should not write it, because writing it would make the auditor responsible for the design it later examines. Auditors are independent, and a SOC 2 examination relies on management owning its controls and making written representations about them. An implementation partner can draft materials, prepare inventories and help you configure tools, while your team approves the scheme and keeps it current. An auditor's role is to assess whether the scheme and its operation meet the criteria. Ask any firm to put in writing which parts it prepares and which parts management must approve, and confirm that the auditor will not do the design work.
How does C1.1 differ from C1.2 disposal in the evidence it produces?
C1.1 produces evidence of identification and protection, while C1.2 produces evidence that confidential data was destroyed when no longer needed. For C1.1, auditors typically look for the classification policy, the inventory of confidential data and the controls that keep it protected while retained, such as access restrictions and encryption settings. For C1.2, they look for retention rules, disposal requests, destruction logs and records showing the data was removed from systems and backups. The two criteria meet at the inventory, since disposal can only be tested against data that was first identified. Ask your partner to show how one inventory will feed both sets of records.
What should we ask a partner to include in a written scope for C1.1?
Ask for a scope that names the systems, the deliverables, the responsibilities and the review points. The document should list which data stores, backups and vendors are included, what classification scheme will be produced, and who approves each deliverable. It should state what the partner prepares, such as the inventory, the handling procedures and the evidence index, and what your team must supply or sign. Ask how the scope handles changes in systems and what it costs when the scope grows. DeployOpen works on fixed-scope engagements agreed in writing before work starts, so request a written scope from any firm you evaluate and check that it names what the auditor will and will not do.
How DeployOpen prepares C1.1 controls and evidence
DeployOpen plans, implements and documents the technical side of confidential information handling inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems, controls and evidence that an independent CPA firm will examine for C1.1, but the organization owns its confidentiality commitments and the auditor alone issues the report.
How we scope
- Engagements are fixed-scope, with systems, data stores and confidentiality commitments agreed in writing before work starts.
- We map which repositories, file shares and databases hold confidential information and which classification labels apply to each.
- The written scope names who owns each classification decision and which retention and destruction triggers the organization has set.
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial scope is delivered.
How we build
- We configure self-hosted platforms so confidential files are encrypted at rest with keys held under your control.
- We set up transit encryption and key rotation for application data so keys are versioned and recorded.
- Access to confidential stores is limited to identified roles, and those permissions are documented for review.
- We run security testing against the configured systems to check that protections hold before handover.
How we hand over
- You receive a documented control description for C1.1 that states what is protected, where and by which mechanism.
- Evidence samples are delivered in a form your auditor can request, such as configuration exports and access records.
- Runbooks explain how staff classify, handle and protect confidential information during the retention period.
- Known limits are stated plainly, including that Nextcloud server-side encryption does not encrypt file names or folder structure.
How we support
- We help your team prepare for the auditor's evidence requests for the examination period you select.
- Changes to platforms, keys or storage locations are documented so the control description stays accurate over time.
- Ask any partner to confirm which controls they own, which the organization owns, and which the independent auditor tests.
- Confirm with your CPA firm which evidence format and sampling approach they expect before fieldwork begins.
