Hey everyone, Alex here. Welcome back to another edition of "Coding with Alex."
If you've spent more than five minutes working in modern SaaS, you’ve probably heard it. You're in a sprint planning meeting, or maybe you're about to merge a slick new pull request that automates a tedious deployment step, when suddenly a product manager or a security officer chimes in: "We can't do that. That’s not SOC 2 compliant."
It’s the ultimate engineering conversation stopper. It's invoked like a mystical spell to shut down developer velocity, justify archaic manual processes, and force us to write convoluted change management tickets. But here is the dirty secret of compliance: 90% of what people tell you is "not SOC 2 compliant" is actually just their company’s specific, highly bureaucratic implementation of it.
SOC 2 is not a technical spec. It doesn't have an RFC number. It won't tell you which port to block or what cipher suites to use. Today, we are going to demystify SOC 2 from a pure developer perspective. We'll look at what it actually demands, how to translate its abstract "Trust Services Criteria" into modern GitOps and infrastructure-as-code, and how you can build highly secure, fully automated pipelines that keep both your auditors and your engineering team happy.
What is SOC 2, Really?
SOC stands for System and Organization Controls. Developed by the American Institute of CPAs (AICPA), a SOC 2 audit evaluates an organization’s information systems based on five "Trust Services Criteria":
- Security: Are your systems protected against unauthorized access? (This is the only mandatory criterion).
- Availability: Are your systems up and running as promised?
- Processing Integrity: Do your systems deliver the right data to the right place at the right time without errors?
- Confidentiality: Is sensitive data restricted to authorized users?
- Privacy: How do you collect and use personal information?
An auditor’s job is not to verify that you follow a industry-standard checklist. Their job is to verify that you do what you say you do. You write the policies, you define the controls, and then you must prove to the auditor that you actually follow them.
If your security policy says, "Every database schema change must be signed in triplicate on physical parchment by the VP of Engineering," then the auditor will ask to see the parchment. If your policy says, "Database schema changes are managed via automated Liquidbase migrations triggered by Git tags, requiring two approved peer reviews on GitHub," the auditor will ask to see your GitHub branch protection settings and merge history. Both are compliant. One of them, however, doesn't make developers want to quit their jobs.
The Developer's Guide to Modern SOC 2 Controls
As engineers, we want automation, reproducibility, and minimal friction. Let’s look at how we can map standard SOC 2 requirements to modern, developer-friendly cloud architectures.
1. Access Control and the Principle of Least Privilege
Auditors want to know how you prevent unauthorized access to production systems and customer data. The old-school way is to give everyone static IAM keys or SSH keys, and then manually revoke them when someone leaves. This is a security nightmare and an auditing disaster.
The modern, compliant approach is Identity Federation and Short-Lived Credentials. Instead of static keys, use an Identity Provider (IdP) like Okta or Google Workspace integrated with AWS IAM Identity Center or HashiCorp Vault. Developers assume temporary roles that expire automatically.
Here is an example of using HashiCorp Terraform to define a secure, auditable IAM role with strict trust relationships that developers can temporarily assume:
resource "aws_iam_role" "developer_read_only" {
name = "DeveloperReadOnlyRole"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRoleWithSAML"
Effect = "Allow"
Principal = {
Federated = "arn:aws:iam::123456789012:saml-provider/Okta"
}
Condition = {
StringEquals = {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
})
}
resource "aws_iam_role_policy_attachment" "read_only_attach" {
role = aws_iam_role.developer_read_only.name
policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}By declaring your IAM configurations in code, you provide your auditor with an immutable, easily inspectable blueprint of your access controls. When they ask, "Who has access to production?" you show them the Terraform repository and your IdP groups.
2. Change Management: Killing the Change Advisory Board (CAB)
The classic "that's not SOC 2 compliant" argument usually surfaces during code deployment. Traditional IT departments love "Change Advisory Boards" (CABs)—weekly meetings where people who don't write code approve things they don't understand.
You do not need a CAB for SOC 2. What you do need is traceability and segregation of duties. Specifically, the person who writes the code cannot be the sole person who deploys it to production without peer review.
We can solve this purely through GitHub/GitLab repository settings and CI/CD pipelines. Here is an architectural flow of a compliant, fully automated GitOps delivery pipeline:
[Developer] -> Commits Code -> Opens PR
|
v
[GitHub] -> Enforces Branch Protection (Requires 1 Apporved Review & Passing CI)
|
v
[CI Pipeline] -> Runs Linter, Unit Tests, SAST Security Scans
|
v
[Merge to Main] -> Triggers CD Pipeline (GitHub Actions / ArgoCD)
|
v
[CD Pipeline] -> Deploys to Production & Generates Cryptographic Build Provenance
To implement the "segregation of duties" control programmatically in GitHub, you can define a .github/workflows/branch-protection.yml or enforce it via Terraform:
resource "github_branch_protection" "main" {
repository_id = github_repository.web_app.node_id
pattern = "main"
required_pull_request_reviews {
dismiss_stale_reviews = true
required_approving_review_count = 1
require_code_owner_reviews = true
}
required_status_checks {
strict = true
contexts = ["ci/security-scan", "ci/unit-tests"]
}
}This configuration ensures that no developer can push code directly to production. Every change requires an independent review and must pass automated security checks. When the auditor asks for evidence of change control, you don't show them Jira tickets; you show them your repository settings and the commit history of merged pull requests.
Audit Logging and Observability
If a tree falls in the forest and no one is around to hear it, does it make a sound? More importantly, if an attacker accesses your production S3 bucket and you don't have log files to prove it, did it even happen? To an auditor, if it isn't logged, it didn't happen—or worse, the worst-case scenario did.
For SOC 2, you need comprehensive logging of administrative actions, authentication attempts, and system modifications. However, simply writing logs to a local disk is not enough. Logs must be:
- Centralized: Shipped to a dedicated log aggregation system (e.g., Datadog, AWS CloudWatch, or Grafana Loki).
- Tamper-proof: Stored in write-once-read-many (WORM) storage where developers (even admins) cannot delete or alter them.
- Monitored: Configured with alerts for anomalous behavior (like unauthorized access attempts).
Here is an example of an AWS S3 bucket configuration using Terraform designed specifically for secure, audit-ready log storage. It enables versioning, server-side encryption, and Object Lock to prevent deletion:
resource "aws_s3_bucket" "audit_logs" {
bucket = "company-audit-logs-prod"
lifecycle {
prevent_destroy = true
}
}
resource "aws_s3_bucket_versioning" "audit_logs_versioning" {
bucket = aws_s3_bucket.audit_logs.id
versioning_configuration {
status = "Enabled"
}
}
resource "aws_s3_bucket_object_lock_configuration" "audit_logs_lock" {
bucket = aws_s3_bucket.audit_logs.id
rule {
default_retention {
mode = "COMPLIANCE"
days = 365
}
}
}By enforcing COMPLIANCE mode with Object Lock, not even the AWS root account can delete these logs before the retention period expires. This is gold dust for an auditor.
Automating Evidence Collection
The worst part of any audit is "evidence gathering season." This is the week where developers stop coding and spend hours taking screenshots of their AWS console, Okta directory, and GitHub settings to prove everything is configured correctly.
Do not do this. Use automated compliance platforms (like Vanta, Drata, or Secureframe) or open-source tools like Prowler or Cloud Custodian.
These tools connect to your cloud providers via API and continuously check your environment against security benchmarks (CIS, SOC 2, ISO 27001). They generate the compliance reports automatically, saving hundreds of hours of manual labor.
You can run security scans right in your local terminal or cron jobs using Prowler to see where you stand:
# Install prowler via pip
pip install prowler
# Run a security assessment against your AWS account specifically for SOC 2
prowler aws --compliance soc2Conclusion
SOC 2 compliance does not have to be an engineering tax. When done right, it is simply a formalization of excellent engineering hygiene. By shifting security left, using infrastructure-as-code, automating our CI/CD guards, and enabling strict, immutable log policies, we satisfy our security auditors while keeping our deployment velocity blazing fast.
The next time someone tells you, "That's not SOC 2 compliant," don't just accept it. Ask them to show you the specific control policy. Chances are, you can design a elegant, automated, and developer-friendly solution that fulfills the control without slowing down the team.
What do you think?
How has your team tackled SOC 2? Have you successfully automated your evidence collection, or are you still trapped in "spreadsheet hell"? Let me know in the comments below or reach out on Twitter/X!