The 30/60/90-Day SOC 2 Plan for Lean Security Teams

Most SOC 2 timelines slip not because the controls are hard to implement but because teams try to solve everything at once — policy, tooling, evidence collection, and vendor reviews all in parallel, with no clear ownership or sequence. The result: three months of activity with an audit that still cannot start on schedule.

This 30/60/90-day plan is built specifically for lean security teams — typically two to four people carrying security alongside engineering and operations responsibilities. The three phases are sequenced so that each phase builds on the last: visibility before controls, controls before evidence, evidence before audit. Skipping phases is how you create audit blockers that surface during fieldwork.

Before starting this plan, complete the SOC 2 readiness checklist so you enter the 90 days knowing your current gap count and highest-risk control areas.

Days 1–30: Scope, visibility, and ownership

The first 30 days are not about implementing controls. They are about establishing exactly what you are securing, who is responsible for each piece of it, and what a complete vulnerability picture looks like. Teams that skip this phase spend months chasing evidence for systems they did not realize were in scope.

Week 1–2: Define your scope and asset inventory

• Map your cardholder or customer data flows to determine which systems, services, and third-party integrations are in scope for SOC 2.
• Build a system inventory spreadsheet (or tool-based inventory) covering production servers, databases, cloud resources, internal tools with admin access, and SaaS systems storing customer data.
• Confirm your Trust Services Criteria scope. Most SaaS SOC 2 audits cover Security (CC1–CC9) as a minimum. Privacy, Availability, Confidentiality, and Processing Integrity add substantially more control surface. Decide before month two.
• Run your first vulnerability scan against all in-scope assets and establish a baseline. If you use Tenable or a similar scanner, this is where ingestion into your remediation workflow should be configured.

Week 3–4: Assign control owners and set SLAs

• Assign a named owner to every control. Not a team — a person. Shared ownership means no ownership during evidence requests.
• Set vulnerability remediation SLAs and communicate them: Critical findings remediated within 7 days, High within 30, Medium within 90. Document these SLAs formally — auditors will ask for them.
• Prioritize your open vulnerability backlog. Pull your first scan results, apply severity-based triage, and assign the top 10–15 critical/high findings to owners with due dates.
• Identify your evidence gaps. For each SOC 2 control area, determine whether you have evidence that would satisfy an auditor sample request, partial evidence that needs strengthening, or no evidence at all.

Exit criterion for Day 30: Every in-scope asset is inventoried. Every critical/high vulnerability has a named owner and due date. Evidence gaps are documented. You know exactly where you stand.

Common trap: Importing 800 scan findings and not triaging them. A backlog without prioritization is noise, not a program. Force yourself to a "Top 10 this week" list you can actually clear.

Days 31–60: Controls in operation and evidence flowing

The second 30 days shift from planning to execution. Controls must operate — not be documented as planned. Auditors evaluate whether controls are consistent over time, which means the clock on evidence collection started when you started running the controls, not when you wrote the policy.

Week 5–6: Core controls running

• Recurring vulnerability scans scheduled and running on a fixed cadence (minimum weekly for internal, weekly for external perimeter). Ad hoc scans do not satisfy SOC 2 — the cadence must be demonstrated.
• Access reviews initiated. Pull a current user access list from every system in scope and conduct a quarterly review. Document who reviewed, when, what was changed, and who approved changes.
• Change management in place. Production changes must go through an approval workflow — even a simple Jira or GitHub review-and-merge process satisfies this if it is consistently applied. Record the approvals.
• Logging enabled and retained. Authentication events, privilege escalations, and system changes must be logged centrally with at least 90 days retention. Verify your log pipeline is actually capturing in-scope system events.

Week 7–8: Evidence flowing automatically

• Build your control-to-evidence mapping. For each SOC 2 criterion, know what artifact satisfies it and where that artifact is collected. This becomes your auditor navigation guide.
• Require verification before vulnerability closure. Findings should not be marked resolved on a verbal basis. Configure your workflow to require a rescan confirmation or an explicit verification record before SLA timers reset.
• Generate your first remediation report. Run a report covering open findings, closed findings, SLA performance, and exception log. This document should be something you could hand to an auditor today. If it is not, identify the gaps.
• Complete policy set approved. Information security policy, access control policy, incident response plan, and vulnerability management policy should be approved by leadership and distributed to the team.

Exit criterion for Day 60: Controls are operating consistently — not just documented. Evidence is being collected in real time. Your remediation report shows measurable progress on the backlog established in month one.

Common trap: Writing policies but not enforcing them. An access review policy dated this week with no review records is an audit flag. Auditors look for consistency, not perfection.

Days 61–90: Mock audit, gap closure, and audit selection

The final 30 days are for stress-testing your evidence, closing remaining gaps, and confirming your audit firm. Teams that wait until day 90 to assess readiness almost always discover blockers they cannot resolve before the audit starts.

Week 9–10: Mock audit sample

• Conduct an internal evidence review for your highest-risk controls — typically vulnerability management (CC7), access control (CC6), and change management (CC8). Attempt to satisfy a sample evidence request for each.
• Time your evidence retrieval. If locating and presenting evidence for a single control takes more than 15 minutes, your evidence organization is not audit-ready.
• Test your exception log. Every open exception should have a named approver, documented business justification, compensating control, and expiration date. Exceptions without expiration are audit findings.
• Review your vendor list. Identify any subprocessors who touch customer data and verify you have current SOC 2 reports or completed security questionnaires for them.

Week 11–12: Finalize and select audit firm

• Close your highest-severity remaining gaps identified in the mock audit.
• Prepare your leadership summary: risk trend (improving / stable / deteriorating), SLA performance percentage, and remaining open critical/high findings with closure timelines.
• Select and engage your audit firm. CPA firms performing SOC 2 audits typically need 4–8 weeks for fieldwork plus report writing. Engage your auditor before day 90 so fieldwork can begin at the planned time.
• Confirm evidence collection cadence post-audit. SOC 2 is an annual certification. Build into your operating calendar: quarterly access reviews, weekly scan schedules, and monthly remediation reports. The compliance system should run year-round, not just before the audit.

Exit criterion for Day 90: You can retrieve auditor-requested evidence samples within 15 minutes. All critical/high vulnerabilities are closed or formally excepted. Leadership has a current risk summary. Audit firm is engaged.