TQS Differentiation Summary
30.7.1. Unique Differentiators of TQS
In Sections 30.2 through 30.6, TQS was compared individually with ISO 27001, ISMS-P, ISO 9001, CMMI, and SOC 2. This section consolidates the comparative analysis to summarize the unique differentiators of TQS.
30.7.1.1. Code-level Verification
TQS directly inspects actual source code and build configurations, not policies or processes.
| Existing Certification Verification | TQS Verification |
|---|---|
| "Has a security policy been established?" | "Are Spring Security settings correctly applied?" |
| "Has an encryption policy been documented?" | "Are BCrypt hashing and AES-256 encryption implemented in the code?" |
| "Has a change management process been defined?" | "Is GitHub Flow applied and are PR reviews being performed?" |
| "Has a testing procedure been documented?" | "Is JaCoCo line coverage 80% or above?" |
| "Has a coding standard been defined?" | "Is Google Java Format applied and does ESLint pass?" |
Existing certifications confirm "the existence of policies and processes." TQS confirms "whether policies are implemented in the code." This difference is the most essential differentiator of TQS.
30.7.1.2. Automated Verification
TQS performs objective verification based on automated tools rather than subjective human judgment.
| Verification Area | Automated Tool | Verification Content |
|---|---|---|
| Java code formatting | Spotless (Google Java Format) | Code style consistency |
| JavaScript/TypeScript linting | ESLint (Flat Config) | Code quality rule compliance |
| JavaScript/TypeScript formatting | Prettier | Code style consistency |
| Backend test coverage | JaCoCo | Line coverage 80%+, branch coverage 70%+ |
| Frontend testing | Vitest | Component testing, Composable testing |
| Web performance | Lighthouse | Performance score 90+ |
| Security vulnerabilities | OWASP Dependency-Check | Detection of dependencies with known vulnerabilities |
| Bundle size | Vite build analysis | Initial load JS under 300KB (gzip) |
This automated verification provides the following advantages.
- Objectivity: Always returns identical results for the same code. No auditor subjectivity is involved.
- Reproducibility: Yields identical results in an identical environment regardless of who runs it or when.
- Immediacy: Verification is performed immediately upon code changes, and results can be confirmed within minutes.
30.7.1.3. Fast Feedback Loop
TQS is integrated into the CI/CD pipeline and automatically verifies standard compliance on every commit and every Pull Request.
| Certification | Feedback Cycle | Feedback Method |
|---|---|---|
| ISO 27001 | Annual (surveillance audit) | Auditor on-site visit |
| ISMS-P | Annual (surveillance audit) | Auditor on-site visit |
| ISO 9001 | Annual (surveillance audit) | Auditor on-site visit |
| CMMI | 3 years (SCAMPI A assessment) | Assessment team on-site evaluation |
| SOC 2 | Annual (Type II renewal) | Auditor evidence verification |
| TQS | Per commit | CI/CD automated verification |
While the feedback cycle of existing certifications ranges from annual to every 3 years, TQS provides real-time feedback on every commit. When issues arise, they can be identified and fixed at the time the code is written, minimizing accumulated technical debt.
30.7.1.4. Specific Technical Specifications
TQS specifies concrete technical specifications and numerical criteria, not abstract requirements.
| Category | Existing Certification Style | TQS Style |
|---|---|---|
| Testing | "Appropriate testing must be performed" | "JaCoCo line coverage 80%+, branch coverage 70%+" |
| Performance | "Service performance must be monitored" | "Lighthouse performance score 90+, initial load JS under 300KB" |
| Security | "Encryption must be applied" | "BCrypt hashing, TLS 1.2+, AES-256, MD5/SHA-1/DES/RC4 prohibited" |
| Code Quality | "A coding standard must be established and followed" | "Google Java Format (Spotless), ESLint Flat Config, Prettier applied" |
| Technology Stack | Not specified | "Java 21, Spring Boot 3.x, PostgreSQL, jOOQ, Vue 3, TypeScript" |
Specific numerical criteria increase the objectivity of verification and provide developers with clear targets. With a clear number like "80% coverage" instead of the ambiguous criterion of "appropriate testing," compliance can be objectively determined.
30.7.1.5. Flexibility of Internal Certification
As a proprietary internal certification, TQS can be immediately updated to reflect changes in the company's technology stack.
| Category | Existing Certifications | TQS |
|---|---|---|
| Standard Establishment | Revised on a multi-year cycle by international bodies/government agencies | Updated immediately as needed by the Technical Standards Committee |
| Technology Stack Reflection | Does not specify a particular technology stack (universal) | Specialized for the company's standard technology stack |
| New Technology Response | Takes years until the standard is revised | Standard updated immediately upon new technology adoption |
| Customization | Not possible (applied as-is) | Adjustable to the company's characteristics |
For example, when the Java version is upgraded or a new framework is adopted, the TQS standard can be immediately revised to reflect it. International standards like ISO 27001 or CMMI have revision cycles of several years, making such flexible responses impossible.
30.7.2. Certification Combination Strategy
The optimal combination of TQS and external certifications varies depending on the business scenario. The following table summarizes the recommended combinations by scenario.
| Business Scenario | Recommended Certification Combination | Rationale |
|---|---|---|
| Internal tools/internal systems | TQS alone | No external customer requirements, only internal code quality management needed |
| B2B SaaS (domestic) | TQS + ISMS-P | Domestic legal requirement compliance + code quality assurance |
| B2B SaaS (overseas/global) | TQS + SOC 2 | Overseas customer trust building + code quality assurance |
| B2B SaaS (domestic + overseas) | TQS + ISMS-P + SOC 2 | Domestic legal requirements + overseas customer trust + code quality |
| Finance/public services | TQS + ISMS-P + ISO 27001 | Legal obligation + international security certification + code-level security verification |
| Large-scale SI projects | TQS + CMMI | Process maturity + deliverable quality verification |
| Public procurement bids | TQS + ISO 9001 (+ CMMI) | Quality management system + code quality + (process maturity) |
| Startups/early stage | TQS alone | Budget constraints, focus on building code quality foundation |
| Healthcare | TQS + ISMS-P + ISO 27001 | Personal information (medical data) protection + security + code quality |
30.7.2.1. Criteria for Selecting a Combination Strategy
The criteria to consider when selecting a certification combination are as follows.
- Legal Obligation: Must be included if the organization is subject to mandatory ISMS-P certification.
- Customer Requirements: The relevant certification must be included if B2B customers require a specific certification.
- Market Entry Region: Overseas markets (especially North America) often require SOC 2, while the domestic market often requires ISMS-P.
- Budget: External certifications incur costs ranging from tens of millions to hundreds of millions of KRW. TQS is free and can be applied regardless of budget.
- Organization Size: Large organizations may find CMMI suitable, while small to medium organizations may find ISO 9001 more appropriate.
TQS should be included as the base certification in all scenarios. TQS incurs no cost, and code-level quality verification is necessary in any business environment.
30.7.3. Positioning Map
Visualizing the positioning of each certification along the two axes of "verification level" and "certification scope" yields the following.
30.7.3.1. Map Interpretation
Vertical Axis: Verification Level (Process <-> Code)
- Certifications at the bottom (ISO 27001, ISMS-P, ISO 9001, CMMI) perform verification at the policy and process level.
- SOC 2 performs verification at the operations control level, one step more concrete than processes.
- TQS is positioned at the top, performing direct verification at the code and build configuration level.
Horizontal Axis: Certification Scope (Project <-> Organization)
- TQS is positioned furthest left, granting certification at the project + version level.
- SOC 2 audits at the service level.
- ISO 27001, ISMS-P, and ISO 9001 certify at the organization or business unit level.
- CMMI is positioned furthest right, assessing the process maturity of the entire organization.
30.7.3.2. TQS's Unique Position
On the positioning map, TQS occupies the unique position of "code-level verification + project-unit certification." All other certifications verify at the process level or below, at the organization or service level.
This unique position is the raison d'etre of TQS. Answering the question "Is the actual code correctly implementing policies and processes?" in the domain that existing certifications cannot cover is something only TQS can do.
30.7.4. Conclusion
30.7.4.1. The Essence of TQS
TQS is not a certification that replaces existing certifications. It is a complementary certification that fills the gaps left by existing certifications.
- ISO 27001 confirms "Has a security policy been established?" TQS confirms "Has the policy been implemented in code?"
- ISMS-P confirms "Is a management system being operated?" TQS confirms "Have the technical requirements of the management system been reflected in the code?"
- ISO 9001 confirms "Are quality processes being followed?" TQS confirms "Do the outputs of those processes meet quality criteria?"
- CMMI confirms "Are the processes mature?" TQS confirms "Do mature processes produce high-quality code?"
- SOC 2 confirms "Is the service operated securely?" TQS confirms "Is the service implemented securely?"
30.7.4.2. Core Message
The core message of TQS is a single statement.
"Verify the code, not the policy."
No matter how perfect a policy document is, it is meaningless if it is not reflected in the actual code. No matter how well defined a process is, the purpose of the process cannot be considered achieved if the quality of the deliverables does not meet the criteria.
TQS bridges this gap. It measures the difference between the "expectations" of policies and processes and the "reality" of code and build results, and verifies whether that difference falls within acceptable bounds through an objective and automated approach.
30.7.4.3. Application Recommendation
All TIENIPIA software projects must apply TQS certification as a baseline. When obtaining external certifications according to business requirements, TQS functions as the foundational certification that underpins the technical implementation of those external certifications.
The most effective certification strategy is to establish TQS as the foundation and layer appropriate external certifications on top according to business needs. Since TQS guarantees code-level quality, organizations can approach external certification audits with confidence in the technical implementation aspects.