The SaaS Security Checklist for SOC 2-Bound Startups

SOC 2 is the first compliance hurdle every B2B SaaS startup hits when its customers start asking "are you SOC 2 compliant" in procurement reviews. This post is the practical engineering side of getting there. Not the auditor side, the policy side, or the marketing side. The controls you actually implement.

The control surface at a glance

Six categories. Most startups have pieces of each. The audit asks for evidence that all six are working together, not just installed.

Access management

The most common finding area. Build these in early.

• SSO for every employee-facing system. Google Workspace or Okta or Azure AD. No shared accounts ever.
• RBAC inside your product. Even if you have 5 customers, model the permissions. Auditors will ask.
• Named accounts everywhere. No "deploy bot" with a human's credentials. No "ops" shared login.
• Quarterly access reviews. Calendar event. List of every account. Owner signs off. Save the artifact.
• Offboarding checklist. When someone leaves, every account gets deactivated within 24 hours. Document it.
• MFA mandatory. SSO enforces MFA. No exceptions.

Change management

Your codebase is one of the most controlled assets in the audit.

• Direct pushes to main are disabled. Branch protection in GitHub. Always.
• PR review required. Configured at the branch protection level. Auditor checks the GitHub settings.
• Signed commits or signed deploys. Easier in 2026 with GitHub's signed commit verification.
• Production deploys are traceable. Every deploy has a commit hash, a deployer, and a timestamp. Captured in your CI logs.
• Database migrations are reviewed. Same PR-review discipline. No "I just ran a quick UPDATE" in production.

Vulnerability management

Auditors want evidence you find and fix issues on a defined cadence.

• Dependency scanning in CI. Snyk, Trivy, Dependabot. Runs on every PR.
• SAST in CI. Semgrep, SonarQube, GitHub CodeQL. Catches code-level issues.
• Patching SLA. Critical: 7 days. High: 30 days. Medium: 90 days. Document the policy.
• Container image scanning. If you ship Docker, scan the images.
• Penetration test annually. External pen test once a year. Cheaper than the customer who asks for the report and walks when you don't have one.

Logging and monitoring

The auditor's favourite category because evidence is concrete.

• Application logs centralised. Datadog, Honeycomb, Logtail, CloudWatch. Whatever you pick, all logs flow to one place.
• Retention period documented. 90 days, 180 days, a year. Pick one. Have a policy.
• Authentication events logged. Every sign-in, every failed sign-in, every MFA failure, every password reset.
• Privileged actions logged. Admin actions inside your app are logged with the actor, the action, and the target.
• Alerts on anomalies. Failed sign-in spikes, privilege escalations, geographic anomalies.
• Logs reviewed periodically. Weekly or monthly review of security-relevant logs. Document it.

Incident response

The category most teams underinvest in before it bites them.

• Documented runbook for the top 5 incident types: security incident, data exposure, prolonged outage, ransomware, vendor breach.
• On-call rotation. Even if it's a 2-person team, document who's on-call.
• Comms templates. Customer notification, internal notification, status page update. Drafted in advance.
• Quarterly tabletop exercise. Walk through an incident together. 30 minutes. Document outcomes.
• Post-mortem culture. Every incident gets a post-mortem. Blameless. Public if customers were affected.

Vendor management

Subprocessors are your security perimeter.

• Subprocessor list. Maintained on a page. Updated when you add or remove vendors.
• Customer notification before adding subprocessors. Standard SOC 2 expectation.
• DPAs signed with every subprocessor that processes customer data.
• Annual vendor review. Are these vendors still in good standing? Any new security incidents?

What to do this week, next week, next month

This week

• Turn on branch protection. Require PR review. Disable direct pushes.
• Add dependency scanning to CI if not there.
• Document who has admin access to every production system. Calendar a quarterly review.

Next week

• Centralise logs. Pick one tool. Migrate everything.
• Set up SSO if you don't have it.
• Document your patching SLA.

Next month

• Write the incident response runbook.
• Schedule a tabletop exercise.
• Publish the subprocessor list.
• Get your first dependency scan SLA report. Fix what's overdue.

Common mistakes

• Implementing controls but not generating evidence. Auditors need artifacts. Calendar events, signed approvals, runbook PDFs, CI logs.
• Skipping the policy work. Technical controls only get you part way. Auditors want written policies too.
• Over-engineering early. Type I doesn't need a security team of 10. It needs a few well-implemented controls and clean documentation.
• Treating SOC 2 as a one-time event. It's an annual cycle. Build the cadences in from the start.

How Hashorn helps SaaS teams with SOC 2 readiness

Hashorn provides security engineering and DevOps and CI/CD services for SaaS teams approaching SOC 2. We implement the engineering controls, set up the evidence pipeline, and run the quarterly cadences that the audit requires. For teams building from scratch, we layer this into a SaaS product development engagement from day one so the controls are baked in, not bolted on.

Conclusion

SOC 2 readiness in 2026 isn't a security project. It's an engineering discipline. The teams that pass cleanly are the ones that put six categories of control on the wall, implement them properly, and generate evidence as they operate. Start with branch protection and access reviews. Layer on the rest. You'll get there in a quarter.