Product

SOC 2 Confidentiality Controls: What Auditors Check and What Evidence You Must Produce

Master SOC 2 Confidentiality controls. Learn how to classify data, secure cloud environments, and provide the specific evidence auditors require for compliance.

June 2, 202610 min read

Introduction

For senior engineers and tech leads, the SOC 2 audit process often feels like a distraction from building product. However, when a major enterprise prospect asks for your SOC 2 Type II report, the technical nuances of the "Confidentiality" Trust Services Criteria (TSC) suddenly move to the front of the roadmap. While Security is the mandatory "Common Criteria" base for any SOC 2 audit, Confidentiality is an optional addition that is frequently requested by clients who entrust you with their intellectual property, proprietary algorithms, or sensitive business data.

Confidentiality is distinct from Privacy. While Privacy focuses on Personal Identifiable Information (PII) and compliance with regulations like GDPR or CCPA, Confidentiality focuses on protecting data that an organization has agreed to keep secret. This includes everything from trade secrets and legal documents to internal financial projections and source code. For a cloud-native SaaS company, demonstrating Confidentiality means proving that you have a rigorous lifecycle for sensitive data: you know where it is, you control who sees it, you encrypt it everywhere, and you destroy it when it is no longer needed.

In this guide, we will break down what auditors specifically look for within the Confidentiality criteria, how to architect your cloud environment to meet these requirements, and how to produce the technical evidence necessary to pass the audit without drowning in manual screenshots.

Understanding the SOC 2 Confidentiality Requirements

The AICPA defines Confidentiality through specific points of focus within the Trust Services Criteria. Unlike the Security criteria, which are broad, Confidentiality is highly targeted. It centers on the principle that confidential information should be protected from the moment it is received or created until it is properly disposed of.

The core requirements generally fall into three categories:

Identification and Classification: You must have a documented policy that defines what "confidential" means for your organization and a process for identifying data that meets that definition.
Protection and Access Control: Once identified, this data must be protected via logical and physical access controls, as well as robust encryption.
Retention and Disposal: Confidential data cannot live forever. You must prove that you have a retention schedule and a secure method for deleting data once its utility or legal requirement has expired.

Auditors test these controls by looking for "operating effectiveness" over an observation period (usually 6–12 months for Type II). It is not enough to have a policy written in a PDF; you must show that the policy was enforced consistently through logs and configuration states.

Data Classification: The Foundation of Confidentiality

You cannot protect what you haven't identified. Auditors will start by asking for your Data Classification Policy. For a technical team, this translates into how you tag and segment data in your cloud environment.

Defining Your Tiers

A standard classification schema often looks like this:

Public: Information intended for public consumption (marketing materials, public docs).
Internal: Data for employees only (internal wikis, non-sensitive Slack channels).
Confidential: Sensitive business data (customer contracts, roadmap, financial data).
Restricted/Highly Confidential: The "crown jewels" (passwords, encryption keys, PII, source code).

Implementation in the Cloud

In an AWS, GCP, or Azure environment, classification should be enforced through resource tagging and infrastructure-as-code (IaC). For example, if you use Amazon S3, every bucket should have a DataClassification tag. This isn't just for the auditor; it allows you to write IAM policies and SCPs (Service Control Policies) that restrict access based on those tags.

If you claim that "Confidential" data is only stored in specific RDS instances or S3 buckets, the auditor will sample those resources and check their configuration. They will look for:

Tags: Evidence that resources are labeled according to the policy.
Network Segregation: Ensuring that databases holding confidential data are in private subnets with no direct internet egress.
Access Logs: Proof that access to these specific resources is logged and monitored (e.g., CloudTrail or VPC Flow Logs).

Technical Controls: Encryption and Key Management

Encryption is the heavy lifter for the Confidentiality criteria. Auditors expect to see encryption at rest and encryption in transit for all data classified as Confidential or Restricted.

Encryption in Transit

The expectation here is TLS 1.2 or higher for all data moving over public networks. However, auditors also look at internal traffic. If your microservices communicate over unencrypted HTTP within a VPC, you may face questions about how you prevent lateral movement or sniffing. Implementing a Service Mesh (like Istio or Linkerd) with Mutual TLS (mTLS) is a gold-standard way to satisfy this requirement at scale.

Encryption at Rest and KMS

For data at rest, auditors aren't just looking for the "encrypted" checkbox to be ticked on an S3 bucket. They want to see how the keys are managed. Who has the authority to use the keys? Are the keys rotated?

Using a managed service like AWS KMS (Key Management Service) or Google Cloud KMS is standard practice. To satisfy a SOC 2 auditor, you should demonstrate:

Key Rotation: Automatic annual rotation of Customer Master Keys (CMKs).
Separation of Duties: The engineers who manage the KMS keys should not necessarily be the same people who have access to the data stored in the encrypted volumes.
Least Privilege: IAM policies should explicitly define which services and roles can call kms:Decrypt.

Below is an example of a technical implementation using Terraform that ensures an S3 bucket is encrypted using a specific KMS key with a rotation policy enabled:

resource "aws_kms_key" "confidential_data_key" {
  description             = "KMS key for confidential customer data"
  deletion_window_in_days = 30
  enable_key_rotation     = true
 
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "Enable IAM User Permissions"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
        }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "Allow access for Confidential Data Service"
        Effect = "Allow"
        Principal = {
          AWS = aws_iam_role.data_processor_role.arn
        }
        Action = [
          "kms:Decrypt",
          "kms:GenerateDataKey"
        ]
        Resource = "*"
      }
    ]
  })
}
 
resource "aws_s3_bucket" "confidential_storage" {
  bucket = "company-confidential-assets"
}
 
resource "aws_s3_bucket_server_side_encryption_configuration" "confidential_cfg" {
  bucket = aws_s3_bucket.confidential_storage.id
 
  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.confidential_data_key.arn
      sse_algorithm     = "aws:kms"
    }
  }
}

This configuration provides the auditor with a "point-in-time" evidence piece showing that encryption is forced and keys are rotated.

Secure Disposal: The "Forgotten" Requirement

One of the most common gaps in SOC 2 Confidentiality is the disposal of data. The criteria require that confidential information is destroyed when it is no longer needed for business or legal purposes.

In the cloud, "disposal" is different than in the physical world. You aren't shredding hard drives; you are deleting objects and volumes. Auditors look for:

Retention Policies: A document stating how long data is kept (e.g., "Customer data is deleted 30 days after contract termination").
Execution Records: Proof that deletion actually happened. This is often the hardest part to prove.
Cryptographic Erasure: For high-security environments, deleting the KMS key used to encrypt the data is considered a valid form of secure disposal, as it renders the data unrecoverable.

If you use S3 Lifecycle Policies to move data to Glacier and then expire it, you should provide the JSON configuration of those policies as evidence.

The Evidence Artifacts: What to Produce

When the audit starts, the auditor will provide a Request List (DRL). For Confidentiality, you should be prepared to provide the following artifacts:

Data Classification Policy: A formal document approved by management.
Inventory of Confidential Data: A list of databases, buckets, or file systems that house confidential information.
Encryption Configuration Logs: Screenshots or JSON exports showing that RDS instances, S3 buckets, and EBS volumes are encrypted.
KMS Key Policies: Documentation showing who has access to decryption keys.
TLS Configuration: Results from an SSL Labs scan or a configuration export from your Load Balancer (ALB/NLB) showing the supported ciphers and TLS versions.
Disposal Logs: Evidence of data deletion (e.g., a ticket showing a database was decommissioned and the underlying storage wiped/deleted).
NDAs: Proof that employees and third-party contractors have signed Non-Disclosure Agreements.

Moving Beyond Screenshots

A major pain point for senior engineers is the manual collection of these artifacts. Traditional audits involve taking hundreds of screenshots of the AWS Console. This is not only tedious but also prone to error and provides poor security value.

As highlighted in the article Beyond Screenshots, the modern approach involves using API-driven evidence collection. Instead of a screenshot of a single S3 bucket, you provide a JSON output of a script that queries the encryption status of all buckets. This provides the auditor with a more comprehensive view and allows your team to automate the evidence-gathering process for future audits.

Common Gaps and How to Close Them

Even well-architected teams often fall short during the first Confidentiality audit. Here are the most common gaps and how to remediate them:

Shadow Data in Logs: Often, engineers carefully encrypt the database but forget that the application logs (CloudWatch, ELK stack) might be capturing confidential parameters or payloads in plain text. Remediation: Implement log scrubbing middleware and ensure log groups have their own KMS encryption.
Staging and Dev Environments: It is common to see production data "sanitized" and moved to staging for debugging. If that staging environment doesn't have the same Confidentiality controls, you are in violation. Remediation: Use synthetic data for testing or ensure your staging environment is within the SOC 2 boundary and fully encrypted.
Over-privileged Service Accounts: If your CI/CD runner or a broad "Developer" role has s3:GetObject on all buckets, your confidentiality controls are weak. Remediation: Use IAM Access Analyzer to identify unused permissions and move toward a Zero Trust architecture.
Lack of Disposal Records: Teams delete data but don't log the event of deletion in a way that is auditable. Remediation: Use a "Deletion Log" or ensure your ticketing system (Jira/Linear) captures the confirmation of data destruction as part of the offboarding or decommissioning workflow.

Conclusion

Passing the SOC 2 Confidentiality audit is less about the "paperwork" and more about the integrity of your data lifecycle. For a technical lead, the goal is to build a system where confidentiality is "secure by default." By implementing rigorous data classification, automating your encryption via IaC, and moving toward API-driven evidence collection, you can satisfy auditors while actually improving the security posture of your organization.

Remember that SOC 2 is not a "one and done" event. It is a continuous commitment to operating your controls. By integrating these requirements into your daily engineering workflows—such as requiring encryption in your Terraform modules and automating your evidence gathering—you ensure that the next audit is a non-event, allowing your team to stay focused on building the product. Protecting your customers' confidential data is not just a compliance checkbox; it is a fundamental component of the trust that allows a SaaS business to scale.

This content was generated by AI.