TSC-C1.1 Guidance

The fastest way to fail TSC-C1.1 is to treat it as a policy-only requirement. Auditors are looking for a working mechanism that reliably identifies confidential information across the environments and processes in scope for your SOC 2 report, then keeps that identification current as systems and data change. Without that, downstream controls (access restriction, encryption, retention, secure disposal, and confidentiality commitments) become inconsistent and hard to test.

For a Compliance Officer, CCO, or GRC lead, TSC-C1.1 is a foundation control: it creates the shared language and authoritative source of truth for what must be protected as “confidential.” In practice, you are building (1) a definition and classification approach, (2) an inventory with ownership, and (3) an operating cadence and evidence trail.

This page gives requirement-level, operator-focused guidance to implement the tsc-c1.1 guidance requirement with artifacts that stand up in a SOC 2 examination. Source reference is the AICPA Trust Services Criteria 2017 confidentiality criterion TSC-C1.1 ¹.

Regulatory text

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

Operator interpretation (what you must do):

1. Identify confidential information in scope: define it, classify it, and locate where it exists (systems, repositories, endpoints, and key processes).
2. Maintain that identification over time: keep it accurate through change management, periodic reviews, and ownership accountability.
3. Make it actionable: the identification must be consumable by control operators (Security, IT, Engineering, HR, Legal, Support) so they can apply confidentiality safeguards consistently.

Plain-English interpretation

You need an up-to-date “map” of confidential information: what it is, where it lives, who owns it, and how it is labeled. If you cannot point to a living inventory and show how it stays current, auditors will treat your confidentiality program as ad hoc, even if your technical controls are strong.

Who it applies to

Entities: Organizations undergoing a SOC 2 audit with the Confidentiality category in scope ¹.

Operational context (typical in-scope scenarios):

• SaaS or managed services handling customer nonpublic data (customer content, business data, configuration, API payloads).
• Internal corporate confidential information used to deliver the service (security keys, credentials, proprietary code, pricing, contracts).
• Third parties that store/process your confidential information (cloud hosting, ticketing systems, analytics, managed support tools). Even if a third party hosts it, you still need to identify it and track where it goes.

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

Step 1: Define “confidential information” for your organization

Create a written Confidential Information Standard (or Data Classification Standard) that includes:

• Definition: what counts as confidential for your organization and services (customer data, proprietary business info, credentials/secrets, security artifacts).
• Classification levels: keep this simple enough to operate. A common pattern is “Public / Internal / Confidential / Restricted,” but use labels that match your culture and risk.
• Examples by function: Sales (pricing), Engineering (source code), Security (private keys), Support (tickets), HR (employee records).
• Handling rules per level: storage locations allowed, access requirements, encryption expectations, sharing constraints, retention/disposal expectations, and logging expectations.

Practical tip: auditors test whether your definition is operational. If two teams classify the same data differently, tighten definitions and add examples.

Step 2: Build an inventory that ties confidential information to systems and owners

Create and maintain an inventory that answers, at minimum:

• System / repository name (e.g., production database, object storage, CRM, ticketing tool)
• Data types stored/processed
• Confidentiality classification
• Business owner (accountable for what the data is and why it’s needed)
• Technical owner (accountable for implementation and access paths)
• Primary access methods (SSO, local accounts, API keys, service accounts)
• Key data flows (what sends data to what, including third parties)

Keep it usable. A spreadsheet works early on, but it must be controlled (versioning, approvals, access restrictions). Many teams operationalize this in a GRC tool or CMDB once scale demands it.

Step 3: Establish triggers so the inventory stays current (maintenance mechanism)

“Maintain” is the hard part. Define explicit update triggers, such as:

• New system introduced into the environment
• New third party stores/processes confidential information
• New product feature changes data collected or stored
• Material change to data retention or customer contract terms
• Migration to new infrastructure (new region, new cloud service, new data store)

Tie triggers to processes you already run:

• Change management: require a classification/inventory check as an approval gate for relevant changes.
• Procurement / third-party onboarding: require data type and classification mapping before contracting.
• SDLC: require engineering to record new data elements and storage locations when building features that collect/store data.

Step 4: Set a review cadence and accountability

Define:

• Control owner: usually Security/GRC.
• Contributors: Engineering, IT, Product, Legal/Privacy, Support Operations.
• Review process: how updates are proposed, approved, and recorded.
• Periodic review: a scheduled review of the classification standard and inventory for completeness and accuracy.

Auditors commonly look for proof that this is not a one-time exercise. Keep meeting notes, review checklists, and approval records.

Step 5: Connect identification to downstream controls (so it’s testable)

TSC-C1.1 is foundational. Make it explicitly drive:

• Access control decisions (who can access Confidential vs Restricted)
• Encryption requirements (at rest/in transit expectations by class)
• Logging/monitoring priorities for systems containing confidential information
• Data retention and disposal rules
• Third-party risk reviews and contractual confidentiality clauses

If your confidentiality identification does not affect real controls, auditors may question whether it is effectively designed.

Step 6: Implement monitoring and an audit trail

Maintain an auditable record of:

• Inventory updates (who changed what, when, and why)
• Policy/standard version history and approvals
• Exceptions (what doesn’t meet the standard, why, who approved, and remediation plan)
• Periodic assessment outcomes and follow-up actions

This aligns with common expectations to “document control activities,” “maintain evidence of operation,” and “test control effectiveness” as part of SOC 2 readiness and examination support ¹.

Required evidence and artifacts to retain

Use this list as your SOC 2 evidence pack for the tsc-c1.1 guidance requirement:

Core documents

• Confidential Information / Data Classification Policy or Standard (approved, version-controlled) ¹
• Data/System inventory with confidentiality classification and owners ¹
• Data flow diagrams or narratives for key services and third-party transfers (where confidential information moves)

Operational evidence (what auditors usually need)

• Change tickets or PRD/architecture review records showing classification/inventory updates tied to system or feature changes
• Periodic review records: agendas, checklists, minutes, sign-offs, and resulting updates
• Samples of completed assessments or reviews (for example, a quarterly inventory review output)
• Audit trail from the system of record (GRC tool/CMDB/wiki version history)

Testing evidence

• Internal control test plan and results for TSC-C1.1 design and operating effectiveness (what was sampled, what passed/failed, remediation)

Daydream note (earned mention): if you’re coordinating evidence across Engineering, IT, and Security, Daydream can act as the control system of record where you track ownership, collect artifacts, and maintain the audit trail for recurring reviews without chasing approvals across inboxes.

Common exam/audit questions and hangups

Auditors tend to probe these areas for TSC-C1.1:

1. Definition clarity: “Show me how you define confidential information. Where is it documented and who approved it?” ¹
2. Inventory completeness: “How do you know you found all the places confidential information is stored and processed?”
3. Maintenance mechanism: “What triggers updates? Show evidence of updates after changes.”
4. Ownership: “Who is accountable for classifying data in a system and keeping it accurate?”
5. Scope alignment: “Does your inventory match the systems in SOC 2 scope, including third parties?”
6. Operational linkage: “Show how classification changes access controls, encryption, retention, or monitoring.”

Hangup to plan for: teams often produce a data inventory but cannot show that updates are required by process. That becomes an operating effectiveness issue in a Type 2 period.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in audit	Fix
Policy exists, but no inventory	Identification is not operational	Build a system-level inventory with classifications and owners
Inventory exists, but no update triggers	“Maintain” is unproven	Add change-management and third-party onboarding gates
Overly complex classification scheme	Teams don’t apply it consistently	Reduce levels, add examples, add decision rules
No evidence of periodic review	Auditors see “set-and-forget”	Schedule reviews and retain sign-offs and diffs
Classification not tied to controls	Identification looks cosmetic	Map classes to access, encryption, retention, and logging requirements
Untracked third parties	Confidential data locations are incomplete	Include third-party systems in inventory and data flows

Enforcement context and risk implications

SOC 2 is an audit framework rather than a regulatory enforcement regime, so you should treat TSC-C1.1 failures primarily as an assurance and customer trust risk ¹. Practically, weak identification and maintenance of confidential information increases the chance of:

• Mis-scoped access controls (over-permissioning)
• Incomplete encryption coverage
• Uncontrolled data sprawl into third-party tools
• Inconsistent retention and disposal

Those gaps can also increase contractual and incident response exposure because you may not know what data was affected or where it resided.

Practical 30/60/90-day execution plan

Days 0–30: Define and inventory the critical path

• Name the control owner and define RACI across Security/GRC, Engineering, IT, Product, Legal/Privacy.
• Draft and approve the Confidential Information / Data Classification Standard with concrete examples ¹.
• Build an initial inventory for in-scope systems and top third parties, focusing on systems that store/process customer data.
• Create a minimal evidence folder structure (policy, inventory, approvals, review records).

Deliverables: approved standard, v1 inventory, documented owners, evidence repository.

Days 31–60: Build maintenance into operations

• Add classification/inventory checks to change management (tickets) and procurement/third-party onboarding.
• Define and document update triggers and an exceptions process.
• Run the first periodic review cycle; record findings and updates.
• Map classification levels to downstream controls (access, encryption, retention) and document those linkages.

Deliverables: change/procurement gates live, review records, control mappings, exception log.

Days 61–90: Prove operating effectiveness and prepare audit-ready evidence

• Test the control internally: sample recent changes and confirm the inventory was updated appropriately.
• Close gaps found in the first review cycle (missing systems, unclear owners, inconsistent classification).
• Produce an auditor-facing narrative: how you identify confidential information, how you maintain it, and where evidence lives.
• If you use Daydream, configure recurring tasks, automated evidence collection reminders, and approval workflows to preserve the audit trail.

Deliverables: test results, remediations, audit narrative, evidence pack ready for walkthrough.

Frequently Asked Questions

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

TSC-C1.1 requires you to define it for your entity and then apply that definition consistently ¹. Most organizations include customer nonpublic data, proprietary business information, and security-sensitive material such as credentials and keys.

Do we need a formal data classification policy, or is a data inventory enough?

You need both: a written standard that defines confidentiality and a maintained inventory that shows where that information exists ¹. Auditors usually expect the standard to drive consistent classification decisions.

How detailed does the inventory need to be for SOC 2?

It must be detailed enough to identify where confidential information is stored and processed, who owns it, and how it is kept current ¹. Start with in-scope systems and third parties, then expand as you mature.

How do we prove we “maintain” confidential information identification over time?

Show update triggers tied to change management and third-party onboarding, plus evidence of periodic reviews and documented updates ¹. Version history and approvals are strong evidence.

Does confidential information include data in third-party tools like ticketing or CRM?

If confidential information is stored or processed there, include it in your inventory and data flows, even if the tool is operated by a third party. TSC-C1.1 focuses on identifying and maintaining knowledge of where confidential information resides ¹.

What’s the simplest “good enough” implementation for a startup preparing for SOC 2?

A short classification standard, a controlled inventory covering in-scope systems and key third parties, and a documented review/update process with an audit trail are the minimum building blocks ¹. Keep the scheme simple so teams can apply it without constant GRC intervention.

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 Trust Services Criteria 2017