How to build a Secure SSN Storage System and pass SOC 2 audit

Introduction to SOC 2 and the Imperative of Confidentiality

Service Organization Control Type 2 (SOC 2) is a comprehensive cybersecurity compliance framework developed by the American Institute of Certified Public Accountants (AICPA). Its primary purpose is to establish and verify that third-party service providers, particularly those operating in the Software-as-a-Service (SaaS) industry, have robust controls in place to protect client data. A SOC 2 audit, conducted by an objective third party, serves as an evaluation of an organization's information security practices. The culmination of this process is a SOC 2 report, a formal attestation of a service provider's security posture.

The Five Trust Services Principles

The SOC 2 framework is built upon a foundation of five interconnected Trust Services Principles (TSPs): Security, Availability, Processing Integrity, Confidentiality, and Privacy. These principles define the criteria against which an organization's internal controls are evaluated.

• Security: This is the foundational and only mandatory principle for a SOC 2 audit. It broadly encompasses the protection of systems and data against unauthorized access.
• Availability: This principle ensures that systems meet their service level agreements (SLAs) for uptime and performance, requiring fault-tolerant design and disaster recovery planning.
• Processing Integrity: This criterion applies to organizations that process or manipulate customer data. It dictates that systems must function as per their design, producing accurate, complete, and timely outputs without errors or vulnerabilities.
• Confidentiality: This principle addresses the protection of data that is designated as confidential, ensuring that access is restricted to a specific group of authorized individuals or systems.
• Privacy: This principle governs the collection, storage, use, and disposal of personally identifiable information (PII). It mandates adherence to the organization's own privacy policies and the AICPA's Generally Accepted Privacy Principles (GAPP)

The Business and Technical Rationale for Prioritizing Confidentiality

The Confidentiality principle is a critical component for any organization handling sensitive business information. This can include a wide range of data types, such as application source code, intellectual property, financial information, business plans, and passwords. The core requirements of this principle are not limited to a single security measure; they address the entire lifecycle of confidential data and can be summarized by three core objectives: identify, protect, and dispose.

Including the Confidentiality principle in a SOC 2 audit is both a security measure and a business advantage: it reduces breach risks and protects sensitive data while also signaling to customers—especially large enterprises—that the company takes data protection seriously, helping win trust, contracts, and new market opportunities.

Architecting for SOC 2 Confidentiality with Google Cloud

Achieving SOC 2 compliance in a cloud environment requires a multi-layered security architecture that aligns with the framework's principles. Google Cloud Platform (GCP) offers a suite of native services that can be used to establish a robust security posture, particularly for meeting the Confidentiality principle.

The following table serves as a comprehensive overview, mapping key GCP services to the SOC 2 Trust Services Principles and the specific controls they enable.

Protecting SSN with RSA

Protecting Social Security Numbers (SSNs) is one of the most critical responsibilities for any financial or compliance-driven platform. Breaches or leaks of SSNs can lead to severe regulatory, legal, and reputational consequences. To address this, we’ve designed a two-perimeter architecture that uses RSA encryption combined with Google Cloud security services to safeguard SSN data end-to-end.

How RSA Encryption Works

RSA is an asymmetric cryptographic algorithm that operates with two mathematically linked keys:

• Public Key – Shared openly and used to encrypt data. In our case, this allows SSNs to be encrypted securely at the point of entry.
• Private Key – Kept secret within a secure environment and used to decrypt the data. This ensures only authorized administrators can access the original SSN.

The crucial advantage of RSA lies in its one-way relationship: while the public key can encrypt data, it is practically impossible to derive the private key from it.

Dual-Perimeter Security Model

We separate responsibilities across two perimeters:

1. User-faced perimeter – Protecting external connections, ensuring that SSNs are securely transmitted and encrypted at entry.
2. Administration-faced perimeter – Allowing access to decrypted SSNs only to highly privileged administrators within a private network.

This model enforces defense-in-depth, combining encryption, network isolation, and granular permission controls.

End User Perspective: Secure Entry and Encryption

When a user submits sensitive data such as an SSN, it passes through a protected flow designed to stop threats and immediately encrypt the information.

Key safeguards in this layer:

• TLS/SSL encryption secures all communication.
• Google Cloud Armor (WAF) blocks malicious requests at the edge.
• Application layer immediately encrypts SSNs using the RSA public key, ensuring plaintext SSNs are never stored.
• Audit logs track all access and encryption operations for compliance requirements.

Admin Perspective: Secure Decryption and Access

Decryption of SSNs is strictly limited to administrators who operate within a private network perimeter. This ensures exposure to decrypted SSNs never occurs over the public internet.

Key safeguards in this layer:

• TailScale VPN ensures admins connect only through a private, secured network.
• Granular permissions: only users with the right roles and credentials can request decrypted SSNs.
• Cloud KMS (Key Management Service) stores and manages the private key.
• Strict logging and auditing record every decryption event, providing accountability and compliance readiness.
• No direct internet exposure: the admin panel runs in a private cluster with no connection to the public web.

Defense in Depth

This dual-perimeter architecture ensures that:

1. Users’ SSNs are encrypted on entry – no plaintext SSNs are stored or transmitted.
2. Decryption only happens inside a private network – minimizing risk of exposure.
3. Audit logs are comprehensive – every encryption, decryption, and access event is tracked.
4. Keys are centrally managed with Cloud KMS – removing the risk of leaked credentials.

By combining RSA encryption, private networking, cloud security tools, and strict operational controls, we achieve end-to-end SSN protection that exceeds compliance requirements and ensures user trust.