• SOC2
  • Regulations
  • Data protection
  • Google cloud

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

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.

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.

GCP ServiceSOC 2 Trust Principles SupportedTechnical Contribution
Cloud Key Management Service (KMS)Security, Confidentiality, PrivacyManages cryptographic keys, enabling data encryption at rest and key rotation policies.
Cloud Load BalancingSecurity, AvailabilityActs as an SSL endpoint, offloading encryption/decryption. Improves system uptime and performance.
Google Cloud ArmorSecurity, AvailabilityProvides a web application firewall (WAF) and DDoS protection. Guards against web application vulnerabilities and denial-of-service attacks.
Virtual Private Cloud (VPC)Security, Confidentiality, PrivacyCreates isolated and secure network environments. Allows for environment segregation (e.g., dev, staging, prod).
IAM & VPC Service ControlsSecurity, Confidentiality, PrivacyEnforces the principle of least privilege. Defines security perimeters around resources to prevent data exfiltration.
Cloud LoggingSecurity, Confidentiality, Processing Integrity, AvailabilityProvides an immutable audit trail of API calls, resource changes, and user activity. Critical for proving the operational effectiveness of controls.
Sensitive Data Protection (DLP)Confidentiality, PrivacyIdentifies, classifies, and redacts sensitive data elements. Helps in monitoring and controlling access to sensitive data.

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.

mermaid
graph TD
    subgraph "User Interaction"
        A[User]
    end

    subgraph "User permission check"
        B["Google Cloud Armor <br> (WAF)"]
        C[Cloud Load Balancing]

        subgraph "Application Project"
            D["Application <br> (GKE, Cloud Run, etc.)"]
            E["Secure config"]
        end
    end

    subgraph "Security & Operations"
        F["Cloud Logging & Cloud Monitoring <br> (Audit and Access Logs)"]
    end

    A -- "HTTPS/TLS" --> B;
    B --> C;
    C --> D;
    D -- "Public Key for <br> Data Tokenization" --> E;
    D --> F;
    E --> F;

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.

mermaid
graph TD
    subgraph "External Access"
        A["Administrator with SSN Permission"]
    end

    subgraph "Admin Private Network"
        B["TailScale VPN"]
        C["Cloud Load Balancing"]
        D["Administration Login"]

         subgraph "Check SSN-aal permission"
            E["Admin Application (K8S)"]
            F["Cloud KMS <br> (Key for Tokenization)"]
            G["Cloud KMS <br> (De-crypt)"]
         end
    end

    subgraph "Monitoring & Auditing"
        H["Cloud Logging & Cloud Monitoring <br> (Audit and Access Logs)"]
    end

    A -- "HTTPS/TLS" --> B
    B --> C
    C --> D
    D -- "Log to Cloud Logging" --> H
    D --> E
    E --> F
    F -- "Private Key" --> G
    E --> H
    G -- "Log to Cloud Logging" --> H

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.

How You Can Make It Easy To Write Unit-Tests In Golang

When I started to write unit-tests in golang at first it wasn't easy and it was taking much time. I didn't know specific tools, technique and libraries to make easy writing of tests.

Handle million requests per second during rush hours

For end-user, it doesn't matter how powerful your server if user needs to wait for couple seconds the see content on the main page. We are talking about latency of the whole platform in general and you need to keep in mind that a system is only as fast as the slowest component.

The Design Process From Idea to Product

When I started my design career, I didn’t fully understand what a design process was and how to build it. Of course, I read several articles about this topic, but this didn’t give me a complete understanding of the whole picture of the stages being built

Help Ukraine to stop russian aggression