Free SOC 2 Self-Assessment Tools

Direct answer: A SOC 2 self-assessment is you walking the Trust Services Criteria and recording, honestly, whether each control is in place at your company. It is free to do, it is the correct first step, and it is not a gap analysis. A self-assessment records what you believe. A gap analysis is somebody independent testing whether that belief survives contact with your systems and your auditor.

What you get from a free self-assessment

• Real scope. How many controls apply to you, and which ones you have never thought about.
• A budget conversation. A count of what is missing is what makes an internal budget request concrete.
• A starting evidence list. Every control names the artefacts it expects.
• An honest baseline. Answering "not in place" forty times is uncomfortable and useful.

What it does not give you

It does not tell you whether your answers are right. You can mark a control in place because you have MFA on email, while the auditor is asking about MFA on the production console. That distinction is the whole job of a gap analysis, and it is the reason a self-assessment score is not a readiness score.

The options

traztech Workspace

Free, no card, no trial clock. All 61 SOC 2 criteria in plain English with what the standard asks for and what to do about it, an evidence register that maps one artefact to every control needing it, policy templates, a risk register, vendor records, and a security testing register. It flags controls you answered "in place" with nothing collected against them, which is the most common way a self-assessment flatters itself. We build it, so check it yourself.

Vendor readiness quizzes

Most compliance platforms offer a short free readiness quiz. Useful for a rough sense of scale, but they are lead capture and they stop well short of the full criteria.

The AICPA criteria themselves

The Trust Services Criteria are published. Free, authoritative, and written for practitioners rather than founders, which is why most people want a plain-English layer over them.

A spreadsheet

Genuinely viable, and plenty of companies have passed with one. You lose control mapping across frameworks and the evidence links, and you own the maintenance.

What to do after

Once you know the real count, there are three honest options: fix it yourself if the list is short and technical, hire a prep partner if it is long or you have a deadline, or wait if no customer is actually asking. The point of doing the assessment first is that you can now tell which of the three you are in.

Frequently asked

Is a self-assessment worth anything to a customer?

Not as assurance. It is for you. Customers want the report from an independent CPA firm.

How long does one take?

A focused pass over the SOC 2 criteria is a few hours if you know your environment. Chasing the answers you do not know takes longer, and that is the useful part.

Does a free assessment expire?

Your answers go stale as your systems change. Re-run it before an audit and after any significant change.

Scope the assessment before you answer a single question

The most common way a self-assessment produces a misleading result is that it was answered against a company rather than against a system. SOC 2 examines a defined service, not your organisation as a whole, and every answer changes depending on where you drew that line.

Settle four things first, on one page, before you start.

Which product or service the report covers. If you sell two products on separate infrastructure, decide whether both are in. Including a second product roughly doubles the evidence burden and is worth it only if buyers ask about it.

Which systems support it. Production cloud accounts, the identity provider, the code repository and pipeline, the data stores, logging and monitoring, and the corporate laptops of anyone with production access. Internal tools that never touch customer data can usually sit outside, and saying so explicitly is what stops scope creeping during the assessment.

Which trust services criteria. Security is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional and each adds controls and audit hours. Pick from what a customer has actually asked for in writing. Adding Privacy because it sounds thorough is a decision people regret about four months in.

Which people. Employees, contractors, and anyone at an outsourced development shop with access. Contractors are the group most often forgotten in a self-assessment and most often sampled in an audit.

Write those four down. When you later disagree with yourself about whether a control is in place, the disagreement is almost always really about scope.

How the criteria are actually organised

Knowing the shape helps, because the common criteria are not evenly weighted and beginners tend to spend their time in the wrong place.

The nine common criteria series run from CC1 through CC9. CC1 covers the control environment: governance, organisational structure, background checks, code of conduct, and whether anyone is accountable for security. CC2 covers communication and information. CC3 is risk assessment, including fraud risk, which is the one nobody expects. CC4 is monitoring, meaning how you check that your own controls are working. CC5 covers control activities generally. CC6 is logical and physical access, and it is the largest and most heavily tested block. CC7 is system operations, covering vulnerability management, monitoring, detection and incident response. CC8 is change management. CC9 is risk mitigation, including vendor management.

If your assessment shows you are strong on CC6 and CC8 and weak on CC1, CC3 and CC4, you are a normal engineering-led company. Those three are governance and they are the ones with the least technical work and the most writing. If the reverse is true, you have documentation without operating controls, which is a harder starting position than it looks.

Under each criterion sit points of focus, which are illustrative rather than mandatory. They are the most useful part of the published criteria for a self-assessment, because they tell you what the criterion means concretely. They are also not a checklist you must satisfy line by line, and treating them as one is how a self-assessment produces a hundred imaginary gaps.

Answer in three states, not two

Binary answers destroy the value of the exercise. Use three, and record evidence separately from status.

In place with evidence. The control operates and you can name the artefact that proves it, plus where it lives and who produces it. This is the only status that should count toward readiness.

In place without evidence. The thing genuinely happens and nothing records it. Change approvals that occur in a call. Access decisions made correctly and never written down. This category is usually the largest in a first assessment and it is the cheapest to fix, because the behaviour already exists and only the record is missing.

Not in place. It does not happen. Be blunt. A control marked partial because someone intends to start doing it next month is not partial.

Separating status from evidence is what turns the assessment into a plan. The two categories need completely different work: one needs a mechanism to capture what already occurs, the other needs somebody to design and run something new. Companies that collapse them into a single percentage cannot tell which kind of project they are about to start.

The self-deceptions that show up every time

Specific, recurring, and worth checking against your own answers.

MFA on email, not on production. Marked in place because Google Workspace enforces it. The criterion is about access to the systems in scope, which includes the cloud console, the database, the CI system and any admin panel with a local login.

Access reviews that never remove anyone. A review with no removals across four quarters usually means a list was approved rather than examined. If your assessment says quarterly access reviews are in place, look at the last one and count the removals.

Change management that excludes the exceptions. Pull requests require approval, except for hotfixes, infrastructure changes made directly in the console, database migrations, and feature flag changes that alter behaviour in production. If most consequential changes travel one of those paths, the control is not in place regardless of the branch protection settings.

Offboarding measured by the identity provider. Deprovisioning is marked in place because accounts are disabled centrally. Then you list the systems with local accounts, the shared credentials in a password manager, the personal access tokens in the repository, and the API keys in the payment provider, and the answer changes.

Backups that have never been restored. Backups running is a configuration. The control is a tested restore with a record of the date, who performed it, and the result.

Vendor management as a list. A spreadsheet of subprocessors is not the control. The control is that somebody assessed each material vendor, read their assurance report, recorded a conclusion, and reviews it on a cadence.

The risk assessment that is a threat model. Engineering-led companies often have a good threat model and no risk assessment. The criteria want identified risks with owners, likelihood and impact, treatment decisions, and evidence it was refreshed. Different artefact, different audience.

Policies that describe an aspiration. Downloaded templates say encryption at rest is enabled everywhere and access is reviewed monthly. If that is not true, you have manufactured findings for yourself, because an auditor tests you against your own documents. Editing the template down to what you actually do is one of the highest value hours in the whole exercise.

Turning the output into a budget and a plan

Once the pass is done, sort every gap into four buckets, because they have very different cost profiles.

Configuration. Enforce MFA on the cloud console, turn on branch protection, enable logging, restrict a security group. Hours of engineering time, done this week, no ongoing burden.

Documentation. Policies, the system description, the risk register, the vendor register. Days of writing, and the difficulty is not the writing but getting accurate answers from the people who know.

Process adoption. Quarterly access reviews, change approvals in the ticket, onboarding checklists, incident response drills. Weeks to months, because they require other people to change habits, and they are the reason first audits slip. Start these first even though they feel least urgent.

Purchases. Device management if you have none, a log retention tier, security awareness training, and a penetration test. Penetration testing starts around $1,000 for a narrow scope and rises with application complexity, and lead times run to weeks, so book it early rather than discovering in month ten that the calendar is full.

With those four buckets counted, you can produce the number your finance lead actually wants: internal hours by team, external spend by line item, and the earliest honest date your observation period could start. That is a far better budget request than a readiness percentage.

Who to sit in the room, and how long it takes

A focused pass over the common criteria takes a few hours if one person knows the environment well. The realistic version takes two sessions of ninety minutes with three or four people, because no single person knows all the answers.

You need whoever administers the cloud and identity provider, whoever owns the deployment pipeline, whoever handles HR onboarding and offboarding, and whoever signs contracts with vendors. In a thirty person company that is four people, and half the value of the exercise is the moment two of them discover they each assumed the other was doing something.

Do it live rather than by circulating a questionnaire. Circulated questionnaires come back optimistic, because nobody wants to write "not in place" next to their own area with no chance to explain.

Build the evidence register while you answer

The assessment produces a second artefact almost for free, and skipping it is the most common waste in the whole exercise. Every time you mark a control in place with evidence, record the artefact name, the system it comes from, who produces it, and how often. By the end you have an evidence register rather than a score.

The register is where the leverage is, because artefacts serve several controls at once. One quarterly access review record answers criteria about provisioning, privileged access and periodic review. One onboarding checklist covers background checks, policy acknowledgement, training and equipment. One infrastructure diagram supports the system description, the risk assessment and several access criteria. A company that maps artefacts to controls typically finds it needs thirty to fifty distinct artefacts to satisfy a hundred-odd control points, and that count is far less intimidating than the control count.

It also tells you what to automate later. Artefacts produced monthly or quarterly by a human are the ones that will slip, and they are exactly what compliance automation platforms are good at. Artefacts produced once a year, such as the penetration test report or the policy review, do not need tooling at all. Knowing which is which before you evaluate any paid platform is how you avoid paying to automate work you do four times a year.

What your auditor does with a self-assessment

Nothing, formally. It is not evidence, it is not referenced in the report, and no firm will accept it in place of testing. Its value to the audit is indirect and still real: it is how you arrive at the scoping call able to describe your boundary, your criteria and your known weaknesses, which shortens that call and produces a more accurate quote.

It also matters commercially. Auditors price disorganisation into their fees because a disorganised client takes longer to audit. On one engagement we saw a firm reduce its own quote by $11,000 once the readiness position was documented and a preparation firm was confirmed. That is one data point rather than a rule, and it shows where the lever sits.

When the self-assessment is not the right first move

Two situations where doing one is a way of avoiding the real decision.

If no customer has asked for a SOC 2 in writing, the useful first step is finding out what your buyer actually requires. Many mid-market security reviews are satisfied by a completed questionnaire, a penetration test summary and a written policy set. Running a full criteria pass to prepare for a requirement nobody has stated is thorough and premature.

If you already know the answer is bad, for instance production access is shared, there is no logging, and nothing is reviewed, you do not need a hundred questions to tell you that. Fix the two or three obvious things first, then assess, and you will avoid the demoralising version of the exercise that ends with a very low score and no idea where to start.

When you should not hire us afterwards

If your gap list comes back short and technical, meaning a dozen configuration items and a few policies, do it yourself. That is a fortnight of focused work for a competent engineering lead, and paying an outside firm to supervise it is money you should spend on the audit and the penetration test instead. The free Workspace will hold the control set, the evidence register and the policy library while you work through it, and there is no card, no trial clock, and no obligation to speak to us.

If your list is long, or it is heavy in the process adoption bucket, or a signed deal has a date attached to it, that is when outside help changes the outcome rather than the paperwork. Our fixed-scope gap analysis starts at $3,000 and produces the independent version of what you just did yourself, which is worth buying precisely because it tests your answers rather than recording them. If you want to know which of the two you are in, send us the gap count and what your buyer asked for and we will tell you plainly, including when the answer is that you do not need us.