SOC2 Type II Compliance

Trust Service Criteria (TSC)

1. Security (Common Criteria - CC)

Control	Requirement	Implementation
CC1.1	COSO principles	Documented security policies
CC2.1	Information communication	Security awareness training
CC3.1	Risk assessment	Annual risk assessment process
CC5.1	Control activities	Technical + administrative controls
CC6.1	Logical access	RBAC, MFA, least privilege
CC6.2	Auth mechanisms	SSO, password policy, key rotation
CC6.3	Access revocation	Automated deprovisioning
CC7.1	Threat detection	IDS/IPS, SIEM, vulnerability scanning
CC7.2	System monitoring	Real-time alerting, log aggregation
CC7.3	Incident evaluation	Severity classification, escalation
CC7.4	Incident response	Documented IR plan, tabletop exercises
CC8.1	Change management	PR review, CI/CD gates, rollback plan
CC9.1	Risk mitigation	Business continuity, DR plan

2. Availability (A)

• SLA definitions (99.9%, 99.99%)
• Uptime monitoring (health checks, synthetic monitoring)
• Disaster recovery plan tested annually
• Capacity planning documented
• Failover procedures tested
• Backup verification (restore tests quarterly)

3. Processing Integrity (PI)

• Input validation on all data entry points
• Data processing accuracy checks
• Error handling and correction procedures
• Output reconciliation
• Transaction logging with checksums

4. Confidentiality (C)

• Data classification policy (Public, Internal, Confidential, Restricted)
• Encryption at rest (AES-256)
• Encryption in transit (TLS 1.2+)
• Key management procedures (rotation, revocation)
• Confidential data access logging
• NDA tracking for third parties

5. Privacy (P)

• Privacy notice published
• Consent collection mechanism
• Data subject request handling (30 gun)
• Data retention and disposal schedule
• Third-party data sharing agreements

Access Control Checklist

Authentication

// MFA enforcement middleware
async function requireMFA(req: Request, res: Response, next: NextFunction) {
  const user = req.user;
  if (!user) return res.status(401).json({ error: 'Unauthenticated' });

  if (!user.mfaVerified) {
    await auditLog({
      action: 'auth.mfa.required',
      actor: user.id,
      resource: req.path,
      result: 'blocked',
    });
    return res.status(403).json({ error: 'MFA verification required' });
  }
  next();
}

Authorization (RBAC)

interface Permission {
  resource: string;
  action: 'read' | 'write' | 'delete' | 'admin';
}

interface Role {
  name: string;
  permissions: Permission[];
}

function checkPermission(user: User, resource: string, action: string): boolean {
  const role = getRoleByName(user.role);
  const hasPermission = role.permissions.some(
    (p) => p.resource === resource && p.action === action
  );

  auditLog({
    action: `authz.${action}.${hasPermission ? 'granted' : 'denied'}`,
    actor: user.id,
    resource,
  });

  return hasPermission;
}

Access Review Checklist

• Quarterly access reviews for all systems
• Terminated employee access revoked within 24 hours
• Privileged access requires manager approval
• Service account inventory maintained
• API key rotation schedule (90 gun max)
• SSH key inventory and rotation

Audit Logging Requirements

What to Log (ZORUNLU)

Event Category	Examples	Retention
Authentication	Login, logout, MFA, password reset	1 yil
Authorization	Permission grants, denials, role changes	1 yil
Data access	PII reads, exports, downloads	1 yil
Data modification	Create, update, delete operations	1 yil
System events	Config changes, deployments, restarts	1 yil
Admin actions	User management, policy changes	3 yil

Log Format

interface AuditLogEntry {
  id: string;               // UUID
  timestamp: string;         // ISO 8601
  action: string;           // 'user.login.success'
  actor: {
    id: string;
    email: string;
    ip: string;
    userAgent: string;
  };
  resource: {
    type: string;           // 'user', 'document', 'config'
    id: string;
    name?: string;
  };
  result: 'success' | 'failure' | 'error';
  details?: Record<string, unknown>;
  correlationId?: string;   // Request tracing
}

async function writeAuditLog(entry: AuditLogEntry): Promise<void> {
  // Append-only, tamper-evident storage
  await auditStore.append({
    ...entry,
    hash: computeHash(entry),  // Chain hash for integrity
  });
}

Anti-Patterns

Anti-Pattern	Neden Yanlis	Dogru Yol
Logging PII in plaintext	Data exposure riski	Mask/hash sensitive fields
Mutable audit logs	Tampering riski	Append-only, immutable store
No correlation ID	Trace edilemez	Her request'e UUID ata
Missing failure logs	Saldiri tespiti zorlasiyor	Basarisiz denemeleri de logla
Client-side only logging	Manipule edilebilir	Server-side zorunlu

Change Management

Change Request Template

## Change Request

**Requester:** [isim]
**Date:** [tarih]
**Priority:** [P0-P3]
**Type:** [Standard | Emergency | Normal]

### Description
[Ne degisecek]

### Impact Assessment
- Affected systems: [liste]
- Affected users: [kac kisi, hangi roller]
- Risk level: [Low | Medium | High | Critical]
- Rollback plan: [nasil geri alinir]

### Approval
- [ ] Engineering lead
- [ ] Security review (High/Critical risk)
- [ ] Business owner (user-facing changes)

### Implementation
- [ ] Changes tested in staging
- [ ] Monitoring dashboards checked
- [ ] Rollback procedure verified
- [ ] Post-deployment verification

CI/CD Gates

# SOC2 compliant pipeline
deployment:
  stages:
    - lint-and-test
    - security-scan
    - code-review-approval    # Min 1 reviewer
    - staging-deploy
    - staging-verification
    - production-approval     # Manual gate
    - production-deploy
    - post-deploy-verification

  rules:
    - require_code_review: true
    - require_passing_tests: true
    - require_security_scan: true
    - no_direct_push_to_main: true
    - branch_protection: true

Incident Response Plan

Severity Classification

Severity	Definition	Response Time	Examples
SEV-1	Service down, data breach	15 min	Production outage, unauthorized access
SEV-2	Major degradation	1 saat	Feature broken, performance issue
SEV-3	Minor impact	4 saat	Non-critical bug, cosmetic issue
SEV-4	No user impact	Next business day	Internal tool issue

Response Workflow

1. DETECT    → Monitoring alert / user report
2. TRIAGE    → Classify severity, assign IC (Incident Commander)
3. CONTAIN   → Stop the bleeding (isolate, rollback, block)
4. ERADICATE → Root cause fix
5. RECOVER   → Restore normal operations
6. REVIEW    → Post-incident review within 48 saat
7. IMPROVE   → Action items tracked to completion

Post-Incident Review Template

## Post-Incident Review

**Incident:** [INC-XXXX]
**Date:** [tarih]
**Duration:** [suresi]
**Severity:** [SEV-1/2/3/4]
**IC:** [isim]

### Timeline
- HH:MM - Event detected
- HH:MM - IC assigned
- HH:MM - Root cause identified
- HH:MM - Fix deployed
- HH:MM - Service restored

### Root Cause
[Detayli aciklama]

### Impact
- Users affected: [sayi]
- Duration: [sure]
- Data impact: [varsa]

### Action Items
- [ ] [Action 1] - Owner: [isim] - Due: [tarih]
- [ ] [Action 2] - Owner: [isim] - Due: [tarih]

### Lessons Learned
[Ne ogrendi]

Evidence Collection Guide

Continuous Evidence Collection

Evidence Type	Source	Frequency	Tool
Access reviews	IAM provider	Quarterly	Okta/Auth0 export
Change logs	Git, CI/CD	Continuous	GitHub audit log
Security scans	SAST/DAST	Per deploy	Snyk, SonarQube
Penetration tests	External auditor	Annual	Report PDF
Training records	LMS	Annual	Completion certs
Incident reports	Incident tracker	Per incident	PagerDuty, Jira
Backup tests	DR runbook	Quarterly	Restore verification
Uptime metrics	Monitoring	Continuous	Datadog, Grafana
Vulnerability patches	Dependency manager	Continuous	Dependabot, Renovate

Evidence Automation

// Automated evidence collector
async function collectMonthlyEvidence(): Promise<EvidencePackage> {
  const [accessLogs, changeLog, securityScans, uptimeMetrics] = await Promise.all([
    fetchAccessReviewReport(),
    fetchGitChangeLog(),
    fetchSecurityScanResults(),
    fetchUptimeMetrics(),
  ]);

  return {
    period: getCurrentMonth(),
    accessReview: accessLogs,
    changeManagement: changeLog,
    securityScanning: securityScans,
    availability: uptimeMetrics,
    generatedAt: new Date().toISOString(),
  };
}

Common SOC2 Findings & Fixes

Finding	Risk	Fix
No MFA for admin accounts	High	Enable MFA for all privileged users
Missing access reviews	Medium	Implement quarterly review process
No encryption at rest	High	Enable disk/database encryption
Inadequate logging	Medium	Implement centralized audit logging
No change management	High	Require PR reviews, approval gates
Missing incident response plan	High	Document and test IR procedures
No vulnerability scanning	Medium	Add SAST/DAST to CI/CD
Shared service accounts	Medium	Individual accounts with RBAC
No backup verification	Medium	Quarterly restore tests
Missing security training	Low	Annual security awareness program

SOC2 Readiness Checklist

Phase 1: Gap Assessment (2-4 hafta)

• Current state documentation
• Policy inventory
• Control gap identification
• Remediation roadmap

Phase 2: Remediation (2-6 ay)

• Policies written and approved
• Technical controls implemented
• Monitoring and alerting configured
• Evidence collection automated
• Employee training completed

Phase 3: Type I Audit (1-2 ay)

• Point-in-time assessment
• Control design evaluation
• Report received

Phase 4: Type II Audit (6-12 ay observation)

• Operating effectiveness tested
• Evidence provided for observation period
• Exceptions documented and remediated
• Final report received