The entity identifies and maintains confidential information

To meet the the entity identifies and maintains confidential information requirement (SOC 2 TSC-C1.1), you need a repeatable way to define what “confidential information” is for your services, inventory where it lives, assign owners, and keep that inventory current as systems, data flows, and third parties change. Auditors will look for clear criteria, consistent classification, and evidence the process runs in practice.

Key takeaways:

• Define “confidential information” in scope-specific terms, then map it to a classification scheme your teams can apply.
• Maintain an authoritative inventory of confidential data (systems, locations, owners, retention, sharing) and keep it current via change triggers.
• Retain evidence of operation: discovery outputs, inventory snapshots, review/approval records, and exceptions with risk acceptance.

SOC 2 Confidentiality is easy to describe and hard to prove. TSC-C1.1 is the foundation: if you cannot identify what confidential information you have and where it is, every downstream control (access, encryption, retention, secure disposal, incident response, third-party sharing) becomes guesswork.

Operationalizing this requirement means turning a concept (“confidential information”) into a managed object with an owner, location, handling rules, and lifecycle controls. For most service organizations, the fastest path is to combine (1) a practical definition and classification policy, (2) a data inventory tied to systems and workflows, and (3) a maintenance mechanism integrated with engineering, IT, and procurement change processes.

This page gives requirement-level guidance you can implement quickly: who owns what, what artifacts to create, how to run the process month to month, and what auditors commonly challenge in SOC 2 examinations. It assumes you’re scoping a SOC 2 report for one or more services and need evidence that the identification and maintenance of confidential information is designed and operating.

Regulatory text

Requirement (SOC 2 TSC-C1.1): “The entity identifies and maintains confidential information.” ¹

What the operator must do

You must (a) determine what information is “confidential” for the services in scope, and (b) keep that determination current and usable by the people and systems that protect it. “Maintains” is the exam pressure point: auditors typically expect an inventory or register that stays accurate through business change, not a one-time spreadsheet created for the audit.

---

Plain-English interpretation

If you handle information that customers or your business would not want broadly disclosed, you need a consistent way to:

1. Recognize it (clear definition and classification criteria).
2. Record it (where it is stored/processed/transmitted and who owns it).
3. Keep records current (updates when systems, integrations, and third parties change).

A practical test: if you had to answer, “Which systems contain customer confidential data, which third parties receive it, and who approves those flows?” you should be able to answer from a controlled, current source of truth.

---

Who it applies to (entity and operational context)

In scope entities

• Service organizations pursuing SOC 2 reports for services that store, process, transmit, or can access customer or company confidential information. ¹

Common operational contexts

• SaaS platforms (multi-tenant or single-tenant)
• Managed services with production access
• Data pipelines/analytics platforms
• Support organizations with ticketing systems that may contain customer secrets, logs, exports, or attachments
• Environments with multiple third parties (cloud providers, sub-processors, contractors) that touch in-scope data

Teams typically involved

• Compliance/GRC (program owner, evidence owner)
• Security (classification standards, discovery tooling)
• Engineering/IT (system ownership, architecture/data flow inputs)
• Legal/Privacy (contractual confidentiality terms, customer definitions)
• Procurement/Vendor management (third-party sharing and sub-processor alignment)

---

What you actually need to do (step-by-step)

Step 1: Define “confidential information” for your SOC 2 scope

Create a written definition aligned to your service commitments and contracts. Keep it operational, not academic.

Minimum outputs

• Confidential Information Definition (policy section or standard)
• Examples and non-examples relevant to your environment

Typical inclusions (customize)

• Customer content and files
• Customer account data and billing records
• Security artifacts: secrets, private keys, tokens, credentials
• Non-public product roadmaps, pricing, internal financials
• Support artifacts: logs, debug exports, tickets with attachments

Exam-ready tip: tie the definition to handling expectations (who can access, where it may be stored, whether it can be shared with third parties, retention/disposal expectations). Auditors want to see that “confidential” changes behavior.

---

Step 2: Establish a classification scheme people can apply

You need a simple taxonomy that maps to your handling controls. Overly complex schemes collapse in practice.

Recommended structure

• 2–4 levels (example: Public / Internal / Confidential / Restricted)
• Decision rules: how to classify, who decides, when to escalate
• Default rules: if uncertain, classify as the higher sensitivity until reviewed

Implementation detail that matters: define how “Confidential” differs from “Restricted” (for example, “Restricted” might include secrets and production credentials with stricter storage and access rules). Consistency reduces exceptions.

---

Step 3: Build a confidential information inventory (source of truth)

This is the core “identify and maintain” artifact. You can start in a GRC tool, CMDB, or controlled spreadsheet, but it must be governed.

Inventory fields auditors expect to be sensible

• Data element/category (what it is)
• Classification level
• System(s) of record and secondary storage locations
• Processing use case(s) and data flows (high level)
• Owner (business + technical)
• Access model summary (roles/teams)
• Encryption expectations (at rest/in transit) as applicable
• Retention period and disposal method reference
• Third parties/sub-processors that receive or can access it
• Notes on exceptions and approvals

Practical scoping approach

• Start with the service boundary: production systems, logging/monitoring, ticketing, analytics, CI/CD artifacts, and file stores.
• Add third-party endpoints where data leaves your boundary.

---

Step 4: Validate the inventory with discovery + interviews

You need evidence that the inventory reflects reality.

Validation methods (use more than one)

• Architecture review: diagrams, repositories, infra-as-code
• Data discovery scans (where available) for common sensitive patterns
• Admin console exports (SaaS systems, cloud storage inventories)
• Stakeholder interviews (engineering leads, support, IT)

Evidence to save: scan outputs, export files, meeting notes, sign-offs, and a dated inventory snapshot.

---

Step 5: Put “maintenance” on rails (change-driven updates)

Most SOC 2 findings here come from stale inventories. Define triggers and owners.

Maintenance triggers (choose what matches your org)

• New system/service introduced into scope
• New data store/bucket/index created for production
• New integration or API sharing customer data externally
• New third party/sub-processor with data access
• Material feature changes affecting data types collected
• M&A or environment consolidation

Mechanisms that work

• Add a required check to the SDLC (privacy/security review) that includes: “Does this create new confidential data types or locations?”
• Add a procurement intake question: “Will this third party store/process/transmit confidential information?”
• Require periodic owner attestation that inventory entries are still accurate (cadence based on your change rate).

What auditors want to see: evidence that updates occur because changes occurred, not just because the audit is coming.

---

Step 6: Connect classification to handling controls (so it’s not shelfware)

TSC-C1.1 is upstream, but auditors will test whether identification drives control behavior.

Examples of linkage

• Access control: restricted groups for Confidential/Restricted repositories
• Storage controls: approved systems for Restricted data (no personal drives)
• Logging: avoid storing Restricted secrets in logs; redaction rules
• Third-party governance: contracts and DPAs aligned to the classification

---

Required evidence and artifacts to retain

Keep artifacts in an audit-ready folder with version control and approvals.

Core artifacts

• Confidential Information Policy/Standard (definition + classification scheme) ¹
• Confidential Information Inventory (current view)
• Inventory snapshots showing history (dated exports)
• Data flow diagrams or architecture references supporting the inventory
• Discovery outputs (scan reports, cloud inventory exports)
• Ownership assignments (RACI or system owner list)
• Maintenance procedure (triggers, responsibilities, review steps)
• Review and approval records (tickets, change reviews, meeting minutes)
• Exceptions log with approvals and risk acceptance rationale

Evidence quality checks

• Dated
• Tied to the in-scope services
• Shows review/approval (who, when, what changed)
• Reproducible (another person could rerun the process)

---

Common exam/audit questions and hangups

Expect auditors to press on these points:

1. “What is your definition of confidential information for this report scope?”
   Hangup: a generic definition that doesn’t map to your actual product data.

2. “Show me where confidential information is stored and processed.”
   Hangup: inventory missing logs, support systems, analytics, or backups.

3. “How do you keep this current?”
   Hangup: no triggers, no assigned owners, no evidence of updates over time.

4. “How do you know teams classify consistently?”
   Hangup: no decision rules, no training, no review for new systems.

5. “Which third parties receive confidential information?”
   Hangup: sub-processors list doesn’t match the inventory or actual integrations.

---

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in SOC 2	Fix
One-time “audit spreadsheet”	Doesn’t meet “maintains”	Add change triggers and recurring review evidence
Inventory limited to production database	Misses ticketing, logs, exports, SaaS tools	Map end-to-end workflows and secondary stores
No owners	Nobody updates entries	Assign business + technical owners per system/data set
Classification levels with no handling rules	Classification has no operational effect	Map each class to access, storage, sharing, retention expectations
Third-party sharing treated separately	Gaps between vendor management and data inventory	Add third-party recipients into the inventory and tie to procurement intake

---

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list enforcement actions.

Operational risk still concentrates in predictable places:

• Scope drift: new features collect new confidential fields without being added to inventory.
• Uncontrolled sprawl: confidential exports land in collaboration tools, personal drives, or unmanaged buckets.
• Third-party blind spots: confidential data shared with a third party that was not assessed or contractually bound to confidentiality expectations.

For SOC 2, the most common outcome is an examination exception or qualification when the auditor can’t reconcile your claimed inventory to real systems and data flows, or when you cannot show the process operates throughout the period.

---

Practical 30/60/90-day execution plan

Days 0–30: Define and baseline

• Confirm in-scope services and environments for the SOC 2 report.
• Publish a confidential information definition and classification scheme aligned to your services. ¹
• Identify system owners for core platforms: production, logs, support, analytics, file storage, CI/CD.
• Build the first version of the confidential information inventory with required fields.
• Set up an evidence repository and versioning approach.

Deliverables: policy/standard, inventory v1, owner list, initial architecture references.

Days 31–60: Validate and connect to change management

• Run discovery and exports to validate locations (cloud storage inventories, SaaS exports, targeted scans).
• Reconcile discrepancies and document exceptions with approvals.
• Add maintenance triggers to:
  • SDLC/security review intake
  • Procurement/third-party intake
  • System change process (cloud account provisioning, new buckets, new integrations)
• Create a lightweight review checklist for inventory updates.

Deliverables: validated inventory v2, scan/export evidence, documented triggers, review checklist.

Days 61–90: Prove operation and make it audit-ready

• Execute at least one maintenance cycle driven by real changes (new integration, new third party, new data store) and retain the evidence trail.
• Run an internal audit-style walkthrough: pick a confidential data element and trace it through systems and third parties using your inventory.
• Train engineering/support leads on classification decision rules and escalation paths.
• If you use a system like Daydream, centralize inventory entries, link them to owners and change tickets, and generate clean evidence snapshots without manual chasing.

Deliverables: operating evidence (tickets/approvals), walkthrough results, training record, audit binder.

---

Frequently Asked Questions

What counts as “confidential information” under SOC 2 TSC-C1.1?

TSC-C1.1 requires you to define it for your services and then manage it consistently. In practice, treat any non-public customer data, security secrets, and non-public business information as candidates, then document the definition and examples in your standard. ¹

Do we need an automated data discovery tool to satisfy this requirement?

No. Auditors look for a reliable method and evidence it operates; a governed inventory plus exports, architecture reviews, and targeted scans can be sufficient. Automation helps with scale, but the requirement is identification and maintenance, not a specific tool. ¹

How detailed does the confidential information inventory need to be?

Detailed enough that someone outside your team can locate where confidential data lives, who owns it, and which third parties touch it. If your inventory cannot explain data in logs, ticketing, analytics, and backups, it is usually too shallow for SOC 2 evidence.

How do we prove we “maintain” the inventory over the audit period?

Keep dated snapshots and show updates tied to change triggers (new system, new integration, new third party). Auditors respond well to a ticket trail that shows review, approval, and the resulting inventory update.

Our product changes weekly. How do we keep this from becoming a spreadsheet fire drill?

Make inventory updates an output of existing workflows: SDLC security reviews, infrastructure provisioning, and procurement intake. Assign owners and require updates as part of “definition of done” for changes that affect confidential data.

Does third-party data sharing belong in this requirement or a separate vendor control?

Put third-party recipients in the confidential information inventory and link them to your third-party due diligence process. Splitting the two creates gaps where data leaves your boundary without being captured in scope.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017