Professional review status
No professional domain review recorded
This bundle covers regulatory subject matter. It is a source-aware research aid, not professional advice, and should not be the sole basis for consequential decisions.
Review before reliance: A qualified legal, compliance, or other domain professional appropriate to the question and jurisdiction.
Maintainer, editorial, or technical review addresses the bundle as a published artifact. It does not constitute legal, medical, financial, accounting, or other regulated professional approval.
Inspect before downloading
See what is inside
These previews come from the published bundle files, so you can judge the method and writing before using it.
Example task
A SaaS founder asks: "A customer says we need SOC 2 before renewal. We have security policies and cloud logs, but no audit yet. Can we tell them we are SOC 2 ready, and what should we gather first?" This is an illustrative example. It does not use private customer data.
Without the bundle
You are probably SOC 2 ready if you have policies and logs. Tell the customer you are preparing for SOC 2 and collect access reviews, incident response records, and cloud security settings. You should also choose a Type II audit if the customer wants stronger proof.
Using the bundle
You should not tell the customer you are SOC 2 ready as a verified status from the facts provided. You can say you are preparing for a SOC 2 readiness review, but any customer-facing statement should be reviewed before sending. Source note: Official source category needed: AICPA/CIMA SOC 2 materials, including Trust Services Criteria and Description Criteria as relevant. User-provided evidence so far: security policies and cloud logs. Missing: customer requirement, intended trust services categories, system boundary, audit type and period, auditor request list, system description, control inventory, and professional review.
Why this is better: Using the SOC 2 source-awareness check: | Condition | Score | Notes | | --- | ---: | --- | | Baseline | 2/8 | Gives plausible advice but lacks source note, evidence separation, and professional-review boundary. | | Bundle-assisted | 8/8 | Separates evidence classes, avoids readiness conclusions, includes source note, and requires confirmation for risky actions.
Inspect this example in the repositoryOverview
SOC 2 Overview
Defines the source scope, applicability framing, and safety boundaries for SOC 2 compliance and readiness work.
Read the fileWorkflow
SOC 2 Readiness Triage
Source-aware workflow for triaging SOC 2 readiness and customer-trust questions without inventing audit conclusions.
Read the fileTemplate
Source-Aware SOC 2 Readiness Brief
Output format for SOC 2 readiness, evidence, and customer-trust questions that require source discipline and professional review.
Read the fileQuality rubric
SOC 2 Source-Awareness Check
Rubric for checking whether a SOC 2 answer is source-aware, conservative, and safe for professional review.
Read the fileIs this bundle right for your task?
Who it is for
- Compliance, legal, risk, security, operations, and product teams assessing SOC 2 (System and Organization Controls 2)
- Teams working in saas, technology, cross-industry
When to use it
- A SOC 2 (System and Organization Controls 2) question needs to be scoped to the correct rule, guidance, regulator, date, and affected entity.
- A draft conclusion needs its stated facts, missing evidence, source citations, and professional-review handoff checked.
What you need to provide
- The jurisdiction, entity and relationship facts, applicable dates, exact question, and accountable professional reviewer.
- Current official sources plus the policies, contracts, records, system evidence, and missing facts relevant to the situation.
Tasks and expected outputs
Questions it helps answer
- Triage SOC 2 questions without inventing audit conclusions or AICPA criteria.
- Separate official AICPA source categories, user-provided evidence, assumptions, and missing evidence.
- Produce source-aware SOC 2 readiness briefs for qualified professional review.
What it helps produce
- source-aware SOC 2 readiness brief
Practical example
Use it with an agent
Load the bundle as context, provide the evidence named above, then adapt this example to your situation.
Provide the jurisdiction, entity and relationship facts, applicable dates, exact question, and accountable professional reviewer. Ask the agent to assess SOC 2 (System and Organization Controls 2) and draft source-aware SOC 2 readiness brief that separates stated facts, assumptions, missing evidence, relevant source sections, and actions requiring professional approval. Begin with aicpa-cima.com — Landing / System And Organization Controls Soc Suite Of Services, then confirm that the reference is current and applicable. Inspect SOC 2 Overview before drafting.
Context path: bundles/compliance/soc-2
What the bundle includes
Frameworks
- source-evidence matrix
- trust services category scoping
- Type I versus Type II readiness framing
Evaluations
- SOC 2 source-awareness check
Sources used to build this bundle
These are the public references behind the role definition and operating guidance. The bundle does not replace current documentation or evidence from your site.
Limitations and safe use
Do not use this for
- Final legal or compliance conclusions, filings, notices, or operational changes without current source review and accountable professional approval.
Known limitations
- This bundle is a compliance hub, not legal, accounting, audit, attestation, or CPA advice.
- Scenario-specific conclusions require current AICPA materials, the actual SOC 2 report or audit request, user-provided system evidence, and qualified professional review.
- The bundle does not reproduce AICPA criteria, points of focus, report templates, or opinion language.
- Measured evaluation is planned but not complete.
Safety notes
- Require qualified CPA, auditor, legal, security, or compliance professional review before relying on outputs for audit, customer, contractual, or control-change decisions.
- Do not request, expose, or publish sensitive security evidence, customer data, report contents, or credentials beyond what is necessary for user-approved analysis.
- Require explicit confirmation before contacting auditors, sending customer responses, exporting evidence, changing controls, or modifying production systems.