The 10 Most Common SOC 2 Findings (And How to Fix Them)

After running thousands of scans across hundreds of companies, we've identified the most common issues that cause SOC 2 audit findings. These aren't theoretical — these are real problems we see every week.

Fix these before your auditor finds them.

1. Missing MFA on Critical Systems

How common: Found in 67% of first scans

Multi-factor authentication is the single most impactful security control you can implement, and it's explicitly required by SOC 2 under CC6.1 (Logical Access).

Where we find it missing:

• AWS root account (yikes)
• CI/CD pipelines (GitHub Actions, GitLab)
• Production databases
• Email accounts for admin users
• VPN access

Fix:

# AWS: Enable MFA on root account
# Go to IAM → Security credentials → Assign MFA device

# GitHub: Enforce org-wide 2FA
# Settings → Authentication security → Require 2FA

Pro tip: Enforce MFA at the IdP level (Okta, Google Workspace) rather than per-application. One policy, everything covered.

2. Outdated TLS Configuration

How common: Found in 54% of scans

Running TLS 1.0 or 1.1 is a guaranteed finding. Even TLS 1.2 with weak cipher suites will get flagged.

What we flag:

• TLS 1.0/1.1 still enabled
• Weak cipher suites (RC4, DES, 3DES)
• Missing HSTS headers
• Certificate chain issues
• Expiring certificates (< 30 days)

Fix:

# Nginx: Enforce TLS 1.2+ with strong ciphers
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

3. Open Ports and Unnecessary Services

How common: Found in 48% of scans

Every open port is an attack surface. We routinely find production servers with SSH (22), databases (3306, 5432, 27017), and debug services (8080, 9090) exposed to the internet.

Most commonly found open:

• Port 22 (SSH) — open to 0.0.0.0/0
• Port 3306 (MySQL) — publicly accessible
• Port 5432 (PostgreSQL) — no IP allowlist
• Port 6379 (Redis) — no authentication
• Port 9200 (Elasticsearch) — no auth, public

Fix:

# AWS: Restrict SSH to your office/VPN IP only
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxx \
  --protocol tcp \
  --port 22 \
  --cidr YOUR_OFFICE_IP/32

# Better: Remove SSH entirely, use SSM Session Manager
aws ec2 revoke-security-group-ingress \
  --group-id sg-xxx \
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

4. No Centralized Logging

How common: Found in 41% of scans

SOC 2 requires you to detect and respond to security events (CC7.2, CC7.3). You can't do that without centralized logging.

What auditors want to see:

• Application logs aggregated centrally
• Infrastructure/cloud audit logs (CloudTrail, GCP Audit Logs)
• Authentication logs (success + failure)
• 30+ days retention minimum (90 days recommended)
• Alerts on suspicious activity

Fix: Use any centralized logging platform — Datadog, Splunk, CloudWatch Logs, or even a self-hosted ELK stack. The tool doesn't matter; the coverage and retention do.

5. Stale User Accounts and Access

How common: Found in 39% of scans

When employees leave or change roles, their access should be revoked or adjusted. We frequently find:

• Former employees still in GitHub org
• Shared service accounts with no owner
• Admin privileges on accounts that should be read-only
• No quarterly access review process

Fix:

• Implement automated offboarding (Proveably's HRIS integration handles this) — use our free Employee Offboarding Security Checklist
• Conduct quarterly access reviews using a formal Access Control Policy
• Follow least-privilege principle
• Maintain an access control matrix

6. Missing Security Headers

How common: Found in 37% of scans

Web applications missing basic security headers are easy targets:

• X-Frame-Options or Content-Security-Policy (frame-ancestors)
• X-Content-Type-Options: nosniff
• X-XSS-Protection
• Referrer-Policy
• Permissions-Policy

Fix:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always;

7. Secrets in Code Repositories

How common: Found in 31% of SAST scans

API keys, database passwords, and tokens committed to git are one of the most dangerous findings because they often grant direct access to production.

What we find:

• AWS access keys in .env files committed to git
• Database connection strings with passwords
• API tokens for Stripe, SendGrid, Twilio
• Private keys and certificates

Fix:

• Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler)
• Add .env to .gitignore immediately
• Rotate any exposed credentials
• Set up pre-commit hooks to prevent future leaks

8. No Encryption at Rest

How common: Found in 28% of cloud scans

Data encryption at rest is a baseline SOC 2 requirement. We find unencrypted:

• S3 buckets (default encryption not enabled)
• RDS databases (encryption must be enabled at creation)
• EBS volumes
• Backups and snapshots

Fix:

# Enable default encryption on S3 bucket
aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'

9. No Vulnerability Management Program

How common: Found in 25% of audits

Having vulnerabilities isn't necessarily a finding. Not having a process to find and fix them absolutely is.

Your auditor wants to see:

• Regular automated scanning (not just annual pentests)
• A defined SLA for remediation by severity
• Evidence that critical/high vulns are patched within your SLA
• A risk acceptance process for exceptions

Fix: This is exactly what Proveably automates. Set up weekly scans, define your SLAs, and our platform tracks remediation timelines with full audit trail.

10. Incomplete Incident Response Plan

How common: Found in 22% of audits

Having an incident response policy is one thing. Having a tested, practical plan is another.

What auditors flag:

• Policy exists but has never been tested
• No defined severity classification
• No communication plan (who to notify, when)
• No post-incident review process
• No evidence of tabletop exercises

Fix: Run a tabletop exercise at least annually. Document it. Download our free Incident Response Plan template which includes a built-in exercise checklist, or grab the Security Incident Report Template for documenting incidents.

The Pattern

Notice something? Most of these findings aren't exotic zero-days. They're basic hygiene issues that compound over time. The companies that pass SOC 2 smoothly aren't doing anything magical — they're just consistently monitoring and fixing these fundamentals.

That's why continuous scanning matters more than point-in-time assessments. A quarterly pentest catches these issues 4 times a year. Proveably catches them every day.

Free Templates to Fix These Findings

Get started with our most-downloaded compliance templates:

• SOC 2 Readiness Checklist — Check your readiness against all Trust Service Criteria
• Change Management Policy — Formalise your change control process
• Vulnerability Management Policy — Define your scanning cadence and remediation SLAs
• Encryption Policy — Document your encryption standards for data at rest and in transit
• Vendor Management Policy — Manage third-party risk

Browse all 25+ free compliance templates →

Start scanning for free →