Comparison with SOC 2
30.6.1. SOC 2 Overview
SOC 2 (Service Organization Controls 2) is an audit framework for verifying the internal controls of service organizations. Based on the Trust Services Criteria established by the American Institute of Certified Public Accountants (AICPA), it primarily targets organizations that provide technology services such as SaaS, cloud services, and data centers.
Unlike ISO 27001 or ISMS-P, SOC 2 is not a "certification" but an "audit report." An independent auditor (CPA firm) examines the organization's internal controls and issues the results as a report. Based on this report, customers (primarily B2B customers) assess the service provider's level of security and operational controls.
SOC 2 originated primarily in the U.S. market, but demand has been growing worldwide with the expansion of the global SaaS market. In particular, a SOC 2 report is effectively a mandatory requirement for providing B2B SaaS services in the North American and European markets. In South Korea, an increasing number of SaaS companies serving overseas customers are undergoing SOC 2 audits.
SOC 2 reports are confidential documents. They are shared only with customers under NDA (Non-Disclosure Agreement) and are not publicly disclosed. This is because the reports contain details of the organization's internal controls.
30.6.2. Trust Services Criteria
SOC 2 audits are performed based on the 5 principles defined in the AICPA's Trust Services Criteria (TSC).
| Principle | Description | Required |
|---|---|---|
| Security | Is the system protected from unauthorized access? | Required (Common Criteria) |
| Availability | Is the system operational and usable at the agreed-upon level? | Optional |
| Processing Integrity | Is system processing complete, accurate, and timely? | Optional |
| Confidentiality | Is information designated as confidential protected? | Optional |
| Privacy | Is personal information protected during collection, use, retention, disclosure, and disposal? | Optional |
30.6.2.1. Security -- Common Criteria
The Security principle is mandatory for all SOC 2 audits. Also known as the "Common Criteria," it includes the following areas.
| Area | Key Content |
|---|---|
| Control Environment (CC1) | Organizational security culture, governance, ethics, accountability |
| Communication and Information (CC2) | Delivery of security information to internal/external stakeholders |
| Risk Assessment (CC3) | Security risk identification, analysis, and response |
| Monitoring Activities (CC4) | Continuous monitoring of internal control effectiveness |
| Control Activities (CC5) | Control activities for security policy implementation |
| Logical and Physical Access Controls (CC6) | System access rights management, authentication, physical security |
| System Operations (CC7) | Change management, incident detection, incident response |
| Change Management (CC8) | Design, development, testing, approval, and deployment of system changes |
| Risk Mitigation (CC9) | Business partner and vendor risk management |
30.6.2.2. Optional Principles
Availability, Processing Integrity, Confidentiality, and Privacy are optionally included based on the organization's service characteristics.
- Availability: Applicable to services where SLA (Service Level Agreement) is critical. Verifies uptime guarantees, incident response, and disaster recovery capabilities.
- Processing Integrity: Applicable to services where accuracy is essential, such as financial transactions and data processing. Verifies the completeness and accuracy of data processing.
- Confidentiality: Applicable to services that handle customer confidential information. Verifies controls for classification, protection, and disposal of confidential information.
- Privacy: Applicable to services that collect/process personal information. Verifies controls according to AICPA's privacy criteria.
30.6.3. Type I vs Type II
SOC 2 audit reports come in two types: Type I and Type II.
| Category | Type I | Type II |
|---|---|---|
| Assessment Point | Specific point in time (point-in-time verification) | Specific period (period verification, typically 6-12 months) |
| Verification Content | Design suitability of internal controls | Design suitability + operational effectiveness of internal controls |
| Question | "Are controls appropriately designed?" | "Are controls appropriately designed and effectively operated during the period?" |
| Duration | 2-4 weeks (audit period) | 6-12 months (observation period) + 4-8 weeks (audit period) |
| Trust Level | Relatively low (point-in-time snapshot) | High (demonstrates operational effectiveness over a period) |
| Cost | Relatively low | Relatively high |
| Use Case | Initial SOC 2 adoption, when rapid market entry is needed | Long-term customer trust building, enterprise customer demand response |
30.6.3.1. Typical Adoption Path
Most organizations adopt SOC 2 in the following sequence.
- Preparation Stage: Internal control status assessment, gap analysis, control design and implementation (3-6 months)
- Type I Acquisition: Confirm control design suitability, rapid market entry (1-2 months)
- Type II Transition: Observation period to demonstrate control operational effectiveness (6-12 months)
- Annual Renewal: Repeat Type II audits annually to demonstrate continuous control effectiveness
Type I is the "starting point" and Type II is the "goal." Customers, especially enterprise customers, predominantly require Type II reports.
30.6.4. Comparative Analysis with TQS
The following table summarizes the comparison between SOC 2 and TQS along key comparison axes.
| Comparison Axis | SOC 2 | TQS |
|---|---|---|
| Purpose | Verification of internal controls of service organizations (customer trust building) | Code-level technical quality verification (internal quality assurance) |
| Verification Level | Service operations control level | Code/configuration/build level |
| Verification Target | Service organization's security, availability, integrity, confidentiality, and privacy controls | Project source code, CI/CD pipelines, build artifacts |
| Access Control Verification | "Are access rights appropriately granted/revoked?" (operational control) | "Is Spring Security RBAC implemented in the code?" (code verification) |
| Change Management Verification | "Are changes deployed through approval procedures?" (control procedure) | "Is GitHub Flow applied and is CI/CD functioning properly?" (automated verification) |
| Monitoring Verification | "Are security events detected and responded to?" (operational monitoring) | "Is SLF4J logging applied and is the Lighthouse score 90+?" (code/performance) |
| Deliverables | SOC 2 audit report (confidential, shared under NDA) | Source code, CI/CD reports, coverage reports |
| Audit Method | CPA firm auditor evidence verification + interviews | Automated tool verification + Technical Standards Committee code review |
| Certification Cost | High cost (tens to hundreds of millions of KRW) | Free (internal self-certification) |
| Renewal Cycle | Annual (Type II) | Per major version (continuous CI verification) |
| Certification Body | AICPA-certified auditor (CPA firm) | TIENIPIA Technical Standards Committee |
| Primary Audience | B2B customers (SaaS service users) | Internal project teams |
30.6.4.1. Control Verification vs Code Verification
The fundamental difference between SOC 2 and TQS lies in the perspective of verification.
SOC 2 verifies whether a service organization "effectively operates internal controls." It confirms through evidence (logs, approval records, procedure documents) that controls such as access rights management, change management, and incident response are designed and actually operating.
TQS verifies whether the code underlying the service "meets technical specifications." It directly verifies Spring Security configuration, SQL parameter binding, test coverage, and code conventions in the source code and build results.
While SOC 2 focuses on "operational effectiveness of controls," TQS focuses on "technical correctness of code."
30.6.4.2. External Trust vs Internal Quality
The primary purpose of SOC 2 is to provide external customers with trust in the security and operational level of the service. SOC 2 reports are used as key documents in B2B sales, enterprise contracts, and vendor assessments.
The primary purpose of TQS is to guarantee the code quality of internal projects. TQS certification serves as a criterion for assessing the technical maturity of projects within the organization.
This difference means the two certifications are not mutually exclusive but complementary. SOC 2 handles "trust directed outward" and TQS handles "quality directed inward."
30.6.5. Application Scenarios
30.6.5.1. Combination Strategy for SaaS Service Providers
Organizations providing SaaS services should find applying SOC 2 and TQS together to be the most effective approach.
| Layer | Responsible Certification | Role | Target |
|---|---|---|---|
| External Trust Layer | SOC 2 | Service operations control verification, customer trust building | B2B customers, partners |
| Internal Quality Layer | TQS | Service code quality verification, technical soundness assurance | Internal development teams |
30.6.5.2. SOC 2 Controls Linked to TQS
Among the SOC 2 Common Criteria, items corresponding to technical controls are linked to the TQS checklist.
| SOC 2 Control Area | SOC 2 Verification Content | TQS Verification Content |
|---|---|---|
| Logical Access Controls (CC6) | Access rights granting/revocation procedures, authentication mechanisms | Spring Security RBAC implementation, SecurityFilterChain configuration |
| Change Management (CC8) | Change approval procedures, post-test deployment, rollback procedures | GitHub Flow, PR review, CI/CD pipeline, build success rate |
| System Operations (CC7) | Incident detection, logging, response procedures | SLF4J logging, standard error response format, exception handling |
| Control Activities (CC5) | Security policy implementation, encryption application | TLS 1.2+, BCrypt hashing, SQL parameter binding |
| Availability | SLA compliance, performance monitoring, incident response | Lighthouse performance 90+, Core Web Vitals, bundle optimization |
30.6.5.3. Expected Benefits of Combined Application
Applying SOC 2 and TQS together yields the following benefits.
- Two-directional Quality Assurance: SOC 2 assures the soundness of service operations, while TQS assures the soundness of service code simultaneously.
- Strengthened Audit Readiness: During SOC 2 audits, TQS's CI/CD automated verification results can be used as supplementary evidence in the change management (CC8) area.
- Development-Operations Quality Connection: TQS guarantees code quality in the development stage, and SOC 2 guarantees control effectiveness in the operations stage, covering the entire software lifecycle.
- Market Trust + Technical Confidence: SOC 2 reports provide trust to customers, and TQS certification provides confidence in code quality to internal development teams.
30.6.5.4. Target Organizations
The SOC 2 and TQS combination is most suitable for the following types of organizations.
- Companies providing SaaS services to overseas markets (especially North America)
- Companies providing B2B services to enterprise customers
- Companies in environments where customers require Vendor Security Assessments
- Companies operating cloud-based services where data security is critical
SOC 2 "proves to customers that the service is operated securely," and TQS "assures internally that the service is implemented securely." The two certifications are in a complementary relationship, each responsible for the two axes of external trust and internal quality.