How to Prepare for a SOC 2 Type II Audit in 90 Days: A DevSecOps Checklist

If you have 90 days before your SOC 2 Type II audit window closes, the fastest path to success is to treat SOC 2 Type II prep as an engineering project, not a paperwork exercise. Type II audits assess whether your controls operated effectively over a period of time, typically three to twelve months. That means the auditor wants evidence that your controls ran continuously, not a snapshot proving they exist today. Your job in the next 90 days is to instrument your systems so evidence collects itself, close the gaps that would produce exceptions, and build a defensible narrative for each Trust Services Criterion.

This checklist is written for engineering teams. I will focus on what to automate, what to document, and what to fix, in the order that produces the least last-minute scramble.

Understand What Type II Actually Tests

Type I answers "are the controls designed correctly at a point in time?" Type II answers "did those controls work, consistently, across the observation period?" That distinction changes your strategy.

For Type II, an auditor samples evidence from across the window. If you enabled MFA on day 60 of a 90-day period, you have 30 days of coverage, and the auditor will note a deficiency for the earlier gap. The lesson: controls need to be live before your observation period starts, and they need to stay live.

The audit is scoped against the AICPA Trust Services Criteria (Security, plus optionally Availability, Confidentiality, Processing Integrity, and Privacy). Security, sometimes called the Common Criteria, is mandatory. See the AICPA Trust Services Criteria for the authoritative control set.

Days 1-15: Scope, Baseline, and Assign Ownership

Before writing a single policy, decide the boundary of your system.

1. Define the system boundary. List the production services, data stores, cloud accounts, and third parties that touch customer data. Anything in scope needs controls and evidence; anything out of scope needs a defensible reason.
2. Pick your Trust Services Criteria. Start with Security. Add Availability if you offer an uptime SLA, Confidentiality if you handle sensitive customer data under contract.
3. Assign control owners. Each control needs a named human. "The team" is not an owner.
4. Run a gap assessment. Map your current state against each criterion. Mark each control as implemented, partial, or missing.

A simple tracking table keeps this honest:

| Control ID | Criterion | Owner    | State     | Evidence Source        |
|------------|-----------|----------|-----------|------------------------|
| CC6.1      | Security  | a.patel  | partial   | IAM policy, MFA report |
| CC7.2      | Security  | j.okoro  | missing   | SIEM alert config      |
| A1.2       | Avail.    | m.lin    | implement | Backup job logs        |

Days 16-45: Close Technical Gaps in the DevSecOps Pipeline

This is where DevSecOps SOC 2 work pays off. Most Common Criteria controls map directly to practices you should already want in a mature pipeline.

Access Control (CC6.x)

• Enforce MFA on all human access to production and cloud consoles.
• Move to role-based access with least privilege. Remove standing admin rights; use just-in-time elevation where possible.
• Implement a quarterly access review. Export the access list, have owners attest, and keep the signed record.
• Automate deprovisioning. Offboarding should trigger revocation across identity providers, cloud, and code repositories within a defined SLA.

Change Management (CC8.1)

Auditors love change management because it is easy to sample. Make every production change traceable to an approved, reviewed pull request.

# Example branch protection (GitHub) — enforce review + status checks
required_pull_request_reviews:
  required_approving_review_count: 1
  dismiss_stale_reviews: true
required_status_checks:
  strict: true
  contexts:
    - "ci/build"
    - "security/sast"
enforce_admins: true

Require at least one reviewer, passing CI, and passing security scans before merge. That single policy generates continuous change-management evidence.

Vulnerability Management (CC7.1)

• Add SAST and dependency scanning to CI. Fail builds on high-severity findings.
• Run container image scanning before deploy.
• Define remediation SLAs by severity and track them. Auditors will ask how fast you fix criticals.

# Example: gate a pipeline on dependency vulnerabilities
trivy fs --severity HIGH,CRITICAL --exit-code 1 .

Logging and Monitoring (CC7.2, CC7.3)

• Centralize logs from applications, infrastructure, and cloud control planes.
• Enable tamper-resistant log storage with defined retention.
• Configure alerting for anomalous access, privilege escalation, and failed logins.
• Document your incident response runbook and, critically, run at least one tabletop exercise inside the observation window so you have evidence the process works.

Encryption (CC6.7)

• Encrypt data in transit (TLS 1.2+) and at rest (managed KMS keys).
• Document key rotation. Managed cloud KMS makes this a configuration line rather than a project.

We help teams wire these controls into existing pipelines through our cybersecurity and compliance capabilities, so evidence generation becomes a byproduct of normal delivery rather than a separate chore.

Days 46-70: Policies, Vendors, and People Controls

Technical controls satisfy roughly half the criteria. The rest are organizational.

Write the Policies Auditors Expect

At minimum, prepare and formally approve:

• Information Security Policy
• Access Control Policy
• Change Management Policy
• Incident Response Plan
• Business Continuity and Disaster Recovery Plan
• Vendor Management Policy
• Data Classification and Retention Policy
• Secure Development Policy

Policies must be dated, versioned, and acknowledged by staff. Track acknowledgment in your HR system or a policy platform so you can produce the report on demand.

Vendor Risk Management (CC9.2)

Build a subprocessor register. For each vendor that touches customer data, collect their SOC 2 report or equivalent attestation, record the data they process, and assign a risk rating. This is often where regulated industries with heavy third-party footprints stumble. If yours is one of them, our industry-specific compliance experience can shortcut the vendor review workload.

People Controls

• Background checks for new hires, where legally permitted.
• Security awareness training completed and logged during the observation window.
• Documented onboarding and offboarding checklists.

Days 71-90: Dry Run, Evidence Assembly, and Readiness

The final stretch is about proving the machine runs.

1. Automate evidence collection. Wherever possible, pull evidence from source systems on a schedule rather than screenshotting by hand. A compliance automation platform or a lightweight cron-driven export both work.
2. Run a readiness assessment. Walk each control as if you were the auditor. For every control, ask: Can I produce evidence covering the entire period? If not, it is a finding you can still address.
3. Reconcile your population lists. Auditors sample from populations: all production changes, all new hires, all access grants. Make sure your lists are complete and match your evidence.
4. Prepare the description of the system. This narrative document describes your services, boundaries, and controls. It is required for the final report.
5. Pick and brief your auditor. SOC 2 reports must be issued by a licensed CPA firm. Engage them early so scope and timing align.

Use this as your final SOC 2 readiness checklist gate before the window closes:

• MFA enforced across all production and admin access
• Access reviews completed with signed attestations
• Branch protection and PR review enforced in every production repo
• SAST, dependency, and container scanning gating deploys
• Centralized, retained, tamper-resistant logs with alerting
• Encryption at rest and in transit documented
• Incident response runbook plus one completed tabletop exercise
• All required policies approved, versioned, and acknowledged
• Vendor register with attestations collected
• Security training completed and logged
• Evidence covering the full observation period, per control

A Realistic Word on Timelines

Ninety days is enough to prepare and to start a short observation window, but the observation period itself still has to elapse. If your auditor requires a minimum three-month window, plan for the audit fieldwork to begin after that window closes. The 90 days is your runway to make sure that when the window opens, every control is already operating. Starting controls late is the single most common cause of exceptions in first-year Type II reports.

Treat this as engineering work with clear owners, automated evidence, and honest gap tracking, and SOC 2 Type II prep becomes a predictable project rather than a fire drill.

FAQ

How long does a SOC 2 Type II observation period need to be?

Type II reports cover a defined observation period, commonly three to twelve months. First-year audits often use a shorter window, frequently three or six months, then extend to twelve in subsequent years. Your controls must be operating for the entire window, so start them before the period begins.

Can we really get audit-ready in 90 days?

You can complete readiness work, close gaps, and open a short observation window in 90 days. What you cannot compress is the observation period itself. The controls still have to run over time for the auditor to sample. Ninety days of focused DevSecOps and policy work is a realistic runway to be ready when the window opens.

What is the difference between SOC 2 Type I and Type II?

Type I evaluates whether controls are designed appropriately at a single point in time. Type II evaluates whether those controls operated effectively across a period. Type II requires evidence of continuous operation, which is why automated evidence collection matters so much.

Do we need a compliance automation tool?

You do not strictly need one, but it reduces manual evidence gathering significantly, especially for access reviews, change tracking, and continuous monitoring. Teams with strong existing pipelines can often generate most evidence from their own tooling and pull the rest on a schedule.

Who is allowed to issue a SOC 2 report?

Only a licensed CPA firm can issue a SOC 2 attestation report. Engineering partners can prepare you, implement controls, and run readiness assessments, but the final report comes from an accredited auditor. Engage that firm early to align on scope and timing.