Soc2 Compliance Expert

SOC 2 Compliance Expert

SOC 2 Type I and Type II compliance management covering all Trust Services Criteria (TSC), infrastructure security validation, evidence collection, and end-to-end audit preparation.

---

SOC 2 Overview

Type I vs Type II

Start with Type I to validate control design, then transition to Type II within 6 months.

Trust Services Criteria Summary

For detailed control requirements per category, see REFERENCE.md.

---

Readiness Assessment Workflow

The agent guides organizations through SOC 2 readiness from gap analysis through audit completion.

Workflow: Phase 1 -- Gap Analysis (Weeks 1-4)

1. Define scope -- determine which TSC categories to include (Security is mandatory), define system boundaries, identify subservice organizations (carve-out vs. inclusive), document principal service commitments. 2. Assess current state -- inventory existing policies and procedures, map current controls to TSC requirements, interview process owners and control operators. 3. Run automated gap analysis using scripts/soc2_readiness_checker.py. 4. Document gaps -- missing controls, controls lacking evidence, controls not operating effectively. 5. Prioritize gaps by risk level and remediation effort. 6. Validation checkpoint: Gap analysis covers all in-scope TSC categories; each gap has severity rating and remediation owner assigned.

Workflow: Phase 2 -- Remediation (Weeks 5-16)

1. Develop/update policies -- information security policy, supporting procedures per control domain, policy review and approval workflows. 2. Implement technical controls -- configure IdP with SSO/MFA enforcement, deploy endpoint security (MDM, EDR, disk encryption), implement SIEM logging and monitoring, configure backup and DR, harden cloud infrastructure. 3. Establish processes -- access review procedures, change management workflow, incident response procedures, vendor management program, security awareness training. 4. Set up evidence collection -- configure automated collection, establish repository structure, define refresh cadence per TSC category. 5. Validation checkpoint: All identified gaps remediated; technical controls verified via scripts/soc2_infrastructure_auditor.py; evidence collection producing artifacts.

Workflow: Phase 3 -- Pre-Audit (Weeks 17-20)

1. Conduct internal readiness assessment -- mock audit against all in-scope TSC, validate evidence completeness and quality, run infrastructure auditor for technical validation. 2. Remediate pre-audit findings -- address remaining gaps, strengthen evidence. 3. Select and engage CPA firm -- negotiate scope, timeline, fees; schedule kickoff; prepare system description draft. 4. Validation checkpoint: Mock audit passes with no critical gaps; system description reviewed; auditor engaged.

Workflow: Phase 4 -- Audit Execution

1. Type I audit (if applicable) -- auditor reviews control design; management provides assertions; address findings before Type II. 2. Type II observation period (3-12 months) -- controls operate consistently, evidence collected continuously, quarterly self-assessments, regular auditor check-ins. 3. Fieldwork (2-4 weeks) -- auditor selects samples, tests controls, interviews personnel; draft report review; final report issuance. 4. Validation checkpoint: Clean opinion received; any findings have management response and remediation plan.

---

Evidence Collection Framework

Evidence by TSC Category

Example: Evidence Collection Command

# Generate evidence checklist for all TSC categories
python scripts/evidence_collector.py --generate-checklist --categories all

# Track evidence status
python scripts/evidence_collector.py --status evidence-tracker.json

# Update specific evidence item
python scripts/evidence_collector.py --update evidence-tracker.json \
  --item CC6.1-MFA --status collected

# Generate readiness dashboard
python scripts/evidence_collector.py --dashboard evidence-tracker.json

# Export for auditor review
python scripts/evidence_collector.py --export evidence-tracker.json --format json

Automation Strategies

GRC Platforms: Vanta, Drata, Secureframe, Laika, AuditBoard -- automated evidence collection via API integrations, continuous control monitoring, auditor collaboration portals.

Infrastructure-as-Evidence: Cloud configuration snapshots (AWS Config, Azure Policy, GCP Org Policies), Terraform state as configuration evidence, Git history as change management evidence, CI/CD pipeline logs as deployment control evidence.

---

Infrastructure Security Validation

The agent validates infrastructure configurations against SOC 2 requirements.

Quick Reference: Infrastructure Checks

For detailed per-provider control mappings, see REFERENCE.md.

Example: Infrastructure Audit Command

# Full infrastructure audit
python scripts/soc2_infrastructure_auditor.py --config infra-config.json

# Audit specific domains only
python scripts/soc2_infrastructure_auditor.py --config infra-config.json \
  --domains dns tls cloud

# JSON output with severity ratings
python scripts/soc2_infrastructure_auditor.py --config infra-config.json --format json

# Generate sample configuration template
python scripts/soc2_infrastructure_auditor.py --generate-template

---

Audit Timeline

Typical Timeline (First SOC 2)

Annual Renewal

• Begin renewal planning 3 months before observation period ends
• Maintain continuous compliance between audit periods
• Address prior-year findings before new observation period
• Bridge letters available for gaps between reports

---

Incident Response Requirements

IRP Structure

1. Preparation -- IR team defined, communication channels established, runbooks for common incidents, legal/PR contacts on retainer. 2. Detection and Analysis -- monitoring/alerting coverage, severity classification (SEV1-SEV4), triage procedures, escalation matrix. 3. Containment, Eradication, Recovery -- isolate affected systems, preserve evidence, identify root cause, restore and validate. 4. Post-Incident -- blameless post-mortem within 5 business days, lessons learned, control improvements, notification assessment (MTTD, MTTR, MTTC tracking).

For severity level definitions and breach notification timelines, see REFERENCE.md.

---

Tools

SOC 2 Readiness Checker

# Full readiness assessment
python scripts/soc2_readiness_checker.py --config org-controls.json

# JSON output for programmatic use
python scripts/soc2_readiness_checker.py --config org-controls.json --format json

# Check specific TSC categories
python scripts/soc2_readiness_checker.py --config org-controls.json \
  --categories security availability

# Include cloud provider control mapping
python scripts/soc2_readiness_checker.py --config org-controls.json --cloud-mapping

Evidence Collector

# Generate checklist and track status
python scripts/evidence_collector.py --generate-checklist --categories all
python scripts/evidence_collector.py --status evidence-tracker.json
python scripts/evidence_collector.py --dashboard evidence-tracker.json

Infrastructure Auditor

# Validate infrastructure against SOC 2 requirements
python scripts/soc2_infrastructure_auditor.py --config infra-config.json
python scripts/soc2_infrastructure_auditor.py --config infra-config.json --format json

---

References

---

Troubleshooting

---

Success Criteria

• SOC 2 scope defined with all applicable TSC categories selected, system boundaries documented, and subservice organizations identified (carve-out vs inclusive)
• Gap analysis completed with every identified gap assigned a severity rating, remediation owner, and target completion date
• Readiness score of 80%+ across all in-scope TSC categories before engaging the CPA firm, trending to 95%+ before Type II fieldwork
• Evidence collection framework operational with centralized repository, defined refresh cadence per TSC category, and automated collection where possible
• Infrastructure audit passes with no critical or high-severity findings in DNS, TLS, cloud, endpoint, or access control domains
• Type II observation period of at least 6 months with continuous control operation, quarterly self-assessments, and no significant control failures
• Clean SOC 2 Type II opinion received with any findings addressed by management response and documented remediation plans

---

Scope & Limitations

In Scope:

• SOC 2 Type I and Type II readiness assessment against all TSC categories (CC1-CC9, A1, PI1, C1, P1)
• Infrastructure security validation (DNS, TLS, cloud, endpoint, network, container, CI/CD, secrets)
• Evidence collection framework generation and tracking
• Gap analysis with severity-rated findings and remediation guidance
• Audit timeline planning and CPA firm engagement preparation
• Incident response plan structure and requirements
• Continuous compliance program design

Out of Scope:

• CPA firm audit execution (the tools prepare for audit; the actual Type I/II report requires an independent CPA firm)
• SOC 1 (ICFR) assessment (SOC 1 covers financial reporting controls, not security/availability/privacy)
• SOC 3 report generation (SOC 3 is a public-facing summary derived from SOC 2; it requires a completed SOC 2 audit)
• Penetration testing execution (use infrastructure-compliance-auditor or engage a third-party pentest firm)
• GRC platform selection or implementation (the skill is compatible with Vanta, Drata, Secureframe, etc., but does not implement them)
• Legal advice on customer contractual requirements for SOC 2 reports
• Physical security assessments (the infrastructure auditor covers logical controls; physical data center audits require on-site assessment)

---

Integration Points

---

Tool Reference

soc2_readiness_checker.py

Evaluates organizational controls against SOC 2 Trust Services Criteria with per-category scoring.

evidence_collector.py

Generates evidence collection checklists and tracks evidence gathering status.

soc2_infrastructure_auditor.py

Audits infrastructure configurations against SOC 2 requirements with severity-rated findings.

SOC 2 Compliance Reference Material

Detailed Trust Services Criteria controls, infrastructure security checks, access control specifications, and operational requirements. Referenced by the main SKILL.md.

---

Trust Services Criteria -- Control Details

CC1: Control Environment

COSO Principles: Commitment to integrity/ethics (1), Board oversight (2), Organizational structure (3), Commitment to competence (4), Accountability enforcement (5).

Board Oversight Requirements:

• Documented board or committee charter for risk oversight
• Quarterly security briefings to the board or audit committee
• Board review and approval of information security policy annually
• Independent directors with cybersecurity expertise (recommended)

CC2: Communication and Information

System Description (Section III of SOC 2 Report):

• Principal service commitments and system requirements
• Components of the system (infrastructure, software, people, procedures, data)
• System boundaries and interconnections
• Complementary user entity controls (CUECs)
• Complementary subservice organization controls (CSOCs)

CC3: Risk Assessment

Risk Identification Process: 1. Asset inventory and classification (data, systems, people) 2. Threat identification (internal, external, environmental) 3. Vulnerability assessment (technical, procedural, human) 4. Likelihood and impact scoring (qualitative or quantitative) 5. Risk treatment decisions (accept, mitigate, transfer, avoid) 6. Residual risk documentation and acceptance

Fraud Risk Considerations: Segregation of duties analysis, management override controls, financial reporting fraud risks, data manipulation risks, social engineering vulnerability assessment, insider threat program.

CC4: Monitoring Activities

Ongoing Monitoring: SIEM, IDS/IPS, real-time alerting, KPI/KRI dashboards, cloud posture management, continuous vulnerability scanning.

Separate Evaluations: Internal audit (annual minimum), penetration testing (annual minimum, quarterly recommended), third-party assessments, control self-assessments, tabletop exercises.

CC5: Control Activities

Control Activity Categories:

• Preventive: Access controls, input validation, encryption
• Detective: Logging, monitoring, anomaly detection, auditing
• Corrective: Incident response, backup restoration, patch management
• Compensating: Additional controls when primary controls have gaps

CC6: Logical and Physical Access Controls

Authentication Requirements:

• MFA enforced for all users
• Password policy: minimum 12 characters, complexity requirements
• Account lockout after 5 failed attempts
• Session timeout: 15 minutes (sensitive), 30 minutes (general)
• SSO via SAML 2.0 or OIDC for all SaaS applications

MFA Standards:

• TOTP: Minimum acceptable
• FIDO2/WebAuthn: Preferred (phishing-resistant)
• Hardware security keys: Required for privileged access
• SMS-based MFA: Not acceptable (SIM swap vulnerability)

Access Review Cadence: Privileged (quarterly), Standard (semi-annual), Service accounts (quarterly), Third-party (quarterly), Dormant accounts (monthly automated detection).

Physical Security: Biometric + badge + escort for data center visitors, badge system with audit trail for offices, visitor sign-in/sign-out, environmental controls (fire, HVAC, water detection), CCTV 90-day retention at entry/exit.

CC7: System Operations

Vulnerability Management SLAs: Critical (24h), High (7d), Medium (30d), Low (90d).

Change Management: CAB process for significant changes, emergency change procedures with post-hoc review, rollback plans required, testing in non-production environments, change calendar and blackout windows.

CC8: Change Management

Change Authorization Process: 1. Change request with business justification 2. Impact assessment (security, performance, compliance) 3. Peer code review (min 1 reviewer, 2 for critical) 4. Approval from change authority 5. Testing in staging/pre-production 6. Deployment with rollback plan 7. Post-deployment validation 8. Change record closure

Deployment Controls: Automated CI/CD pipelines, separation of dev/staging/production, restricted production access, deployment audit trail, automated rollback capability.

CC9: Risk Mitigation

A1: Availability

Backup Requirements: Daily minimum for production, point-in-time recovery for databases, encrypted at rest/transit, monthly restoration testing, 30-day retention minimum (90 recommended), air-gapped/immutable for ransomware protection.

SLA Management: 99.9% uptime minimum, scheduled maintenance windows, real-time status page, SLA credit structure, monthly reporting.

PI1: Processing Integrity

C1: Confidentiality

Data Classification: Public, Internal, Confidential, Highly Confidential/Restricted.

Encryption Requirements: AES-256 at rest, TLS 1.2+ in transit (1.3 preferred), TDE or field-level for databases, HSM for production keys, annual key rotation (90 days for high-sensitivity).

P1: Privacy

Data Subject Rights: Access (30 days), correction/rectification, deletion/erasure, portability (machine-readable), restrict processing, object to processing, automated decision-making transparency.

---

Infrastructure Security Checks

Cloud Provider Security

AWS Security Controls

Azure Security Controls

GCP Security Controls

DNS Security

TLS/SSL Configuration

Endpoint Security

Network, Container, and CI/CD Security

Network: Production/staging/development segmented, WAF on public endpoints, DDoS protection, VPN/ZTNA for remote access, egress filtering.

Container: Image scanning on every build, minimal hardened base images, no privileged containers, private registry with access controls, K8s RBAC and network policies, external secrets operator.

CI/CD: GPG-signed commits, branch protection with PR approvals, SAST on every PR, DAST in staging, dependency scanning on every build, secret scanning (pre-commit + CI), SBOM generation, immutable deployment logs.

---

Access Control Deep-Dive

Identity Provider Configuration

SSO: SAML 2.0 or OIDC for all SaaS, centralized IdP (Okta, Azure AD, Google Workspace, OneLogin), JIT provisioning, group-based access, 8-12h max session duration.

SCIM Provisioning: Automated provisioning/deprovisioning, group sync, real-time deprovisioning on termination, attribute mapping standardization.

MFA Enforcement

Privileged Access Management

Just-in-Time (JIT) Access: No standing privileged access, time-bound grants (max 8h), approval workflow, automated revocation, full session recording.

Break-Glass Procedures: Accounts in secure vault (sealed), dual-custody (two approvers), usage triggers immediate review, credentials rotated after use, annual testing.

Service Account Governance: Inventory with owners, no interactive login, 90-day API key rotation, quarterly reviews, no shared credentials, secrets in vault.

Secret Rotation Schedule

---

Vendor and Third-Party Risk Management

Vendor Risk Tiers

Contractual Requirements

• Data Processing Agreement (DPA)
• Security requirements addendum
• Right to audit clause
• Breach notification (24-72h)
• Data return/destruction on termination
• Subprocessor notification and approval
• Insurance requirements

---

Employee Security Awareness Training

Tracking: 100% completion required (30-day grace for new hires), LMS tracking, non-completion escalated to manager then HR, phishing failure triggers additional training.

---

Incident Response Plan

Severity Levels

Breach Notification Requirements

• Internal: Immediately upon confirmation
• Customer: Within 72 hours (per contract/regulation)
• Regulatory: Per applicable law (GDPR 72h, CCPA expedient)
• Law enforcement: As required by legal counsel
• Insurance carrier: Per policy terms (typically 24-48h)

---

Business Continuity and Disaster Recovery

DR Strategy by Tier

DR Testing Requirements

• Full DR failover: Annual minimum
• Tabletop exercise: Semi-annual
• Backup restoration: Monthly
• Communication tree: Semi-annual
• Results documented with lessons learned
• RTO/RPO achievement tracking

---

Common Audit Findings

---

SOC 2 Report Structure

Report Components

1. Section I: Independent Service Auditor's Report (opinion letter) 2. Section II: Management's Assertion 3. Section III: Description of the System 4. Section IV: Trust Services Criteria, Controls, Tests, and Results (Type II) 5. Section V: Other Information (optional)

Report Distribution

Best Practices: Require mutual NDA, use secure portal (not email), track recipients, watermark with recipient name, share only current-period reports.

SOC 2 Audit Preparation Playbook

End-to-end guide for preparing, executing, and maintaining SOC 2 compliance, from initial scoping through post-audit continuous compliance.

---

Pre-Audit Checklist

90-Day Milestone (T-90 Days)

Scope and Planning:

• [ ] Define TSC categories in scope (Security is mandatory; add Availability, Processing Integrity, Confidentiality, Privacy as needed)
• [ ] Define system boundaries (which systems, data stores, networks are in scope)
• [ ] Identify subservice organizations (AWS, GCP, Azure, SaaS vendors)
• [ ] Decide carve-out vs. inclusive method for subservice organizations
• [ ] Document principal service commitments and system requirements
• [ ] Identify complementary user entity controls (CUECs)
• [ ] Determine audit type (Type I first, then Type II, or directly to Type II)
• [ ] Establish SOC 2 project team with executive sponsor

Gap Analysis:

• [ ] Inventory all existing policies and procedures
• [ ] Map current controls to TSC requirements (use soc2_readiness_checker.py)
• [ ] Interview process owners for each control domain
• [ ] Review existing security assessments, pen tests, and audits
• [ ] Document all gaps with severity and remediation effort estimates
• [ ] Create prioritized remediation roadmap

Auditor Selection (begin process):

• [ ] Research CPA firms with SOC 2 experience in your industry
• [ ] Request proposals from 2-3 firms
• [ ] Evaluate based on: experience, methodology, team, timeline, cost
• [ ] Check references from similar-sized companies
• [ ] Negotiate scope, timeline, and fees

60-Day Milestone (T-60 Days)

Policy and Procedure Development:

• [ ] Information security policy (comprehensive, board-approved)
• [ ] Acceptable use policy
• [ ] Access control policy
• [ ] Data classification and handling policy
• [ ] Change management policy
• [ ] Incident response plan
• [ ] Business continuity / disaster recovery plan
• [ ] Vendor management policy
• [ ] Data retention and disposal policy
• [ ] Password and authentication policy
• [ ] Encryption policy
• [ ] Privacy policy (if Privacy in scope)
• [ ] Employee handbook security section
• [ ] Deploy all policies via centralized policy management system
• [ ] Collect employee acknowledgments for all policies

Technical Controls Implementation:

• [ ] Identity provider configured (SSO, MFA enforced for all users)
• [ ] SIEM deployed with log sources from all critical systems
• [ ] Endpoint security deployed (EDR, MDM, disk encryption)
• [ ] Vulnerability scanning configured (internal + external, monthly)
• [ ] Network security configured (firewalls, WAF, segmentation)
• [ ] Encryption at rest enabled for all data stores
• [ ] TLS 1.2+ enforced on all endpoints
• [ ] Backup and recovery configured with encryption
• [ ] CI/CD pipeline security (branch protection, code review, SAST)
• [ ] Secret scanning enabled (pre-commit + CI)
• [ ] DNS security configured (SPF, DKIM, DMARC, DNSSEC, CAA)

Process Implementation:

• [ ] Access request and approval workflow operational
• [ ] Access review schedule defined and first review completed
• [ ] Change management workflow operational
• [ ] Incident response team designated and trained
• [ ] Vendor risk assessment program launched
• [ ] Security awareness training deployed
• [ ] Offboarding/deprovisioning process documented and tested

30-Day Milestone (T-30 Days)

Evidence Collection Setup:

• [ ] Evidence repository structure created (organized by TSC category)
• [ ] Evidence collection calendar established
• [ ] Evidence owners assigned per control domain
• [ ] Automated evidence collection configured (GRC platform or manual process)
• [ ] Initial evidence collection completed for all controls
• [ ] Evidence gaps identified and collection plans in place

Pre-Audit Readiness:

• [ ] Internal readiness assessment completed (mock audit)
• [ ] Run soc2_infrastructure_auditor.py for technical validation
• [ ] Run evidence_collector.py to verify evidence completeness
• [ ] All critical and high gaps remediated
• [ ] System description draft completed
• [ ] Management assertion drafted
• [ ] Auditor engagement letter signed
• [ ] Audit kickoff meeting scheduled
• [ ] Key personnel briefed on auditor interactions

Training and Preparation:

• [ ] All employees completed security awareness training
• [ ] Control owners prepared for auditor interviews
• [ ] FAQ document for common auditor questions distributed
• [ ] Interview preparation sessions conducted
• [ ] Evidence request list reviewed and pre-staged

---

Auditor Selection Criteria

Evaluation Framework

Key Questions for Prospective Auditors

1. How many SOC 2 engagements has your firm completed in the past year? 2. Do you have experience in our specific industry/technology stack? 3. What does your evidence collection process look like? Do you use a GRC platform? 4. How do you handle exceptions and qualified findings? 5. What is your typical turnaround time from fieldwork completion to report issuance? 6. Can you provide a sample report (redacted) for reference? 7. What is the engagement team structure (partner, manager, staff)? 8. How do you handle questions or disagreements during fieldwork? 9. What is included in the engagement fee vs. billed separately? 10. Do you offer a readiness assessment as a pre-engagement service?

Red Flags in Auditor Selection

• Firm has limited SOC 2 experience (fewer than 20 engagements annually)
• Cannot provide references from similar-sized companies
• Unwilling to share methodology or sample report
• Significantly lower price than competitors (may indicate less thorough testing)
• High staff turnover on engagement teams
• No dedicated technology or platform for evidence collection
• Inflexible timeline with no accommodation for observation period

---

System Description Preparation

Required Content (Section III)

The system description is the most time-intensive document for first-time SOC 2 reports. It must cover:

1. Services Provided

• Description of the services your organization provides
• Customer types and markets served
• Service delivery model (SaaS, PaaS, managed services)

2. Principal Service Commitments

• Security commitments (data protection, access controls)
• Availability commitments (uptime SLAs, recovery objectives)
• Processing integrity commitments (data accuracy, timeliness)
• Confidentiality commitments (data classification, encryption)
• Privacy commitments (data handling practices)

3. System Components

Infrastructure:

• Cloud providers and services used
• Data center locations
• Network architecture (high-level)
• Production environment description

Software:

• Core application technology stack
• Third-party software and services
• Monitoring and security tools
• Database technologies

People:

• Organizational structure for system operations
• Key roles (CISO, CTO, engineering leads, security team)
• Training requirements
• Background check policies

Procedures:

• Access management procedures
• Change management procedures
• Incident response procedures
• Monitoring and alerting procedures
• Backup and recovery procedures

Data:

• Types of data processed
• Data classification levels
• Data flow overview (how data enters, moves through, and exits the system)
• Data retention practices

4. System Boundaries

• What is IN scope (systems, data, locations)
• What is OUT of scope (with justification)
• Interconnections with other systems

5. Subservice Organizations

• List of subservice organizations relied upon
• Services provided by each
• Carve-out or inclusive treatment
• Relevant controls (CSOCs)

6. Complementary User Entity Controls (CUECs)

• Controls customers are expected to implement
• Examples: securing their own credentials, configuring their own access controls, managing their own backup of exported data

System Description Best Practices

• Engage the auditor to review the draft system description before fieldwork
• Use diagrams (data flow, network architecture) to supplement text
• Be specific about technologies and configurations
• Update the system description for any significant changes during the observation period
• Have the system description reviewed by engineering, security, and legal teams
• Version control the system description with change tracking

---

Management Assertion Writing

Structure

The management assertion is a formal statement from the organization's management that accompanies the SOC 2 report.

Required Elements: 1. Statement that the system description is fairly presented 2. Statement that controls are suitably designed (Type I) / designed and operating effectively (Type II) 3. Statement regarding the criteria used (Trust Services Criteria) 4. Description of the period covered

Template

Management's Assertion

>

We have prepared the accompanying description of [Company Name]'s [System Name] system (the "System Description") throughout the period [Start Date] to [End Date] (the "Period"), based on the criteria for a description of a service organization's system in DC Section 200, 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report.

>

We confirm, to the best of our knowledge and belief, that:

>

a. The description fairly presents the [System Name] system that was designed and implemented throughout the Period.

>

b. The controls stated in the description were suitably designed and operating effectively to provide reasonable assurance that the service commitments and system requirements were achieved based on the applicable trust services criteria throughout the Period.

>

c. The criteria we used in making this assertion were the Trust Services Criteria established by the AICPA (TSP Section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy).

---

Evidence Organization Strategies

Folder Structure

soc2-evidence/
├── 01-control-environment/
│   ├── CC1.1-code-of-conduct/
│   │   ├── code-of-conduct-policy-v2.1.pdf
│   │   └── employee-acknowledgments-2026.csv
│   ├── CC1.2-board-oversight/
│   │   ├── board-meeting-minutes-Q1-2026.pdf
│   │   └── security-committee-charter.pdf
│   └── ...
├── 02-communication/
├── 03-risk-assessment/
├── 04-monitoring/
├── 05-control-activities/
├── 06-access-controls/
├── 07-system-operations/
├── 08-change-management/
├── 09-risk-mitigation/
├── 10-availability/
├── 11-processing-integrity/
├── 12-confidentiality/
├── 13-privacy/
├── system-description/
│   ├── system-description-v1.0.docx
│   ├── data-flow-diagram.png
│   └── network-architecture.png
└── management-assertion/
    └── management-assertion-signed.pdf

Naming Conventions

Format: [TSC-ID]_[Description]_[Date].[ext]

Examples:

• CC6.1_MFA-enrollment-report_2026-03.pdf
• CC7.1_vuln-scan-external_2026-02.pdf
• CC8.1_change-tickets-sample_2026-Q1.xlsx
• A1.2_DR-test-results_2026-01.pdf

Evidence Quality Checklist

For each evidence artifact, verify:

• [ ] Dated within the observation period
• [ ] Shows the complete control (not partial)
• [ ] Clearly readable (not blurry screenshots)
• [ ] Sensitive data redacted (PII, passwords, keys)
• [ ] Consistent with system description
• [ ] Attribution clear (who performed the control)
• [ ] Standalone comprehensible (auditor can understand without explanation)

---

Common Deficiency Types and Responses

Deficiency Classification

Top Deficiency Categories and Mitigation

1. Access Control Deficiencies (Most Common)

Examples:

• Terminated user access not removed within 24 hours
• MFA not enforced for all users
• Access reviews not completed on schedule

Mitigation:

• Automate deprovisioning via HRIS-IdP integration (SCIM)
• Enforce MFA at IdP level with no exceptions
• Automate access review scheduling with escalation

2. Change Management Deficiencies

Examples:

• Changes deployed without documented approval
• Code reviews bypassed
• Emergency changes without post-hoc review

Mitigation:

• Enforce branch protection (approvals required, no bypass)
• Implement CI/CD gates that block without approval
• Create emergency change tracking with 48-hour review requirement

3. Monitoring Deficiencies

Examples:

• Insufficient log coverage
• Alerts not responded to within SLA
• Vulnerability scan gaps

Mitigation:

• Audit log sources against system inventory monthly
• Implement alert response SLAs with tracking
• Automate vulnerability scanning schedule

4. Vendor Management Deficiencies

Examples:

• Critical vendor SOC 2 reports not collected
• Vendor risk assessments not performed annually
• Missing DPAs

Mitigation:

• Create vendor review calendar with automated reminders
• Template vendor security questionnaire for efficiency
• Centralize vendor management in GRC platform

5. Documentation Deficiencies

Examples:

• Policies not reviewed within 12 months
• System description inaccurate
• Missing evidence for controls

Mitigation:

• Implement policy management system with review reminders
• Update system description with every significant change
• Establish evidence collection calendar and ownership

Responding to Auditor Findings

1. Do not argue the finding. Understand what the auditor observed. 2. Provide context. Explain any compensating controls or mitigating circumstances. 3. Accept the finding and commit to a remediation timeline. 4. Document the root cause (process gap, tool limitation, human error). 5. Implement the fix and document evidence of remediation. 6. Verify the fix addresses the root cause, not just the symptom.

Management Response Template

Finding: [Auditor's description of the deficiency]

>

Management Response: Management acknowledges this finding. The root cause was [explanation]. We have implemented [remediation actions] effective [date]. Specifically:

- [Action 1 with owner and completion date]

- [Action 2 with owner and completion date]

>

We believe these actions adequately address the identified deficiency and will prevent recurrence. We will verify effectiveness through [monitoring approach].

---

Post-Audit Remediation Tracking

Remediation Register

Remediation SLAs

---

Continuous Compliance Maintenance

Monthly Activities

• [ ] Review security monitoring alerts and response metrics
• [ ] Verify vulnerability scanning completed (internal + external)
• [ ] Check MFA enrollment report (100% compliance)
• [ ] Review access provisioning/deprovisioning tickets
• [ ] Verify backup success and test restoration
• [ ] Review change management tickets for compliance
• [ ] Update evidence repository with monthly artifacts
• [ ] Check phishing simulation results
• [ ] Review endpoint compliance (EDR, encryption, patches)
• [ ] Verify log ingestion and SIEM health

Quarterly Activities

• [ ] Complete privileged access review
• [ ] Service account access review
• [ ] Conduct incident response tabletop exercise
• [ ] Review vendor security (critical vendors)
• [ ] Update risk register
• [ ] Security metrics report to management
• [ ] Review and update system description (if changes occurred)
• [ ] Third-party access review
• [ ] Review and test DR/backup procedures

Semi-Annual Activities

• [ ] Complete standard user access review
• [ ] DR failover test
• [ ] Communication tree test
• [ ] Review and update BIA
• [ ] Security program effectiveness assessment
• [ ] Review insurance coverage adequacy

Annual Activities

• [ ] Comprehensive risk assessment
• [ ] Policy review and update cycle (all policies)
• [ ] Penetration testing (external, may be quarterly)
• [ ] Security awareness training (refresh for all employees)
• [ ] Board/committee annual security briefing
• [ ] Code of conduct acknowledgment renewal
• [ ] Background check compliance review
• [ ] Vendor reassessment (all critical and high vendors)
• [ ] SOC 2 report renewal planning (begin 3 months before observation period ends)
• [ ] Privacy impact assessment review
• [ ] Data retention schedule review
• [ ] Encryption key rotation verification
• [ ] Incident response plan update
• [ ] DR plan update

Compliance Calendar Template

---

Cost Estimation Framework

First-Year SOC 2 Costs

Annual Renewal Costs

Cost Optimization Strategies

1. Use a GRC platform to automate evidence collection (saves 200+ hours annually) 2. Start with Type I to validate control design before committing to Type II observation period 3. Scope carefully -- only include TSC categories required by customers 4. Use cloud-native security tools (many are included in cloud provider pricing) 5. Combine audits if pursuing multiple certifications (ISO 27001 + SOC 2 unified audit) 6. Negotiate multi-year audit contracts for reduced annual fees 7. Invest in automation (automated access reviews, SCIM provisioning, CI/CD security gates)

ROI Justification

Timeline to Revenue Impact

---

GRC Platform Comparison

Selection Criteria:

• Number of native integrations with your technology stack
• Automated evidence collection coverage
• Auditor collaboration portal
• Multi-framework support (if pursuing SOC 2 + ISO 27001)
• Policy management and employee acknowledgment tracking
• Pricing model (per-user, flat-rate, or scope-based)

---

Common Mistakes to Avoid

1. Starting the observation period before controls are ready. Every control must be operational before the clock starts. Gaps during observation become findings.

2. Treating SOC 2 as a one-time project. SOC 2 requires continuous compliance. Build sustainable processes, not one-time fixes.

3. Over-scoping. Include only the TSC categories your customers require. Each additional category adds cost and complexity.

4. Under-investing in evidence collection. Auditors need evidence. If you cannot prove a control exists and operates, it effectively does not exist.

5. Waiting until fieldwork to prepare evidence. Start collecting evidence from day one of the observation period. Do not scramble during fieldwork.

6. Ignoring complementary user entity controls (CUECs). If your service requires customers to implement certain controls (e.g., securing their credentials), document these in the system description.

7. Not preparing employees for auditor interviews. Auditors will interview control owners. Prepare employees with common questions and ensure they know what controls they operate.

8. Choosing the cheapest auditor. A poor audit experience wastes time and may require rework. Choose auditors with relevant experience and good communication.

9. Not addressing prior-year findings. If you had findings in a previous audit, address them before the next observation period. Repeat findings raise auditor concerns.

10. Manual processes that cannot scale. Automate where possible (access reviews, evidence collection, vulnerability scanning). Manual processes break under growth.

Infrastructure Security Controls Reference

Comprehensive reference for infrastructure security configurations required for SOC 2 compliance, covering cloud providers, DNS, TLS, endpoints, network, containers, CI/CD, hardware security keys, and secrets management.

---

Cloud Security Configurations

AWS Security Controls

IAM and Access Management

Key AWS IAM Policies:

{
  "MinimumPasswordLength": 14,
  "RequireSymbols": true,
  "RequireNumbers": true,
  "RequireUppercaseCharacters": true,
  "RequireLowercaseCharacters": true,
  "MaxPasswordAge": 90,
  "PasswordReusePrevention": 12,
  "AllowUsersToChangePassword": true
}

Encryption

Logging and Monitoring

Network Security

Azure Security Controls

Identity and Access

Encryption and Key Management

Monitoring

GCP Security Controls

Identity and Access

Encryption

Monitoring

---

DNS Security

SPF (Sender Policy Framework)

Purpose: Specifies which mail servers are authorized to send email for your domain.

Required Configuration:

v=spf1 include:_spf.google.com include:amazonses.com -all

Best Practices:

• Use -all (hard fail) instead of ~all (soft fail) in production
• Keep DNS lookups under 10 (SPF lookup limit)
• Include all legitimate sending services
• Monitor SPF validation failures via DMARC aggregate reports
• Review quarterly for accuracy

SOC 2 Mapping: CC6.6, CC2.2

DKIM (DomainKeys Identified Mail)

Purpose: Adds a digital signature to outgoing emails for authenticity verification.

Required Configuration:

selector._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Best Practices:

• Minimum 2048-bit RSA key (1024-bit is considered weak)
• Rotate DKIM keys annually
• Configure DKIM for all email sending services
• Test with dig selector._domainkey.example.com TXT
• Consider Ed25519 keys for modern implementations

SOC 2 Mapping: CC6.6, CC2.2

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Purpose: Instructs receiving servers how to handle emails that fail SPF/DKIM checks.

Required Configuration (production):

_dmarc.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=s; aspf=s"

Deployment Path: 1. p=none - Monitor only (collect data for 30-60 days) 2. p=quarantine; pct=10 - Gradually increase percentage 3. p=reject - Full enforcement (target state for SOC 2)

Best Practices:

• Start with p=none to identify legitimate email sources
• Analyze aggregate reports before increasing enforcement
• Use strict alignment (adkim=s; aspf=s) for maximum protection
• Monitor forensic reports for attack attempts

SOC 2 Mapping: CC6.6, CC2.2

DNSSEC

Purpose: Cryptographically signs DNS records to prevent DNS spoofing.

Required Configuration:

• Enable DNSSEC signing at DNS provider
• Publish DS records at domain registrar
• Verify with: dig +dnssec example.com

Best Practices:

• Enable for all production domains
• Verify DS record propagation after enabling
• Test DNSSEC validation with online tools
• Monitor for DNSSEC validation failures

SOC 2 Mapping: CC6.6

CAA (Certificate Authority Authorization)

Purpose: Restricts which Certificate Authorities can issue certificates for your domain.

Required Configuration:

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "amazon.com"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

Best Practices:

• List only CAs you actually use
• Use issuewild to control wildcard certificate issuance
• Configure iodef for violation notifications
• Review after any CA changes

SOC 2 Mapping: CC6.6

MTA-STS (Mail Transfer Agent Strict Transport Security)

Purpose: Enforces TLS encryption for inbound SMTP connections.

Required Configuration:

_mta-sts.example.com IN TXT "v=STSv1; id=20260101"

Policy file at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

---

TLS/SSL Best Practices

Minimum Protocol Version

Recommended Cipher Suites

TLS 1.3 (all are AEAD, all are acceptable):

• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256
• TLS_CHACHA20_POLY1305_SHA256

TLS 1.2 (recommended AEAD only):

• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305

Cipher suites to disable:

• All RC4 ciphers (broken)
• All DES/3DES ciphers (weak)
• All CBC mode ciphers (vulnerable to padding oracle)
• All export-grade ciphers
• All NULL ciphers
• All anonymous (ADH/AECDH) ciphers

HSTS Configuration

Recommended Header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Deployment Path: 1. Set max-age=300 (5 min) to test 2. Increase to max-age=86400 (1 day) 3. Increase to max-age=31536000 (1 year) 4. Add includeSubDomains 5. Add preload and submit to hstspreload.org

Certificate Management

Additional TLS Headers

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 0
Content-Security-Policy: default-src 'self'; script-src 'self'
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

---

Endpoint Security

MDM Platforms

Disk Encryption Requirements

SOC 2 Requirement: 100% of company-managed devices must have disk encryption enabled. Verify via MDM compliance reports.

EDR Solutions

Minimum Requirements:

• Real-time malware detection and prevention
• Behavioral analysis for zero-day threats
• Automated response capabilities (isolate, kill process)
• Central management console with alerting
• 100% endpoint coverage

Patch Management SLAs

Patch Management Process: 1. Vulnerability advisory intake (vendor notifications, NVD) 2. Severity assessment and SLA assignment 3. Testing in pilot group (24-48 hours) 4. Phased rollout (pilot > general > production) 5. Compliance verification and exception management

---

Network Security

Network Segmentation

Required Separation:

Implementation:

• Separate VPCs/VNets per environment (preferred) or separate subnets with strict NSG/SG rules
• No direct connectivity between production and development
• All inter-zone traffic through firewall with logging
• Production data never copied to non-production (use synthetic data)

WAF Configuration

DDoS Protection

VPN and Zero Trust

Zero Trust Principles:

• Never trust, always verify
• Least privilege access
• Microsegmentation
• Continuous authentication
• Device posture assessment
• Encrypted connections everywhere

---

Container Security

Image Scanning Tools

Container Best Practices

Image Security:

• Use minimal base images (distroless, Alpine, scratch)
• Pin image versions (never use latest tag)
• Scan images on every build in CI/CD
• Sign images with cosign/Notary
• Private registry with access controls
• Rebuild images regularly (weekly minimum) for base image updates

Runtime Security:

# Kubernetes Pod Security Standards (Restricted)
securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Kubernetes Security:

Container Registry Security

• Private registry (not public Docker Hub)
• Access control with RBAC
• Vulnerability scanning on push
• Image signing and verification
• Retention policies for old images
• Geo-replication for availability

---

CI/CD Security

Branch Protection Rules

GitHub Configuration:

Required status checks: [ci/build, ci/test, security/sast, security/dependency-check]
Required reviewers: 1 (2 for critical repos)
Dismiss stale reviews: true
Require review from code owners: true
Restrict who can push: [release-managers]
Force push: disabled
Deletion: disabled
Require signed commits: true (recommended)
Require linear history: true (recommended)

GitLab Configuration:

• Protected branches with merge request approvals
• Code owners approval required
• No force push allowed
• Pipeline must succeed before merge

SAST Tools

DAST Tools

Dependency Scanning (SCA)

Secret Scanning

Pre-commit:

• gitleaks - Comprehensive secret detection
• truffleHog - Entropy-based and regex detection
• detect-secrets - Yelp's pre-commit hook

CI-level:

• GitHub Secret Scanning (native)
• GitLab Secret Detection
• Snyk Code (includes secret detection)

Configuration (gitleaks):

[allowlist]
description = "Allowlisted files"
paths = ["test/fixtures/"]

[[rules]]
description = "AWS Access Key"
regex = '''AKIA[0-9A-Z]{16}'''

SBOM Generation

Tools:

• Syft (Anchore) - Generates SPDX and CycloneDX SBOMs
• Trivy - SBOM generation + vulnerability scanning
• CycloneDX CLI - Standard SBOM format
• Microsoft SBOM Tool - Cross-platform SBOM generation

Best Practice: Generate SBOM on every release, store with release artifacts, scan for new vulnerabilities periodically.

---

Hardware Security Keys

YubiKey 5 Series

FIDO2/WebAuthn Configuration

Identity Provider Setup (Okta example): 1. Enable FIDO2 (WebAuthn) as MFA factor 2. Set attestation preference to "direct" (verify key authenticity) 3. Configure user verification to "required" (PIN or biometric) 4. Restrict allowed authenticators to FIDO2 certified devices 5. Configure resident key preference based on passwordless strategy

Browser Support:

• Chrome 67+ (full support)
• Firefox 60+ (full support)
• Safari 13+ (full support)
• Edge 18+ (full support)

SOC 2 Recommendation:

• Require hardware security keys for: root accounts, admin accounts, production access, break-glass accounts
• Issue two keys per user (primary + backup)
• Store backup keys in secure location
• Register both keys with all services
• Document lost key procedures

Phishing Resistance

---

Secrets Management

HashiCorp Vault

Architecture:

• Deploy in HA mode (3+ nodes) for production
• Enable audit logging to external SIEM
• Use auto-unseal with cloud KMS
• Enable Sentinel policies for governance

Key Features for SOC 2:

AWS Secrets Manager

Azure Key Vault

GCP Secret Manager

Secret Rotation Policies

Git Secret Prevention

Pre-commit hook (gitleaks):

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

CI Pipeline (GitHub Actions):

- name: Gitleaks
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Response to Detected Secrets: 1. Immediately rotate the compromised credential 2. Audit access logs for unauthorized usage 3. Remove from git history (git-filter-repo) 4. Notify security team 5. Update pre-commit hooks to prevent recurrence 6. Document incident

---

Compliance Mapping Summary