Introducing the Asteros SOC 2 Readiness Toolkit ★ Asteros

Today we’re releasing the Asteros SOC 2 Readiness Toolkit: a plain-English guide to all 33 Security criteria, a working readiness workbook, and a set of vendor due diligence questions you can actually send to vendors.

It’s free to use and share at asteros.com/soc2. No email capture or signup form. Just download it.

I recently came across a SOC 2 readiness toolkit being sold for $100. It was the sort of thing that made me think, someone should just make a good one and give it away.

So here we are.

Most of the engineering teams we work with are going through their first or second SOC 2. The criteria are public and reasonably straightforward to find. What tends to be harder is turning them into something useful for the people actually running the company: what needs to be in place, what evidence to keep, and where the gaps are likely to show up when the auditor starts asking questions.

What does this criterion actually look like inside a SaaS startup? What evidence will an auditor want to see? Which things need to exist now, rather than being written the night before the audit? What should you ask a vendor that doesn’t have its own SOC 2 report?

The toolkit is meant to make those questions easier to answer.

What’s in the toolkit

There are two parts: a readiness guide and a workbook.

The Readiness Guide

The guide walks through every Security criterion from CC1.1 through CC9.2.

For each criterion, it explains what it looks like in practice and the kinds of evidence a company typically collects.

It also includes 35 vendor due diligence questions, with notes explaining what a useful answer looks like.

The goal isn’t to turn the Trust Services Criteria into another giant compliance checklist. It’s to give the person actually doing the work a plain-English translation of what they’re looking at.

The Readiness Workbook

The workbook turns that guidance into something you can work from.

It includes:

Readiness Checklist: All 33 criteria with status, owner, evidence links, and target dates.
Risk Register: A Likelihood × Impact register that calculates risk scores and ratings.
SOC 2 Report Review: A place to record a vendor’s report type, audit period, opinion, CPA firm, and exceptions.
Vendor DDQ: The 35 questions, ready to send, with space to record responses and decisions.
Dashboard: Live progress by criteria category, open high and critical risks, and pending vendor reviews.

It’s available in Excel, Google Sheets, and Notion, so you can use whichever format fits the way your team already works.

One important distinction

We were careful about one thing throughout the toolkit:

The Trust Services Criteria are criteria, not a list of mandatory controls.

You’ll see common security practices mentioned throughout the guide, including things like MFA, encryption, TLS, access reviews, and penetration testing.

Where we mention them, we identify them as common ways companies address a criterion rather than pretending the SOC 2 criteria themselves require a particular technology, configuration, or vendor.

SOC 2 readiness isn’t about collecting a pile of security products because somebody on the internet said auditors require them. It’s about understanding the criteria, implementing appropriate controls for your environment, and being able to produce evidence that those controls actually exist and operate.

Evidence matters more than the policy document

A policy sitting in a folder is not particularly interesting to an auditor. Unfortunately, auditors are not moved by good intentions.

What matters is evidence that the thing described by the policy actually happened.

For a Type 1 examination, the auditor is evaluating whether controls are suitably designed and implemented at a point in time. For a Type 2 examination, the question extends to whether those controls operated effectively over the examination period.

That means evidence such as:

Dated access reviews
Termination records
Change approvals
Ticket history
Security training acknowledgments
Incident response exercises
Vendor assessments
Configuration or system exports

This is where first-time SOC 2 are often lacking.

We’ve seen organizations where:

Access reviews happened, but nobody recorded them.
Former employees still had accounts.
Production changes happened without an approval trail.
An incident response plan existed, but nobody had ever walked through it.
Vendors were being used without any documented assessment.

None of these means an automatic audit failure. But each one can turn something that looked fine on paper into a last-minute scramble once the auditor asks for evidence.

Finding those gaps months before fieldwork is considerably easier than discovering them during the audit. That’s what the workbook is designed to help with.

Where the pentest fits

A penetration test is not a universal SOC 2 requirement.

It’s one way organizations can address security testing and vulnerability management, including the activities associated with CC7.1. What your auditor ultimately expects depends on your controls, scope, and examination.

For the audit, the question about a pentest may be fairly straightforward: Was testing performed, and can you provide evidence of it?

But your auditor may not be the next person who reads the report.

An enterprise customer’s security or procurement team might ask:

What exactly was tested?
If something was left untested, why?
What methodology was used?
Was testing conducted against a standard?
Was testing manual or automated?
How were findings rated?
Were the findings remediated according to your SLAs?
Can you show evidence that the fixes were validated?

That’s where the difference between a vulnerability scan packaged as a pentest and a real penetration test starts to matter. A scan with a cover page is a home inspection performed from the driveway. Sure, somebody looked at the house. But how useful are those results going to be?

And even if your app turns out to be exceptionally secure, the report still shows the work that was performed. “We found nothing” and “we looked at nothing” can produce remarkably similar PDFs. A clean result shouldn’t leave you wondering which one you paid for.

Any report might be enough to clear the audit checkbox, but completely inadequate for your enterprise client’s procurement review.

Who it’s for

The toolkit is primarily for teams preparing for their first SOC 2, especially founders, engineering leaders, and operations people who have suddenly found themselves responsible for compliance without a dedicated compliance department.

That’s a common position for a growing SaaS company.

You’re already building the product. Now somebody has added SOC 2 to the calendar.

You don’t need another consultant telling you that security is important. You need to know what needs to be done, what evidence to keep, and where the gaps are likely to be.

The toolkit is also useful for companies that already have a SOC 2 report and want a more organized way to manage vendor risk and readiness work.

Get the toolkit

You can download the guide and workbook at asteros.com/soc2.

Use it with your team. Make a copy. Change it to fit your environment. Send it to the person who got volunteered (voluntold?) to own SOC 2.

And if you’re looking for a penetration test that satisfies the audit requirement and produces a report you won’t be embarrassed to hand to your next enterprise customer, that’s something we can help with too. Their security team has read a great many pentest reports and believes very few of them. We’d like yours to be one of the few.