claude-code-arcane 1.0.0

package/skills/soc2-compliance/references/trust_service_criteria.md

@@ -0,0 +1,273 @@
+# SOC 2 Trust Service Criteria Reference
+
+Comprehensive reference for all five AICPA Trust Service Criteria (TSC) categories. Each criterion includes its objective, sub-criteria, typical controls, and evidence examples.
+
+---
+
+## 1. Security (Common Criteria) — Required
+
+The Security category is mandatory for every SOC 2 engagement. It maps to the 17 COSO 2013 internal control principles organized into nine groups (CC1-CC9).
+
+### CC1 — Control Environment
+
+Establishes the foundation for all other components of internal control.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC1.1 | Demonstrate commitment to integrity and ethical values | Code of conduct, ethics hotline, background checks | Signed code of conduct, hotline reports, screening records |
+| CC1.2 | Board exercises oversight of internal control | Independent board/committee, regular reporting | Board meeting minutes, committee charters, oversight reports |
+| CC1.3 | Management establishes structure and reporting lines | Organizational charts, role definitions, RACI matrices | Org charts, job descriptions, authority matrices |
+| CC1.4 | Commitment to attract, develop, and retain competent individuals | Training programs, competency assessments, career development | Training completion records, skills assessments, HR policies |
+| CC1.5 | Hold individuals accountable for internal control responsibilities | Performance evaluations, disciplinary procedures | Performance review records, accountability documentation |
+
+### CC2 — Communication and Information
+
+Ensures relevant, quality information flows internally and externally.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC2.1 | Obtain and generate relevant quality information | Data classification, information quality standards | Classification policy, data quality reports |
+| CC2.2 | Internally communicate information and responsibilities | Internal newsletters, policy distribution, security awareness | Communication logs, training materials, acknowledgment records |
+| CC2.3 | Communicate with external parties | Customer notifications, vendor communications, incident notices | External communication policy, notification records, status pages |
+
+### CC3 — Risk Assessment
+
+Identifies and assesses risks that may prevent achievement of objectives.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC3.1 | Specify objectives to identify and assess risks | Risk management framework, risk appetite statement | Risk methodology document, risk appetite approval |
+| CC3.2 | Identify and analyze risks | Risk assessments, threat modeling, vulnerability analysis | Risk register, threat models, assessment reports |
+| CC3.3 | Consider potential for fraud | Fraud risk assessment, segregation of duties | Fraud risk report, SoD matrix, anti-fraud controls |
+| CC3.4 | Identify and assess changes impacting internal control | Change impact analysis, environmental scanning | Change assessments, business impact analyses |
+
+### CC4 — Monitoring Activities
+
+Ongoing evaluations to verify internal controls are present and functioning.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC4.1 | Select and perform ongoing and separate evaluations | Continuous monitoring, internal audits, control testing | Monitoring dashboards, audit reports, testing results |
+| CC4.2 | Evaluate and communicate deficiencies | Deficiency tracking, remediation management, management reporting | Deficiency logs, remediation plans, management reports |
+
+### CC5 — Control Activities
+
+Policies and procedures that ensure management directives are carried out.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC5.1 | Select and develop control activities that mitigate risks | Risk-based control selection, control design documentation | Control matrix, risk treatment plans |
+| CC5.2 | Select and develop technology controls | IT general controls, automated controls, technology governance | ITGC documentation, technology policies, automated control configs |
+| CC5.3 | Deploy control activities through policies and procedures | Policy library, procedure documentation, acknowledgment tracking | Policy repository, version history, signed acknowledgments |
+
+### CC6 — Logical and Physical Access Controls
+
+Restrict logical and physical access to information assets.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC6.1 | Logical access security over protected assets | IAM platform, SSO, MFA enforcement | IAM configuration, SSO settings, MFA enrollment reports |
+| CC6.2 | Access provisioning based on role and need | Role-based access, provisioning workflows, approval chains | Provisioning tickets, role matrix, approval records |
+| CC6.3 | Access removal on termination or role change | Offboarding checklists, automated deprovisioning | Deprovisioning tickets, termination checklists, access removal logs |
+| CC6.4 | Periodic access reviews | Quarterly user access reviews, entitlement validation | Access review reports, entitlement listings, sign-off records |
+| CC6.5 | Physical access restrictions | Badge systems, visitor management, secure areas | Badge access logs, visitor logs, physical access policies |
+| CC6.6 | Encryption of data in transit and at rest | TLS enforcement, disk encryption, key management | TLS configuration, encryption settings, key rotation records |
+| CC6.7 | Data transmission and movement restrictions | DLP tools, network segmentation, firewall rules | DLP configuration, network diagrams, firewall rule sets |
+| CC6.8 | Prevention/detection of unauthorized software | Endpoint protection, application whitelisting, malware scanning | EDR configuration, whitelist policies, scan reports |
+
+### CC7 — System Operations
+
+Detect and mitigate security events and anomalies.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC7.1 | Vulnerability identification and management | Vulnerability scanning, patch management, remediation SLAs | Scan reports, patch records, SLA compliance metrics |
+| CC7.2 | Monitor for anomalies and security events | SIEM, IDS/IPS, behavioral analytics | SIEM dashboards, alert rules, detection logs |
+| CC7.3 | Security event evaluation and classification | Incident classification criteria, triage procedures | Classification matrix, triage logs, escalation records |
+| CC7.4 | Incident response execution | Incident response plan, response team, communication procedures | IR plan, incident tickets, communication records |
+| CC7.5 | Incident recovery and lessons learned | Recovery procedures, post-incident reviews, plan updates | Recovery records, postmortem reports, plan revision history |
+
+### CC8 — Change Management
+
+Authorize, design, develop, test, and implement changes to infrastructure and software.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC8.1 | Change authorization, testing, and approval | Change management process, approval workflows, testing requirements | Change tickets, approval records, test results, deployment logs |
+
+### CC9 — Risk Mitigation
+
+Manage risks associated with business disruption, vendors, and partners.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC9.1 | Vendor and business partner risk management | Vendor assessment program, third-party risk management | Vendor risk assessments, vendor register, vendor SOC reports |
+| CC9.2 | Risk mitigation through transfer mechanisms | Cyber insurance, contractual protections | Insurance certificates, contract provisions |
+
+---
+
+## 2. Availability (A1) — Optional
+
+Addresses system uptime, performance, and recoverability commitments.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| A1.1 | Capacity and performance management | Auto-scaling, resource monitoring, capacity planning | Capacity dashboards, scaling policies, resource utilization trends |
+| A1.2 | Recovery operations | Backup procedures, DR planning, BCP documentation | Backup logs, DR plan, BCP documentation, recovery procedures |
+| A1.3 | Recovery testing | DR drills, failover tests, RTO/RPO validation | DR test reports, failover results, RTO/RPO measurements |
+
+### When to Include Availability
+
+- Your customers depend on your service uptime
+- You have SLAs with financial penalties for downtime
+- Your service is in the critical path of customer operations
+- You provide infrastructure or platform services
+
+### Key Metrics
+
+| Metric | Description | Typical Target |
+|--------|-------------|----------------|
+| RTO | Recovery Time Objective — max acceptable downtime | 1-4 hours |
+| RPO | Recovery Point Objective — max acceptable data loss | 1-24 hours |
+| SLA | Service Level Agreement — uptime commitment | 99.9%-99.99% |
+| MTTR | Mean Time to Recovery — average recovery duration | < 1 hour |
+
+---
+
+## 3. Confidentiality (C1) — Optional
+
+Protects information designated as confidential throughout its lifecycle.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| C1.1 | Identification of confidential information | Data classification scheme, confidential data inventory | Classification policy, data inventory, labeling standards |
+| C1.2 | Protection of confidential information | Encryption, access restrictions, DLP, secure transmission | Encryption configs, ACLs, DLP rules, secure transfer logs |
+| C1.3 | Disposal of confidential information | Secure deletion, media sanitization, retention enforcement | Disposal procedures, sanitization certificates, deletion logs |
+
+### When to Include Confidentiality
+
+- You handle trade secrets or proprietary business information
+- Contracts require confidentiality assurance
+- You process data classified above "public" in your classification scheme
+- Customers share confidential data for processing
+
+### Data Classification Levels
+
+| Level | Description | Handling Requirements |
+|-------|-------------|----------------------|
+| Public | No restrictions | No special controls |
+| Internal | Business use only | Access controls, basic encryption |
+| Confidential | Restricted access | Strong encryption, DLP, access reviews |
+| Highly Confidential | Strictly controlled | Strongest encryption, MFA, audit logging, need-to-know |
+
+---
+
+## 4. Processing Integrity (PI1) — Optional
+
+Ensures system processing is complete, valid, accurate, timely, and authorized.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| PI1.1 | Processing accuracy | Input validation, data integrity checks, output verification | Validation rules, integrity check logs, reconciliation reports |
+| PI1.2 | Processing completeness | Transaction monitoring, completeness checks, reconciliation | Transaction logs, batch processing reports, reconciliation records |
+| PI1.3 | Processing timeliness | SLA monitoring, batch job scheduling, processing alerts | SLA reports, job schedules, processing time metrics |
+| PI1.4 | Processing authorization | Authorization controls, segregation of duties, approval workflows | Authorization matrix, SoD analysis, approval records |
+
+### When to Include Processing Integrity
+
+- You perform financial calculations or transactions
+- Data accuracy is critical to customer operations
+- You provide analytics or reporting that drives business decisions
+- Regulatory requirements demand processing accuracy (e.g., healthcare, finance)
+
+### Validation Checkpoints
+
+| Stage | Validation | Method |
+|-------|-----------|--------|
+| Input | Data format, range, completeness | Automated validation rules |
+| Processing | Calculation accuracy, transformation correctness | Unit tests, reconciliation |
+| Output | Report accuracy, data completeness | Cross-checks, manual review, checksums |
+| Transfer | Transmission integrity, completeness | Hash verification, acknowledgment protocols |
+
+---
+
+## 5. Privacy (P1-P8) — Optional
+
+Governs the collection, use, retention, disclosure, and disposal of personal information. Closely aligns with GDPR, CCPA, and other privacy regulations.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| P1.1 | Notice — inform data subjects about data practices | Privacy policy, collection notices, purpose statements | Published privacy policy, collection banners, purpose documentation |
+| P2.1 | Choice and consent — provide opt-in/opt-out mechanisms | Consent management, preference centers, granular consent | Consent records, preference logs, opt-out mechanisms |
+| P3.1 | Collection — collect only necessary personal information | Data minimization, lawful basis documentation, purpose specification | Collection audits, lawful basis records, data flow diagrams |
+| P4.1 | Use, retention, and disposal — limit use and enforce retention | Purpose limitation, retention schedules, automated deletion | Use restriction controls, retention policies, deletion logs |
+| P4.2 | Disposal — secure disposal when no longer needed | Secure deletion, media sanitization | Disposal certificates, sanitization records |
+| P5.1 | Access — provide data subjects access to their data | DSAR processing, data portability, access portals | DSAR logs, response timelines, export capabilities |
+| P5.2 | Correction — allow data subjects to correct their data | Correction request processing, data update mechanisms | Correction logs, update records |
+| P6.1 | Disclosure — control third-party data sharing | Data sharing agreements, third-party inventory, DPAs | DPAs, sharing agreements, third-party register |
+| P6.2 | Notification — notify of breaches affecting personal data | Breach notification procedures, regulatory reporting | Breach response plan, notification records, reporting logs |
+| P7.1 | Quality — maintain accurate personal information | Data quality checks, accuracy verification, correction mechanisms | Quality reports, accuracy audits, correction records |
+| P8.1 | Monitoring — monitor privacy program effectiveness | Privacy audits, compliance reviews, complaint tracking | Audit reports, compliance dashboards, complaint logs |
+
+### When to Include Privacy
+
+- You process personal information (PII) of end users or customers
+- You operate in jurisdictions with privacy regulations (GDPR, CCPA, LGPD)
+- Customers request privacy assurance as part of vendor assessment
+- Your service involves health, financial, or other sensitive personal data
+
+### Privacy Criteria Overlap with GDPR
+
+| SOC 2 Privacy | GDPR Article | Alignment |
+|---------------|-------------|-----------|
+| P1 (Notice) | Art. 13-14 | Direct — transparency requirements |
+| P2 (Consent) | Art. 6-7 | Direct — lawful basis and consent |
+| P3 (Collection) | Art. 5(1)(b-c) | Direct — purpose limitation, minimization |
+| P4 (Retention) | Art. 5(1)(e) | Direct — storage limitation |
+| P5 (Access) | Art. 15-16 | Direct — data subject rights |
+| P6 (Disclosure) | Art. 33-34 | Direct — breach notification |
+| P7 (Quality) | Art. 5(1)(d) | Direct — accuracy principle |
+| P8 (Monitoring) | Art. 5(2) | Direct — accountability principle |
+
+---
+
+## TSC Selection Guide
+
+| Question | If Yes, Include |
+|----------|----------------|
+| Do you store/process customer data? | Security (required) |
+| Do customers depend on your uptime? | Availability |
+| Do you handle confidential business data? | Confidentiality |
+| Is data accuracy critical to your service? | Processing Integrity |
+| Do you process personal information? | Privacy |
+
+### Common Combinations
+
+| Company Type | Typical TSC Selection |
+|-------------|----------------------|
+| SaaS platform | Security + Availability |
+| Data analytics | Security + Processing Integrity + Confidentiality |
+| Healthcare SaaS | Security + Availability + Privacy + Confidentiality |
+| Financial services | Security + Availability + Processing Integrity + Confidentiality |
+| Infrastructure/PaaS | Security + Availability |
+| HR/Payroll SaaS | Security + Availability + Privacy |
+
+---
+
+## Mapping to Other Frameworks
+
+| SOC 2 Criteria | ISO 27001 | NIST CSF | HIPAA | PCI DSS |
+|---------------|-----------|----------|-------|---------|
+| CC1 (Control Environment) | A.5 (Policies) | ID.GV | Administrative Safeguards | Req 12 |
+| CC2 (Communication) | A.5.1 (Policies) | ID.GV | Administrative Safeguards | Req 12 |
+| CC3 (Risk Assessment) | A.8.2 (Risk) | ID.RA | Risk Analysis | Req 12.2 |
+| CC4 (Monitoring) | A.8.34 (Monitoring) | DE.CM | Audit Controls | Req 10 |
+| CC5 (Control Activities) | A.5-A.8 | PR | All Safeguards | Multiple |
+| CC6 (Logical/Physical Access) | A.5.15, A.7 | PR.AC | Access Controls | Req 7-9 |
+| CC7 (System Operations) | A.8.8, A.8.15 | DE, RS | Technical Safeguards | Req 5-6, 11 |
+| CC8 (Change Management) | A.8.32 | PR.IP | Change Management | Req 6.4 |
+| CC9 (Risk Mitigation) | A.5.19-5.22 | ID.SC | Business Associate Agreements | Req 12.8 |
+| A1 (Availability) | A.8.13-14 | PR.IP | Contingency Plan | Req 12.10 |
+| C1 (Confidentiality) | A.5.13-14, A.8.10-12 | PR.DS | Access Controls | Req 3-4 |
+| PI1 (Processing Integrity) | A.8.24-25 | PR.DS | Integrity Controls | Req 6.5 |
+| P1-P8 (Privacy) | A.5.34 (Privacy) | PR.PT | Privacy Rule | N/A |

package/skills/soc2-compliance/references/type1_vs_type2.md

@@ -0,0 +1,273 @@
+# SOC 2 Type I vs Type II Comparison
+
+Detailed guide for understanding the differences between SOC 2 Type I and Type II reports, selecting the right starting point, planning timelines, and managing the upgrade path.
+
+---
+
+## Overview
+
+| Dimension | Type I | Type II |
+|-----------|--------|---------|
+| **Full Name** | SOC 2 Type I Report | SOC 2 Type II Report |
+| **What It Tests** | Design of controls at a specific point in time | Design AND operating effectiveness over a period |
+| **Observation Period** | None — single date | 3-12 months (6 months typical) |
+| **Auditor Opinion** | "Controls are suitably designed as of [date]" | "Controls are suitably designed and operating effectively for the period [start] to [end]" |
+| **Evidence Volume** | Lower — policies, configs, descriptions | Higher — ongoing logs, tickets, samples across the period |
+| **Timeline to Complete** | 1-3 months (prep + audit) | 6-15 months (prep + observation + audit) |
+| **Audit Fee Range** | $20K-$50K | $30K-$100K+ |
+| **Internal Cost** | $50K-$150K (implementation + audit) | $100K-$300K+ (implementation + monitoring + audit) |
+| **Market Perception** | "They have controls" | "Their controls actually work" |
+| **Validity** | Snapshot — stale quickly | Covers a defined period; renewed annually |
+
+---
+
+## When to Start with Type I
+
+Type I is the right starting point when:
+
+1. **First SOC 2 engagement** — You need to validate control design before investing in a full observation period
+2. **Rapid market need** — A customer or deal requires SOC 2 assurance within 3 months
+3. **Building the program** — Your compliance program is new and you want a structured assessment
+4. **Budget constraints** — Type I costs significantly less and helps justify future Type II investment
+5. **Control maturity is low** — You are still implementing controls and need a milestone before Type II
+
+### Type I Limitations
+
+- **Short shelf life** — Enterprise customers often ask "When is your Type II coming?"
+- **No operating proof** — Does not demonstrate that controls work consistently
+- **Annual deals may require Type II** — Many procurement teams mandate Type II for contracts above a threshold
+- **Repeated cost** — If you plan to go Type II anyway, Type I is an additional expense
+
+---
+
+## When to Go Directly to Type II
+
+Skip Type I and go directly to Type II when:
+
+1. **Controls are already mature** — You have been operating security controls for 6+ months
+2. **Customer requirements** — Your target customers explicitly require Type II
+3. **Competitive pressure** — Competitors already have Type II reports
+4. **Existing framework** — You already have ISO 27001 or similar, and controls are mapped
+5. **Budget allows it** — You can absorb the longer timeline and higher cost
+
+---
+
+## Timeline Comparison
+
+### Type I Timeline (Typical: 3-4 Months)
+
+```
+Month 1-2: Gap Assessment + Remediation
+├── Assess current controls against TSC
+├── Implement missing controls
+├── Document policies and procedures
+└── Assign control owners
+
+Month 3: Audit Execution
+├── Auditor reviews control descriptions
+├── Auditor inspects configurations and policies
+├── Management provides representation letter
+└── Report issued
+```
+
+### Type II Timeline (Typical: 9-15 Months)
+
+```
+Month 1-3: Gap Assessment + Remediation
+├── Assess current controls against TSC
+├── Implement missing controls
+├── Document policies and procedures
+├── Set up evidence collection processes
+└── Assign control owners
+
+Month 4-9: Observation Period (6 months minimum)
+├── Controls operate normally
+├── Evidence is collected continuously
+├── Periodic internal reviews
+├── Address any control failures
+└── Maintain documentation
+
+Month 10-12: Audit Execution
+├── Auditor tests operating effectiveness
+├── Auditor samples evidence across the period
+├── Exceptions documented and evaluated
+├── Management provides representation letter
+└── Report issued
+```
+
+### Accelerated Type II (Bridge from Type I)
+
+```
+Month 1-3: Type I Audit
+├── Complete Type I assessment
+├── Receive Type I report
+└── Begin observation period immediately
+
+Month 4-9: Observation Period
+├── Controls operate with evidence collection
+├── Address any Type I findings
+└── Prepare for Type II testing
+
+Month 10-12: Type II Audit
+├── Auditor tests operating effectiveness
+└── Type II report issued
+```
+
+---
+
+## Cost Breakdown
+
+### Type I Costs
+
+| Cost Category | Range | Notes |
+|--------------|-------|-------|
+| Readiness assessment | $5K-$15K | Optional, but recommended for first-timers |
+| Gap remediation | $10K-$50K | Depends on current maturity |
+| Audit firm fees | $20K-$50K | Varies by scope, firm, and company size |
+| Internal labor | $20K-$60K | Staff time for preparation and audit support |
+| Tooling | $0-$20K | Compliance platforms, evidence management |
+| **Total** | **$55K-$195K** | |
+
+### Type II Costs
+
+| Cost Category | Range | Notes |
+|--------------|-------|-------|
+| Readiness assessment | $5K-$15K | If not already done for Type I |
+| Gap remediation | $15K-$75K | More thorough than Type I |
+| Observation period monitoring | $10K-$30K | Internal effort for evidence collection |
+| Audit firm fees | $30K-$100K+ | Larger scope, more testing |
+| Internal labor | $40K-$120K | Ongoing effort across the observation period |
+| Tooling | $5K-$40K | Compliance platforms, automation tools |
+| **Total** | **$105K-$380K** | |
+
+### Annual Renewal Costs (Type II)
+
+| Cost Category | Range |
+|--------------|-------|
+| Audit firm fees | $25K-$80K |
+| Internal labor | $30K-$80K |
+| Tooling renewal | $5K-$30K |
+| Remediation (if findings) | $5K-$30K |
+| **Total** | **$65K-$220K** |
+
+---
+
+## Upgrade Path: Type I to Type II
+
+### Step 1: Receive Type I Report
+
+Review the Type I report for:
+- Any exceptions or findings
+- Auditor recommendations
+- Control gaps identified during testing
+- Areas where design could be strengthened
+
+### Step 2: Address Type I Findings
+
+- Remediate any exceptions before starting the observation period
+- Strengthen control design based on auditor feedback
+- Document all changes and their effective dates
+
+### Step 3: Begin Observation Period
+
+- Start the clock on your observation period (minimum 3 months, recommend 6)
+- Implement evidence collection automation
+- Assign control owners and review cadences
+- Document any control changes during the period
+
+### Step 4: Maintain During Observation
+
+- Conduct monthly internal control reviews
+- Track and remediate any control failures
+- Keep evidence organized and timestamped
+- Prepare for auditor walkthroughs
+
+### Step 5: Type II Audit
+
+- Auditor tests a sample of evidence across the observation period
+- Auditor evaluates operating effectiveness
+- Exceptions are documented with management responses
+- Type II report issued
+
+---
+
+## What Auditors Test Differently
+
+### Type I Testing
+
+| Test | What the Auditor Does |
+|------|----------------------|
+| Inquiry | Asks control owners to describe how controls work |
+| Inspection | Reviews policies, configurations, and documentation |
+| Observation | May watch a control being executed (single instance) |
+
+### Type II Additional Testing
+
+| Test | What the Auditor Does |
+|------|----------------------|
+| Re-performance | Re-executes the control to verify it works correctly |
+| Sampling | Selects samples from the full observation period |
+| Walkthroughs | Traces a transaction end-to-end through all controls |
+| Exception testing | Investigates any deviations found in samples |
+| Consistency checks | Verifies controls operated the same way throughout the period |
+
+---
+
+## Report Distribution and Use
+
+### Who Receives the Report
+
+SOC 2 reports are **restricted-use documents** under AICPA standards:
+- Your organization (the service organization)
+- Your auditor
+- User entities (customers) and their auditors
+- Prospective customers under NDA
+
+### Report Shelf Life
+
+| Report Type | Practical Validity | Market Expectation |
+|-------------|-------------------|-------------------|
+| Type I | 6-12 months | Replace with Type II within 12 months |
+| Type II | 12 months from period end | Renew annually; gap > 3 months raises concerns |
+
+### Bridge Letters
+
+If there is a gap between your report period end and a customer's request date, you may issue a **bridge letter** (also called a gap letter) stating:
+- No material changes to the system since the report period
+- No known control failures since the report period
+- Management's assertion that controls continue to operate effectively
+
+---
+
+## Decision Framework
+
+```
+START
+  │
+  ├─ Do you have existing controls operating for 6+ months?
+  │   ├─ YES → Do customers require Type II specifically?
+  │   │         ├─ YES → Go directly to Type II
+  │   │         └─ NO  → Type I first (lower risk, validates design)
+  │   └─ NO  → Type I first (build foundation)
+  │
+  ├─ Is there an urgent deal requiring SOC 2 in < 4 months?
+  │   ├─ YES → Type I (fastest path to a report)
+  │   └─ NO  → Evaluate maturity and go Type I or Type II
+  │
+  └─ Budget available for full Type II program?
+      ├─ YES → Consider direct Type II if controls are mature
+      └─ NO  → Type I first, budget Type II for next fiscal year
+```
+
+---
+
+## Common Mistakes in the Upgrade Path
+
+| Mistake | Consequence | Prevention |
+|---------|------------|-----------|
+| Starting observation before fixing Type I findings | Findings carry into Type II as exceptions | Remediate all Type I findings first |
+| Choosing a 3-month observation period | Less convincing to customers; some reject < 6 months | Default to 6-month minimum observation |
+| Changing auditors between Type I and Type II | New auditor must re-learn your environment; potential scope changes | Use the same firm for continuity |
+| Not collecting evidence from day one of observation | Missing evidence for early-period controls | Start automated collection before observation begins |
+| Treating the observation period as passive | Control failures go undetected until audit | Conduct monthly internal reviews during observation |
+| Letting the Type I report expire before Type II is ready | Gap in coverage erodes customer confidence | Plan Type II timeline to overlap with Type I validity |