The Big Three: Security, Availability, and Confidentiality

The Pillars of Compliance

In SOC 2, compliance is an architectural standard, not just paperwork. We focus on the 'Big Three' Trust Services Criteria (TSC) that impact engineering most: Security, Availability, and Confidentiality.

Welcome. For developers, SOC 2 isn't about legal jargon—it's about how you build and run systems. While there are five categories, engineering teams primarily live within the 'Big Three': Security, Availability, and Confidentiality. Security is our foundation, while Availability and Confidentiality ensure our systems are resilient and our data is protected.

SOC 2 translates to operational standards for engineers.
The Big Three are the most relevant criteria for DevOps and Developers.
Security is the mandatory foundation for all audits.

Security: The Common Criteria

Security is the mandatory foundation for every SOC 2 audit. It focuses on protecting systems against unauthorized access through technical controls in your CI/CD pipeline and workflows.

Security is often called the 'Common Criteria' because it's required for everyone. Think of your CI/CD pipeline as the gatekeeper. When an auditor asks how you ensure only authorized code reaches production, they are looking for your Pull Request approval workflows and Multi-Factor Authentication logs.

Mandatory for all SOC 2 audits.
Focuses on access control and change management.
Evidence includes PR approvals and MFA logs.

Availability: Resilience in Action

Availability ensures systems are operational and accessible as committed in your SLAs. It requires proof of resilience and recovery strategies.

Real-World Example: During a major cloud region outage (e.g., AWS US-East-1), a compliant SaaS provider's automated DNS failover routes traffic to US-West-2. The auditor doesn't just ask if you stayed online; they inspect the automated failover logs and the post-mortem incident report to verify your 99.9% SLA commitment was met.

Availability is more than just avoiding a 500 error. It's about how your architecture handles stress. When traffic spikes, do your auto-scaling groups kick in? For example, during a major AWS region outage, a compliant system's automated DNS failover routes traffic to a backup region. SOC 2 auditors look for capacity monitoring and failover logs to prove you are managing resources proactively.

Goes beyond simple uptime metrics.
Involves load balancing, auto-scaling, and DR testing.
Capacity monitoring (e.g., 80% CPU alerts) is a key control.

Confidentiality: Protecting the Crown Jewels

Confidentiality focuses on protecting proprietary data—like trade secrets or IP—from unauthorized disclosure through encryption and strict access controls.

Confidentiality is about keeping secrets. While Privacy focuses on personal data, Confidentiality is broader, covering your company's proprietary IP. You satisfy this by implementing encryption at rest and in transit. It also means using Role-Based Access Control to ensure a microservice only accesses the specific data it needs to function.

Protects business-sensitive data (IP, trade secrets).
Requires encryption at rest and in transit.
Enforces the Principle of Least Privilege (RBAC).

Scenario: The Quick Fix Trap

An emergency performance patch is needed. Do you bypass the PR approval to restore service faster? Choose your path carefully.

A critical service is lagging. You have a patch ready. Do you bypass the mandatory PR approval to fix the lag immediately, or wait for a peer review? Choose an option. You restored Availability, but you've triggered a major Security control failure. In an audit, bypassing authorized change management is a red flag, regardless of the intent. Excellent choice. By following the PR process, you maintained the mandatory Security foundation while addressing Availability within compliant boundaries.

Prioritizing Availability can sometimes violate Security.
SOC 2 requires consistent adherence to controls.
Emergency changes must still follow authorized paths.

Design Checklist & Common Pitfalls

Avoid common compliance traps by using this developer checklist for every new feature or infrastructure change.

To stay compliant, use this checklist during design. Ask: Does this change require a peer review? Does the service have a health check? Can I restrict database access further? Beware of the biggest pitfall: giving all developers 'Admin' access to production. It's a major violation of both Security and Confidentiality.

Security: Peer reviews and secret management.
Availability: Health checks and failover strategies.
Confidentiality: Least privilege and data restriction.

Final Diagnosis: The Auditor's Eye

A developer hardcodes a DB password into a microservice's environment variables to fix a connection timeout. Diagnose the compliance failure in 2-3 sentences.

Look at the scenario on the left. Why would a SOC 2 auditor flag this? Type your diagnosis, focusing on which of the Big Three was violated and why.

Identify the broken criteria.
Explain the risk of hardcoded secrets.
Suggest a compliant alternative.