SOC 2 Readiness Checklist: 12 Things to Fix Before the Audit

Three decisions shape everything else:

1. Which systems are in scope. Usually the production application, its cloud accounts, the code repositories, and the tools used to support it. Keep the scope as small as honest.
2. Which Trust Services Criteria apply. Security is the base. Availability, confidentiality, processing integrity and privacy are added only when customers ask for them.
3. Who owns the program. Name one person, even if they do it part time.

Ask two or three customers or prospects what they need: a report, which type and by when. That answer decides whether you're aiming for a point-in-time report or one covering a period of operation. A description of your system and its boundaries, written now, will be reused in the final report.

Access and change management produce the most evidence, so tighten them early:

• Single sign-on and multi-factor authentication on email, cloud, code hosting and anything holding customer data.
• Access reviews. A scheduled check, with a record, that each person's access still matches their role.
• Offboarding. Access removed on the last day, with a timestamped ticket to prove it.
• Code review. Production changes go through a pull request with a second reviewer and pass automated checks. Restrict direct pushes to the main branch.
• Separation of environments. Development, staging and production are separate, and real customer data stays out of development.

An auditor samples these over time, so consistent habits beat a burst of cleanup right before the audit.

Write a policy that sets fix deadlines by severity and a place where findings are tracked. If you need a reference point, CISA's federal directives required agencies to patch critical vulnerabilities on internet-facing systems within 15 days and high-severity ones within 30¹. Your own deadlines can differ, but write them down and meet them.

Then prepare for incidents:

1. Define what counts as a security incident and who declares one.
2. Write a short response plan with roles, contact lists and a customer notification step.
3. Run one tabletop exercise, and keep the notes as evidence.

Also confirm backups exist and that you have restored one. Auditors like to see the restore, not only the schedule.

You'll need a set of written policies that reflect real practice. Don't paste a generic set and hope. If a policy says you review access quarterly, someone must do it. Keep each one short and true, and delete any rule you can't commit to.

Beyond policies:

• Vendor management. A list of vendors that touch customer data, with a review of each one's security posture at onboarding and each year.
• Risk assessment. A documented, annual review of what could go wrong and what you're doing about it.
• Security training. New hires complete training soon after they join, and everyone repeats it on a schedule you set.
• Background checks where the law and your policy allow.

Evidence should come from systems, not memory: exported access lists, pull request histories, training completions and ticket records. A compliance automation platform such as Vanta, Drata or Secureframe can help you gather evidence and track tasks instead of relying on screenshots. Confirm in a demo which of your systems each one connects to. It doesn't replace the decisions above, so pick one after you know your scope.

When you select an auditor, ask about their experience with companies your size and stack, how they handle a first-time audit, what evidence format they accept and what the timeline looks like. Get two quotes; compare scope carefully before comparing price, and read what SOC 2 audits cost and how ISO 27001 compares before you commit, and see Vanta vs Drata vs Secureframe if you're weighing platforms.