SOC 2 Compliance Roadmap: How Dancing Dragons Can Get Audited and Pass

Why SOC 2 Matters for a Coaching Platform

If you're building a platform that handles sensitive personal data—career goals, psychological assessments, wellness conversations, session recordings, billing information—you're already operating in the trust business. And in 2026, trust has a formal name: SOC 2.

SOC 2 (Service Organization Control 2) is a compliance framework developed by the American Institute of CPAs (AICPA) that evaluates how well a service organization protects customer data. It's not a one-time checkbox—it's a continuous discipline built around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

For Dancing Dragons (https://dancingdragons.cc), SOC 2 isn't aspirational—it's a prerequisite. Enterprise clients, HR departments, and corporate coaching buyers won't sign contracts with platforms that can't prove they protect data. This blog post is our honest, engineering-driven assessment of where we stand, what we need to do, and exactly how to get audited and pass.

What SOC 2 Actually Evaluates

A SOC 2 audit isn't a penetration test. It's not a security scan. It's a process audit conducted by a licensed CPA firm. The auditor evaluates whether your organization has designed (Type I) and operated (Type II) controls that meet the Trust Services Criteria over a sustained period.

The Five Trust Services Criteria

Criterion	What It Covers	Dancing Dragons Relevance
Security	Protection against unauthorized access (logical and physical)	Auth, RBAC, encryption, network controls
Availability	System uptime and performance commitments	Vercel SLA, database redundancy, incident response
Processing Integrity	Accuracy and completeness of data processing	Billing logic, ledger synchronization, data pipelines
Confidentiality	Protection of data designated as confidential	Coach-client session data, NDA-protected content
Privacy	Collection, use, retention, disclosure, and disposal of personal information	GDPR alignment, data retention lifecycle, consent

Most organizations start with Security and Availability (the "Common Criteria"), then extend to Confidentiality and Privacy. For a coaching platform handling psychometric profiles, session recordings, and billing data, we'll need all five.

Where Dancing Dragons Already Stands

The honest truth: we're closer than most startups. Our codebase already implements many of the technical controls that SOC 2 auditors look for. The gap is primarily in documentation, formal policies, and third-party attestation—not in the engineering.

What We Already Have ✅

1. Authentication and Access Control

Our platform uses a Convergent Authentication model that bridges Clerk (identity provider) and Supabase (data security layer) with a tiered identity architecture (Legal, Social, Professional tiers). Key controls already in place:

Multi-Factor Authentication (2FA): Hybrid SMS + TOTP system with secondary PIN gates for high-sensitivity operations.
Role-Based Access Control (RBAC): Database-driven role system with explicit status lifecycle hooks, administrative bypass patterns, and owner-to-admin promotion logic.
Row-Level Security (RLS): Enforced on all Supabase tables via get_dd_user_id() bridge functions—ensuring users can only access their own data.
Mandatory Slow Path Authentication: After a critical "Identity Pollution" hazard in January 2026, we disabled fast-path auth globally, forcing authoritative database lookups for every request.
Session Management: Aggressive multi-domain logout, cross-subdomain session synchronization, and deterministic SSR hydration patterns.

2. Encryption

Data at Rest: Database-level encryption on NeonDB and all S3 buckets configured with server-side encryption (AES-256).
Data in Transit: TLS 1.3 enforced across all endpoints via Vercel's edge network and Cloudflare.
Application-Level Encryption: Sensitive fields processed through encrypt-decrypt utilities in src/lib/server/crypto/.

3. Audit Logging and Observability

Our production observability stack is robust and already generates much of the evidence SOC 2 auditors need:

Error Tracking Database: Persistent ErrorTrackingTable for all production exceptions with trace IDs.
Structured Trace IDs: Every server action returns a traceId following the dd-trace-* naming convention, creating an immutable correlation chain.
Outermost Catch Block Standard: Mandatory error boundary pattern ensuring no exception goes unlogged.
Automated Monitoring: Dual-environment health audits triggered every 8 minutes via internal crons, plus real-time log drains for immediate error detection.
Admin Diagnostic Views: In-app tools at /u/admin/traces/view and /u/admin/production for real-time health monitoring.
PHI Read Access Logging: VIEW_PHI activity events logged whenever coaches access sensitive client data (psychometric profiles, session notes).

4. Data Retention and Deletion Lifecycle

This is a control that most startups completely ignore. We've implemented a three-stage lifecycle that directly maps to SOC 2's Privacy criteria:

Stage	Trigger	Action	Window
Archival & Soft-Delete	User/System Delete	Copy to archive, soft-delete in source	Immediate
Deletion Ledgering	~70 days in archive	Hard-delete source, preserve in ledger	After 70 days
Hard Deletion	~110 days cumulative	Permanent purge from all stores + cloud	After 110 days

Users can view and restore archived data via /u/user/archived-entities and /u/user/deleted-entities.
All transitions are wrapped in dbtx transactions for integrity.
Automated cron jobs handle stage transitions every 3 days.

5. Vendor and Infrastructure Security

Vercel: Enterprise-grade serverless deployment with SOC 2 Type II attestation.
NeonDB: Primary PostgreSQL provider with encryption at rest and network isolation.
Clerk: Identity provider with their own SOC 2 Type II report.
Supabase: Real-time data layer with RLS enforcement.
AWS S3 + Google Cloud Storage: Multi-cloud binary storage with server-side encryption.
Stripe: Payment processing with PCI DSS Level 1 compliance.

6. Change Management

Version-controlled codebase with branch protection and merge protocols.
Semantic merge conflict resolution (Rule 19) with manual oversight.
Local production build verification mandate before deployment.
Type-safety enforcement via strict TypeScript configuration.

What We Still Need 🔧

Having the technical controls is only half the battle. SOC 2 is a controls audit, which means the auditor needs to see documented policies, procedures, and evidence that those controls have been operating effectively.

1. Formal Security Policies (Critical Gap)

We need written, board-approved policies for:

Information Security Policy: Overarching document defining the organization's security posture, risk tolerance, and governance structure.
Access Control Policy: Formalizes our RBAC system, onboarding/offboarding procedures, and access review cadence.
Incident Response Plan: Documented, tested procedures for detecting, classifying, responding to, and recovering from security incidents. Our observability stack generates the data—we need the formal playbook.
Change Management Policy: Formalizes our existing git-based workflow into a documented control with approval requirements, rollback procedures, and emergency change protocols.
Data Classification Policy: Defines sensitivity levels (Public, Internal, Confidential, Restricted) and maps them to our data types (coach profiles = Internal, psychometric data = Restricted, session recordings = Confidential).
Vendor Management Policy: Documents how we evaluate, onboard, monitor, and offboard third-party vendors. Includes collecting SOC 2 reports from our own vendors.
Acceptable Use Policy: Rules for employees and contractors regarding system and data access.
Business Continuity and Disaster Recovery Plan: Documented recovery procedures, RTO/RPO targets, and annual testing.

2. Risk Assessment Framework

SOC 2 requires a formal risk assessment process:

Identify and catalog risks across the organization.
Evaluate likelihood and impact.
Map risks to controls.
Review and update at least annually.

We should adopt a lightweight framework like NIST CSF (Cybersecurity Framework) or CIS Controls as the backbone.

3. Employee Security Training

Annual security awareness training for all team members.
Role-specific training for engineers (secure coding), coaches (data handling), and administrators (access management).
Documented completion records with dates and attestation.

4. Penetration Testing

Annual third-party penetration test of the application and infrastructure.
Documented remediation of findings.
We should engage a firm like Cobalt, HackerOne, or Bishop Fox.

5. Formalized Access Reviews

Quarterly review of all user access rights.
Documented offboarding procedures that revoke access within 24 hours of termination.
Privileged access reviews (admin accounts) monthly.

6. Background Checks

SOC 2 auditors expect background checks on employees with access to sensitive systems.
This includes engineers, administrators, and anyone with database access.

The SOC 2 Audit Process: Step by Step

Step 1: Choose Your Audit Type

SOC 2 Type I evaluates the design of your controls at a single point in time. Think of it as a snapshot: "Are the right controls in place today?"

SOC 2 Type II evaluates the operating effectiveness of those controls over a period of time (typically 6–12 months). This is the one enterprise clients actually care about: "Have these controls been working consistently?"

Our recommendation: Start with a Type I to validate control design, then immediately begin the observation period for Type II. Some auditors can combine these into a single engagement.

Step 2: Select Trust Services Criteria

For Dancing Dragons, we recommend including all five criteria:

Security (mandatory for all SOC 2 reports)
Availability (enterprise clients expect uptime commitments)
Processing Integrity (critical for billing accuracy and ledger synchronization)
Confidentiality (coach-client data is inherently confidential)
Privacy (we collect and process extensive personal data)

Step 3: Choose a Compliance Platform

Manual SOC 2 compliance is brutal. Modern compliance platforms automate evidence collection, policy management, and audit workflows. The major options:

Platform	Best For	Estimated Cost
Vanta	Startups, fast onboarding, integrations with Vercel/AWS/GitHub	$10K–$ 30K/year
Drata	Mid-market, strong automation, custom frameworks	$10K–$ 25K/year
Secureframe	Developer-friendly, good for engineering-led orgs	$10K–$ 20K/year
Tugboat Logic (OneTrust)	Larger orgs, multi-framework compliance	$15 K$ 40K/year

Our recommendation: Vanta or Drata. Both integrate directly with our infrastructure (Vercel, AWS, GitHub, Clerk) and can automatically pull evidence for many controls. Vanta has particularly strong integrations for cloud-native SaaS companies.

Step 4: Engage an Auditor

The auditor must be a licensed CPA firm with experience in SOC 2 attestation. They're independent—they don't help you build controls; they evaluate them. Key considerations:

Not all CPA firms are equal. Look for firms with SaaS/technology experience. Firms like Schellman, Prescient Assurance, A-LIGN, Johanson Group, and Coalfire specialize in technology SOC 2 audits.
Cost: A SOC 2 Type I audit typically costs $20K–$ 50K. A Type II audit costs $30K–$ 80K. Firms working through compliance platforms often offer discounted rates.
Timeline: Type I can be completed in 4–8 weeks once controls are in place. Type II requires a 3–12 month observation window before the final report.

Step 5: The Readiness Assessment

Before the formal audit, most auditors offer a readiness assessment (sometimes called a "gap assessment"). This is a pre-audit review where the auditor:

Reviews your documented policies and procedures.
Evaluates your technical controls against the Trust Services Criteria.
Identifies gaps and provides recommendations.
Estimates the timeline and effort for remediation.

Cost: $5K–$ 15K. This is the single best investment you can make. It turns unknowns into a concrete punch list.

Step 6: The Observation Period (Type II)

Once you've passed the readiness assessment and remediated gaps, the auditor begins the observation period. During this time, you must:

Operate all controls consistently.
Collect evidence continuously (this is where Vanta/Drata shine).
Respond to auditor inquiries promptly.
Document any exceptions or incidents and your response to them.

Critical: Exceptions don't automatically fail you. What matters is how you detect, respond to, and remediate them. An incident with a documented response is better than no incidents with no monitoring.

Step 7: The Final Report

After the observation period, the auditor issues a SOC 2 Report. This includes:

Section I: Independent auditor's opinion (Unqualified = pass, Qualified = pass with caveats, Adverse = fail).
Section II: Management's assertion that controls are designed and operating effectively.
Section III: System description (your infrastructure, data flows, control environment).
Section IV: Trust Services Criteria, controls, tests of controls, and results.
Section V (Type II only): Changes since last report (if applicable).

You share this report with enterprise prospects under NDA. It's typically valid for 12 months.

How to Pass: Practical Engineering Playbook

Based on our current architecture, here's our concrete action plan organized by Trust Services Criterion:

Security (CC1–CC9)

Already Passing ✅

Multi-provider authentication with MFA (Clerk + Supabase convergent auth)
RBAC with database-driven roles and secondary PIN gates
Row-Level Security on all Supabase tables
Encryption at rest (AES-256 on NeonDB, S3) and in transit (TLS 1.3)
Comprehensive audit logging with trace IDs
Automated production monitoring every 8 minutes

Action Items 🔧

Write and approve Information Security Policy
Write and approve Access Control Policy
Implement quarterly access reviews with documented sign-off
Engage penetration testing firm for annual assessment
Implement formal onboarding/offboarding procedures with access checklists
Configure alerts for unauthorized access attempts (currently logged, not alerted)
Document network architecture diagram (Vercel → NeonDB → Supabase → S3/GCS)

Availability (A1)

Already Passing ✅

Vercel edge deployment with global CDN and automatic failover
NeonDB managed PostgreSQL with automated backups
Multi-cloud storage (S3 + GCS) for redundancy
Production health dashboard at /u/admin/production

Action Items 🔧

Define SLA targets (e.g., 99.9% uptime for application, 99.95% for API)
Write Business Continuity and Disaster Recovery Plan
Document and test failover procedures
Establish status page (consider Statuspage.io or Instatus)
Define and document RTO (Recovery Time Objective) and RPO (Recovery Point Objective)

Processing Integrity (PI1)

Already Passing ✅

Transaction-wrapped database operations (dbtx)
Double-entry accounting in UserPaymentsLedgerTable and LedgerEntriesTable
Stripe integration with PCI DSS compliance
Idempotent migration protocol for schema changes

Action Items 🔧

Document data flow diagrams for billing pipeline (session → postmortem → Stripe charge → ledger)
Implement automated reconciliation checks between Stripe and internal ledger
Document error handling for payment processing failures and retry logic

Confidentiality (C1)

Already Passing ✅

Application-level encryption for sensitive fields via encrypt-decrypt
PHI read access logging (VIEW_PHI activity events)
S3 bucket policies restricting access to authorized services
Coach-client data isolation through RLS

Action Items 🔧

Create formal Data Classification Policy
Label all data stores with classification levels
Implement data loss prevention (DLP) rules for outbound communications
Review and document retention of confidential data types

Privacy (P1–P8)

Already Passing ✅

Three-stage data retention lifecycle (Archive → Ledger → Purge)
User self-service for data access, export, and deletion
User-facing archived/deleted entities portals
Consent management for communication preferences

Action Items 🔧

Publish comprehensive Privacy Policy aligned with SOC 2 Privacy criteria
Document all personal data collected, purposes, and legal bases
Implement formal Data Subject Access Request (DSAR) process with SLA (30 days)
Review cookie consent and tracking practices
Document cross-border data transfer mechanisms (for EU users)

Timeline and Budget Estimate

Realistic Timeline

Phase	Duration	Activities
Phase 1: Policy & Gap Assessment	Months 1–2	Write policies, engage compliance platform, conduct readiness assessment
Phase 2: Remediation	Months 3–4	Implement missing controls, penetration test, employee training
Phase 3: Type I Audit	Month 5	Point-in-time design audit
Phase 4: Observation Period	Months 5–11	Operate controls, collect evidence continuously
Phase 5: Type II Audit	Month 12	Final attestation report

Budget Estimate

Item	Estimated Cost
Compliance platform (Vanta/Drata)	$15K–$ 25K/year
Readiness assessment	$5K–$ 15K
SOC 2 Type I audit	$20K–$ 40K
SOC 2 Type II audit	$30K–$ 60K
Penetration testing

These costs can be significantly reduced by using a compliance platform that bundles auditor relationships, and by doing policy work in-house.

Common Mistakes That Cause Audit Failures

1. Treating SOC 2 as a technical project. SOC 2 is an organizational discipline, not an engineering sprint. You can have perfect encryption and still fail because you don't have a documented access review process.

2. Starting the observation period too early. If your controls aren't mature yet, every gap during the observation period becomes an exception in the final report. Get the readiness assessment first.

3. Ignoring vendor management. Auditors will ask about your vendors. If you can't produce SOC 2 reports from Vercel, Clerk, NeonDB, and Stripe, that's a finding.

4. No evidence of training. "We told everyone to be careful" isn't a control. You need documented training with completion dates and acknowledgment signatures.

5. Inconsistent access reviews. Saying you do quarterly access reviews means you need four documented reviews per year with sign-off. Miss one, and it's an exception.

6. Over-scoping. Don't include every system you own. Scope the audit to the specific systems and data flows that handle customer data. For Dancing Dragons, that's the web application, its databases, and the cloud storage—not the company's internal Slack workspace.

The Competitive Advantage

SOC 2 compliance transforms a coaching platform from a "nice tool" into an enterprise-ready partner. Specifically:

Faster Enterprise Sales: Corporate procurement teams can approve vendors with SOC 2 reports in weeks instead of months of custom security questionnaires.
Premium Pricing: Security compliance justifies higher pricing by reducing buyer risk.
Market Differentiation: In the coaching platform space, very few competitors have SOC 2. It's a moat.
Reduced Insurance Premiums: Cyber insurance providers offer better rates to SOC 2 compliant organizations.
Foundation for ISO 27001: SOC 2 controls map closely to ISO 27001, making international certification a natural next step.

Conclusion

Dancing Dragons is architecturally ready for SOC 2. Our convergent authentication system, row-level security enforcement, three-stage data retention lifecycle, comprehensive audit logging, and multi-cloud encrypted infrastructure provide a strong technical foundation. The path to certification is primarily about formalizing what we already do—writing the policies, documenting the procedures, and proving consistency over time.

The investment is significant—roughly $85K–$ 180K in Year 1—but the return is clear. SOC 2 Type II is the key that unlocks enterprise coaching contracts, corporate HR partnerships, and the trust premium that separates serious platforms from the rest of the market.

The plan is straightforward: engage a compliance platform in Q1, complete the readiness assessment by the end of Q2, pass the Type I audit in Q3, and achieve Type II attestation by early 2027. Every day we operate our existing controls is another day of evidence. The clock is already running.

For questions about our security posture or to request our SOC 2 readiness documentation, contact us at security@dancingdragons.cc.

Book a Discovery Call

Loading...

SOC 2 Compliance Roadmap: How Dancing Dragons Can Get Audited and Pass

Why SOC 2 Matters for a Coaching Platform

What SOC 2 Actually Evaluates

The Five Trust Services Criteria

Where Dancing Dragons Already Stands

What We Already Have ✅

What We Still Need 🔧

1. Formal Security Policies (Critical Gap)

2. Risk Assessment Framework

3. Employee Security Training

4. Penetration Testing

5. Formalized Access Reviews

6. Background Checks

The SOC 2 Audit Process: Step by Step

Step 1: Choose Your Audit Type

Step 2: Select Trust Services Criteria

Step 3: Choose a Compliance Platform

Step 4: Engage an Auditor

Step 5: The Readiness Assessment

Step 6: The Observation Period (Type II)

Step 7: The Final Report

How to Pass: Practical Engineering Playbook

Security (CC1–CC9)

Availability (A1)

Processing Integrity (PI1)

Confidentiality (C1)

Privacy (P1–P8)

Timeline and Budget Estimate

Realistic Timeline

Budget Estimate

Common Mistakes That Cause Audit Failures

The Competitive Advantage

Conclusion

Explore Further

Leave a Comment

Comments (0)

Related Posts

Stories vs. Reels: The Real Difference in 2026

The Science of Extended Water Fasting

The Paradox of Youth and Work: Why Your Best Years Might Be Ahead

Leave a Comment

Comments (0)

Related Posts

Stories vs. Reels: The Real Difference in 2026

The Science of Extended Water Fasting

The Paradox of Youth and Work: Why Your Best Years Might Be Ahead