diff --git a/content/en/guide/iso18974_guide/1-program-foundation/1-policy/_index.md b/content/en/guide/iso18974_guide/1-program-foundation/1-policy/_index.md
new file mode 100644
index 0000000000..42c9f75712
--- /dev/null
+++ b/content/en/guide/iso18974_guide/1-program-foundation/1-policy/_index.md
@@ -0,0 +1,125 @@
+---
+title: "§4.1.1 Policy"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "policy"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.1.1 corresponds to ISO/IEC 5230 §3.1.1 (License Compliance Policy), but the focus shifts to **Security Assurance**. A policy that systematically manages known and newly discovered vulnerabilities in open source components of the supplied software must be documented and communicated internally. The key difference from ISO/IEC 5230 §3.1.1 is the requirement for a **periodic review process for the policy itself and its communication method**. It is not enough to establish a policy; a review system must be in place to ensure the policy always remains valid and up to date.
+
+## 2. What to Do
+
+- Document and formalize a policy for managing security vulnerabilities in open source components included in the supplied software.
+- Include vulnerability detection, assessment, response, and notification principles, as well as a Coordinated Vulnerability Disclosure (CVD) policy.
+- Establish and document a procedure for communicating the policy to Program Participants (developers, security personnel, legal, IT, etc.).
+- **Specify in the policy a review process that periodically reviews the policy and its communication method to keep them current and valid.**
+- Record the review completion date, reviewer, and change history in the document.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.1.1 | A written open source software security assurance policy shall exist that governs open source software security assurance of the supplied software. The policy shall be internally communicated. **The policy and its method of communication shall have a review process to ensure they remain current and valid.** | **4.1.1.1** A documented open source software security assurance policy<br>**4.1.1.2** A documented procedure that makes Program Participants aware of the security assurance policy |
+
+> **§4.1.1 Policy**
+> A written open source software security assurance policy shall exist that
+> governs open source software security assurance of the supplied software.
+> The policy shall be internally communicated. The policy and its method of
+> communication shall have a review process to ensure they remain current and
+> valid.
+>
+> **Verification Material(s):**
+> 4.1.1.1 A documented open source software security assurance policy.
+> 4.1.1.2 A documented procedure that makes program participants aware of the
+> security assurance policy.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.1.1.1 Documented Security Assurance Policy
+
+**How to Comply**
+
+If an Open Source Policy for ISO/IEC 5230 is already in place, you can either add a security assurance section to that policy or create a separate security assurance policy document. Both approaches satisfy Verification Material 4.1.1.1.
+
+The policy should include: ① principles for identifying, tracking, and responding to security vulnerabilities; ② risk assessment criteria based on CVSS and remediation timelines; ③ Coordinated Vulnerability Disclosure (CVD) policy; ④ post-deployment monitoring principles; and ⑤ periodic review cycle and reviewer. The key difference from ISO/IEC 5230 §3.1.1.1 is that the **periodic review process must be explicitly stated within the policy document**.
+
+**Considerations**
+
+- **Integration with 5230 Policy**: It can be managed in an integrated manner by expanding the §5 Security Vulnerability Response section of the existing ISO/IEC 5230 policy.
+- **Specify Review Cycle**: Include a clause stating that a minimum of one annual periodic review is conducted, with an immediate review triggered by changes in the threat environment or legal requirements.
+- **Adopt CVSS Criteria**: Use CVSS (Common Vulnerability Scoring System) for vulnerability severity assessment and specify remediation timelines in the policy (e.g., Critical: 7 days, High: 30 days).
+- **Include CVD Policy**: Include a CVD procedure in the policy for collaborating confidentially to resolve externally reported vulnerabilities before public disclosure.
+- **Version Control**: Record the policy version number, change history, and review completion date.
+
+**Sample**
+
+The following is a sample of the security assurance section of an open source policy.
+
+```
+## §5 Open Source Security Assurance
+
+### 5.1 Purpose
+The company systematically identifies and responds to security vulnerabilities
+in open source components included in the supplied software to minimize security risks.
+
+### 5.2 Vulnerability Response Principles
+Remediation timeline criteria for known vulnerabilities (CVEs) are as follows:
+- Critical (CVSS 9.0–10.0): Patch or mitigation within 7 days
+- High (CVSS 7.0–8.9): Patch or mitigation within 30 days
+- Medium (CVSS 4.0–6.9): Establish patch plan within 90 days
+- Low (CVSS 0.1–3.9): Address in next scheduled update
+
+### 5.3 Coordinated Vulnerability Disclosure (CVD) Policy
+When a vulnerability is reported externally, it will be resolved in cooperation
+with the reporter before public disclosure.
+Vulnerability reporting channel: security@company.com
+
+### 5.4 Policy Review
+This policy and its communication method shall be reviewed at least annually
+to remain current and valid.
+The review completion date and reviewer shall be recorded in the document.
+```
+
+---
+
+### 4.1.1.2 Documented Procedure for Security Assurance Policy Awareness
+
+**How to Comply**
+
+A procedure for communicating the security assurance policy to Program Participants must be documented, in the same manner as the policy communication procedure for ISO/IEC 5230 (§3.1.1.2). The additional requirement of §4.1.1 is that the communication procedure itself must also be periodically reviewed to maintain its validity. You can either add security assurance policy content to the existing 5230 policy communication procedure, or establish a separate security policy communication procedure.
+
+**Considerations**
+
+- **Reuse 5230 Procedure**: Respond efficiently by adding the security assurance policy to existing open source policy communication channels (onboarding, internal wiki, email).
+- **Review the Communication Procedure**: Specify the review cycle (annually) and the reviewer in the communication procedure document to manage the validity of the procedure itself.
+- **Retain Evidence**: Keep notification history and training completion records for a minimum of 3 years.
+
+**Sample**
+
+```
+Subject: [Security] Open Source Security Assurance Policy Notice and Acknowledgment Request
+
+To: All employees in development/deployment/security-related roles
+From: Open Source Program Manager
+
+Dear all,
+
+The company's open source security assurance policy has been established (or revised).
+Please review and familiarize yourself with the policy document at the link below.
+
+- Policy document: [Internal portal link]
+- Key content: Vulnerability response principles, CVSS-based remediation timelines, CVD policy
+- Policy version: v1.0 (Effective date: YYYY-MM-DD) / Next review scheduled: YYYY-MM-DD
+
+Inquiries: Open Source Program Manager (oss@company.com)
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.1.1 Policy](../../iso5230_guide/1-program-foundation/1-policy/)
+- Related guide: [Enterprise Open Source Management Guide — 2. Policy](../../../opensource_for_enterprise/2-policy/)
+- Related template: [Open Source Policy Template](../../../templates/1-policy/)
diff --git a/content/en/guide/iso18974_guide/1-program-foundation/2-competence/_index.md b/content/en/guide/iso18974_guide/1-program-foundation/2-competence/_index.md
new file mode 100644
index 0000000000..a8ff26a2d6
--- /dev/null
+++ b/content/en/guide/iso18974_guide/1-program-foundation/2-competence/_index.md
@@ -0,0 +1,154 @@
+---
+title: "§4.1.2 Competence"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "competence"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.1.2 has the same basic structure as ISO/IEC 5230 §3.1.2 (Competence), but requires 3 additional Verification Material items. While 5230 requires three items — a list of roles, a definition of competencies per role, and evidence of competency assessment — 18974 additionally requires a **list of participants and their role mappings (4.1.2.3)**, **evidence of periodic review and process changes (4.1.2.5)**, and **verification of alignment with internal best practices (4.1.2.6)**. These three additional items require demonstrating that the competence framework is not merely formal, but is actively kept up to date and aligned with industry standards.
+
+## 2. What to Do
+
+- Create a list of responsibilities per program role (same as 5230).
+- Define and document the competencies required for each role (same as 5230).
+- **Create a separate list mapping participant names to their respective roles** (added in 18974).
+- Assess and record the competencies of each participant (same as 5230).
+- **Periodically review the competence framework and record process changes** (added in 18974).
+- **Confirm that the competence framework aligns with the company's internal best practices and assign a person responsible** (added in 18974).
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.1.2 | The organization shall: identify the roles and responsibilities that impact the performance and effectiveness of the program; determine the necessary competence for each role; ensure that participants are competent; take actions where applicable to acquire the necessary competence; and retain documented evidence of competence. | **4.1.2.1** A documented list of roles with corresponding responsibilities for the different participants in the program<br>**4.1.2.2** A document that identifies the competencies for each role<br>**4.1.2.3** List of participants and their roles ★<br>**4.1.2.4** Documented evidence of assessed competence for each program participant<br>**4.1.2.5** Documented evidence of periodic reviews and changes to the process ★<br>**4.1.2.6** Documented evidence that these processes align with and are up-to-date with company internal best practices, and that a person has been assigned to make sure they remain so ★ |
+
+★ = Additional items compared to ISO/IEC 5230 §3.1.2
+
+> **§4.1.2 Competence**
+> The organization shall:
+> - Identify the roles and responsibilities that impact the performance and
+>   effectiveness of the program;
+> - Determine the necessary competence of program participants fulfilling
+>   each role;
+> - Ensure that program participants are competent on the basis of appropriate
+>   education, training, and/or experience;
+> - Where applicable, take actions to acquire the necessary competence;
+> - Retain appropriate documented information as evidence of competence.
+>
+> **Verification Material(s):**
+> 4.1.2.1 A documented list of roles with corresponding responsibilities for
+> the different participants in the program.
+> 4.1.2.2 A document that identifies the competencies for each role.
+> 4.1.2.3 List of participants and their roles.
+> 4.1.2.4 Documented evidence of assessed competence for each program
+> participant.
+> 4.1.2.5 Documented evidence of periodic reviews and changes to the process.
+> 4.1.2.6 Documented evidence that these processes align with and are
+> up-to-date with company internal best practices, and that a person has been
+> assigned to make sure they remain so.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.1.2.1 Documented List of Roles and Responsibilities
+
+This is the same as ISO/IEC 5230 §3.1.2.1. From a security assurance perspective, the roles of security personnel (DevSecOps, vulnerability analysis) must be clearly included. Refer to [§3.1.2.1 Documented List of Roles and Responsibilities](../../iso5230_guide/1-program-foundation/2-competence/) for how to prepare this.
+
+---
+
+### 4.1.2.2 Document Identifying Competencies per Role
+
+This is the same as ISO/IEC 5230 §3.1.2.2. The security personnel role should include competencies in **CVSS score interpretation, operation of vulnerability analysis tools (OSV-SCALIBR, Dependency-Track, etc.), and DevSecOps understanding**. Refer to [§3.1.2.2 Document Identifying Competencies per Role](../../iso5230_guide/1-program-foundation/2-competence/) for how to prepare this.
+
+---
+
+### 4.1.2.3 List of Participants and Their Roles ★
+
+**How to Comply**
+
+Unlike the list of roles in 4.1.2.1, this item requires a list mapping **actual individuals by name** to the roles they are assigned. The purpose is to clearly identify who the actual personnel participating in the program are, not just the organizational roles. This list must be updated immediately when personnel changes occur.
+
+**Considerations**
+
+- **Name or job title**: Using a job title instead of a personal name is acceptable, but it must be specific enough to identify a particular individual.
+- **Multiple roles**: If someone holds multiple roles, list all of them.
+- **Timely updates**: Update the document and increment the version immediately when an assignee changes.
+
+**Sample**
+
+```
+| Name | Role | Contact | Assigned Date |
+|------|------|---------|---------------|
+| Gil-dong Hong | Open Source Program Manager | oss@company.com | 2025-01-01 |
+| Chul-su Kim | Security (DevSecOps) | security@company.com | 2025-01-01 |
+| Young-hee Lee | Legal | legal@company.com | 2025-01-01 |
+| Infra Park | IT | it@company.com | 2025-03-15 |
+```
+
+---
+
+### 4.1.2.4 Evidence of Assessed Competence
+
+This is the same as ISO/IEC 5230 §3.1.2.3. Refer to [§3.1.2.3 Evidence of Assessed Competence](../../iso5230_guide/1-program-foundation/2-competence/) for how to prepare this.
+
+---
+
+### 4.1.2.5 Evidence of Periodic Reviews and Process Changes ★
+
+**How to Comply**
+
+The competence framework (role definitions, competency criteria, assessment methods) must be periodically reviewed, and any changes resulting from the review process must be recorded. The key is to verify that new security tool adoption, organizational restructuring, and improvements to vulnerability response processes have been reflected in the competence framework. The review record itself serves as Verification Material 4.1.2.5.
+
+**Considerations**
+
+- **Review cycle**: Conduct a minimum annual periodic review and an immediate review when the organization or processes change.
+- **Record changes**: Record the content of changes, reasons for changes, change dates, and who made the changes.
+- **Evidence format**: Review meeting minutes, review completion confirmations, and change history logs can all serve as evidence.
+
+**Sample**
+
+```
+[Competence Framework Periodic Review Record]
+
+| Review Date | Review Content | Changes | Reviewer |
+|-------------|---------------|---------|----------|
+| 2025-01-10 | Full review of all roles and competencies | Added CVSS v4.0 interpretation item to security competency | Gil-dong Hong |
+| 2026-01-08 | Full review of all roles and competencies | Added Dependency-Track operation competency to IT role | Gil-dong Hong |
+```
+
+---
+
+### 4.1.2.6 Verification of Alignment with Internal Best Practices ★
+
+**How to Comply**
+
+It must be confirmed that the competency definitions and assessment processes are aligned with the company's internal best practices (HR policy, technical training standards, etc.), and a person responsible for continuously managing this must be assigned. The purpose is to ensure that the competence framework does not deviate from industry standards or internal guidelines.
+
+**Considerations**
+
+- **Assign a responsible person**: Explicitly assign and record a person responsible for managing the currency of the competence framework and its alignment with internal best practices.
+- **Best practice criteria**: Industry standards (NIST SSDF, ISO 27001, etc.), internal security policies, and DevSecOps guidelines can be used as best practice criteria.
+
+**Sample**
+
+```
+[Internal Best Practice Alignment Confirmation]
+
+Competence Framework Manager: Gil-dong Hong (Open Source Program Manager)
+Last alignment review date: 2026-01-08
+Reference best practice criteria: Internal Security Training Standard v3.0, NIST SSDF 1.1
+
+Review results:
+- Security competency criteria align with the internal security training curriculum ✓
+- Vulnerability analysis tool competency reflects the latest tools (Dependency-Track v4.x) ✓
+- Next alignment review scheduled: 2027-01-08
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.1.2 Competence](../../iso5230_guide/1-program-foundation/2-competence/)
+- Related guide: [Enterprise Open Source Management Guide — 1. Organization](../../../opensource_for_enterprise/1-teams/)
+- Related template: [Open Source Policy Template — Appendix 1. Personnel Status](../../../templates/1-policy/appendix/)
diff --git a/content/en/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md b/content/en/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md
new file mode 100644
index 0000000000..181f3dc555
--- /dev/null
+++ b/content/en/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md
@@ -0,0 +1,81 @@
+---
+title: "§4.1.3 Awareness"
+weight: 30
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "awareness"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.1.3 has the same Verification Material structure as ISO/IEC 5230 §3.1.3 (Awareness). It requires that awareness of program objectives, how individuals contribute to the program, and the implications of non-compliance be assessed and recorded for Program Participants. The difference from 5230 is that the **focus of the awareness assessment shifts to Security Assurance**. Participants must be aware not only of license compliance but also of the vulnerability management process, CVD procedures, and CVSS-based response criteria.
+
+## 2. What to Do
+
+- Confirm that Program Participants understand the objectives of the open source security assurance program (vulnerability detection, assessment, response, and notification).
+- Assess whether each participant is aware of how their role contributes to the security assurance framework.
+- Assess awareness of the legal, business, and security implications of failing to comply with the vulnerability response process.
+- Record and retain the results of awareness assessments as documentation.
+- Provide additional training to participants with gaps and retain the results of re-assessments.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.1.3 | The organization shall ensure that program participants are aware of: the existence and location of the security assurance policy / relevant security assurance objectives / their contribution to the effectiveness of the program / the implications of not following the program's requirements | **4.1.3.1** Documented evidence of assessed awareness for the program participants — which shall include the program's objectives, contributions within the program, and implications of failing to follow the program's requirements |
+
+> **§4.1.3 Awareness**
+> The organization shall ensure that the program participants are aware of:
+> - The open source software security assurance policy and where to find it;
+> - Relevant open source software security assurance objectives;
+> - Their contribution to the effectiveness of the program; and
+> - The implications of not following the program's requirements.
+>
+> **Verification Material(s):**
+> 4.1.3.1 Documented evidence of assessed awareness for the program
+> participants - which shall include the program's objectives, contributions
+> within the program, and implications of failing to follow the program's
+> requirements.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.1.3.1 Evidence of Assessed Awareness for Program Participants
+
+**How to Comply**
+
+The basic approach is the same as ISO/IEC 5230 §3.1.3.1, but the awareness assessment questions must focus on **Security Assurance**. The three core awareness items are: ① the objectives of the security assurance program (vulnerability identification, assessment, response, and CVD); ② how one's own role contributes to the security framework; and ③ the security, legal, and business risks of non-compliance with the process.
+
+The method for recording and retaining assessment results as documentation is the same as for 5230. Conduct a minimum annual periodic assessment, and perform an initial assessment for new participants immediately upon joining.
+
+**Considerations**
+
+- **Design security-specific questions**: Include content specific to security assurance in the assessment questions, such as vulnerability response procedures, CVSS criteria, and CVD policy.
+- **Role-specific in-depth assessment**: For security personnel, assess awareness up to technical vulnerability analysis; for developers, assess awareness of secure coding practices as well.
+- **Assessment cycle and evidence retention**: Conduct assessments at a minimum annually and immediately upon a new participant joining, and retain results for a minimum of 3 years.
+
+**Sample**
+
+The following is a sample security assurance policy awareness acknowledgment form.
+
+```
+[Open Source Security Assurance Policy Awareness Acknowledgment]
+
+I confirm that I have familiarized myself with the following:
+
+1. The existence and location of the company's open source security assurance policy
+2. The objectives of the open source component vulnerability detection, assessment,
+   response, and CVD program
+3. How my role contributes to the operation of the security assurance program
+4. The security breaches, legal liabilities, and business risks that may arise
+   from failing to comply with the vulnerability response process
+
+Name: ________________  Role: ________________
+Signature: ________________  Date: ________________
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.1.3 Awareness](../../iso5230_guide/1-program-foundation/3-awareness/)
+- Related guide: [Enterprise Open Source Management Guide — 5. Training](../../../opensource_for_enterprise/5-training/)
+- Related template: [Open Source Policy Template — §6 Training and Awareness](../../../templates/1-policy/)
diff --git a/content/en/guide/iso18974_guide/1-program-foundation/4-scope/_index.md b/content/en/guide/iso18974_guide/1-program-foundation/4-scope/_index.md
new file mode 100644
index 0000000000..29ed8fe949
--- /dev/null
+++ b/content/en/guide/iso18974_guide/1-program-foundation/4-scope/_index.md
@@ -0,0 +1,116 @@
+---
+title: "§4.1.4 Program Scope"
+weight: 40
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "program scope"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.1.4 is the clause from ISO/IEC 5230 §3.1.4 (Program Scope) with 2 additional Verification Materials. While 5230 only requires a written statement that clearly defines the program's scope, 18974 additionally requires a **set of performance metrics the program seeks to improve upon (4.1.4.2)** and **documented evidence from each review, update, or audit demonstrating continuous improvement (4.1.4.3)**. These two items are intended to demonstrate that the security assurance program is not static compliance, but a system with measurable goals that continuously improves.
+
+## 2. What to Do
+
+- Create a documented written statement that clearly defines the program scope (target software, organizational units, exclusions) (same as 5230).
+- **Define the performance metrics that the program seeks to improve upon** (added in 18974).
+- **Maintain records demonstrating that continuous improvement is achieved through periodic reviews, updates, and audits** (added in 18974).
+- Periodically measure actual performance against metric targets and record the results.
+- Identify areas for improvement and document the history of follow-up actions.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.1.4 | The program scope must be clearly defined, and metrics for program improvement and evidence of continuous improvement must be maintained. | **4.1.4.1** A written statement that clearly defines the scope and limits of the program<br>**4.1.4.2** A set of metrics the program seeks to improve upon ★<br>**4.1.4.3** Documented evidence from each review, update, or audit to demonstrate continuous improvement ★ |
+
+★ = Additional items compared to ISO/IEC 5230 §3.1.4
+
+> **§4.1.4 Program Scope**
+> Different programs may be designed to address different scopes depending on
+> the supplier's needs and business model. The scope needs to be clear.
+>
+> **Verification Material(s):**
+> 4.1.4.1 A written statement that clearly defines the scope and limits of
+> the program.
+> 4.1.4.2 A set of metrics the program seeks to improve upon.
+> 4.1.4.3 Documented evidence from each review, update, or audit to
+> demonstrate continuous improvement.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.1.4.1 Written Statement of Program Scope
+
+This is the same as ISO/IEC 5230 §3.1.4.1. Refer to [§3.1.4.1 Written Statement of Program Scope](../../iso5230_guide/1-program-foundation/4-scope/) for how to prepare this. From a security assurance perspective, explicitly state that "response to known and newly discovered vulnerabilities" is included within the scope.
+
+---
+
+### 4.1.4.2 Set of Performance Metrics ★
+
+**How to Comply**
+
+The performance metrics that the security assurance program seeks to improve must be defined and documented. Metrics must be measurable and realistic, and connected to the program's key objectives (vulnerability detection rate, response time, SBOM completeness, etc.). The metrics set itself is Verification Material 4.1.4.2.
+
+**Considerations**
+
+- **Measurability**: Set quantitative indicators rather than qualitative descriptions.
+- **Realistic targets**: Set targets at an achievable level initially and progressively raise them.
+- **Periodic measurement**: Measure metrics at a minimum quarterly and record the results.
+
+**Sample**
+
+```
+[Security Assurance Program Performance Metrics]
+
+| Metric | Measurement Method | Target | Measurement Cycle |
+|--------|--------------------|--------|--------------------|
+| SBOM Completeness | Proportion of distributed software with an SBOM | 100% | Quarterly |
+| Critical Vulnerability Average Response Time | Detection date to patch application date | 7 days or less | Quarterly |
+| High Vulnerability Average Response Time | Detection date to patch application date | 30 days or less | Quarterly |
+| Vulnerability Recurrence Rate | Rate of re-vulnerability in the same component | 10% or less | Semi-annually |
+| New Participant Awareness Assessment Completion Rate | Rate of assessment completion within 30 days of joining | 100% | Quarterly |
+| External Vulnerability Inquiry Response Compliance Rate | Rate of response completion within 14 days | 95% or more | Quarterly |
+```
+
+---
+
+### 4.1.4.3 Evidence of Continuous Improvement ★
+
+**How to Comply**
+
+Records showing that the security assurance program is actually improving through periodic reviews, process updates, internal audits, etc. must be maintained. Document the issues found, improvement actions taken, and improvement results at each review or audit. These records themselves are Verification Material 4.1.4.3.
+
+**Considerations**
+
+- **Regular audit schedule**: Conduct a full program audit at a minimum annually and record the results.
+- **Track improvement history**: Track and record whether issues raised in previous audits were resolved in subsequent audits.
+- **Link to metrics**: Use the performance trend of the metrics defined in 4.1.4.2 as evidence of improvement.
+
+**Sample**
+
+```
+[Security Assurance Program Periodic Review Record]
+
+Review date: 2026-01-10
+Reviewers: Gil-dong Hong (Open Source Program Manager), Chul-su Kim (Security)
+
+Metrics performance:
+- SBOM Completeness: 97% → 100% (target achieved)
+- Critical vulnerability average response time: 9 days → 6 days (target achieved)
+- High vulnerability average response time: 35 days → 28 days (target achieved)
+
+Improvements identified:
+1. External vulnerability inquiry response compliance rate 88% → target of 95% not met
+   Action: Additional inquiry monitoring assignee designated (completed 2026-02-01)
+2. Delays in awareness assessment for new participants identified
+   Action: Awareness assessment added as mandatory item to onboarding checklist (completed 2026-01-20)
+
+Next review scheduled: 2027-01-09
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.1.4 Program Scope](../../iso5230_guide/1-program-foundation/4-scope/)
+- Related guide: [Enterprise Open Source Management Guide — 2. Policy](../../../opensource_for_enterprise/2-policy/)
+- Related template: [Open Source Policy Template — §1.4 Scope](../../../templates/1-policy/)
diff --git a/content/en/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md b/content/en/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md
new file mode 100644
index 0000000000..31b74e0fc7
--- /dev/null
+++ b/content/en/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md
@@ -0,0 +1,177 @@
+---
+title: "§4.1.5 Standard Practice Implementation"
+weight: 50
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "standard practice", "vulnerability response"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.1.5 is a new clause exclusive to 18974 that does not exist in ISO/IEC 5230. It requires establishing documented procedures for each of the **8 standard handling methods** for open source vulnerabilities. This clause goes beyond a simple declaration of "responding" to vulnerabilities, requiring the formalization of the entire vulnerability lifecycle into procedures — from threat identification, detection, follow-up, customer notification, post-deployment monitoring, continuous security testing, risk verification, to information export. This clause, together with §4.3.2 Security Assurance, forms the core of ISO/IEC 18974.
+
+## 2. What to Do
+
+Establish documented procedures for each of the 8 methods:
+
+1. **Identification of structural and technical threats**: Define a method to identify threats affecting the supplied software.
+2. **Detection of known vulnerabilities**: Define a method to detect the existence of known vulnerabilities (CVEs) in open source components.
+3. **Follow-up on vulnerabilities**: Define a method to take follow-up actions such as patching, mitigation, or acceptance for identified vulnerabilities.
+4. **Customer notification**: Define a method to communicate identified vulnerabilities to customers, where applicable.
+5. **Post-deployment analysis for newly disclosed vulnerabilities**: Define a method to analyze already-deployed software for newly published CVEs.
+6. **Continuous security testing**: Define a method to apply continuous and iterative security testing to all supplied software before release.
+7. **Verification of risk resolution**: Define a method to verify that identified risks have been addressed before release.
+8. **Export of risk information**: Define a method to export risk information to third parties, where appropriate.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.1.5 | A program shall demonstrate defined and implemented processes for sound and robust handling of known vulnerabilities and security software development, specifically by defining and implementing the following 8 methods: threat identification / vulnerability detection / follow-up / customer notification / post-deployment newly disclosed vulnerability analysis / continuous security testing / risk resolution verification / risk information export | **4.1.5.1** A documented procedure exists for each of the methods identified above |
+
+> **§4.1.5 Standard Practice Implementation**
+> A program shall demonstrate defined and implemented processes for sound and
+> robust handling of known vulnerabilities and security software development,
+> specifically by defining and implementing the following:
+> - A method to identify structural and technical threats to the supplied
+>   software;
+> - A method to detect the existence of known vulnerabilities in the supplied
+>   software;
+> - A method to follow up on identified known vulnerabilities;
+> - A method to communicate identified known vulnerabilities to customers,
+>   where applicable;
+> - A method to analyze the supplied software for newly disclosed known
+>   vulnerabilities when they are published;
+> - A method to apply continuous and iterative security testing to all
+>   supplied software before release;
+> - A method to verify that identified risks have been addressed before
+>   release; and
+> - A method to export information about identified risks to third parties,
+>   where appropriate.
+>
+> **Verification Material(s):**
+> 4.1.5.1 A documented procedure exists for each of the methods identified
+> above.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.1.5.1 Documented Procedures for the 8 Vulnerability Handling Methods
+
+**How to Comply**
+
+A procedure explaining "how" each of the 8 methods is performed must be documented. These procedures together constitute Verification Material 4.1.5.1. You can create 8 separate documents, or organize all 8 as sections within a single integrated vulnerability management procedure document. The latter approach is recommended as it reduces management burden and is easier to maintain consistency.
+
+**Method 1 — Identification of Structural and Technical Threats**
+
+Define a method to identify structural (architecture design, dependency structure) and technical (known vulnerable patterns, risky components) threats that may affect the supplied software. Using threat modeling (STRIDE, PASTA, etc.) or periodically analyzing the dependency tree to identify risky components is a common approach.
+
+```
+[Threat Identification Procedure Overview]
+- Conduct threat modeling when designing a new software architecture.
+- Analyze the dependency tree quarterly to identify EOL (End-of-Life) components,
+  abandoned projects, and components with high dependency concentration.
+- Register identified threats in the Risk Registry and assign a responsible party.
+```
+
+**Method 2 — Detection of Known Vulnerabilities**
+
+Define a method to detect the existence of CVEs (Common Vulnerabilities and Exposures) in open source components based on the SBOM. Integrating automated tools (OSV-SCALIBR, Dependency-Track, Grype, etc.) into the CI/CD pipeline to scan for vulnerabilities at every build is an effective approach.
+
+```
+[Vulnerability Detection Procedure Overview]
+- Integrate SCA (Software Composition Analysis) tools into the CI/CD pipeline.
+- Automatically run SBOM-based vulnerability scans on every build.
+- Reference multiple vulnerability databases such as OSV (Open Source Vulnerabilities),
+  NVD (National Vulnerability Database), and GitHub Advisory Database.
+- Automatically notify the security team of detected vulnerabilities along with their severity.
+```
+
+**Method 3 — Follow-up on Vulnerabilities**
+
+Define a method to take follow-up actions on identified vulnerabilities, such as applying patches, implementing mitigations, replacing components, or accepting risk. Specify priority and remediation timelines based on CVSS scores in the procedure.
+
+```
+[Follow-up Procedure Overview]
+- Determine remediation priority and timelines based on CVSS score:
+  Critical (9.0+): within 7 days / High (7.0-8.9): within 30 days
+  Medium (4.0-6.9): within 90 days / Low (0.1-3.9): at next release
+- If no patch is available, implement mitigation measures (network isolation, WAF rule additions, etc.)
+  and risk acceptance decisions require joint approval from the security team and open source PM.
+- Record the remediation outcome in the vulnerability tracking system and verify completion.
+```
+
+**Method 4 — Customer Notification**
+
+Define a method to communicate vulnerabilities to customers when they are discovered in supplied software and may affect customers. Specify the notification criteria (severity, customer impact scope), notification channels, and notification timelines in the procedure.
+
+```
+[Customer Notification Procedure Overview]
+- Notify customers for Critical/High vulnerabilities that affect distributed products.
+- Notification channels: Product security notice (website), customer security contact email,
+  security advisory publication
+- Notification timeline: Within 7 days of confirming patch or mitigation measures
+- Notification content: Affected components, CVE ID, severity, recommended actions, patch delivery schedule
+```
+
+**Method 5 — Post-deployment Analysis for Newly Disclosed Vulnerabilities**
+
+Define a method to analyze whether newly published CVEs affect already-deployed software. A monitoring system is needed that retains the SBOM for deployed software and automatically cross-references newly published CVEs against those SBOMs.
+
+```
+[Post-deployment Newly Disclosed Vulnerability Analysis Procedure Overview]
+- Retain SBOMs for deployed software by version.
+- Use tools such as Dependency-Track to automatically cross-reference newly published CVEs
+  against deployed SBOMs and generate a list of affected software versions.
+- When affected versions are confirmed, process them according to Method 3 (follow-up)
+  and Method 4 (customer notification) procedures.
+- Monitoring is performed automatically at all times, with weekly summary reports
+  sent to the security team.
+```
+
+**Method 6 — Continuous Security Testing**
+
+Define a method to apply continuous and iterative security testing to all supplied software before release. Integrating SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and SCA into the CI/CD pipeline is the common approach.
+
+```
+[Continuous Security Testing Procedure Overview]
+- Security testing by CI/CD pipeline stage:
+  · On code commit: SAST (static analysis), SCA (open source vulnerability scan)
+  · On PR merge: Verify passage of security gate (blocking if Critical/High unresolved)
+  · On release candidate build: DAST (dynamic analysis), container image scan
+- Automatically block release on security test failure and notify the security team.
+- Continuously monitor test coverage and results on a dashboard.
+```
+
+**Method 7 — Verification of Risk Resolution**
+
+Define a method to verify that identified risks have actually been resolved before release. After applying a patch, confirm via rescan that the vulnerability has been eliminated and record the result.
+
+```
+[Risk Resolution Verification Procedure Overview]
+- Run a rescan using the same tool after patch or mitigation is complete.
+- Confirm that the vulnerability has been eliminated in the rescan result and record
+  it in the vulnerability tracking system.
+- For Critical/High vulnerabilities, the security team approves the verification result.
+- If releasing with unresolved risks, document management approval and a mitigation plan.
+```
+
+**Method 8 — Export of Risk Information**
+
+Define a method to export identified risk information to third parties (supply chain partners, customers, vulnerability databases, etc.) where appropriate. This includes using the VEX (Vulnerability Exploitability eXchange) format, or procedures for reporting vulnerability information to upstream projects through CVD channels.
+
+```
+[Risk Information Export Procedure Overview]
+- When a new vulnerability is independently discovered, report it to the upstream project
+  or CERT following CVD procedures.
+- Use VEX format when sharing vulnerability impact information with supply chain partners.
+- Before sharing with third parties, conduct a legal review to ensure no trade secrets
+  or undisclosed information are included.
+- Record and retain a log of information exports (recipient, date, content summary).
+```
+
+## 5. References
+
+- No corresponding ISO/IEC 5230 clause (new clause exclusive to 18974)
+- Related guide: [Enterprise Open Source Management Guide — 3. Process](../../../opensource_for_enterprise/3-process/)
+- Related tools: [OSV-SCALIBR](../../../tools/4-osvscalibr/), [Dependency-Track](../../../tools/7-dependency-track/)
diff --git a/content/en/guide/iso18974_guide/1-program-foundation/_index.md b/content/en/guide/iso18974_guide/1-program-foundation/_index.md
new file mode 100644
index 0000000000..04bee31553
--- /dev/null
+++ b/content/en/guide/iso18974_guide/1-program-foundation/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§4.1 Program Foundation"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974"]
+description: >
+---
diff --git a/content/en/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md b/content/en/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md
new file mode 100644
index 0000000000..054d249901
--- /dev/null
+++ b/content/en/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md
@@ -0,0 +1,116 @@
+---
+title: "§4.2.1 Access"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "external inquiry"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.2.1 has the same structure as ISO/IEC 5230 §3.2.1 (External Inquiry Response), but the focus shifts from **license compliance inquiries** to **vulnerability inquiries**. A publicly visible channel must be established for third parties to make inquiries about known or newly discovered vulnerabilities in the supplied software, and an internal procedure for systematically handling these inquiries must be documented. Since the security vulnerability reporting channel is connected to the Coordinated Vulnerability Disclosure (CVD) procedure, a system for safely receiving and processing vulnerabilities discovered by security researchers or customers is required.
+
+## 2. What to Do
+
+- Specify a public contact (email address, web form, etc.) on the product or website where third parties can send vulnerability-related inquiries.
+- Document the internal procedure for handling vulnerability reports received through the public channel.
+- Include the processing stages — receipt, triage, assignment, response, and closure — in the procedure.
+- Specify in the procedure a handling policy following CVD principles (confidential collaboration followed by public disclosure).
+- Record and retain inquiry receipt and response history for a designated period.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.2.1 | Maintain a process to effectively respond to external vulnerability inquiries. Publicly identify a means by which a third party can make an inquiry about known vulnerabilities or newly discovered vulnerabilities. | **4.2.1.1** Publicly visible method that allows any third party to make a known vulnerability or newly discovered vulnerability inquiry (e.g., via a published contact email address, or web portal monitored by Program Participants)<br>**4.2.1.2** An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries |
+
+> **§4.2.1 Access**
+> Maintain a process to effectively respond to external vulnerability
+> inquiries. Publicly identify a means by which a third party can make an
+> inquiry about known vulnerabilities or newly discovered vulnerabilities.
+>
+> **Verification Material(s):**
+> 4.2.1.1 Publicly visible method that allows any third party to make a known
+> vulnerability or newly discovered vulnerability inquiry (e.g., via a
+> published contact email address, or web portal that is monitored by
+> program participants).
+> 4.2.1.2 An internal documented procedure for responding to third party known
+> vulnerability or newly discovered vulnerability inquiries.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.2.1.1 Publicly Available Vulnerability Inquiry Channel
+
+**How to Comply**
+
+A public contact for third parties to report or inquire about vulnerabilities must be established and published externally. Publishing a security-dedicated email address (e.g., security@company.com) on product documentation, the website's security policy page, or in a `SECURITY.md` file (for GitHub or other open source repositories) is common practice. This public channel itself is Verification Material 4.2.1.1.
+
+This can be operated separately from the ISO/IEC 5230 §3.2.1.1 license inquiry channel, or configured by adding a channel dedicated to security vulnerability reporting.
+
+**Considerations**
+
+- **Separate security-dedicated channel**: Operating a license inquiry channel (oss@company.com) and a security vulnerability reporting channel (security@company.com) separately makes it easier to manage processing priorities.
+- **Guarantee of response**: State explicitly that the reporting channel is actively monitored (e.g., "acknowledgment response within 3 business days").
+- **Use the `security.txt` standard**: Applying the RFC 9116 `security.txt` standard makes it easy for security researchers to find contact information.
+
+**Sample**
+
+```
+[Website Security Policy Page / SECURITY.md Sample]
+
+## Security Vulnerability Reporting
+
+To report a security vulnerability in our software, please use the channel below.
+We follow Coordinated Vulnerability Disclosure (CVD) practices.
+
+- Reporting email: security@company.com
+- Acknowledgment: Within 3 business days
+- Handling policy: Vulnerabilities are reviewed confidentially and disclosed after patching
+```
+
+---
+
+### 4.2.1.2 Internal Vulnerability Inquiry Response Procedure
+
+**How to Comply**
+
+A procedure for internally handling vulnerability reports received from external parties must be documented. Following CVD principles, the basic framework involves collaborating confidentially with the reporter to resolve the vulnerability and then disclosing it after the patch is ready. This procedure document is Verification Material 4.2.1.2.
+
+**Considerations**
+
+- **Follow CVD principles**: Maintain confidentiality with the reporter until the vulnerability is resolved and agree on a disclosure schedule.
+- **Processing timelines**: Specify timelines for each stage — acknowledgment, vulnerability verification, patch delivery, and disclosure — in the procedure.
+- **Record retention**: Retain the report content, review process, response actions, and disclosure history for a minimum of 3 years.
+
+**Sample**
+
+```
+[External Vulnerability Report Response Procedure]
+
+1. Receipt and Acknowledgment (within 3 business days)
+   - Check the security@company.com inbox daily.
+   - Reply to the reporter with an acknowledgment and a promise of confidential handling.
+
+2. Vulnerability Verification (within 7 business days)
+   - The security team verifies the reproducibility and impact scope of the reported vulnerability.
+   - Calculate the CVSS score and classify the severity.
+
+3. Patch Development and Remediation (7–90 days depending on severity)
+   - Perform patching or mitigation according to the §4.1.5 Method 3 (follow-up) procedure.
+   - Share the patch schedule with the reporter and coordinate as needed.
+
+4. Disclosure (after patch is complete)
+   - Draft a Security Advisory, confirm with the reporter, and publish.
+   - Request CVE ID issuance if necessary.
+   - Notify affected customers according to the §4.1.5 Method 4 (customer notification) procedure.
+
+5. Record Retention
+   - Retain the report content, review process, remediation outcome, and disclosure history
+     for a minimum of 3 years.
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.2.1 External Inquiry Response](../../iso5230_guide/2-relevant-tasks/1-access/)
+- Related guide: [Enterprise Open Source Management Guide — 3. Process](../../../opensource_for_enterprise/3-process/)
diff --git a/content/en/guide/iso18974_guide/2-relevant-tasks/2-resourced/_index.md b/content/en/guide/iso18974_guide/2-relevant-tasks/2-resourced/_index.md
new file mode 100644
index 0000000000..7d098c2920
--- /dev/null
+++ b/content/en/guide/iso18974_guide/2-relevant-tasks/2-resourced/_index.md
@@ -0,0 +1,113 @@
+---
+title: "§4.2.2 Effectively Resourced"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "resources"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.2.2 corresponds to ISO/IEC 5230 §3.2.2 (Effectively Resourced) but has two key differences. First, while 5230 requires 5 Verification Materials, 18974 requires 4. The §3.2.2.5 item from 5230 (procedure for reviewing and correcting non-compliance cases) is absorbed into §4.1.5 Standard Practice Implementation in 18974. Second, §3.2.2.3 (method for accessing legal expertise) is replaced in §4.2.2.3 by **vulnerability resolution expertise**. Rather than legal expertise for license matters, the organization must secure technical and security expertise capable of actually resolving known vulnerabilities and document how that expertise is accessed.
+
+## 2. What to Do
+
+- Document the names or job titles of personnel assigned to each role in the program.
+- Confirm and record that sufficient time and budget are allocated to each role assignee.
+- **Identify and document the internal or external security expertise available to resolve known vulnerabilities** (different focus from 5230).
+- Document the procedure for assigning internal responsibility for security assurance compliance to each role.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.2.2 | Identify and resource program tasks: assign responsibilities per role and provide sufficient resources, secure access to vulnerability resolution expertise, and establish an internal responsibility assignment procedure. | **4.2.2.1** A document with the names of the persons, group or function in program role(s) identified<br>**4.2.2.2** The identified program roles have been properly staffed and adequate funding provided<br>**4.2.2.3** A document identifying the expertise available to address identified known vulnerabilities ★<br>**4.2.2.4** A documented procedure that assigns internal responsibilities for security assurance |
+
+★ = Different from ISO/IEC 5230 §3.2.2.3 (legal expertise) — focus shifted to security expertise
+
+> **§4.2.2 Effectively Resourced**
+> Identify and Resource Program Task(s):
+> - Assign accountability to ensure the successful execution of program tasks.
+> - Program tasks are sufficiently resourced.
+>
+> **Verification Material(s):**
+> 4.2.2.1 A document with the names of the persons, group or function in
+> program role(s) identified.
+> 4.2.2.2 The identified program roles have been properly staffed and adequate
+> funding provided.
+> 4.2.2.3 A document identifying the expertise available to address identified
+> known vulnerabilities.
+> 4.2.2.4 A documented procedure that assigns internal responsibilities for
+> security assurance.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.2.2.1 Document Identifying Role Assignees
+
+This is the same as ISO/IEC 5230 §3.2.2.1. Security assurance roles (DevSecOps engineer, vulnerability analysis personnel, etc.) must be specified. Refer to [§3.2.2.1 Document Identifying Role Assignees](../../iso5230_guide/2-relevant-tasks/2-resourced/) for how to prepare this.
+
+---
+
+### 4.2.2.2 Confirmation of Staffing and Budget Support
+
+This is the same as ISO/IEC 5230 §3.2.2.2. Security-related budget items such as vulnerability scanning tools, security training, and external security consulting should be included. Refer to [§3.2.2.2 Confirmation of Staffing and Budget Support](../../iso5230_guide/2-relevant-tasks/2-resourced/) for how to prepare this.
+
+---
+
+### 4.2.2.3 Document Identifying Vulnerability Resolution Expertise ★
+
+**How to Comply**
+
+The expertise available to actually analyze and resolve identified known vulnerabilities must be identified and documented. This differs in nature from the legal expertise access method in ISO/IEC 5230 §3.2.2.3. If an internal security team exists, record that team's competencies and contact information; if internal expertise is insufficient, document how external security experts or PSIRT (Product Security Incident Response Team) services are utilized.
+
+**Considerations**
+
+- **Internal expertise list**: Identify internal experts or responsible teams by vulnerability type (web security, firmware security, cryptography, etc.).
+- **Securing external expertise**: For vulnerability types that are difficult to handle internally, record contract details or contact methods with external security organizations (CERT, security consulting firms).
+- **Escalation criteria**: Specify the criteria under which external expertise is utilized.
+
+**Sample**
+
+```
+[Vulnerability Resolution Expertise Status]
+
+Internal expertise:
+- Security (Chul-su Kim): Web vulnerabilities, open source component CVE analysis, CVSS assessment
+- DevSecOps team: CI/CD security pipeline operation, container vulnerability analysis
+
+Criteria for utilizing external expertise:
+- When zero-day vulnerabilities, firmware vulnerabilities, or cryptography-related vulnerabilities occur
+- When the internal team determines that resolution within 30 days is not feasible
+
+External organizations:
+- [External Security Consulting Firm Name] (annual contract, vulnerability analysis service)
+- KrCERT/CC (vulnerability coordination and reporting channel)
+```
+
+---
+
+### 4.2.2.4 Internal Responsibility Assignment Procedure
+
+This has the same structure as ISO/IEC 5230 §3.2.2.4, but must include the assignment of security assurance-specific responsibilities (vulnerability detection, CVSS assessment, customer notification, CVD management, etc.) to each role. Refer to [§3.2.2.4 Internal Responsibility Assignment Procedure](../../iso5230_guide/2-relevant-tasks/2-resourced/) for preparation, and reflect security tasks as shown in the sample below.
+
+**Sample**
+
+```
+| Task | Open Source PM | Security | IT | Developer |
+|------|----------------|----------|----|-----------|
+| Vulnerability scan tool operation | I | C | A/R | I |
+| CVE detection and classification | I | A/R | C | I |
+| CVSS score assessment | I | A/R | - | C |
+| Patch application and verification | C | A | C | R |
+| Customer notification decision | A | R | - | I |
+| CVD external report response | C | A/R | - | I |
+| Vulnerability record management | I | A/R | C | I |
+
+R: Responsible / A: Accountable / C: Consulted / I: Informed
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.2.2 Effectively Resourced](../../iso5230_guide/2-relevant-tasks/2-resourced/)
+- Related guide: [Enterprise Open Source Management Guide — 1. Organization](../../../opensource_for_enterprise/1-teams/)
diff --git a/content/en/guide/iso18974_guide/2-relevant-tasks/_index.md b/content/en/guide/iso18974_guide/2-relevant-tasks/_index.md
new file mode 100644
index 0000000000..b0fba4331e
--- /dev/null
+++ b/content/en/guide/iso18974_guide/2-relevant-tasks/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§4.2 Relevant Tasks"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974"]
+description: >
+---
diff --git a/content/en/guide/iso18974_guide/3-content-review/1-sbom/_index.md b/content/en/guide/iso18974_guide/3-content-review/1-sbom/_index.md
new file mode 100644
index 0000000000..85937edc74
--- /dev/null
+++ b/content/en/guide/iso18974_guide/3-content-review/1-sbom/_index.md
@@ -0,0 +1,104 @@
+---
+title: "§4.3.1 SBOM"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "SBOM"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.3.1 has the same basic structure as ISO/IEC 5230 §3.3.1 (SBOM), but the emphasis differs. While 5230 covers the SBOM for license management of open source components, §4.3.1 of 18974 emphasizes **continuously recording and retaining the SBOM throughout the entire software lifecycle**. In particular, the SBOM must be maintained even after deployment so it can be integrated with the vulnerability monitoring in §4.3.2 Security Assurance. Without an SBOM, post-deployment impact analysis for newly published CVEs (§4.1.5 Method 5) cannot be performed.
+
+## 2. What to Do
+
+- Establish a procedure for identifying, tracking, reviewing, and approving open source components in the supplied software (same as 5230).
+- **Establish a procedure for continuously recording and retaining the SBOM throughout the software lifecycle** (emphasized in 18974).
+- Retain SBOMs by version for deployed software to use in post-deployment vulnerability impact analysis.
+- Integrate SBOM information with vulnerability management tools (such as Dependency-Track) so that automatic impact analysis occurs whenever new CVEs are published.
+- Define triggers for immediately updating the SBOM when components are added, changed, or removed.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.3.1 | A process shall exist to ensure all open source software used in the supplied software is continuously recorded throughout the lifecycle of the supplied software. | **4.3.1.1** A documented procedure to ensure that all open source software used in the supplied software is continuously recorded during the life cycle of the supplied software (including an archive of all open source software used in the supplied software)<br>**4.3.1.2** Open source software component records for the supplied software that demonstrate the documented procedure was followed |
+
+> **§4.3.1 Software Bill of Materials**
+> A process shall exist for creating and managing a software bill of materials
+> that includes each open source software component (and its identified
+> licenses) from which the supplied software is comprised, in a manner that
+> ensures the supplied software's open source software components are
+> continuously recorded throughout the supplied software's life cycle,
+> including archiving.
+>
+> **Verification Material(s):**
+> 4.3.1.1 A documented procedure to ensure that all open source software used
+> in the supplied software is continuously recorded during the life cycle of
+> the supplied software. This includes an archive of all open source software
+> used in the supplied software.
+> 4.3.1.2 Open source software component records for the supplied software
+> that demonstrates the documented procedure was followed.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.3.1.1 SBOM Lifecycle Continuous Recording Procedure
+
+**How to Comply**
+
+Building on the SBOM management procedure from ISO/IEC 5230 §3.3.1.1, the procedure must be strengthened to focus on **continuous lifecycle recording** and **archiving**. This procedure document is Verification Material 4.3.1.1.
+
+From a security assurance perspective, the key to SBOM management is that the SBOM must remain valid even after deployment so it can be immediately used for impact analysis whenever new CVEs are published. To this end, the procedure must include archiving the SBOMs of all deployed software versions and integrating with vulnerability management tools.
+
+**Considerations**
+
+- **Maintain SBOM at each lifecycle stage**: Define procedures to keep the SBOM current at each stage — development, build, deployment, and post-deployment monitoring.
+- **Archive policy**: Archive the SBOMs of all deployed versions by version and specify the retention period (minimum: support period of the relevant software + 3 years).
+- **Integration with vulnerability tools**: Import SBOMs into tools such as Dependency-Track so that automatic cross-referencing occurs every time new CVEs are published.
+- **Update triggers**: Mandate SBOM updates upon the following events: component addition, version upgrade, component removal, license change, and replacement due to newly discovered vulnerabilities.
+
+**Sample**
+
+The following is a sample overview of an SBOM management procedure enhanced from a security assurance perspective.
+
+```
+[SBOM Lifecycle Management Procedure Overview]
+
+(1) Development stage
+    - Register open source components in the SBOM immediately upon introduction.
+    - SCA tools (Syft, cdxgen, etc.) in the CI/CD pipeline automatically detect them.
+
+(2) Build stage
+    - Automatically generate the latest SBOM on every build (SPDX or CycloneDX format).
+    - Integrate with vulnerability scanning tools to record the vulnerability status at build time.
+
+(3) Deployment stage
+    - Finalize the SBOM for the release version and store it in the archive repository.
+    - Import the SBOM into Dependency-Track to activate continuous monitoring.
+
+(4) Post-deployment monitoring
+    - When new CVEs are published, automatically cross-reference against all archived version SBOMs.
+    - When affected versions are confirmed, process them according to the §4.1.5 Method 5 procedure.
+
+(5) Update triggers
+    - Update the SBOM immediately upon the following events:
+      · Component addition, version upgrade, component removal
+      · License change, replacement due to newly discovered vulnerability
+
+(6) Archive retention
+    - Retain SBOMs of all deployed versions by version.
+    - Retention period: Minimum 3 years after the official support end of the relevant software
+```
+
+---
+
+### 4.3.1.2 Open Source Component Records (SBOM)
+
+This is the same as ISO/IEC 5230 §3.3.1.2. From a security assurance perspective, recording the **known vulnerability status** of each component or a link to the vulnerability management tool alongside license information in the SBOM makes integration with §4.3.2 easier. Refer to [§3.3.1.2 Open Source Component Records](../../iso5230_guide/3-content-review/1-sbom/) for how to prepare this.
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.3.1 SBOM](../../iso5230_guide/3-content-review/1-sbom/)
+- Related guide: [Enterprise Open Source Management Guide — 3. Process](../../../opensource_for_enterprise/3-process/)
+- Related tools: [Syft](../../../tools/6-syft/), [cdxgen](../../../tools/5-cdxgen/), [Dependency-Track](../../../tools/7-dependency-track/)
diff --git a/content/en/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md b/content/en/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md
new file mode 100644
index 0000000000..01e0cf2576
--- /dev/null
+++ b/content/en/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md
@@ -0,0 +1,168 @@
+---
+title: "§4.3.2 Security Assurance"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "Security Assurance", "vulnerability", "CVE"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.3.2 is the core clause of ISO/IEC 18974 and is a new clause exclusive to 18974 that does not exist in ISO/IEC 5230. It requires establishing a procedure covering the entire process — **vulnerability detection → risk assessment → remediation decision → customer consent (where applicable) → remediation → post-deployment newly disclosed vulnerability response → continuous monitoring** — for each open source component in the SBOM, and maintaining implementation records. If §4.1.5 requires the existence of vulnerability handling methods, §4.3.2 requires that those methods have actually been applied to each component with records retained.
+
+## 2. What to Do
+
+- Detect the existence of known vulnerabilities in each open source component in the SBOM.
+- Assign a risk/impact score (CVSS) to each detected vulnerability.
+- Determine and document the necessary remediation or mitigation steps for each vulnerability.
+- Obtain customer consent above a pre-determined threshold, where applicable.
+- Perform appropriate actions based on the risk/impact score and record them.
+- Perform appropriate actions for newly disclosed vulnerabilities in already-deployed software.
+- Monitor and respond to vulnerability disclosures for the supplied software after its release.
+- Maintain detection and remediation results per vulnerability as component records.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.3.2 | A process shall exist to apply security assurance activities to each open source software component in the SBOM: known vulnerability detection / risk/impact score assignment / determination and documentation of remediation or mitigation steps / obtaining customer consent where applicable / performing actions based on risk score / addressing newly disclosed vulnerabilities / post-release monitoring and vulnerability disclosure response | **4.3.2.1** A documented procedure for handling detection and resolution of known vulnerabilities for the open source software components of the supplied software<br>**4.3.2.2** For each open source software component, a record is maintained of the identified known vulnerabilities and action taken (including a determination that no action was required) |
+
+> **§4.3.2 Security Assurance**
+> There shall exist a process to apply security assurance activities to each
+> open source software component that is to be included in the bill of
+> materials (SBOM):
+> - Applying a method to detect the existence of known vulnerabilities;
+> - Assign a risk/impact score to each identified known vulnerability;
+> - Determine and document the necessary remediation or mitigation steps for
+>   each detected and scored known vulnerability;
+> - Obtain customer approval above a pre-determined threshold, where
+>   applicable;
+> - Perform appropriate action based on risk/impact score;
+> - Perform appropriate action for newly disclosed known vulnerabilities in
+>   previously released supplied software;
+> - Ability to monitor and respond to vulnerability disclosures for the
+>   supplied software after its release.
+>
+> **Verification Material(s):**
+> 4.3.2.1 A documented procedure for handling detection and resolution of
+> known vulnerabilities for the open source software components of the
+> supplied software.
+> 4.3.2.2 For each open source software component, a record is maintained of
+> the identified known vulnerabilities and action taken (including a
+> determination that no action was required).
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.3.2.1 Vulnerability Detection and Resolution Procedure
+
+**How to Comply**
+
+A documented procedure covering the entire process from vulnerability detection to resolution for each open source component in the SBOM is Verification Material 4.3.2.1. This procedure is a concrete operational flow that integrates the individual methods defined in §4.1.5.
+
+The flowchart below illustrates the entire flow from CVE detection to remediation completion.
+
+```mermaid
+flowchart TD
+    A([SBOM Component]) --> B[Vulnerability Scan\nSCA Tool]
+    B --> C{CVE Detected?}
+    C -- No --> D[Record: No Detection\nAwait Periodic Rescan]
+    C -- Yes --> E[Calculate CVSS Score\nRisk/Impact Assessment]
+    E --> F{Severity Classification}
+    F -- Critical/High --> G[Immediate Response\n7–30 day deadline]
+    F -- Medium --> H[Planned Response\n90 day deadline]
+    F -- Low --> I[Address at Next Release]
+    G --> J{Customer Impact?}
+    H --> J
+    J -- Yes --> K[Customer Notification\n§4.1.5 Method 4]
+    J -- No --> L[Remediation Decision]
+    K --> L
+    L --> M{Patch Available?}
+    M -- Yes --> N[Apply Patch\nRescan Verification]
+    M -- No --> O[Mitigation Measures\nor Risk Acceptance]
+    N --> P[Record Remediation Result\n§4.3.2.2]
+    O --> P
+    P --> Q([Continuous Monitoring\n§4.1.5 Method 5])
+```
+
+**Detailed Steps**
+
+The following is a sample describing each step of the flowchart in procedure document form.
+
+```
+[Vulnerability Detection and Resolution Procedure]
+
+Step 1 — Vulnerability Detection
+- At CI/CD pipeline build, SCA tools (Dependency-Track, OSV-SCALIBR, etc.)
+  automatically scan for vulnerabilities based on the SBOM.
+- Reference multiple vulnerability DBs such as NVD, OSV, and GitHub Advisory Database.
+- Even after deployment, automatically cross-reference against archived SBOMs
+  when new CVEs are published.
+
+Step 2 — Risk/Impact Score Assessment
+- Calculate the CVSS v3.1 base score for each detected CVE.
+- Adjust the Environmental Score by considering the actual usage context of the
+  company's product (network exposure, privilege requirements, etc.).
+- Severity classification: Critical (9.0+) / High (7.0-8.9) / Medium (4.0-6.9) / Low (0.1-3.9)
+
+Step 3 — Remediation Decision and Documentation
+- Determine the remediation method based on severity and customer impact scope:
+  · Patch application: Upgrade to a newer version or apply a patch
+  · Mitigation: Network isolation, disabling functionality, etc. when no patch is available
+  · Risk acceptance: When the actual exploitability is low and mitigation is also unnecessary
+    (joint approval from security team + open source PM required)
+- Record the basis for the remediation decision in the vulnerability tracking system.
+
+Step 4 — Customer Consent (where applicable)
+- For Critical/High vulnerabilities affecting customer-distributed products:
+  · Proactively notify the customer's security contact of vulnerability information
+    and the response plan.
+  · Share the patch deployment schedule and mitigation methods.
+
+Step 5 — Remediation
+- Perform the determined remediation within the remediation deadline.
+- Run a rescan after patch application to confirm the vulnerability is eliminated.
+- Update the remediation completion result in the §4.3.2.2 record.
+
+Step 6 — Continuous Monitoring
+- Continuously monitor the vulnerability status of deployed software using tools
+  such as Dependency-Track.
+- When new CVEs are published, automatically or immediately re-execute steps 1–3.
+```
+
+---
+
+### 4.3.2.2 Vulnerability and Action Records
+
+**How to Comply**
+
+For each open source component in the SBOM, records of identified vulnerabilities and actions taken (including a determination that no action was required) must be maintained. These records are Verification Material 4.3.2.2. The phrase "including a determination that no action was required" is important — components where no vulnerability was detected must also record the fact that a scan was performed and the detection result.
+
+Records can be managed using various tools such as Dependency-Track, a Jira security issue tracker, or spreadsheets, and must be maintained in a form that can be produced immediately during an audit.
+
+**Considerations**
+
+- **Record per component**: Maintain individual records for each component in the SBOM.
+- **Record "no detection" as well**: Record the scan date and result even for components where no vulnerability was detected.
+- **Track remediation history**: Manage the history of vulnerability occurrence, remediation, and rescan for the same component in chronological order.
+- **Retention period**: Retain for the support period of the relevant software plus a minimum of 3 years.
+
+**Sample**
+
+The following is a sample per-component vulnerability and action record.
+
+```
+| Software | Version | Component | Component Version | CVE ID | CVSS | Severity | Action | Action Date | Assignee | Notes |
+|----------|---------|-----------|-------------------|--------|------|----------|--------|-------------|----------|-------|
+| MyProduct | v1.2.0 | openssl | 3.0.7 | CVE-2023-0286 | 7.4 | High | Upgraded to 3.0.8 | 2023-02-10 | Chul-su Kim | Rescan confirmed |
+| MyProduct | v1.2.0 | zlib | 1.2.11 | CVE-2022-37434 | 9.8 | Critical | Upgraded to 1.2.13 | 2022-10-15 | Chul-su Kim | Customer notified |
+| MyProduct | v1.2.0 | libpng | 1.6.37 | None | - | - | No action required | 2023-03-01 | Chul-su Kim | Periodic scan result |
+| FirmwareX | v2.3.0 | busybox | 1.35.0 | CVE-2022-28391 | 9.8 | Critical | Risk acceptance (network isolation mitigation) | 2022-11-20 | Chul-su Kim | No patch available, PM approval obtained |
+```
+
+## 5. References
+
+- No corresponding ISO/IEC 5230 clause (new clause exclusive to 18974)
+- Related guide: [Enterprise Open Source Management Guide — 3. Process](../../../opensource_for_enterprise/3-process/)
+- Related tools: [Dependency-Track](../../../tools/7-dependency-track/), [OSV-SCALIBR](../../../tools/4-osvscalibr/)
+- Related clauses: [§4.1.5 Standard Practice Implementation](../../../iso18974_guide/1-program-foundation/5-standard-practice/), [§4.3.1 SBOM](../1-sbom/)
diff --git a/content/en/guide/iso18974_guide/3-content-review/_index.md b/content/en/guide/iso18974_guide/3-content-review/_index.md
new file mode 100644
index 0000000000..b1e3f0a1b5
--- /dev/null
+++ b/content/en/guide/iso18974_guide/3-content-review/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§4.3 Content Review and Approval"
+weight: 30
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974"]
+description: >
+---
diff --git a/content/en/guide/iso18974_guide/4-conformance/1-completeness/_index.md b/content/en/guide/iso18974_guide/4-conformance/1-completeness/_index.md
new file mode 100644
index 0000000000..594ddde3fe
--- /dev/null
+++ b/content/en/guide/iso18974_guide/4-conformance/1-completeness/_index.md
@@ -0,0 +1,117 @@
+---
+title: "§4.4.1 Completeness"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "completeness"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.4.1 corresponds to ISO/IEC 5230 §3.6.1 (Conformance). A document must be prepared affirming that the program defined in §4.1.4 satisfies all requirements of ISO/IEC 18974. The structure is the same as 5230 §3.6.1, but the difference is that the subject of confirmation covers all 25 Verification Material items of 18974. When preparing for ISO/IEC 5230 and 18974 certification simultaneously, it is efficient to conduct an integrated review of the common items of both standards and then additionally confirm the 9 items exclusive to 18974 (marked with ★).
+
+## 2. What to Do
+
+- Conduct a self-assessment to verify that all Verification Materials (25 items) of all clauses from §4.1 to §4.3 are in place.
+- Prepare a document affirming that the program defined in §4.1.4 satisfies all requirements of ISO/IEC 18974 within the defined scope.
+- Record the reviewer, approver, and confirmation date in the confirmation document.
+- When simultaneously complying with ISO/IEC 5230 and 18974, use an integrated checklist to reduce duplicated review burden.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.4.1 | For a program to be deemed conformant with this specification, the organization shall affirm that the program satisfies all the requirements of this specification. | **4.4.1.1** Documented evidence affirming the program specified in §4.1.4 satisfies all the requirements of this specification |
+
+> **§4.4.1 Completeness**
+> In order for a program to be deemed conformant with this specification, the
+> organization shall affirm that the program satisfies the requirements
+> presented in this specification.
+>
+> **Verification Material(s):**
+> 4.4.1.1 Documented evidence affirming the program specified in §4.1.4
+> satisfies all the requirements of this specification.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.4.1.1 Specification Conformance Confirmation Document
+
+**How to Comply**
+
+A document affirming that the program defined in §4.1.4 satisfies all requirements of ISO/IEC 18974 within the defined scope must be prepared. This document is Verification Material 4.4.1.1. Use the checklist below to review all 25 Verification Material items and record the confirmation results.
+
+**ISO/IEC 18974 Conformance Self-Assessment Checklist**
+
+```
+§4.1 Program Foundation
+[ ] 4.1.1.1 Documented security assurance policy
+[ ] 4.1.1.2 Procedure for communicating policy awareness
+[ ] 4.1.2.1 List of roles and responsibilities
+[ ] 4.1.2.2 Document identifying competencies per role
+[ ] 4.1.2.3 List of participants and role mapping ★
+[ ] 4.1.2.4 Evidence of assessed competence
+[ ] 4.1.2.5 Evidence of periodic reviews and changes ★
+[ ] 4.1.2.6 Verification of alignment with internal best practices ★
+[ ] 4.1.3.1 Evidence of assessed awareness for participants
+[ ] 4.1.4.1 Written statement of program scope
+[ ] 4.1.4.2 Set of performance metrics ★
+[ ] 4.1.4.3 Evidence of continuous improvement ★
+[ ] 4.1.5.1 Documented procedures for 8 vulnerability handling methods ★
+
+§4.2 Relevant Tasks
+[ ] 4.2.1.1 Publicly available vulnerability inquiry channel
+[ ] 4.2.1.2 Internal vulnerability inquiry response procedure
+[ ] 4.2.2.1 Document identifying role assignees
+[ ] 4.2.2.2 Confirmation of staffing and budget
+[ ] 4.2.2.3 Document identifying vulnerability resolution expertise ★
+[ ] 4.2.2.4 Internal responsibility assignment procedure
+
+§4.3 Content Review and Approval
+[ ] 4.3.1.1 SBOM lifecycle continuous recording procedure
+[ ] 4.3.1.2 Open source component records (SBOM)
+[ ] 4.3.2.1 Vulnerability detection and resolution procedure ★
+[ ] 4.3.2.2 Vulnerability and action records ★
+
+§4.4 Conformance
+[ ] 4.4.1.1 Document affirming all requirements are satisfied
+[ ] 4.4.2.1 Document affirming requirements satisfied within past 18 months
+
+★ = Additional items compared to ISO/IEC 5230 (9 items)
+```
+
+**Considerations**
+
+- **Integrated review with 5230**: If ISO/IEC 5230 certification is held, reuse existing materials for the 16 common items and focus on the 9 items exclusive to 18974.
+- **Approval procedure**: Formalize the document through review by the Open Source Program Manager and approval by management.
+- **Specify specification version**: Specify ISO/IEC 18974:2023 (version 1.0) as the specification confirmed for conformance in the document.
+
+**Sample**
+
+```
+[ISO/IEC 18974 Specification Conformance Confirmation]
+
+Program name: [Company name] Open Source Security Assurance Program
+Scope: [Scope as defined in §4.1.4]
+Specification confirmed for conformance: ISO/IEC 18974:2023 (version 1.0)
+Confirmation date: YYYY-MM-DD
+
+This document affirms that the above program satisfies all requirements
+(25 Verification Material items) of ISO/IEC 18974:2023 from §4.1 through §4.4.
+
+Conformance confirmation summary:
+- §4.1 Program Foundation (5 clauses, 13 Verification Materials): Satisfied ✓
+- §4.2 Relevant Tasks (2 clauses, 6 Verification Materials): Satisfied ✓
+- §4.3 Content Review and Approval (2 clauses, 4 Verification Materials): Satisfied ✓
+- §4.4 Conformance (2 clauses, 2 Verification Materials): Satisfied ✓
+
+Reviewer: [Open Source Program Manager name]
+Approver: [Management or OSRB head name]
+Approval date: YYYY-MM-DD
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.6.1 Conformance](../../iso5230_guide/6-conformance/1-conformance/)
+- ISO/IEC 18974 self-certification: [https://certification.openchainproject.org/](https://certification.openchainproject.org/)
+- Full clause checklist: [ISO/IEC 18974 Conformance Guide](../../)
diff --git a/content/en/guide/iso18974_guide/4-conformance/2-duration/_index.md b/content/en/guide/iso18974_guide/4-conformance/2-duration/_index.md
new file mode 100644
index 0000000000..9ef6c5a6d3
--- /dev/null
+++ b/content/en/guide/iso18974_guide/4-conformance/2-duration/_index.md
@@ -0,0 +1,73 @@
+---
+title: "§4.4.2 Duration"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "Duration"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.4.2 has the same structure as ISO/IEC 5230 §3.6.2 (Duration). It requires organizations to maintain a document confirming that all requirements of the specification are met within the past 18 months of obtaining conformance. When a new version of the specification is published, conformance under the previous version is maintained for a grace period of 18 months, during which it is recommended to update to the latest version.
+
+## 2. What to Do
+
+- Record and manage the date on which conformance was obtained.
+- Within the past 18 months of obtaining conformance, re-confirm and document that all requirements of the specification are still met.
+- If a new version of ISO/IEC 18974 is published, update the program to meet the latest version and re-confirm within 18 months.
+- Conduct periodic internal audits to verify that all 25 verification material items remain continuously compliant.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §4.4.2 | A program that is conformant with this specification shall remain conformant even if the version of the specification it was conformant against is subsequently updated, for a period of 18 months after the new version of the specification is published. It is recommended that conformant programs be updated to be conformant with the latest version of the specification. | **4.4.2.1** A document affirming the program meets all the requirements of this version of the specification, within the past 18 months of obtaining conformance. |
+
+<details><summary>View original text</summary>
+
+> **§4.4.2 Duration**
+> A program that is conformant with this specification shall remain conformant
+> even if the version of the specification it was conformant against is
+> subsequently updated, for a period of 18 months after the new version of
+> the specification is published. It is recommended that conformant programs
+> be updated to be conformant with the latest version of the specification.
+>
+> **Verification Material(s):**
+> 4.4.2.1 A document affirming the program meets all the requirements of this
+> version of the specification, within the past 18 months of obtaining
+> conformance.
+
+</details>
+
+## 4. How to Comply with Each Verification Material
+
+### 4.4.2.1 Document Confirming All Requirements Met Within 18 Months
+
+**How to Comply**
+
+In the same manner as ISO/IEC 5230 §3.6.2.1, review and update the specification conformance document from §4.4.1.1 at least once a year. Each time it is updated, record the review date and reviewer to demonstrate that a review was conducted within the past 18 months.
+
+For organizations operating both ISO/IEC 5230 and 18974 simultaneously, consolidating the periodic re-confirmation schedules for both specifications into a single annual integrated audit improves management efficiency.
+
+**Sample**
+
+```
+[ISO/IEC 18974 Specification Conformance Periodic Re-confirmation Record]
+
+Initial Conformance Date: YYYY-MM-DD
+Specification Version Confirmed: ISO/IEC 18974:2023 (Version 1.0)
+
+| Re-confirmation Date | Result | Changes | Reviewer | Notes |
+|----------------------|--------|---------|----------|-------|
+| 2025-01-10 | Fully Met | Vulnerability resolution expertise document updated (§4.2.2.3) | John Doe | - |
+| 2026-01-08 | Fully Met | Performance metric targets raised (§4.1.4.2) | John Doe | - |
+
+Next re-confirmation scheduled: YYYY-MM-DD
+18-month validity deadline: YYYY-MM-DD
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.6.2 Duration](../../iso5230_guide/6-conformance/2-duration/)
+- Check latest OpenChain specification version: [https://www.openchainproject.org/security-assurance](https://www.openchainproject.org/security-assurance)
diff --git a/content/en/guide/iso18974_guide/4-conformance/_index.md b/content/en/guide/iso18974_guide/4-conformance/_index.md
new file mode 100644
index 0000000000..f186bcdf8b
--- /dev/null
+++ b/content/en/guide/iso18974_guide/4-conformance/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§4.4 Conformance"
+weight: 40
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974"]
+description: >
+---
diff --git a/content/en/guide/iso18974_guide/_index.md b/content/en/guide/iso18974_guide/_index.md
new file mode 100644
index 0000000000..703ac7f0a2
--- /dev/null
+++ b/content/en/guide/iso18974_guide/_index.md
@@ -0,0 +1,145 @@
+---
+title: "ISO/IEC 18974 Conformance Guide"
+linkTitle: "ISO/IEC 18974 Conformance Guide"
+weight: 30
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "Security Assurance", "OpenChain"]
+description: >
+  A conformance guide that explains the 25 Verification Material items of ISO/IEC 18974 clause by clause.
+---
+
+This guide explains each requirement clause of ISO/IEC 18974 (OpenChain Security Assurance) one by one. It describes what Verification Materials each clause requires, how to comply, and what sample documents can be used immediately.
+
+**Author : OpenChain Korea Work Group / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)**
+
+## Target Audience
+
+- Security managers and open source program managers at organizations establishing an open source security assurance framework for the first time
+- Engineers building open source vulnerability management processes in DevSecOps environments
+- Organization staff preparing to add ISO/IEC 18974 certification after obtaining ISO/IEC 5230 certification
+
+## Relationship with ISO/IEC 5230
+
+{{% alert title="ISO/IEC 18974 adds a security layer on top of ISO/IEC 5230" color="warning" %}}
+
+**ISO/IEC 5230 (License Compliance)** covers the foundational program for systematically managing open source license obligations.
+
+**ISO/IEC 18974 (Security Assurance)** adds a security layer of vulnerability detection, assessment, and response on top of that foundation. The two standards share core infrastructure such as policy, competence, and SBOM, and 18974 extends and deepens this from a security perspective.
+
+| Category | ISO/IEC 5230 | ISO/IEC 18974 |
+|------|-------------|--------------|
+| Purpose | License Compliance | Security Assurance |
+| Verification Materials | 24 items | 25 items |
+| Common Foundation Clauses | — | 16 (corresponding to 5230) |
+| 18974-Exclusive Clauses | — | 9 (security-specific) |
+| Key Additional Elements | — | Vulnerability detection, response, and CVD procedures |
+
+{{% /alert %}}
+
+{{% alert title="Recommended Certification Path" color="success" %}}
+Organizations preparing for open source security assurance certification for the first time are recommended to proceed in stages: **obtain ISO/IEC 5230 first, then add ISO/IEC 18974**. The policy, process, and SBOM infrastructure built for 5230 can be reused directly for 18974, minimizing additional cost and effort.
+
+For a detailed clause-by-clause comparison of the two standards, refer to the **[ISO/IEC 5230 vs 18974 Comparison](./compare/)** page.
+{{% /alert %}}
+
+## How to Use This Guide
+
+{{% alert title="Relationship with the Enterprise Open Source Management Guide" color="success" %}}
+
+The **[Enterprise Open Source Management Guide](../opensource_for_enterprise/)** explains practical implementation methods (policy, process, tools, and organization) for managing open source.
+
+**This guide (ISO/IEC 18974 Conformance Guide)** organizes what must be demonstrated for security assurance certification, clause by clause.
+
+| Guide | Focus | When to Use |
+|--------|------|-----------|
+| Enterprise Open Source Management Guide | Practical implementation (How to implement) | When building an open source management framework for the first time |
+| ISO/IEC 18974 Conformance Guide | Clause-level Verification Material criteria (What to prove) | When preparing for security assurance certification or conducting a self-assessment |
+
+{{% /alert %}}
+
+## Full Clause Checklist
+
+ISO/IEC 18974 consists of a total of **11 clauses and 25 Verification Material items**.
+Items marked with ★ are added or changed from a security perspective compared to ISO/IEC 5230.
+
+### §4.1 Program Foundation
+
+| Clause | Title | Verification Materials | Details |
+|------|------|:---:|------|
+| §4.1.1 | Policy | 2 items | [Go](./1-program-foundation/1-policy/) |
+| §4.1.2 | Competence ★ | 6 items | [Go](./1-program-foundation/2-competence/) |
+| §4.1.3 | Awareness | 1 item | [Go](./1-program-foundation/3-awareness/) |
+| §4.1.4 | Program Scope ★ | 3 items | [Go](./1-program-foundation/4-scope/) |
+| §4.1.5 | Standard Practice Implementation ★ | 1 item | [Go](./1-program-foundation/5-standard-practice/) |
+
+### §4.2 Relevant Tasks
+
+| Clause | Title | Verification Materials | Details |
+|------|------|:---:|------|
+| §4.2.1 | Access | 2 items | [Go](./2-relevant-tasks/1-access/) |
+| §4.2.2 | Effectively Resourced | 4 items | [Go](./2-relevant-tasks/2-resourced/) |
+
+### §4.3 Content Review and Approval
+
+| Clause | Title | Verification Materials | Details |
+|------|------|:---:|------|
+| §4.3.1 | SBOM | 2 items | [Go](./3-content-review/1-sbom/) |
+| §4.3.2 | Security Assurance ★ | 2 items | [Go](./3-content-review/2-security-assurance/) |
+
+### §4.4 Conformance
+
+| Clause | Title | Verification Materials | Details |
+|------|------|:---:|------|
+| §4.4.1 | Completeness | 1 item | [Go](./4-conformance/1-completeness/) |
+| §4.4.2 | Duration | 1 item | [Go](./4-conformance/2-duration/) |
+
+**Total: 11 clauses / 25 Verification Material items**
+
+{{% pageinfo %}}
+
+★ **Summary of 18974 Additional Items Compared to ISO/IEC 5230**
+
+| Clause | Added Content | Number of Added Items |
+|------|-----------|:-----------:|
+| §4.1.2 Competence | List of participants (4.1.2.3), evidence of periodic review (4.1.2.5), alignment with internal best practices (4.1.2.6) | +3 items |
+| §4.1.4 Program Scope | Performance metrics (4.1.4.2), evidence of continuous improvement (4.1.4.3) | +2 items |
+| §4.1.5 Standard Practice Implementation | Documented procedures for all 8 vulnerability handling methods (4.1.5.1) | New clause |
+| §4.3.2 Security Assurance | Vulnerability detection and resolution procedure (4.3.2.1), vulnerability and action records (4.3.2.2) | New clause |
+
+{{% /pageinfo %}}
+
+## ISO/IEC 18974 Certification Process
+
+There are three ways to officially have ISO/IEC 18974 conformance recognized.
+
+{{% pageinfo %}}
+
+**Step 1. Self-Certification**
+
+Complete the online checklist provided by the OpenChain Project to self-declare conformance. There is no cost and you can start immediately.
+
+- Checklist: [https://certification.openchainproject.org/](https://certification.openchainproject.org/)
+- Suitable for: Organizations preparing for certification for the first time or for internal review purposes
+
+---
+
+**Step 2. Independent Assessment**
+
+An external expert or consulting organization evaluates the security assurance program. This is used to demonstrate the level of conformance to supply chain partners.
+
+- Partner list: [Open Compliance Directory](https://www.openchainproject.org/find-a-partner)
+
+---
+
+**Step 3. Third-party Certification**
+
+A certification body approved by OpenChain conducts an audit and issues an official certificate. This is suitable for meeting global supply chain requirements.
+
+- Approved certification bodies (as of 2024): ORCRO, PwC, TÜV SÜD, Synopsys, Bureau Veritas
+
+{{% /pageinfo %}}
+
+{{% alert title="Phased Approach Recommended" color="success" %}}
+Organizations that have already obtained ISO/IEC 5230 can efficiently prepare for 18974 certification by leveraging their existing infrastructure (policy, competence, SBOM) and adding the security assurance-specific items (§4.1.5, §4.3.2).
+{{% /alert %}}
diff --git a/content/en/guide/iso18974_guide/compare/_index.md b/content/en/guide/iso18974_guide/compare/_index.md
new file mode 100644
index 0000000000..00babc340f
--- /dev/null
+++ b/content/en/guide/iso18974_guide/compare/_index.md
@@ -0,0 +1,76 @@
+---
+title: "ISO/IEC 5230 vs 18974 Comparison"
+weight: 50
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "ISO/IEC 18974", "comparison"]
+description: >
+---
+
+## 1. Relationship Between the Two Standards
+
+ISO/IEC 5230 and ISO/IEC 18974 are both international open source standards led by the OpenChain Project, but they address different problems. 5230 covers open source license compliance (fulfillment of copyright obligations, SBOM management, and distribution of Compliance Artifacts), while 18974 covers open source security assurance (vulnerability detection, assessment, response, and CVD). The two standards do not have a complete superset/subset relationship. They share 9 common clauses covering policy, competence, SBOM, and similar areas, but each has its own exclusive clauses — 5230 has clauses for license compliance, artifacts, and contributions, while 18974 has clauses for Standard Practice Implementation and Security Assurance.
+
+Complying with both standards simultaneously allows license obligation fulfillment and security vulnerability management to be operated as a single integrated open source program. Common foundational documents (policy, competence records, SBOM procedures) can be written once and used for both standards simultaneously, so the practical additional work required to prepare for 18974 after obtaining 5230 certification is approximately 30–40% of the total.
+
+---
+
+## 2. Clause-by-Clause Comparison Table
+
+| ISO/IEC 5230 Clause | Title | ISO/IEC 18974 Clause | Differences |
+|---|---|---|---|
+| §3.1.1 | Policy | §4.1.1 | Added requirement for a periodic review process for the policy and its communication method |
+| §3.1.2 | Competence | §4.1.2 | 3 additional Verification Materials (list of participants, evidence of periodic review, alignment with internal best practices) |
+| §3.1.3 | Awareness | §4.1.3 | Added awareness items from a security assurance perspective; same number of Verification Materials |
+| §3.1.4 | Program Scope | §4.1.4 | 2 additional Verification Materials (performance metrics, evidence of continuous improvement) |
+| — | — | §4.1.5 | Standard Practice Implementation (new in 18974 — documentation of 8 vulnerability handling methods) |
+| §3.2.1 | External Inquiry Response | §4.2.1 | Focus shifted from license inquiries to vulnerability inquiries |
+| §3.2.2 | Effectively Resourced | §4.2.2 | Legal expertise replaced by vulnerability resolution expertise; Verification Materials reduced from 5 to 4 |
+| §3.3.1 | SBOM | §4.3.1 | Emphasis on continuous lifecycle recording and integration with vulnerability monitoring |
+| §3.3.2 | License Compliance | — | 5230 exclusive (not in 18974) |
+| §3.4.1 | Compliance Artifacts | — | 5230 exclusive (not in 18974) |
+| §3.5.1 | Contribution | — | 5230 exclusive (not in 18974) |
+| — | — | §4.3.2 | Security Assurance (new in 18974 — full lifecycle of CVE detection, assessment, remediation, notification, and monitoring) |
+| §3.6.1 | Conformance | §4.4.1 | Name changed to Completeness only; content is the same |
+| §3.6.2 | Duration | §4.4.2 | Same |
+
+**Summary**
+
+- **Common clauses**: 9 (16 Verification Materials)
+- **5230-exclusive clauses**: §3.3.2, §3.4.1, §3.5.1 (6 Verification Materials)
+- **18974-exclusive clauses**: §4.1.5, §4.3.2 (3 Verification Materials)
+- **Common clauses expanded in 18974**: 4 — §4.1.1, §4.1.2, §4.1.4, §4.2.2 (+6 Verification Materials)
+
+---
+
+## 3. Verification Material Count Comparison
+
+| Category | ISO/IEC 5230 | ISO/IEC 18974 |
+|------|-------------|--------------|
+| Total Verification Materials | 24 | 25 |
+| Exclusive clause (Verification Materials) | §3.3.2, §3.4.1, §3.5.1 (6 items) | §4.1.5, §4.3.2 (3 items) |
+| Additional Verification Materials within common clauses | — | +6 items (expanded common clauses) |
+| Common Verification Materials | 18 | 16 (including those with changed scope) |
+
+---
+
+## 4. Strategy for Simultaneous Conformance with Both Standards
+
+The most efficient path is to obtain 5230 first and then prepare for 18974 as an addition. The policy documents, competence records, and SBOM procedures built during the 5230 certification process can be directly used for 18974's common clauses (§4.1.1–§4.1.4, §4.2.1, §4.2.2, §4.3.1, §4.4.1, §4.4.2). What needs to be separately prepared are additions to existing documents and 2 new clauses exclusive to 18974.
+
+The items that need to be newly prepared exclusively for 18974 are as follows:
+
+- **§4.1.5 Standard Practice Implementation**: Documented procedures for each of the 8 vulnerability handling methods (threat identification, detection, follow-up, customer notification, post-deployment analysis, security testing, risk verification, and information export)
+- **§4.3.2 Security Assurance**: Full process from CVE detection → risk assessment → remediation decision → execution → monitoring, and per-component vulnerability action records
+- **Supplementing common clauses**: Additional preparation of §4.1.2 list of participants (4.1.2.3), evidence of periodic review (4.1.2.5), alignment with best practices (4.1.2.6), §4.1.4 performance metrics (4.1.4.2), and evidence of continuous improvement (4.1.4.3)
+
+The practical workload for an organization with a 5230 framework to additionally prepare for 18974 is estimated to be approximately 30–40% of the total 5230 preparation work.
+
+---
+
+## 5. Reference Links
+
+- [ISO/IEC 5230 Conformance Guide](../../iso5230_guide/)
+- [ISO/IEC 18974 Conformance Guide](../)
+- [Enterprise Open Source Management Guide](../../../opensource_for_enterprise/)
+- [OpenChain Self-Certification](https://certification.openchainproject.org/)
diff --git a/content/en/guide/iso5230_guide/1-program-foundation/1-policy/_index.md b/content/en/guide/iso5230_guide/1-program-foundation/1-policy/_index.md
new file mode 100644
index 0000000000..186b4ac3af
--- /dev/null
+++ b/content/en/guide/iso5230_guide/1-program-foundation/1-policy/_index.md
@@ -0,0 +1,170 @@
+---
+title: "§3.1.1 Policy"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Policy"]
+description: >
+---
+
+## 1. Clause Overview
+
+A company without an Open Source Policy risks distributing software while developers are unaware of their
+open source license obligations. This can lead to serious legal and business risks, such as copyright
+infringement lawsuits, mandatory source code disclosure, and termination of business contracts. §3.1.1
+requires organizations to establish a documented policy governing open source license compliance for
+supplied software and to communicate it so that all Program Participants within the organization are
+aware of the policy's existence. This clause forms the foundation of the entire ISO/IEC 5230 program;
+all subsequent clauses (competence, processes, artifacts, etc.) operate on top of this policy.
+
+## 2. What to Do
+
+- Write and formalize a policy document governing open source license compliance.
+- Clearly define the scope of the policy (supplied software, contribution activities, internal releases, etc.).
+- Include principles for open source use, contribution, distribution, SBOM management, and security vulnerability response in the policy.
+- Establish and document a procedure for communicating the policy to Program Participants (developers, legal, IT, security, etc.).
+- Retain records (training completion records, notification history, etc.) that demonstrate the communication took place.
+- Include a procedure in the policy for periodically reviewing it and re-communicating it upon changes.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.1.1 | A written open source policy shall exist that governs open source license compliance of the supplied software. The policy shall be internally communicated. | **3.1.1.1** A documented open source policy.<br>**3.1.1.2** A documented procedure that makes Program Participants aware of the existence of the open source policy (e.g., via training, internal wiki, or other practical communication method). |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.1.1.1 Documented Open Source Policy
+
+**How to Comply**
+
+An Open Source Policy is an official document containing the principles and procedures for a company to
+use open source software safely and effectively. The policy document must include key items such as purpose,
+scope, roles and responsibilities, principles for open source use, contribution, and distribution, SBOM
+management, security vulnerability response, and training and review cycles. Since this document itself
+constitutes Verification Material 3.1.1.1, it must be managed as an official document with version and
+approval history recorded.
+
+When establishing the policy, the company's business environment and software supply chain characteristics
+must be reflected. For example, product companies and service companies that distribute software externally
+may differ in the scope of their obligation to generate Compliance Artifacts, so the scope must be clearly
+defined. The policy should go through a review by the legal team or OSRB (Open Source Review Board) and
+be approved by senior management or an authorized department head.
+
+A policy is not a document that is established once and left alone. It should be reviewed at least once a
+year to reflect changes in ISO/IEC 5230 requirements, the emergence of new license types, and legal
+environment changes, with the change history recorded in the document.
+
+**Considerations**
+
+- **Items to include**: Include all of the following in the policy: open source use, external contributions,
+  internal project releases, SBOM management, and security vulnerability response principles.
+- **Scope definition**: Clearly distinguish the scope to which the policy applies, such as externally
+  distributed software, internally used software, and contribution activities.
+- **Approval process**: Final approval by OSRB or the head of the legal team or above, with the approval
+  date and approver recorded in the document.
+- **Version control**: Maintain document version numbers and change history so that previous versions can
+  be compared during audits.
+- **Periodic review**: Review the policy at least once a year, recording the completion date and reviewer.
+
+**Sample**
+
+The following is a sample of the Purpose and Scope section of an Open Source Policy document. This text
+itself becomes a key component of Verification Material 3.1.1.1 (documented open source policy).
+
+```
+## 1. Purpose and Scope
+
+### 1.1 Purpose
+
+This policy provides the principles and procedures for the company to use open source software
+safely and effectively. The main purposes of the policy are as follows:
+
+1. Open Source License Compliance:
+   Comply with the license obligations of open source components included in supplied software
+   and meet related legal requirements.
+2. Open Source Security Assurance:
+   Identify security vulnerabilities in open source components included in supplied software and
+   minimize security risks through appropriate response measures.
+
+These principles are designed to meet the requirements of ISO/IEC 5230 (Open Source License Compliance)
+and ISO/IEC 18974 (Open Source Security Assurance).
+
+### 1.4 Scope
+
+This policy applies to all software projects developed, distributed, or used by the company.
+
+- All supplied software provided or distributed externally.
+- Activities contributing to external open source projects.
+- Activities releasing internal projects as open source.
+
+However, open source used solely for internal purposes may have the applicability of this policy
+determined through a separate review procedure.
+
+The scope of the policy is periodically reviewed and updated in accordance with changes in the
+company's business environment.
+```
+
+---
+
+### 3.1.1.2 Documented Procedure for Policy Awareness
+
+**How to Comply**
+
+Writing a policy document alone is not sufficient. A procedure for communicating the policy must be
+established and documented so that Program Participants (all employees involved in developing, distributing,
+or contributing to software) can actually become aware of the policy's existence. The communication
+procedure document must specifically state through which channels, when, and to whom the policy is
+communicated. This communication procedure document itself is Verification Material 3.1.1.2.
+
+It is effective to combine multiple channels for communication. For new employees, include an open source
+policy briefing in the onboarding process. For existing employees, use internal wiki posts and email
+announcements. The procedure should also include a step for immediately notifying changes when the policy
+is updated. To prove that communication took place, retain evidence such as notification sending history,
+training completion records, and policy acknowledgment signatures for at least 3 years.
+
+**Considerations**
+
+- **Use multiple channels**: Use two or more channels such as internal wiki, email announcements, and
+  onboarding training to increase the effectiveness of communication.
+- **New hires**: Include an open source policy briefing as a mandatory item in the onboarding process.
+- **Policy updates**: Establish a separate procedure for immediately notifying Program Participants of
+  changes when the policy is updated.
+- **Evidence retention**: Retain notification history, training completion certificates, and policy
+  acknowledgment signatures for at least 3 years.
+- **Accessibility**: Post the policy document on the internal portal or wiki at all times so that
+  participants can check it at any time.
+
+**Sample**
+
+The following is a sample policy communication notification email. Retaining the sending history can
+serve as evidence for Verification Material 3.1.1.2.
+
+```
+Subject: [Open Source] Open Source Policy Notice and Acknowledgment Request
+
+To: All development/distribution-related employees
+From: Open Source Program Manager
+
+Hello,
+
+The company's open source policy has been established (or revised).
+All employees involved in using, contributing to, or distributing open source software are
+requested to review and familiarize themselves with the policy document at the link below.
+
+- Policy document: [Internal portal link]
+- Key contents: Open source use principles, license compliance procedures,
+               SBOM management, security vulnerability response principles
+- Policy version: v1.0 (Effective date: YYYY-MM-DD)
+
+For inquiries about the policy content, please contact the Open Source Program Manager
+(oss@company.com).
+
+Thank you.
+Open Source Program Manager
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 2. Policy](../../../opensource_for_enterprise/2-policy/)
+- Related template: [Open Source Policy Template](../../../templates/1-policy/)
diff --git a/content/en/guide/iso5230_guide/1-program-foundation/2-competence/_index.md b/content/en/guide/iso5230_guide/1-program-foundation/2-competence/_index.md
new file mode 100644
index 0000000000..97f0f6f45e
--- /dev/null
+++ b/content/en/guide/iso5230_guide/1-program-foundation/2-competence/_index.md
@@ -0,0 +1,176 @@
+---
+title: "§3.1.2 Competence"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Competence"]
+description: >
+---
+
+## 1. Clause Overview
+
+For an open source program to actually function, the people assigned to relevant roles must have the
+competence to perform those roles. If roles and responsibilities are only written in documents and the
+people responsible have no basic knowledge of open source license or security vulnerability management,
+the policies and processes will be nominal. §3.1.2 requires the organization to identify the roles
+involved in the program, define the competence required for each role, evaluate and record whether
+participants actually possess that competence. This clause advances the role structure defined in §3.1.1
+Policy into a concrete competence framework.
+
+## 2. What to Do
+
+- Create a list of roles that affect the performance of the open source program and the responsibilities of each role.
+- Specifically define and document the competence (knowledge, skills, experience) required to perform each role.
+- Evaluate whether each Program Participant has the competence required for their role.
+- Where competence is insufficient, take measures such as training, mentoring, etc. to acquire the necessary competence.
+- Document and retain competence assessment results and subsequent action history.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.1.2 | The organization shall: <br>- Identify the roles and responsibilities that impact the performance and effectiveness of the program; <br>- Determine the necessary competence of Program Participants fulfilling each role; <br>- Ensure that Program Participants are competent on the basis of appropriate education, training, and/or experience; <br>- Where applicable, take actions to acquire the necessary competence; <br>- Retain appropriate documented information as evidence of competence. | **3.1.2.1** A documented list of roles with corresponding responsibilities for the different participants in the program.<br>**3.1.2.2** A document that identifies the competencies for each role.<br>**3.1.2.3** Documented evidence of assessed competence for each Program Participant. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.1.2.1 Documented List of Roles and Responsibilities
+
+**How to Comply**
+
+A document listing all roles involved in the program and clearly defining the responsibilities of each
+role must be created. Generally, the Open Source Program Manager, legal counsel, IT staff, security
+staff, developer culture staff, and business units are the key roles. Depending on the company size or
+organizational structure, it is also possible to have people hold multiple roles concurrently or operate
+as a virtual organization in the form of an OSRB (Open Source Review Board).
+
+When defining roles, listing specific responsibility items rather than abstract descriptions is more
+advantageous for proving during audits. For example, instead of "open source management," describe it
+clearly as "oversight of license review and SBOM generation for open source components used in supplied
+software." This document can be included in the Open Source Policy document (§3.1.1.1) under the roles
+and responsibilities section, or managed as a separate appendix.
+
+**Considerations**
+
+- **Role identification scope**: Include roles from all organizations involved in the software supply chain,
+  such as development, legal, IT, security, and procurement, and also review outsourced development and
+  vendor management roles.
+- **Responsibility specificity**: Describe responsibilities for each role in terms of specific activities,
+  not abstract descriptions.
+- **Concurrent roles**: When one person holds multiple roles concurrently, clearly note this in the document.
+- **Update cycle**: Immediately update the document and version when organizational changes or personnel
+  transfers occur.
+
+**Sample**
+
+The following is a sample roles and responsibilities list from an Open Source Policy Appendix.
+The full form can be found in [Open Source Policy Template Appendix 1](../../../templates/1-policy/appendix/).
+
+```
+| Role | Responsibilities |
+|------|-----------------|
+| Open Source Program Manager | Overall management of the company's open source program / SBOM generation oversight /
+                                External inquiry response / Internal best practice management |
+| Legal Counsel | Interpretation and review of open source license obligations /
+                 License compatibility review / Legal risk assessment and advisory |
+| IT Staff | Operation of open source analysis tools and CI/CD pipeline integration /
+             Support for SBOM generation automation |
+| Security Staff | Response to known and newly discovered vulnerabilities /
+                  DevSecOps environment integration and security measures |
+| Developer Culture Staff | Encouraging open source community participation / Training program operation |
+| Business Unit | Compliance with open source policy and processes / Open source identification and reporting |
+```
+
+---
+
+### 3.1.2.2 Document Identifying Competencies for Each Role
+
+**How to Comply**
+
+The knowledge, skills, and experience required to perform each role must be specifically defined and
+documented. The competence definition should be written to a level where a person newly assigned to that
+role can clearly understand "what I need to know." Instead of writing vaguely like "open source knowledge
+required," describe it specifically, such as "understanding of the obligations and compatibility of major
+open source licenses (MIT, Apache-2.0, GPL-2.0, etc.)."
+
+Breaking down competence levels into categories like "basic understanding," "practical application," and
+"expert" makes the evaluation criteria clearer and makes it easier to establish training plans. This
+document can be included in the Open Source Policy document or managed as a separate competence definition
+document, and should be reviewed periodically to reflect changes in the technical environment.
+
+**Considerations**
+
+- **Specificity**: Describe competence items at a measurable level so they can be used as evaluation criteria.
+- **Competence level distinction**: Defining levels such as "Basic Understanding / Practical Application /
+  Expert" facilitates evaluation and training design.
+- **Update cycle**: Update competence items when new tools, licenses, or security technologies emerge.
+- **Training linkage**: Design role-specific training curricula based on the defined competencies.
+
+**Sample**
+
+The following is a sample competence definition table by role.
+
+```
+| Role | Required Competence |
+|------|---------------------|
+| Open Source Program Manager | Understanding of major open source license obligations and compatibility /
+                                Understanding of software development processes /
+                                SBOM generation and management knowledge / Communication skills |
+| Legal Counsel | Specialized knowledge of software copyright law /
+                 Ability to interpret open source licenses / Legal risk assessment ability |
+| IT Staff | Operation of open source analysis tools (FOSSology, ORT, Syft, etc.) /
+             Understanding of CI/CD pipelines / IT infrastructure expertise |
+| Security Staff | Understanding of DevSecOps / Operation of vulnerability analysis tools /
+                  CVSS score interpretation and risk assessment ability |
+| Developer Culture Staff | Understanding of open source policy / Training design ability /
+                           Open source community participation experience |
+| Business Unit | Basic knowledge of open source compliance /
+                 Basic understanding of open source licenses / Understanding of open source policy |
+```
+
+---
+
+### 3.1.2.3 Documented Evidence of Assessed Competence
+
+**How to Comply**
+
+Each Program Participant must be evaluated to confirm they actually possess the defined competencies,
+and the results must be documented and retained. Evaluation methods can combine a variety of approaches
+such as online training completion confirmation, verification of certification possession, written or
+practical exams, review of job performance records, and interviews. The important thing is that the
+evaluation results must remain as records. These records themselves are Verification Material 3.1.2.3.
+
+If insufficient competence is found from evaluation results, take remedial measures such as training,
+external consulting, or mentoring, and retain completion records as well. Evaluations should be conducted
+regularly at least once a year, and new assignees should be immediately evaluated upon role assignment.
+Evaluation records should be stored in the internal Learning Management System (LMS) or document system
+and maintained in a state where they can be submitted immediately during audits.
+
+**Considerations**
+
+- **Diverse evaluation methods**: Comprehensively evaluate competence by combining multiple methods such
+  as online training completion, exams, and on-the-job performance.
+- **Regular evaluation cycle**: Conduct at least once a year, and immediately perform a new evaluation
+  when an assignee changes.
+- **Remediation of insufficient competence**: Establish a training plan for items found insufficient in
+  evaluation results, and conduct re-evaluation after completion.
+- **Record retention period**: Retain evaluation records at least for the duration of the assignee's
+  tenure, and maintain them for a certain period after departure for audit purposes.
+
+**Sample**
+
+The following is a sample competence evaluation record form. It is written by role and stored in the
+LMS or document system.
+
+```
+| Name | Role | Evaluation Item | Evaluation Method | Result | Evaluation Date | Notes |
+|------|------|-----------------|-------------------|--------|-----------------|-------|
+| Gil-dong Hong | Open Source Program Manager | Understanding of license obligations | Online training completion | Completed (95 points) | 2026-01-15 | - |
+| Gil-dong Hong | Open Source Program Manager | SBOM management knowledge | Practical evaluation | Completed | 2026-01-15 | - |
+| Chul-su Kim | Security Staff | Understanding of DevSecOps | External training completion | Completed | 2026-02-03 | Certificate retained |
+| Young-hee Lee | Legal Counsel | Open source license interpretation | Interview evaluation | Completed | 2026-01-20 | - |
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 1. Organization](../../../opensource_for_enterprise/1-teams/)
+- Related template: [Open Source Policy Template — Appendix 1. Personnel Status](../../../templates/1-policy/appendix/)
diff --git a/content/en/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md b/content/en/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md
new file mode 100644
index 0000000000..6cb715c2e9
--- /dev/null
+++ b/content/en/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md
@@ -0,0 +1,102 @@
+---
+title: "§3.1.3 Awareness"
+weight: 30
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Awareness"]
+description: >
+---
+
+## 1. Clause Overview
+
+Even participants with the right roles and competencies will only participate in a perfunctory manner
+if they do not understand the purpose of the open source program and the meaning of their own contribution
+to the overall compliance framework. §3.1.3 requires the organization to evaluate and record that Program
+Participants actually understand the program's objectives, how they contribute, and the consequences of
+failing to follow the program's requirements. This clause is the next step after §3.1.2 Competence
+(possessing knowledge and skills), forming the practical motivation by connecting the competence
+participants hold to the program's purpose.
+
+## 2. What to Do
+
+- Verify that Program Participants understand the objectives of the open source program (license compliance,
+  Security Assurance, etc.).
+- Evaluate whether each participant is aware of how their role contributes to the overall program operation.
+- Verify that participants are aware of the legal and business impacts that may arise from failing to comply
+  with the program's requirements.
+- Conduct awareness assessments periodically and document and retain the results.
+- For participants with insufficient awareness, provide additional training and retain re-evaluation results.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.1.3 | The organization shall ensure that the Program Participants are aware of: the existence and location of the open source policy / relevant open source objectives / their contribution to the effectiveness of the program / the implications of not following the program's requirements. | **3.1.3.1** Documented evidence of assessed awareness for the Program Participants — which should include the program's objectives, contributions within the program, and implications of failing to follow the program's requirements. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.1.3.1 Documented Evidence of Assessed Awareness
+
+**How to Comply**
+
+Program Participants must be evaluated on three key areas of awareness, and the results must be recorded.
+The three key areas are: (1) the program's objectives (open source license compliance and Security
+Assurance), (2) how one's role contributes to the program, and (3) the legal and business impacts of
+not following the program.
+
+Evaluation methods can be combined in various ways such as online quizzes, offline surveys, training
+completion confirmation, and interviews. The important thing is that the evaluation results must remain
+as documents. These records are Verification Material 3.1.3.1. Evaluations should be conducted regularly
+at least once a year, and new participants should be immediately evaluated when they join the program.
+For participants with insufficient awareness, provide additional training and retain re-evaluation results
+together.
+
+**Considerations**
+
+- **Evaluation scope**: Design evaluation questions that cover all three key areas of awareness
+  (objectives, contributions, implications).
+- **Evaluation cycle**: Conduct a regular evaluation at least once a year, and new participants should
+  be evaluated immediately upon joining.
+- **Evidence format**: Retain in a format that can be submitted during audits, such as quiz results,
+  signed policy acknowledgment forms, and training completion certificates.
+- **Measures for insufficient participants**: Provide additional training for participants with
+  insufficient evaluation results and retain re-evaluation records.
+- **Accessibility**: Keep policy documents and training materials used for evaluation always accessible
+  on the internal portal.
+
+**Sample**
+
+The following is a sample participant awareness assessment record form. It is written at the time of
+training completion and stored in the LMS or document system.
+
+```
+| Name | Role | Evaluation Item | Evaluation Method | Result | Evaluation Date | Notes |
+|------|------|-----------------|-------------------|--------|-----------------|-------|
+| Gil-dong Hong | Open Source Program Manager | Understanding of program objectives | Online quiz | Completed (90 points) | 2026-01-15 | - |
+| Gil-dong Hong | Open Source Program Manager | Awareness of non-compliance implications | Online quiz | Completed (90 points) | 2026-01-15 | - |
+| Chul-su Kim | Developer | Understanding of program objectives | Online quiz | Completed (85 points) | 2026-01-20 | - |
+| Young-hee Lee | Security Staff | Awareness of contribution method | Interview | Completed | 2026-01-22 | Interview record retained |
+```
+
+The following is a sample policy acknowledgment form. Obtaining a signature after training completion
+can serve as Verification Material.
+
+```
+[Open Source Policy Acknowledgment Form]
+
+I confirm that I have reviewed and understood the following:
+
+1. The existence of the company's open source policy and the location of the document
+2. The objectives of the open source license compliance and Security Assurance program
+3. How my role contributes to the operation of the open source program
+4. The legal and business risks that may arise from failing to comply with open source
+   policies and processes
+
+Name: ________________  Role: ________________
+Signature: ____________  Date: ________________
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 5. Training](../../../opensource_for_enterprise/5-training/)
+- Related template: [Open Source Policy Template — §6 Training and Awareness](../../../templates/1-policy/)
diff --git a/content/en/guide/iso5230_guide/1-program-foundation/4-scope/_index.md b/content/en/guide/iso5230_guide/1-program-foundation/4-scope/_index.md
new file mode 100644
index 0000000000..742fb36d31
--- /dev/null
+++ b/content/en/guide/iso5230_guide/1-program-foundation/4-scope/_index.md
@@ -0,0 +1,98 @@
+---
+title: "§3.1.4 Program Scope"
+weight: 40
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Program Scope"]
+description: >
+---
+
+## 1. Clause Overview
+
+If it is unclear whether the open source program applies to the entire organization or only to specific
+product lines or business units, the boundaries of compliance activities become vague and accountability
+becomes unclear. §3.1.4 requires a documented written statement that clearly defines which software,
+organizational units, and distribution channels the open source program applies to, and what is outside
+the scope. The scope may vary depending on the organization's size and business model, and this clause
+requires that choice to be explicitly recorded.
+
+## 2. What to Do
+
+- Determine the types of software the open source program applies to (externally distributed products,
+  services, internal systems, etc.).
+- Define the organizational scope the program applies to (company-wide, specific business unit, specific
+  product line, etc.).
+- If there are items explicitly excluded from the scope, record them together with the rationale.
+- Document the scope statement and officially manage it as an open source policy or separate document.
+- Re-examine and update the scope when the business environment changes (entry into new businesses,
+  mergers and acquisitions, etc.).
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.1.4 | Different programs may be designed to address different scopes depending on the supplier's needs and business model. The scope might include the entire organization, a particular business unit, a particular product line, a specific product, or even a single open source component. The definition of the scope needs to be clear. | **3.1.4.1** A written statement that clearly defines the scope and limits of the program. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.1.4.1 Written Statement of Program Scope
+
+**How to Comply**
+
+A document must be written that clearly describes where the program applies and where it does not. This
+statement can be included in the scope section of the Open Source Policy document (§3.1.1.1) or managed
+as a separate document. The key point is that the boundaries must be clear. For example, it can be stated
+clearly as "all software products distributed externally," or the scope can be specifically limited such
+as "limited to embedded software developed by business unit A."
+
+When determining the scope, comprehensively consider the software distribution format (binary products,
+SaaS, internal tools), how open source is used (direct use, indirect dependencies), and external
+contribution activities. It is also advisable to clearly state the handling policy for software used
+only internally. The scope statement must be periodically reviewed and versioned in response to business
+environment changes.
+
+**Considerations**
+
+- **Distribution format distinction**: Specify the applicability for each software distribution type
+  such as externally distributed products, SaaS services, and internal systems.
+- **Organizational scope**: Clearly state whether it applies company-wide or only to specific business
+  units or product lines.
+- **Exception recording**: If there are items excluded from the scope, record them in the document
+  together with the reason for exclusion.
+- **Update cycle**: Immediately re-examine and update the version when entering new businesses,
+  undergoing mergers and acquisitions, or changing the product portfolio.
+- **Policy alignment**: The scope statement should be consistent with the open source policy §1.4
+  scope section.
+
+**Sample**
+
+The following is a sample scope statement within an open source policy. This text itself constitutes
+Verification Material 3.1.4.1.
+
+```
+## Program Scope
+
+This open source program applies to the following scope:
+
+**Applicable**
+- All software products externally distributed or sold by the company (including embedded software)
+- Activities contributing to external open source projects
+- Activities releasing internal projects as open source
+
+**Excluded**
+- Software used internally only and not distributed externally (however, a separate review procedure
+  may be applied)
+- Commercial software procured from third parties (however, review for open source inclusion is required)
+
+**Organizational Scope**
+This program applies to all business units of [Company Name], and subsidiaries and affiliates
+determine applicability through separate consultation.
+
+This scope is reviewed at least once a year in accordance with business environment changes,
+and the Open Source Program Manager publishes the revised version when changes occur.
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 2. Policy](../../../opensource_for_enterprise/2-policy/)
+- Related template: [Open Source Policy Template — §1.4 Scope](../../../templates/1-policy/)
diff --git a/content/en/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md b/content/en/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md
new file mode 100644
index 0000000000..b38c040024
--- /dev/null
+++ b/content/en/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md
@@ -0,0 +1,118 @@
+---
+title: "§3.1.5 License Obligations"
+weight: 50
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "License Obligations"]
+description: >
+---
+
+## 1. Clause Overview
+
+The most critical task when including open source components in software is accurately understanding
+the obligations, restrictions, and rights imposed by the licenses applied to those components. Distributing
+without reviewing license obligations can result in serious legal risks such as mandatory source code
+disclosure, missing copyright notices, and patent clause violations. §3.1.5 requires the establishment
+of a procedure for reviewing all identified licenses to determine their obligations, restrictions, and
+rights, and for recording the results. This procedure forms the foundation of the §3.3.2 License
+Compliance process.
+
+## 2. What to Do
+
+- Identify and list the licenses of open source components used in the software.
+- Review the obligations (notice obligations, source code disclosure obligations, etc.), restrictions
+  (commercial use restrictions, patent use restrictions, etc.), and rights (use, modification, and
+  redistribution rights, etc.) imposed by each license.
+- Document review results by license and maintain records.
+- Establish a procedure for requesting legal review when there is uncertainty in license interpretation.
+- Update the procedure when new licenses emerge or existing license interpretations change.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.1.5 | A process shall exist for reviewing the identified licenses to determine the obligations, restrictions and rights granted by each license. | **3.1.5.1** A documented procedure to review and document the obligations, restrictions, and rights granted by each identified license. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.1.5.1 License Obligation Review Procedure
+
+**How to Comply**
+
+A procedure for reviewing and recording the obligations, restrictions, and rights of each open source
+license must be documented. The procedure must include the following steps: (1) license identification,
+(2) obligation, restriction, and rights analysis, (3) recording review results, (4) requesting legal
+review for uncertain items, and (5) record retention. This procedure document itself is Verification
+Material 3.1.5.1.
+
+License obligations by license can be efficiently managed by utilizing pre-compiled license databases
+(SPDX License List, etc.). It is practically effective to prepare an obligation summary table in advance
+for major licenses (MIT, Apache-2.0, GPL-2.0, GPL-3.0, LGPL-2.1, AGPL-3.0, etc.) and to immediately
+conduct additional review when new licenses are discovered. The criteria for escalating to the legal
+team in the case of complex license combinations or situations requiring legal judgment should also be
+specified in the procedure.
+
+**Considerations**
+
+- **SPDX utilization**: Using the SPDX License List as a reference license list standardizes
+  identification and classification.
+- **Obligation type distinction**: Record obligations by type, such as notice obligations, source code
+  disclosure obligations, patent clauses, and trademark restrictions.
+- **Review by distribution format**: Review by distribution format, as license obligations may differ
+  depending on the distribution format such as binary distribution, SaaS, and internal use.
+- **Escalation criteria**: Specify in the procedure the situations requiring legal review (license
+  conflicts, non-standard licenses, commercial restriction clauses, etc.).
+- **Update cycle**: Immediately update the procedure and records when new licenses are adopted or
+  existing license interpretations change.
+
+**Sample**
+
+The following is a sample obligation summary table for major open source licenses. Writing and retaining
+it as part of the license review procedure can serve as Verification Material.
+
+```
+| License | Notice Obligation | Source Code Disclosure | Same License for Modifications | Patent Clause | Commercial Use |
+|---------|-------------------|----------------------|-------------------------------|---------------|----------------|
+| MIT | Yes | No | No | No | Yes |
+| Apache-2.0 | Yes | No | No | Yes (patent grant) | Yes |
+| GPL-2.0 | Yes | Yes (upon distribution) | Yes | No | Yes |
+| GPL-3.0 | Yes | Yes (upon distribution) | Yes | Yes (patent grant) | Yes |
+| LGPL-2.1 | Yes | Yes (library) | Yes (library) | No | Yes |
+| AGPL-3.0 | Yes | Yes (including network) | Yes | Yes (patent grant) | Yes |
+| MPL-2.0 | Yes | Yes (file-level) | Yes (file-level) | Yes (patent grant) | Yes |
+| BSD-2-Clause | Yes | No | No | No | Yes |
+| BSD-3-Clause | Yes | No | No | No | Yes |
+```
+
+The following is a sample outline of a license obligation review procedure.
+
+```
+[License Obligation Review Procedure]
+
+1. License Identification
+   - Identify open source components and licenses through SBOM generation tools
+     (FOSSology, ORT, etc.).
+
+2. Obligation, Restriction, and Rights Analysis
+   - Refer to the pre-compiled license obligation summary table to confirm the
+     obligations, restrictions, and rights of the applicable license.
+   - For licenses not in the summary table, review the SPDX License List and
+     license text to add new entries.
+
+3. Legal Review Request (if applicable)
+   - When license conflicts, non-standard licenses, or commercial restriction
+     clauses are present, request legal review from the legal team.
+
+4. Recording Review Results
+   - Record review results in the SBOM or license review record and store in
+     the open source management system.
+
+5. Obligation Fulfillment Confirmation
+   - Before distribution, confirm that license obligations (notice inclusion,
+     source code disclosure, etc.) have been completed.
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 3. Process](../../../opensource_for_enterprise/3-process/)
+- Related template: [Open Source Process Template](../../../templates/2-process-template/)
diff --git a/content/en/guide/iso5230_guide/1-program-foundation/_index.md b/content/en/guide/iso5230_guide/1-program-foundation/_index.md
new file mode 100644
index 0000000000..3de5252f1a
--- /dev/null
+++ b/content/en/guide/iso5230_guide/1-program-foundation/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.1 Program Foundation"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Program Foundation"]
+description: >
+---
diff --git a/content/en/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md b/content/en/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md
new file mode 100644
index 0000000000..29c7b3b26d
--- /dev/null
+++ b/content/en/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md
@@ -0,0 +1,144 @@
+---
+title: "§3.2.1 External Inquiry Response"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "External Inquiry"]
+description: >
+---
+
+## 1. Clause Overview
+
+Companies distributing software may receive inquiries from third parties (customers, open source copyright
+holders, researchers, etc.) regarding open source license compliance. Failure to respond to these
+inquiries in a timely manner risks escalation into copyright infringement disputes. §3.2.1 requires
+organizations to establish a publicly available means of contact for receiving external inquiries and to
+document a procedure internally for systematically responding to those inquiries. This clause requires
+both a public channel (Verification Material 3.2.1.1) and an internal response procedure (Verification
+Material 3.2.1.2).
+
+## 2. What to Do
+
+- Specify a publicly available contact (email address, web form, etc.) on the product or website where
+  third parties can send open source license compliance inquiries.
+- Document the internal response procedure from receiving an external inquiry through review, response,
+  and closure.
+- Include the person responsible for each type of inquiry (Open Source Program Manager, legal team, etc.)
+  and the escalation path in the procedure.
+- Record and retain the history of inquiries received and responses given.
+- Periodically verify the validity of the public contact and the currency of the internal procedure.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.2.1 | Maintain a process to effectively respond to external open source inquiries. Publicly identify a means by which a third party can make an open source compliance inquiry. | **3.2.1.1** Publicly visible method that allows any third party to make an open source license compliance inquiry (e.g., via a published contact email address, or the OpenChain Conformance website).<br>**3.2.1.2** An internal documented procedure for responding to third party open source license compliance inquiries. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.2.1.1 Publicly Available External Inquiry Channel
+
+**How to Comply**
+
+A means by which third parties can send open source license compliance inquiries must be publicly
+specified. The most common method is to publish a dedicated email address (e.g., oss@company.com)
+in product documentation, software open source notices, or the company website. This public contact
+itself is Verification Material 3.2.1.1.
+
+It is better to use a role-based address rather than an individual's personal email. This way the
+address is maintained even when the person in charge changes, and it is advisable to manage it as a
+team mailbox to prevent inquiries from being missed. Registering the contact on the OpenChain Conformance
+website is also an option.
+
+**Considerations**
+
+- **Use role-based address**: Use a role-based address such as oss@company.com instead of a personal
+  email to prepare for changes in the person in charge.
+- **Publication location**: Publish in locations that third parties can easily find, such as product
+  manuals, open source notices (NOTICES file), and the company website.
+- **Verify responsiveness**: Periodically check that the published contact is actually being received
+  and monitored.
+- **Multilingual consideration**: For global products, also provide English contact information.
+
+**Sample**
+
+The following is a sample public contact notice to be posted on the product open source notice or website.
+
+```
+Open Source License Compliance Inquiry
+
+For inquiries regarding open source license compliance of the software components
+included in this software, please contact us at the email below.
+
+- Email: oss@company.com
+- Response time: Within 14 business days
+
+Open Source License Compliance Inquiry
+
+For inquiries regarding open source license compliance of this software,
+please contact: oss@company.com
+```
+
+---
+
+### 3.2.1.2 Internal External Inquiry Response Procedure
+
+**How to Comply**
+
+An internal procedure defining how to handle an external inquiry when it is received must be documented.
+The procedure must include the following steps: (1) receiving and classifying the inquiry, (2) assigning
+a person responsible, (3) reviewing and drafting a response, (4) legal review (if necessary), (5) sending
+the response, and (6) record retention. This procedure document is Verification Material 3.2.1.2.
+
+Response deadlines should be set within a reasonable range and specified in the procedure. In general,
+an initial response within 14 days and a final response within 60 days are common standards. The history
+of inquiry receipt, handling, and closure should be recorded in the internal system and retained for
+submission during audits.
+
+**Considerations**
+
+- **Person responsible and escalation**: Specify the primary person responsible (Open Source Program
+  Manager) and the escalation path for legal review in the procedure.
+- **Response deadline**: Specify the deadlines for initial and final responses in the procedure and
+  adhere to them.
+- **Record retention**: Record the inquiry content, review process, and final response, and retain for
+  at least 3 years.
+- **Response by type**: Include in the procedure methods for responding to different types of inquiries
+  such as license notice requests, source code provision requests, and copyright infringement claims.
+
+**Sample**
+
+The following is a sample outline of an external inquiry response procedure.
+
+```
+[External Open Source Inquiry Response Procedure]
+
+1. Receipt and Classification (within 1 business day)
+   - Check the oss@company.com inbox daily.
+   - Classify inquiries by type:
+     A. Request for open source notice or source code provision
+     B. Request for confirmation of license obligation compliance
+     C. Copyright infringement claim or legal warning
+
+2. Person Assignment and Initial Response (within 3 business days)
+   - The Open Source Program Manager reviews the inquiry and sends a receipt confirmation.
+   - Type C (legal warning) is immediately escalated to the legal team.
+
+3. Review and Response Drafting (within 14 business days)
+   - Review the relevant SBOM, license records, and Compliance Artifacts.
+   - Type A: Confirm and provide the notice or source code.
+   - Type B: Review compliance evidence and respond.
+   - If necessary, request legal review of the draft response.
+
+4. Response Sending and Closure
+   - Send the final response and close the inquiry.
+
+5. Record Retention
+   - Document the inquiry content, review process, and final response and retain
+     for at least 3 years.
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 3. Process](../../../opensource_for_enterprise/3-process/)
+- Related template: [Open Source Policy Template — §9 External Inquiry Response](../../../templates/1-policy/)
diff --git a/content/en/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md b/content/en/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md
new file mode 100644
index 0000000000..bd06e2c961
--- /dev/null
+++ b/content/en/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md
@@ -0,0 +1,245 @@
+---
+title: "§3.2.2 Effective Resources"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Resources"]
+description: >
+---
+
+## 1. Clause Overview
+
+For an open source program to actually function, it is not enough to just define roles. Actual personnel
+must be assigned to each role, and sufficient time and budget must be provided to carry out the work.
+§3.2.2 requires organizations to document the persons responsible for each program role, confirm that
+staffing and budget are appropriately allocated, and to have a method for accessing legal expertise, a
+procedure for assigning internal responsibilities, and a procedure for handling non-compliance cases.
+This clause consists of five verification material items and is the stage that implements the role
+structure defined in §3.1 Program Foundation into an actual operational framework.
+
+## 2. What to Do
+
+- Record the names or job titles of the persons responsible for each role in the program (Open Source
+  Program Manager, legal counsel, IT staff, etc.) in a document.
+- Confirm and record that sufficient time and budget have been allocated for each role assignee to
+  perform their duties.
+- Identify and document internal or external legal expertise available when legal issues related to
+  open source license compliance arise.
+- Document a procedure for assigning internal open source compliance responsibilities to each role.
+- Document a procedure for reviewing and remedying non-compliance cases when discovered.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.2.2 | Identify and Resource Program Task(s): assign accountability to ensure the successful execution of program tasks / provide sufficient resources (time, budget) for program tasks / ensure access to legal expertise / establish a process for reviewing and resolving non-compliance cases. | **3.2.2.1** A document with the names of the persons, group or function in program role(s) identified.<br>**3.2.2.2** The identified program roles have been properly staffed and adequate funding provided.<br>**3.2.2.3** Identification of legal expertise available to address open source license compliance matters which could be internal or external.<br>**3.2.2.4** A documented procedure that assigns internal responsibilities for open source compliance.<br>**3.2.2.5** A documented procedure for handling the review and remediation of non-compliant cases. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.2.2.1 Document with Names of Persons in Program Roles
+
+**How to Comply**
+
+A document must be created listing the names, group names, or job titles of the actual persons
+responsible for each role in the program. This document can be managed by adding assignee information
+to the roles and responsibilities list document from §3.1.2.1, or can be included as an assignee status
+table in the Open Source Policy Appendix. It is acceptable to use job titles (Open Source Program
+Manager, Head of Legal, etc.) instead of specific individual names, and the document must be updated
+immediately when organizational changes occur.
+
+**Considerations**
+
+- **Individual name or job title**: Using job titles instead of names reduces the frequency of document
+  updates when personnel changes occur.
+- **Concurrent roles**: When one person handles multiple roles, note this fact for all relevant roles.
+- **Update management**: Immediately update the document and record the version when organizational
+  changes or personnel transfers occur.
+
+**Sample**
+
+The following is a sample assignee status table for program roles.
+The full form can be found in [Open Source Policy Template Appendix 1](../../../templates/1-policy/appendix/).
+
+```
+| Role | Assignee | Contact |
+|------|----------|---------|
+| Open Source Program Manager | Gil-dong Hong (Dev Team Lead) | oss@company.com |
+| Legal Counsel | Legal Kim (Head of Legal) | legal@company.com |
+| IT Staff | Infra Lee (Infrastructure Team) | it-oss@company.com |
+| Security Staff | Security Park (Security Team) | security@company.com |
+| Developer Culture Staff | Culture Choi (HR Team) | culture@company.com |
+```
+
+---
+
+### 3.2.2.2 Staffing and Funding Confirmation
+
+**How to Comply**
+
+It must be confirmed and the basis recorded that sufficient time and budget have been allocated for each
+role assignee to perform open source program duties. Even if there is no dedicated organization, there
+must be internal records confirming that the time available for concurrent assignees to invest in the
+work is secured, and that necessary budgets such as tool purchases or training costs have been allocated.
+Budget plans or work assignment documents that include management approval may constitute this
+Verification Material.
+
+**Considerations**
+
+- **Specify dedicated vs. concurrent**: Record whether it is a dedicated position or concurrent, and
+  if concurrent, specify the input ratio (e.g., 20% of working hours).
+- **Retain budget evidence**: Retain records proving budget support such as tool purchase contracts,
+  training cost expenditure records, and external consulting contracts.
+- **Management confirmation**: Maintain records of management approval or confirmation of staffing and
+  budget support.
+
+**Sample**
+
+```
+[Open Source Program Resource Allocation Confirmation]
+
+Program year: 2026
+Approver: [Executive name] / Approval date: 2026-01-10
+
+| Role | Assignee | Input Ratio | Annual Budget |
+|------|----------|-------------|---------------|
+| Open Source Program Manager | Gil-dong Hong | 50% | - |
+| Legal Counsel | Legal Kim | 20% | - |
+| IT Staff (tool operation) | Infra Lee | 10% | Including tool license costs |
+| Training budget | - | - | Annual OOO amount |
+| External legal advisory budget | - | - | Executed as needed |
+```
+
+---
+
+### 3.2.2.3 Legal Expertise Access Method
+
+**How to Comply**
+
+The method for accessing professional legal advice when legal issues related to open source license
+compliance arise must be identified and documented. If there is an internal legal team, record the
+team's contact information and escalation procedure. If there is no internal legal team or if expertise
+is insufficient, specify in the document the method for utilizing external law firms or open source
+consulting specialists.
+
+**Considerations**
+
+- **Internal vs. external**: Specify both the method for utilizing the internal legal team and the
+  criteria for requesting external consultation.
+- **Escalation criteria**: Include in the procedure the criteria for when legal advice is needed
+  (copyright infringement claims, non-standard licenses, patent clauses, etc.).
+- **Maintain external advisory list**: Keep information on open source specialist external law firms
+  or consultants up to date.
+
+**Sample**
+
+```
+[Legal Expertise Access Method]
+
+Internal Legal Team:
+- Contact: Legal Team (legal@company.com)
+- Escalation criteria: When copyright infringement claims are received, when
+  interpretation of GPL-family license obligations is uncertain, when review
+  of non-standard licenses is required
+
+External Legal Advisory:
+- Utilization criteria: When complex legal disputes arise that are difficult for
+  the internal legal team to adjudicate
+- Contract status: [External law firm name] (annual advisory contract in place)
+- Open source specialist consulting: Refer to the OpenChain partner list
+```
+
+---
+
+### 3.2.2.4 Internal Responsibility Assignment Procedure
+
+**How to Comply**
+
+A procedure for clearly assigning internal responsibilities related to open source compliance to each
+role must be documented. This procedure defines who is responsible for what, and specifies the responsible
+person for each work stage such as open source use approval, SBOM generation, license review, and
+Compliance Artifacts distribution. This procedure document can be included in the open source policy
+or process document.
+
+**Considerations**
+
+- **Responsibility by work stage**: Designate a responsible person for each stage of open source
+  introduction, review, approval, and distribution.
+- **RACI utilization**: Defining responsibilities by role (Responsible, Accountable, Consulted, Informed)
+  as a RACI matrix increases clarity.
+- **Update cycle**: Immediately update the procedure when organizational or process changes occur.
+
+**Sample**
+
+```
+| Task | Open Source PM | Legal | IT | Security | Developer |
+|------|----------------|-------|----|----------|-----------|
+| Open source use approval | A | C | - | C | R |
+| License obligation review | R | A | - | - | I |
+| SBOM generation | A | - | R | - | C |
+| Vulnerability monitoring | I | - | C | A/R | I |
+| Compliance Artifacts distribution | A | C | R | - | I |
+| External inquiry response | A/R | C | - | - | - |
+
+R: Responsible / A: Accountable / C: Consulted / I: Informed
+```
+
+---
+
+### 3.2.2.5 Non-Compliance Case Review and Remediation Procedure
+
+**How to Comply**
+
+A procedure for reviewing and remediating non-compliance cases (license obligation failures, SBOM
+omissions, unauthorized open source use, etc.) when discovered must be documented. The procedure must
+include: (1) identification and reporting of non-compliance cases, (2) severity assessment, (3) root
+cause analysis, (4) corrective action, (5) preventive measures, and (6) record retention.
+
+Non-compliance cases can be discovered through various channels such as internal audits, external
+inquiries, and automated tool alerts. It is effective to distinguish between urgent measures (distribution
+suspension, immediate source code disclosure, etc.) and general measures depending on severity, and to
+set different deadlines for processing.
+
+**Considerations**
+
+- **Severity classification**: Classify the severity (high/medium/low) of non-compliance cases based
+  on legal risk and set different processing deadlines.
+- **Escalation**: Make management reporting and legal review mandatory for high-severity cases.
+- **Recurrence prevention**: After completing corrective action, derive and record process improvement
+  measures to prevent recurrence of the same type of non-compliance.
+- **Record retention**: Retain non-compliance case history and corrective completion records for at
+  least 3 years.
+
+**Sample**
+
+```
+[Non-Compliance Case Handling Procedure]
+
+1. Identification and Reporting
+   - Identify non-compliance cases through internal audits, external inquiries,
+     CI/CD tool alerts, etc.
+   - Report immediately to the Open Source Program Manager.
+
+2. Severity Assessment
+   - High: GPL source code not disclosed for distributed software, copyright infringement claim received
+     → Emergency review initiated within 48 hours
+   - Medium: SBOM omission, incomplete license notice
+     → Corrective action completed within 7 business days
+   - Low: Internal process non-compliance (approval procedure skipped, etc.)
+     → Corrective action completed within 30 days
+
+3. Root Cause Analysis and Corrective Action
+   - Identify the cause of non-compliance and establish a corrective plan.
+   - For high and medium cases, take action after consulting with the legal team.
+
+4. Recurrence Prevention
+   - Derive and implement process or training improvement measures.
+
+5. Record Retention
+   - Record the case content, action progress, and completion date, and retain for at
+     least 3 years.
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 1. Organization](../../../opensource_for_enterprise/1-teams/)
+- Related template: [Open Source Policy Template — Appendix 1. Personnel Status](../../../templates/1-policy/appendix/)
diff --git a/content/en/guide/iso5230_guide/2-relevant-tasks/_index.md b/content/en/guide/iso5230_guide/2-relevant-tasks/_index.md
new file mode 100644
index 0000000000..4f6709d31a
--- /dev/null
+++ b/content/en/guide/iso5230_guide/2-relevant-tasks/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.2 Relevant Tasks"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Relevant Tasks"]
+description: >
+---
diff --git a/content/en/guide/iso5230_guide/3-content-review/1-sbom/_index.md b/content/en/guide/iso5230_guide/3-content-review/1-sbom/_index.md
new file mode 100644
index 0000000000..a0dd0205f0
--- /dev/null
+++ b/content/en/guide/iso5230_guide/3-content-review/1-sbom/_index.md
@@ -0,0 +1,163 @@
+---
+title: "§3.3.1 SBOM"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "SBOM"]
+description: >
+---
+
+## 1. Clause Overview
+
+Without knowing what open source components are included in the supplied software, it is impossible to
+fulfill license obligations or respond to security vulnerabilities. §3.3.1 requires the establishment
+of a procedure for identifying, tracking, reviewing, approving, and archiving the open source components
+that make up supplied software, and maintaining component records (SBOM) that demonstrate the procedure
+has actually been followed. This clause forms the foundation for operating the SBOM, which is the core
+infrastructure of open source license compliance and Security Assurance.
+
+## 2. What to Do
+
+- Identify and list the open source components included in supplied software using automated tools
+  (FOSSology, ORT, Syft, cdxgen, etc.).
+- Document a procedure for tracking, reviewing, approving, and archiving open source component information
+  (component name, version, license, source, etc.).
+- Generate and manage an SBOM for each supplied software release.
+- Write SBOM data in SPDX or CycloneDX standard formats to ensure interoperability.
+- Immediately update the SBOM when software changes (new component addition, version upgrade, component
+  removal) occur.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.3.1 | A process shall exist for creating and managing a bill of materials that includes each open source component (and its identified licenses) from which the supplied software is comprised. | **3.3.1.1** A documented procedure for identifying, tracking, reviewing, approving, and archiving information about the collection of open source components from which the supplied software is comprised.<br>**3.3.1.2** Open source component records for the supplied software that demonstrates the documented procedure was followed. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.3.1.1 Open Source Component Management Procedure
+
+**How to Comply**
+
+A series of procedures for identifying, tracking, reviewing, approving, and archiving open source
+components included in supplied software must be documented. The procedure covers how open source is
+managed throughout the software development lifecycle and must include the following steps: (1) component
+identification, (2) license confirmation, (3) obligation review, (4) use approval, (5) SBOM generation
+and registration, (6) providing SBOM upon distribution, (7) SBOM update upon changes, and (8) SBOM
+archiving. This procedure document itself is Verification Material 3.3.1.1.
+
+It is recommended to adopt SPDX (ISO/IEC 5962) or CycloneDX format for standardizing the SBOM.
+Integrating automated tools into the CI/CD pipeline makes it easier to keep the SBOM up to date as it
+is automatically updated when components change.
+
+**Considerations**
+
+- **Automated tool integration**: Automate SBOM generation by integrating tools such as FOSSology, ORT,
+  Syft, and cdxgen into CI/CD.
+- **Standard format adoption**: Write SBOMs in SPDX or CycloneDX format to ensure interoperability
+  with supply chain partners.
+- **Define update triggers**: Mandate SBOM updates when new components are added, versions are upgraded,
+  components are removed, or licenses change.
+- **Approval procedure specification**: Include in the procedure the approval procedure by the Open
+  Source Program Manager or OSRB when introducing new open source components.
+- **Retention period**: Retain the SBOM for at least [N] years after the relevant software is distributed.
+
+**Sample**
+
+The following is a sample outline of an open source component management procedure.
+The full process form can be found in the [Open Source Process Template](../../../templates/2-process-template/).
+
+```
+[Open Source Component Management Procedure Outline]
+
+(1) Identification
+    - Developers report open source components to the open source management system
+      when introducing them.
+    - SCA tools in the CI/CD pipeline (Syft, ORT, etc.) automatically detect components.
+
+(2) License Confirmation and Obligation Review
+    - Confirm the license of identified components based on the SPDX License List.
+    - Refer to the license obligation summary table to review obligations based on
+      the distribution format.
+    - Request legal review if uncertain.
+
+(3) Use Approval
+    - The Open Source Program Manager approves use based on review results.
+    - Components that conflict with license policy are rejected after reviewing alternatives.
+
+(4) SBOM Generation and Registration
+    - Register approved components in the SBOM (format: SPDX or CycloneDX).
+    - The SBOM includes component name, version, license, source (URL), and copyright notice.
+
+(5) Distribution and SBOM Provision
+    - Provide the SBOM with the software upon distribution or upon request.
+
+(6) Update Upon Changes
+    - Immediately update the SBOM when components are added, upgraded, removed, or when
+      licenses change.
+
+(7) Archiving
+    - Retain the SBOM by version for at least [N] years after software distribution.
+```
+
+---
+
+### 3.3.1.2 Open Source Component Records (SBOM)
+
+**How to Comply**
+
+Component records that demonstrate the procedure defined in 3.3.1.1 has actually been followed must be
+maintained for each supplied software. These records are the SBOM (Software Bill of Materials) and
+constitute Verification Material 3.3.1.2. The SBOM must include at minimum the name, version, license,
+and source of each open source component. Writing it in SPDX or CycloneDX format makes it immediately
+submittable during audits.
+
+The SBOM should be managed by software release version, and past version SBOMs should also be retained
+so that the component configuration at a specific point in time can always be verified. The output from
+SBOM generation tools can be used directly, or it can be stored and managed in an open source management
+system (SW360, Dependency-Track, etc.).
+
+**Considerations**
+
+- **Required items**: Include component name, version, license identifier (SPDX ID), source (package
+  registry URL or source repository), and copyright notice.
+- **Version-by-version management**: Manage SBOMs separately for each software release version and
+  retain past versions.
+- **Utilize management tools**: Using open source management systems such as SW360 and Dependency-Track
+  allows for systematic management of SBOM generation, tracking, and distribution.
+- **Customer provision**: Retain in an accessible format so that the SBOM can be provided immediately
+  when requested by customers or supply chain partners.
+
+**Sample**
+
+The following is a sample of key items in an SPDX format SBOM.
+
+```
+SPDXVersion: SPDX-2.3
+DataLicense: CC0-1.0
+SPDXID: SPDXRef-DOCUMENT
+DocumentName: MyProduct-v1.2.0-sbom
+DocumentNamespace: https://company.com/sbom/myproduct-1.2.0
+
+PackageName: openssl
+SPDXID: SPDXRef-openssl
+PackageVersion: 3.0.8
+PackageDownloadLocation: https://www.openssl.org/source/openssl-3.0.8.tar.gz
+PackageLicenseConcluded: Apache-2.0
+PackageLicenseDeclared: Apache-2.0
+PackageCopyrightText: Copyright (c) 1998-2023 The OpenSSL Project
+
+PackageName: zlib
+SPDXID: SPDXRef-zlib
+PackageVersion: 1.2.13
+PackageDownloadLocation: https://zlib.net/zlib-1.2.13.tar.gz
+PackageLicenseConcluded: Zlib
+PackageLicenseDeclared: Zlib
+PackageCopyrightText: Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 3. Process](../../../opensource_for_enterprise/3-process/)
+- Related template: [Open Source Process Template](../../../templates/2-process-template/)
+- Related tools: [FOSSology](../../../tools/1-fossology/), [ORT](../../../tools/2-ort/), [Syft](../../../tools/6-syft/), [cdxgen](../../../tools/5-cdxgen/), [Dependency-Track](../../../tools/7-dependency-track/)
diff --git a/content/en/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md b/content/en/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md
new file mode 100644
index 0000000000..93cebc87df
--- /dev/null
+++ b/content/en/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md
@@ -0,0 +1,110 @@
+---
+title: "§3.3.2 License Compliance"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "License Compliance"]
+description: >
+---
+
+## 1. Clause Overview
+
+License obligations for open source components vary depending on the distribution format (binary, source
+code), whether modifications were made, and how they are combined with other components. §3.3.2 requires
+the program to have the capability to handle the common open source license use cases for open source
+components in the supplied software. This clause goes beyond simply identifying licenses to establishing
+procedures that define how to fulfill obligations for various distribution scenarios.
+
+## 2. What to Do
+
+- Identify major license use cases such as binary distribution, source code distribution, and distribution
+  of modified open source, and establish handling procedures for each case.
+- Include in the procedure how to handle license conflicts (combination of incompatible license components).
+- Define the handling method for licenses requiring notice obligations (including copyright notices and
+  full license text).
+- Establish a distribution procedure for software containing licenses with source code disclosure
+  obligations such as GPL.
+- Document the procedure and periodically review it to address new license types.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.3.2 | The program shall be capable of handling the common open source license use cases for the open source components of the supplied software, which may include the following use cases: distributed in binary form / distributed in source form / integrated with other open source such that it may trigger additional licensing obligations / contains modified open source / contains open source or other software under an incompatible license interacting with other components within the supplied software / contains open source with attribution requirements. | **3.3.2.1** A documented procedure for handling the common open source license use cases for the open source components of the supplied software. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.3.2.1 Procedure for Handling License Use Cases
+
+**How to Comply**
+
+A procedure defining how to fulfill license obligations for the various scenarios in which open source
+is included in supplied software must be documented. This procedure document is Verification Material
+3.3.2.1. ISO/IEC 5230 presents the following 6 major use cases as examples, and the organization selects
+the applicable cases based on its business environment to establish handling procedures.
+
+Each use case procedure must include: (1) criteria for determining whether the case applies, (2) license
+obligation items, (3) method for fulfilling the obligation, (4) person responsible, and (5) artifacts
+(notices, source code packages, etc.). The path for escalating to the legal team in the case of license
+conflicts must also be specified.
+
+**Considerations**
+
+- **Determine use case scope**: Select the use cases matching the organization's software distribution
+  method to establish procedures (not all cases may apply to every organization).
+- **License conflict response**: Pre-define the handling method for incompatible license combinations
+  such as GPL and Apache-2.0.
+- **Notice management**: Establish a procedure for writing notices in a NOTICES file or product
+  documentation for licenses with copyright notice obligations.
+- **Source code disclosure procedure**: Separately define the procedure for responding to source code
+  disclosure requests under GPL-family licenses.
+- **Update cycle**: Update the procedure when new license types are adopted or distribution formats change.
+
+**Sample**
+
+The following is a sample summary table of procedures for handling license use cases.
+
+```
+| Use Case | License Examples | Key Obligations | Handling Method |
+|----------|-----------------|-----------------|-----------------|
+| Binary distribution | MIT, Apache-2.0 | Include copyright notice | Include notice in NOTICES file or in-app notice screen |
+| Binary distribution | GPL-2.0, GPL-3.0 | Disclose source code or include written offer | Distribute source code package or enclose written offer |
+| Source code distribution | All licenses | Preserve original license file and copyright notice | Keep license file and copyright notice as is |
+| Contains modified open source | GPL-2.0, LGPL-2.1 | Note modifications, apply same license to modifications | Record modification details, disclose modified source code |
+| Incompatible license combination | GPL-2.0 + Apache-2.0 | Resolve license conflict | Replace component or change structure after legal review |
+| Attribution requirement | BSD-3-Clause, Apache-2.0 | Include copyright notice in product documentation or UI | Add notice to product manual or About screen |
+```
+
+The following is a sample outline of a license obligation handling procedure by distribution format.
+
+```
+[License Obligation Handling Procedure for Binary Distribution]
+
+1. SBOM Review
+   - Review the list of included open source based on the latest SBOM of the
+     distributed software.
+
+2. License Obligation Classification
+   - Notice obligation: MIT, Apache-2.0, BSD, etc. → Create NOTICES file
+   - Source code disclosure obligation: GPL-2.0, GPL-3.0 → Prepare source code package
+   - LGPL: Determine scope of obligation based on dynamic linking status
+     (legal review if necessary)
+
+3. Compliance Artifacts Preparation
+   - NOTICES file: Include copyright notices and full license text for all open source
+   - Source code package: Include modified source code and build scripts for GPL components
+
+4. Review and Approval
+   - The Open Source Program Manager conducts a final review of the completeness of
+     the artifacts.
+   - License conflicts or uncertain items are escalated to the legal team.
+
+5. Distribution
+   - Provide Compliance Artifacts together with the software.
+   - Retain a copy of the artifacts (see §3.4.1).
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 3. Process](../../../opensource_for_enterprise/3-process/)
+- Related template: [Open Source Process Template](../../../templates/2-process-template/)
diff --git a/content/en/guide/iso5230_guide/3-content-review/_index.md b/content/en/guide/iso5230_guide/3-content-review/_index.md
new file mode 100644
index 0000000000..dea23c1e7e
--- /dev/null
+++ b/content/en/guide/iso5230_guide/3-content-review/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.3 Content Review and Approval"
+weight: 30
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Content Review"]
+description: >
+---
diff --git a/content/en/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md b/content/en/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md
new file mode 100644
index 0000000000..2b2634e3d7
--- /dev/null
+++ b/content/en/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md
@@ -0,0 +1,134 @@
+---
+title: "§3.4.1 Artifacts"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Compliance Artifacts"]
+description: >
+---
+
+## 1. Clause Overview
+
+To fulfill license obligations, Compliance Artifacts such as notices and source code packages must
+actually be prepared and provided with the software. §3.4.1 requires the establishment of a procedure
+for preparing the Compliance Artifacts required by the identified licenses and distributing them with
+the supplied software, as well as a procedure for retaining copies of the artifacts for a certain period.
+This clause connects the results of the §3.3 review and approval stage to actual distribution and archiving.
+
+## 2. What to Do
+
+- Define the types of Compliance Artifacts (NOTICES file, source code package, written offer, etc.)
+  required for each license.
+- Document a procedure for preparing artifacts and providing them with the supplied software.
+- Establish and document a procedure for retaining copies of distributed artifacts for a certain period.
+- Specify the artifact retention period in the policy (industry practice: at least 3 years after the
+  last distribution).
+- Maintain records that prove the archiving procedure was carried out correctly.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.4.1 | A process shall exist for creating the identified compliance artifacts for the supplied software. | **3.4.1.1** A documented procedure that describes the process under which the compliance artifacts are prepared and distributed with the supplied software as required by the identified licenses.<br>**3.4.1.2** A documented procedure for archiving copies of the compliance artifacts of the supplied software - where the archive is planned to exist for a reasonable period of time since the last offer of the supplied software; at least 3 years is a common practice. Records exist that demonstrate the procedure was followed. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.4.1.1 Compliance Artifacts Preparation and Distribution Procedure
+
+**How to Comply**
+
+A procedure for preparing Compliance Artifacts required by license obligations and providing them with
+the supplied software must be documented. This procedure document is Verification Material 3.4.1.1.
+The procedure must include the following steps: (1) determining artifact types, (2) creating artifacts,
+(3) reviewing and approving, (4) providing with the software, and (5) record retention.
+
+The types of Compliance Artifacts vary depending on the licenses being distributed. Generally, licenses
+with notice obligations (MIT, Apache-2.0, etc.) require a NOTICES file, and GPL-family licenses require
+a source code package or written offer. Artifacts can be provided in various ways such as enclosed in
+the product, included in the package, posted on a website, or provided upon request.
+
+**Considerations**
+
+- **Define artifact types**: Define in advance what artifacts are required for each license so that
+  distribution preparation can proceed quickly.
+- **NOTICES file quality**: Review that copyright notices and full license text for all open source
+  components are included without omission.
+- **Source code package**: For GPL components, prepare a complete source code package that includes
+  modified source code and build scripts.
+- **Provision method**: Determine whether to enclose artifacts with the software, post them on a
+  website, or provide them upon request based on license requirements.
+- **Final review**: The Open Source Program Manager conducts a final check of the completeness of
+  artifacts before distribution.
+
+**Sample**
+
+The following is a sample outline of a Compliance Artifacts preparation and distribution procedure.
+
+```
+[Compliance Artifacts Preparation and Distribution Procedure]
+
+1. Determine Artifact Types
+   - Review the list of included licenses based on the SBOM.
+   - Determine the necessary artifacts based on license obligations:
+     · Notice obligation licenses → NOTICES file
+     · GPL-2.0/3.0 → Source code package or written offer
+     · LGPL → Dynamic link structure proof document or source code
+
+2. Create Artifacts
+   - NOTICES file: Generate using automated tools (FOSSology, ORT, etc.) or create manually.
+     Include component name, version, full license text, and copyright notice.
+   - Source code package: Include modified source code and build scripts for GPL components.
+
+3. Review and Approval
+   - The Open Source Program Manager reviews the completeness and accuracy of the artifacts.
+   - Incomplete items are corrected and re-reviewed.
+
+4. Provide with Software
+   - Enclose in the product package or include in the screen displayed during installation.
+   - If posting on a website or providing upon request, specify the relevant URL or procedure.
+   - If using a written offer, include a written commitment valid for 3 years.
+```
+
+---
+
+### 3.4.1.2 Compliance Artifacts Archiving Procedure
+
+**How to Comply**
+
+A procedure for retaining copies of Compliance Artifacts for distributed supplied software for a certain
+period must be documented, and records must be maintained that prove the procedure was actually followed.
+This procedure document and archiving records are Verification Material 3.4.1.2.
+
+The retention period must be a reasonable period from the last distribution of the software, and at
+least 3 years is recommended as industry practice. The items to be retained include all artifacts provided
+upon distribution such as NOTICES files, source code packages, written offer copies, and SBOMs. Artifacts
+should be systematically managed by software version so that artifacts for a specific version can be
+immediately retrieved and submitted.
+
+**Considerations**
+
+- **Specify retention period**: Specify the retention period (at least 3 years) in the policy or
+  procedure document.
+- **Version-by-version management**: Link software release versions to artifacts and retain by version.
+- **Storage location**: Store in an accessible and secure location such as an internal file server,
+  document management system, or source code repository.
+- **Maintain archiving records**: Record the history of when artifacts for which version were archived.
+- **Accessibility**: Store in a searchable format so that artifacts can be immediately submitted when
+  audits or external inquiries occur.
+
+**Sample**
+
+The following is a sample Compliance Artifacts archiving record form.
+
+```
+| Software Name | Version | Distribution Date | Artifact Type | Storage Location | Retention Deadline | Responsible |
+|---------------|---------|-------------------|---------------|-----------------|-------------------|-------------|
+| MyProduct | v1.0.0 | 2024-03-01 | NOTICES file, GPL source code package | /archive/myproduct/v1.0.0/ | 2027-03-01 | Gil-dong Hong |
+| MyProduct | v1.1.0 | 2024-09-15 | NOTICES file | /archive/myproduct/v1.1.0/ | 2027-09-15 | Gil-dong Hong |
+| FirmwareX | v2.3.0 | 2025-01-10 | NOTICES file, LGPL source code package, SBOM | /archive/firmwarex/v2.3.0/ | 2028-01-10 | Infra Lee |
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 3. Process](../../../opensource_for_enterprise/3-process/)
+- Related template: [Open Source Process Template](../../../templates/2-process-template/)
diff --git a/content/en/guide/iso5230_guide/4-artifacts/_index.md b/content/en/guide/iso5230_guide/4-artifacts/_index.md
new file mode 100644
index 0000000000..705ad27c10
--- /dev/null
+++ b/content/en/guide/iso5230_guide/4-artifacts/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.4 Compliance Artifacts"
+weight: 40
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Compliance Artifacts"]
+description: >
+---
diff --git a/content/en/guide/iso5230_guide/5-community/1-contributions/_index.md b/content/en/guide/iso5230_guide/5-community/1-contributions/_index.md
new file mode 100644
index 0000000000..543f8f718a
--- /dev/null
+++ b/content/en/guide/iso5230_guide/5-community/1-contributions/_index.md
@@ -0,0 +1,206 @@
+---
+title: "§3.5.1 Contributions"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Contributions"]
+description: >
+---
+
+## 1. Clause Overview
+
+Many companies contribute code, documentation, bug reports, and more to external open source projects.
+Contribution activities build community trust and expand technical influence, but they also carry the
+risk of unintentionally disclosing company code or patents. §3.5.1 requires organizations that allow
+external open source contributions to establish a documented policy and procedure governing contributions,
+and to ensure that Program Participants are aware of their existence. This clause does not apply to
+organizations that do not allow contributions, but if they do, all three verification materials must
+be in place.
+
+## 2. What to Do
+
+- Decide whether the organization allows external open source contributions and specify this in the policy.
+- If contributions are allowed, document a contribution policy including the types of contributions
+  (code, documentation, bug reports, etc.), approval process, and copyright and patent handling policy.
+- Establish and document a procedure for managing actual contributions from proposal through approval,
+  submission, and recording.
+- Establish a procedure for communicating the existence of the contribution policy to Program Participants.
+- Record and retain the contribution history.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.5.1 | If an organization considers contributions to open source projects, then: a written policy shall exist that governs contributions to open source projects / the policy shall be internally communicated / a documented procedure shall exist that governs open source contributions. | **3.5.1.1** A documented open source contribution policy.<br>**3.5.1.2** A documented procedure that governs open source contributions.<br>**3.5.1.3** A documented procedure that makes all Program Participants aware of the existence of the open source contribution policy (e.g., via training, internal wiki, or other practical communication method). |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.5.1.1 Open Source Contribution Policy
+
+**How to Comply**
+
+A policy governing the act of contributing to external open source projects must be documented. This
+policy document is Verification Material 3.5.1.1. The contribution policy must include: (1) scope of
+allowed contributions (code, documentation, bug reports, etc.), (2) contribution approval process,
+(3) copyright handling (company-owned vs. individually-owned), (4) patent handling policy, (5) criteria
+for signing a CLA (Contributor License Agreement), and (6) prohibited contribution items (trade secrets,
+unpublished patents, etc.).
+
+The policy can be included as a separate section in the Open Source Policy document or managed as an
+independent contribution policy document. Even organizations that completely prohibit contributions
+should explicitly document that "contributions are not permitted."
+
+**Considerations**
+
+- **Define contribution scope**: Specifically list the types of contributions allowed (bug fixes,
+  feature additions, documentation writing, etc.).
+- **Copyright attribution**: Specify in the policy whether copyright of contributions belongs to the
+  company or to the individual.
+- **Patent risk management**: When contributions may include company patents, make legal review mandatory.
+- **CLA handling**: When an external project requires CLA signing, specify the signing authority and
+  procedure in the policy.
+- **Prohibited items**: Prohibit contributions containing trade secrets, unregistered patents, or
+  third-party intellectual property.
+
+**Sample**
+
+The following is a sample of key items in an open source contribution policy.
+
+```
+## Open Source Contribution Policy
+
+### Scope of Allowed Contributions
+The company allows employees to contribute to external open source projects for business purposes.
+The types of contributions allowed are as follows:
+- Bug fixes and patch submissions
+- Documentation improvements
+- Feature additions (prior approval required)
+- Bug reports and issue submissions
+
+### Copyright and Patents
+- Copyright of contributions created during working hours using company resources belongs to the company.
+- If there is a possibility that company patents are included in the contribution, prior review by
+  the legal team is required.
+
+### Prohibited Items
+Code containing the following items cannot be contributed:
+- Trade secrets or confidential information
+- Third-party intellectual property
+- The company's unpublished patent technology
+
+### CLA (Contributor License Agreement)
+If an external project requires CLA signing, prior reporting to and approval from the Open Source
+Program Manager is required.
+```
+
+---
+
+### 3.5.1.2 Open Source Contribution Management Procedure
+
+**How to Comply**
+
+A procedure defining step-by-step how to handle actual contribution activities must be documented. This
+procedure document is Verification Material 3.5.1.2. The procedure must include the following steps:
+(1) contribution proposal and approval request, (2) legal and patent review (if necessary), (3) approval,
+(4) contribution submission, and (5) contribution history recording. Depending on the scale or type of
+contribution, it is possible to operate a simplified procedure (small bug fixes) and a formal procedure
+(large-scale feature additions) separately.
+
+**Considerations**
+
+- **Procedure distinction by contribution scale**: Set scale-based criteria so that small bug fixes
+  use simplified approval and large-scale feature additions go through formal legal review.
+- **Retain contribution records**: Record and retain the contribution proposal, approval record, and
+  submission link (PR/commit URL).
+- **Escalation**: Include in the procedure an escalation path to the legal team when patent or copyright
+  issues arise.
+
+**Sample**
+
+The following is a sample outline of an open source contribution management procedure.
+
+```
+[Open Source Contribution Management Procedure]
+
+1. Contribution Proposal
+   - The employee reports the contribution details (project name, contribution type, content
+     summary) to the Open Source Program Manager.
+
+2. Review and Approval
+   - Small contributions (bug fixes, documentation improvements):
+     The Open Source Program Manager confirms policy compliance and approves.
+   - Large contributions (feature additions, core module contributions):
+     The Open Source Program Manager gives final approval after the legal team's
+     patent and copyright review.
+
+3. CLA Handling (if applicable)
+   - If the external project requires a CLA, process according to the approved CLA
+     signing form.
+
+4. Contribution Submission
+   - Submit only the approved content.
+   - Contribute using a company email or company-approved account.
+
+5. Contribution Recording
+   - Record and retain the contribution content, approver, submission date, and
+     contribution URL (PR/commit link).
+```
+
+---
+
+### 3.5.1.3 Contribution Policy Awareness Procedure
+
+**How to Comply**
+
+A procedure for communicating the open source contribution policy to all Program Participants so they
+are aware of its existence must be documented. This procedure document is Verification Material 3.5.1.3.
+It can be integrated with the §3.1.1.2 open source policy communication procedure by including the
+contribution policy in it.
+
+It is effective to combine new hire onboarding briefings on the contribution policy, internal wiki
+posts, and email announcements for communication. Retain notification history and training completion
+records to prove that communication took place.
+
+**Considerations**
+
+- **Include in onboarding**: Include the contribution policy briefing as a mandatory item in the new
+  hire onboarding process.
+- **Re-communication when policy is updated**: Immediately notify Program Participants when the
+  contribution policy is changed.
+- **Evidence retention**: Retain notification sending history and training completion certificates for
+  at least 3 years.
+- **Policy accessibility**: Post the contribution policy on the internal portal or wiki at all times
+  so it can be checked at any time.
+
+**Sample**
+
+The following is a sample contribution policy communication email.
+
+```
+Subject: [Open Source] Open Source Contribution Policy Notice
+
+To: All development-related employees
+From: Open Source Program Manager
+
+Hello,
+
+We would like to inform you about the company's open source contribution policy.
+All employees involved in contributing to external open source projects are requested
+to review and familiarize themselves with the policy document at the link below.
+
+- Policy document: [Internal portal link]
+- Key contents: Scope of allowed contributions, approval procedure, copyright and
+               patent handling policy
+- Policy version: v1.0 (Effective date: YYYY-MM-DD)
+
+If you wish to make a contribution, you must go through the prior approval procedure.
+Inquiries: Open Source Program Manager (oss@company.com)
+
+Thank you.
+Open Source Program Manager
+```
+
+## 5. References
+
+- Related guide: [Enterprise Open Source Management Guide — 6. Contributions](../../../opensource_for_enterprise/6-contribution/)
+- Related template: [Open Source Policy Template — §3 Open Source Contributions](../../../templates/1-policy/)
diff --git a/content/en/guide/iso5230_guide/5-community/_index.md b/content/en/guide/iso5230_guide/5-community/_index.md
new file mode 100644
index 0000000000..ec980d1dcf
--- /dev/null
+++ b/content/en/guide/iso5230_guide/5-community/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.5 Community Engagement"
+weight: 50
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Community", "Contributions"]
+description: >
+---
diff --git a/content/en/guide/iso5230_guide/6-conformance/1-conformance/_index.md b/content/en/guide/iso5230_guide/6-conformance/1-conformance/_index.md
new file mode 100644
index 0000000000..b7e1f271fb
--- /dev/null
+++ b/content/en/guide/iso5230_guide/6-conformance/1-conformance/_index.md
@@ -0,0 +1,92 @@
+---
+title: "§3.6.1 Conformance"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Conformance"]
+description: >
+---
+
+## 1. Clause Overview
+
+To receive official recognition of ISO/IEC 5230 conformance, the program defined in §3.1.4 must be
+confirmed in a document as satisfying all requirements of this specification. §3.6.1 is the stage for
+officially affirming that all clauses from §3.1 through §3.5 have been satisfied. This clause is the
+final confirmation procedure that completes adherence to the specification, requiring the organization's
+official confirmation that the program satisfies all requirements of ISO/IEC 5230:2020 version 2.1.
+
+## 2. What to Do
+
+- Conduct a self-assessment to verify that all verification material items (24 items) for all clauses
+  from §3.1 to §3.5 are in place.
+- Write a document confirming that the program satisfies all requirements of ISO/IEC 5230 within the
+  scope of application defined in §3.1.4.
+- Record the reviewer, approver, and confirmation date in the confirmation document.
+- Choose an appropriate certification method — self-certification, independent assessment, or third-party
+  certification — and proceed.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.6.1 | In order for a program to be deemed conformant with this specification, the organization shall affirm that the program satisfies the requirements presented in this document (version 2.1). | **3.6.1.1** A document affirming the program specified in §3.1.4 satisfies all the requirements of this specification. |
+
+## 4. How to Comply and Samples by Verification Material
+
+### 3.6.1.1 Specification Conformance Confirmation Document
+
+**How to Comply**
+
+A document must be written confirming that all requirements of ISO/IEC 5230:2020 are satisfied within
+the scope of application defined in §3.1.4. This document is Verification Material 3.6.1.1. It can be
+written in the form of a checklist confirming compliance for each of the 24 verification material items,
+or as a general conformance statement.
+
+Before writing, use this guide's [Full Clause Checklist](../../) to verify that all verification
+materials are in place. The document must include the scope of the program being confirmed, the
+specification version confirmed (ISO/IEC 5230:2020 version 2.1), the confirmation date, and the reviewer
+and approver.
+
+**Considerations**
+
+- **Self-assessment first**: Before writing the document, conduct a self-assessment of all 24 verification
+  material items to confirm there are no missing items.
+- **Specify specification version**: Specify the specification version confirmed in the document
+  (ISO/IEC 5230:2020 version 2.1).
+- **Approval process**: Formalize the document through the Open Source Program Manager's review and
+  management or OSRB approval.
+- **Update cycle**: After a new version of the specification is published, re-confirm based on the
+  latest version within 18 months (see §3.6.2).
+
+**Sample**
+
+The following is a sample ISO/IEC 5230 specification conformance confirmation document.
+
+```
+[ISO/IEC 5230 Specification Conformance Confirmation]
+
+Program name: [Company name] Open Source Compliance Program
+Scope of application: [Enter scope defined in §3.1.4]
+Specification confirmed: ISO/IEC 5230:2020 (version 2.1)
+Confirmation date: YYYY-MM-DD
+
+This document confirms that the above program satisfies all requirements of
+ISO/IEC 5230:2020 from §3.1 to §3.6.
+
+Summary of conformance items:
+- §3.1 Program Foundation (5 clauses, 8 verification materials): Satisfied ✓
+- §3.2 Relevant Tasks (2 clauses, 7 verification materials): Satisfied ✓
+- §3.3 Content Review and Approval (2 clauses, 3 verification materials): Satisfied ✓
+- §3.4 Compliance Artifacts (1 clause, 2 verification materials): Satisfied ✓
+- §3.5 Community Engagement (1 clause, 3 verification materials): Satisfied ✓
+- §3.6 Adherence to the Specification (2 clauses, 2 verification materials): Satisfied ✓
+
+Reviewer: [Open Source Program Manager name]
+Approver: [Management or OSRB head name]
+Approval date: YYYY-MM-DD
+```
+
+## 5. References
+
+- ISO/IEC 5230 self-certification: [https://certification.openchainproject.org/](https://certification.openchainproject.org/)
+- Full clause checklist: [ISO/IEC 5230 Conformance Guide](../../)
diff --git a/content/en/guide/iso5230_guide/6-conformance/2-duration/_index.md b/content/en/guide/iso5230_guide/6-conformance/2-duration/_index.md
new file mode 100644
index 0000000000..c415841839
--- /dev/null
+++ b/content/en/guide/iso5230_guide/6-conformance/2-duration/_index.md
@@ -0,0 +1,99 @@
+---
+title: "§3.6.2 Duration"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Duration"]
+description: >
+---
+
+## 1. Clause Overview
+
+ISO/IEC 5230 conformance does not remain valid indefinitely once obtained. When a new version of the specification is published, a program that was conformant against the previous version retains its conformance for only 18 months after the new version is published. §3.6.2 requires organizations to maintain a document confirming that the program meets all requirements of the specification within the past 18 months of obtaining conformance. This clause serves as a mechanism to ensure that open source compliance programs remain continuously operational rather than stopping at formal certification.
+
+## 2. What to Do
+
+- Record and manage the date on which conformance was obtained.
+- Within the past 18 months of obtaining conformance, re-confirm and document that the program still meets all requirements of the specification.
+- If a new version of the specification is published, update the program to meet the latest version and re-confirm within 18 months.
+- Conduct periodic internal audits to verify that the program maintains continuous compliance.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|--------|-------------|--------------------------|
+| §3.6.2 | A program that is conformant with this specification shall remain conformant even if the version of the specification it was conformant against is subsequently updated, for a period of 18 months after the new version of the specification is published. It is recommended that conformant programs be updated to be conformant with the latest version of the specification. | **3.6.2.1** A document affirming the program meets all the requirements of this version of the specification, within the past 18 months of obtaining conformance. |
+
+<details><summary>View original text</summary>
+
+> **§3.6.2 Duration**
+> A program that is conformant with this specification shall remain conformant
+> even if the version of the specification it was conformant against is
+> subsequently updated, for a period of 18 months after the new version of
+> the specification is published. It is recommended that conformant programs
+> be updated to be conformant with the latest version of the specification.
+>
+> **Verification Material(s):**
+> 3.6.2.1 A document affirming the program meets all the requirements of this
+> version of the specification, within the past 18 months of obtaining
+> conformance.
+
+</details>
+
+## 4. How to Comply with Each Verification Material
+
+### 3.6.2.1 Document Confirming All Requirements Met Within 18 Months
+
+**How to Comply**
+
+A document confirming that the program still meets all requirements of the specification must be maintained within 18 months of obtaining conformance. This document constitutes Verification Material 3.6.2.1. The simplest approach is to periodically review and update the specification conformance document from §3.6.1.1 at least once a year. Each time it is updated, record the review date and reviewer to demonstrate that a review was conducted within the past 18 months.
+
+When a new version of ISO/IEC 5230 is published, update the program to meet the latest version within the 18-month grace period and create a re-confirmation document. Since conformance expires if the grace period is exceeded, it is important to monitor specification revision trends and respond in a timely manner.
+
+**Considerations**
+
+- **Establish a periodic re-confirmation schedule**: Conduct a minimum of one annual internal audit to re-confirm and document the validity of all verification material items.
+- **Monitor specification revisions**: Regularly check OpenChain Project announcements for specification revisions and establish a response plan within 18 months when a new version is published.
+- **Manage conformance expiration**: Register the conformance acquisition date and validity period (18 months) in a calendar or management system to receive renewal reminders before expiration.
+- **Reflect changes**: When organizational structure, product portfolio, or process changes occur, immediately reflect them in the program and update the re-confirmation document.
+
+**Sample**
+
+Below is a sample periodic re-confirmation record for ISO/IEC 5230 specification compliance.
+
+```
+[ISO/IEC 5230 Specification Conformance Periodic Re-confirmation Record]
+
+Program Name: [Company Name] Open Source Compliance Program
+Initial Conformance Date: YYYY-MM-DD
+Specification Version Confirmed: ISO/IEC 5230:2020 (Version 2.1)
+
+| Re-confirmation Date | Result | Changes | Reviewer | Notes |
+|----------------------|--------|---------|----------|-------|
+| 2025-01-10 | Fully Met | Reflected personnel change (§3.2.2.1 updated) | John Doe | - |
+| 2026-01-08 | Fully Met | None | John Doe | Next re-confirmation: 2027-01-08 |
+
+Next re-confirmation scheduled: YYYY-MM-DD (within 12 months of last re-confirmation)
+18-month validity deadline: YYYY-MM-DD (18 months from last re-confirmation)
+```
+
+Below is a sample response checklist for when a new version of the specification is published.
+
+```
+[ISO/IEC 5230 New Version Response Checklist]
+
+New Version Publication Date: YYYY-MM-DD
+Response Deadline (18 months): YYYY-MM-DD
+
+□ Identify changes in requirements between new version and current version
+□ Establish program update plan based on changed requirements
+□ Complete updates and organize verification materials under new version
+□ Create and approve specification conformance document under new version
+□ Proceed with self-certification or certification renewal process
+```
+
+## 5. References
+
+- Check latest OpenChain specification version: [https://www.openchainproject.org/license-compliance](https://www.openchainproject.org/license-compliance)
+- Self-certification renewal: [https://certification.openchainproject.org/](https://certification.openchainproject.org/)
+- §3.6.1 Conformance: [Previous Clause](../1-conformance/)
diff --git a/content/en/guide/iso5230_guide/6-conformance/_index.md b/content/en/guide/iso5230_guide/6-conformance/_index.md
new file mode 100644
index 0000000000..6dc033b442
--- /dev/null
+++ b/content/en/guide/iso5230_guide/6-conformance/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.6 Adherence to the Specification"
+weight: 60
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "Adherence", "Conformance"]
+description: >
+---
diff --git a/content/en/guide/iso5230_guide/_index.md b/content/en/guide/iso5230_guide/_index.md
new file mode 100644
index 0000000000..6ddacfa86f
--- /dev/null
+++ b/content/en/guide/iso5230_guide/_index.md
@@ -0,0 +1,130 @@
+---
+title: "ISO/IEC 5230 Conformance Guide"
+linkTitle: "ISO/IEC 5230 Conformance Guide"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "License Compliance", "OpenChain"]
+description: >
+  A clause-by-clause conformance guide explaining all 24 verification material items of ISO/IEC 5230.
+---
+
+This guide walks through each requirement clause of ISO/IEC 5230 (OpenChain License Compliance) one by one.
+It explains what verification materials each clause requires, how to comply, and what sample documents
+can be used directly.
+
+**Author : OpenChain Korea Work Group / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)**
+
+## Target Audience
+
+- Open source compliance officers and open source program managers
+- Personnel at companies preparing for ISO/IEC 5230 certification
+- Practitioners who want to review their existing open source management framework against ISO standards
+
+## How to Use This Guide
+
+{{% alert title="Relationship with the Enterprise Open Source Management Guide" color="success" %}}
+
+The **[Enterprise Open Source Management Guide](../opensource_for_enterprise/)** explains how to implement open
+source management in practice (policies, processes, tools, and organization).
+
+**This guide (ISO/IEC 5230 Conformance Guide)** organizes, clause by clause, what must be demonstrated for certification.
+
+| Guide | Focus | When to Use |
+|-------|-------|-------------|
+| Enterprise Open Source Management Guide | Practical implementation (How to implement) | When building an open source management framework from scratch |
+| ISO/IEC 5230 Conformance Guide | Verification material criteria by clause (What to prove) | When preparing for certification or conducting a self-assessment |
+
+The two guides are complementary. Each clause page provides cross-links to the corresponding section of the
+Enterprise Open Source Management Guide.
+
+{{% /alert %}}
+
+## Full Clause Checklist
+
+ISO/IEC 5230 consists of **13 clauses and 24 verification material items**.
+
+### §3.1 Program Foundation
+
+| Clause | Title | Verification Materials | Details |
+|--------|-------|:---------------------:|---------|
+| §3.1.1 | Policy | 2 | [Go to](./1-program-foundation/1-policy/) |
+| §3.1.2 | Competence | 3 | [Go to](./1-program-foundation/2-competence/) |
+| §3.1.3 | Awareness | 1 | [Go to](./1-program-foundation/3-awareness/) |
+| §3.1.4 | Program Scope | 1 | [Go to](./1-program-foundation/4-scope/) |
+| §3.1.5 | License Obligations | 1 | [Go to](./1-program-foundation/5-license-obligations/) |
+
+### §3.2 Relevant Tasks
+
+| Clause | Title | Verification Materials | Details |
+|--------|-------|:---------------------:|---------|
+| §3.2.1 | External Inquiry Response (Access) | 2 | [Go to](./2-relevant-tasks/1-access/) |
+| §3.2.2 | Effective Resources (Effectively Resourced) | 5 | [Go to](./2-relevant-tasks/2-resourced/) |
+
+### §3.3 Content Review and Approval
+
+| Clause | Title | Verification Materials | Details |
+|--------|-------|:---------------------:|---------|
+| §3.3.1 | SBOM | 2 | [Go to](./3-content-review/1-sbom/) |
+| §3.3.2 | License Compliance | 1 | [Go to](./3-content-review/2-license-compliance/) |
+
+### §3.4 Compliance Artifacts
+
+| Clause | Title | Verification Materials | Details |
+|--------|-------|:---------------------:|---------|
+| §3.4.1 | Compliance Artifacts | 2 | [Go to](./4-artifacts/1-compliance-artifacts/) |
+
+### §3.5 Community Engagement
+
+| Clause | Title | Verification Materials | Details |
+|--------|-------|:---------------------:|---------|
+| §3.5.1 | Contributions | 3 | [Go to](./5-community/1-contributions/) |
+
+### §3.6 Adherence to the Specification
+
+| Clause | Title | Verification Materials | Details |
+|--------|-------|:---------------------:|---------|
+| §3.6.1 | Conformance | 1 | [Go to](./6-conformance/1-conformance/) |
+| §3.6.2 | Duration | 1 | [Go to](./6-conformance/2-duration/) |
+
+**Total: 13 clauses / 24 verification material items**
+
+## ISO/IEC 5230 Certification Process
+
+There are three ways to officially recognize conformance with ISO/IEC 5230.
+
+{{% pageinfo %}}
+
+**Step 1. Self-Certification**
+
+Complete an online checklist provided by the OpenChain Project to self-declare conformance.
+There is no cost and it can be started immediately.
+
+- Checklist: [https://certification.openchainproject.org/](https://certification.openchainproject.org/)
+- Suitable for: First-time certification preparation or internal assessment
+
+---
+
+**Step 2. Independent Assessment**
+
+An external expert or consulting organization evaluates the open source program. This is more
+credible than self-certification and is used to demonstrate compliance levels to supply chain partners.
+
+- Partner list: [Open Compliance Directory](https://www.openchainproject.org/find-a-partner)
+
+---
+
+**Step 3. Third-party Certification**
+
+An OpenChain-accredited certification body conducts an audit and issues an official certificate.
+This provides the highest level of credibility and is suitable for meeting global supply chain requirements.
+
+- Accredited certification bodies (as of 2024): ORCRO, PwC, TÜV SÜD, Synopsys, Bureau Veritas
+
+{{% /pageinfo %}}
+
+{{% alert title="Phased Approach Recommended" color="success" %}}
+For companies preparing for certification for the first time, it is recommended to proceed in stages:
+**Self-Certification → Independent Assessment → Third-party Certification**.
+Self-certification alone can satisfy the compliance level required by many supply chain partners.
+{{% /alert %}}
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/3rdpartycertifiers.png b/content/en/guide/opensource_for_enterprise/0-openchain/3rdpartycertifiers.png
new file mode 100644
index 0000000000..27b6eb1c3c
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/3rdpartycertifiers.png differ
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/_index.md b/content/en/guide/opensource_for_enterprise/0-openchain/_index.md
new file mode 100644
index 0000000000..ad6fb13d39
--- /dev/null
+++ b/content/en/guide/opensource_for_enterprise/0-openchain/_index.md
@@ -0,0 +1,209 @@
+---
+title: "0. Exploring OpenChain"
+linkTitle: "0. OpenChain"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["OpenChain", "ISO/IEC 5230", "ISO/IEC 18974"]
+description: >
+---
+
+## 1. What is the OpenChain Project?
+
+Software today is growing ever larger and more complex. Developing a single piece of software may involve not only internally developed code but also open source, third-party software, vendor SDKs, and a wide variety of software across the software supply chain.
+
+If even one organization in this complex software supply chain fails to comply with open source license obligations or does not provide accurate open source information, the company ultimately distributing the software will inevitably fail to meet its open source license compliance obligations. This can lead to lawsuits and the suspension of product sales.
+
+{{< imgproc supplychain Fit "900x600" >}}
+<center>[OpenChain Open Source Software License Compliance General Public Guide]</center>
+{{< /imgproc >}}
+
+In December 2009, there was a lawsuit involving an open source project called [Busybox](https://busybox.net/). Busybox is an open source project licensed under GPL-2.0 that is widely used in embedded systems, and 14 companies — including two Korean companies — were named in the lawsuit. A notable aspect of this case is that some of the companies sued were those that had only distributed the product without developing it themselves.
+
+In this complex software supply chain environment, even if one company has excellent processes in place, it is extremely difficult to achieve complete open source compliance on its own. Ultimately, for a company to properly fulfill its open source compliance obligations, all members of the software supply chain must comply with license obligations and provide accurate open source information. This trust must be built across the entire supply chain.
+
+The [Linux Foundation](https://www.linuxfoundation.org/)'s [OpenChain](https://www.openchainproject.org/) project was founded on the belief that by concisely and consistently defining the key requirements companies must follow for open source compliance, and ensuring universal adherence, trust in the open source license dimension can be built across the entire software supply chain.
+
+{{< imgproc openchainlogo Fit "600x450" >}}
+<center>[OpenChain Project Logo]</center>
+{{< /imgproc >}}
+
+At an open source conference in Europe in 2016, Dave Marr, an open source lawyer at Qualcomm, emphasized exactly this point. To raise the level of open source compliance at one company, the level of compliance across all members of the software supply chain must be raised. He also suggested that leading companies with a deep understanding of open source and already established policies and processes open up their assets and know-how so that anyone can reference them. Conference participants resonated with the idea that "open source compliance is not an area where companies can differentiate their business advantages. Companies want to manage risk at an appropriate level with minimal resources. Therefore, the more companies share their assets with each other, the more all can achieve compliance together with fewer resources." And so the OpenChain project (then a Work Group) was born, with global companies such as [Qualcomm](https://www.qualcomm.com/), [Siemens](https://www.siemens.com/), [Wind River](https://www.windriver.com/), [ARM](https://www.arm.com/), and [Adobe](https://www.adobe.com/) joining.
+
+The OpenChain project provides companies with three major things to help them achieve open source compliance more easily:
+
+1. [OpenChain Specification](https://www.openchainproject.org/get-started/conformance)
+2. [OpenChain Conformance Certification](https://certification.openchainproject.org/)
+3. [Documentation and Resources](https://www.openchainproject.org/resources)
+
+Let's explore how companies can leverage each of these.
+
+## 2. OpenChain Specification and ISO/IEC Standards
+
+The OpenChain Specification is a 10-page document defining the core requirements for open source compliance. OpenChain Specification Version 1.0 was released in 2016. The OpenChain Specification is designed to be suitable for all companies regardless of their size or industry.
+
+In 2020, Version 2.1 of the specification was released, defining six core requirements that companies must fulfill to achieve open source compliance, along with a list of materials needed to demonstrate compliance.
+
+1. Program Foundation
+2. Relevant Tasks Defined and Supported
+3. Open Source Content Review and Approval
+4. Compliance Artifact Creation and Delivery
+5. Understanding Open Source Community Engagements
+6. Adherence to the Specification Requirements
+
+For companies just starting with open source compliance, a good strategy is to work through each of the OpenChain Specification's requirements one by one to improve their level.
+
+{{< imgproc spec Fit "1200x900" >}}
+<center>< Source: https://github.com/OpenChain-Project/Specification/blob/master/Official/en/2.1/openchainspec-2.1.pdf></center>
+{{< /imgproc >}}
+
+This OpenChain Specification was formally registered as [ISO/IEC 5230:2020](https://www.iso.org/standard/81039.html), the international standard for open source compliance, in December 2020.
+
+{{< imgproc iso Fit "900x600" >}}
+<center>< Source: https://www.iso.org/standard/81039.html></center>
+{{< /imgproc >}}
+
+The OpenChain Specification, which had been a de facto standard for the past four years, was converted into the formal international standard ISO/IEC 5230:2020 — the first international standard defining open source compliance and process management. This has heightened interest among global IT companies in complying with ISO/IEC 5230, and it is expected that more companies in the software supply chain will begin requiring suppliers to comply with ISO/IEC 5230.
+
+In 2023, a new standard for open source security assurance, [ISO/IEC 18974](https://www.iso.org/standard/81039.html), was announced. This standard is based on the OpenChain Security Assurance Specification and defines the core requirements for managing known security vulnerabilities in open source software. ISO/IEC 18974 covers the following key areas:
+
+1. Identifying the key areas where security processes are needed
+2. How to assign roles and responsibilities
+3. How to ensure the sustainability of processes
+
+Like ISO/IEC 5230, ISO/IEC 18974 is concise and easy to understand, and is supported by the global community to provide free reference materials and conformance resources.
+
+These two standards work together to help organizations effectively manage license compliance and security assurance for open source software. While ISO/IEC 5230 focuses on license compliance, ISO/IEC 18974 focuses on security vulnerability management, making them complementary to each other.
+
+
+## 3. How to Obtain ISO/IEC Standard Certification
+
+If a company complies with all the requirements of both ISO/IEC 5230 and ISO/IEC 18974, it can be certified as having an open source program conformant with these standards. An open source program refers to the set of management systems — including policies, processes, and personnel — that a company uses to carry out open source compliance and security assurance activities.
+
+The image below lists the item numbers required by ISO/IEC 5230. Companies that satisfy all of these items can be recognized as having established a transparent and trustworthy open source governance system in the software supply chain.
+
+{{< imgproc spec3111 Fit "900x600" >}}
+{{< /imgproc >}}
+
+The [OpenChain Project](https://www.openchainproject.org/) proposes three methods of certification:
+
+* Self-certification
+* Independent evaluation
+* Third-party certification
+
+{{< imgproc certify Fit "900x600" >}}
+<center><i> https://www.openchainproject.org/get-started/conformance </i></center>
+{{< /imgproc >}}
+
+Let's look at each method.
+
+### (1) Self-certification
+
+Self-certification is the most recommended method by the OpenChain project, with the advantage of being free of charge. The OpenChain Project provides an [ISO/IEC 5230 self-certification website](https://openchainproject.org/checklist-iso-5230-2020) so that companies can verify for themselves whether they comply with the OpenChain Specification. The open source officers of a company can register on this website and begin the online self-certification process. Self-certification proceeds by answering Yes/No questions as shown below.
+
+{{< imgproc question Fit "900x600" >}}
+<center>< Source: https://certification.openchainproject.org/></center>
+{{< /imgproc >}}
+
+If a company has established its open source compliance system well enough to answer Yes to all the questions in the OpenChain self-certification, it can submit those results on the website (Conforming Submission). After a simple confirmation procedure by the [Linux Foundation](https://www.linuxfoundation.org/), the company can then declare ISO/IEC 5230 conformance.
+
+{{< imgproc sktannounce Fit "900x600" >}}
+<center><Example: SK Telecom conformance declaration - Source: https://www.openchainproject.org/featured/2021/09/08/sk-telecom></center>
+{{< /imgproc >}}
+
+By making this conformance declaration, the company is recognized in the Global Software Supply Chain as having an open source program that complies with ISO/IEC 5230.
+
+{{< imgproc announcelogo Fit "900x600" >}}
+<center>< Companies that have declared conformant open source programs, Source - https://www.openchainproject.org/ ></center>
+{{< /imgproc >}}
+
+The OpenChain project recommends the self-certification method. For reference, most companies that have declared OpenChain conformance have also adopted the self-certification method.
+
+In addition, companies can use the self-certification process to identify what is lacking and what additional activities are needed. This guide explains how to comply with ISO/IEC 5230 and ISO/IEC 18974 requirements for each major component such as organization, policy, and process.
+
+Companies that lack the capacity to make improvements on their own through this guide alone may consider the independent evaluation method.
+
+### (2) Independent Evaluation
+
+In an independent evaluation, an independent external organization assesses and evaluates a company's open source compliance and security assurance status from a fair perspective. The distinguishing feature of an independent evaluation is that it not only generates an assessment report but also provides consulting to address the identified deficiencies. (However, it does not issue an accredited certification.)
+
+Companies can improve their compliance and security assurance levels through fair assessment and consulting from an independent organization, and then go through a repeating process of independent evaluation again to refine policies and build processes.
+
+{{< imgproc independent2 Fit "900x1200" >}}
+<center>< Independent Compliance Assessment, Source - https://youtu.be/DEBd-g0Ab8E ></center>
+{{< /imgproc >}}
+
+Ultimately, the company reaches the level where it can obtain ISO/IEC 5230 and ISO/IEC 18974 certification, at which point it can enter the process of obtaining self-certification or third-party certification. Independent evaluation thus supports companies in raising their level of open source compliance and security assurance through assessment and consulting, helping them obtain conformant programs and achieve certification.
+
+Companies offering independent evaluation include [AlektoMetis](https://alektometis.com/), [Source Code Control](https://sourcecodecontrol.co/), and others.
+
+In Korea, the [Conformance Group](https://openchain-project.github.io/OpenChain-KWG/subgroup/conformance/), a subgroup of the OpenChain Korea Work Group, operates as a community where companies discuss and share methods for complying with ISO/IEC 5230 and ISO/IEC 18974 independently. Any OpenChain Korea Work Group member is welcome to participate and receive assistance.
+
+### (3) Third-party Certification
+
+If a company wants to demonstrate a more credible and transparent level of open source compliance and security assurance to buyers in the software supply chain, it can obtain a certificate from a third-party certification body and use it for promotional purposes. Additionally, some buyers who require a more robust level of trust in open source compliance and security assurance may mandate third-party certification from their suppliers.
+
+As of 2024, the officially recognized OpenChain third-party certification bodies are [ORCRO](https://orcro.co.uk/), [PWC](https://www.pwc.de/en/opensource), [TÜV SÜD](https://www.tuvsud.com/), [Synopsys](https://www.synopsys.com/), and [Bureau Veritas](https://group.bureauveritas.com/).
+
+{{< imgproc 3rdpartycertifiers Fit "900x600" >}}
+<center>< Third-Party Certifiers, Source - https://www.openchainproject.org/partners ></center>
+{{< /imgproc >}}
+
+These bodies provide assessments to verify conformant programs under ISO/IEC 5230 and ISO/IEC 18974 and issue certificates to companies that pass.
+
+{{< imgproc pwc Fit "900x600" >}}
+<center>< PWC certification, Source - https://youtu.be/HslvXCM-4pQ ></center>
+{{< /imgproc >}}
+
+As of 2024, there are still few buyers or organizations that mandatorily require third-party certification. However, in the European automotive industry, some experts predict that it will not be long before ISO/IEC 5230 and ISO/IEC 18974 are mandated for automotive software suppliers, similar to [ASPICE](http://www.automotivespice.com/) (Automotive SPICE, the international standard process model for automotive software development).
+
+For detailed information on the self-certification process, you can refer to the following slides:
+
+* [OpenChain Korea 9th Meeting - How to Self Certify](https://openchain-project.github.io/OpenChain-KWG/meeting/9th/OpenChain_Korea_20210311_howto.pptx)
+
+
+
+## 4. OpenChain Resources
+
+The [OpenChain Project](https://www.openchainproject.org/) provides a variety of documentation such as policy document templates and educational materials needed by companies to build their compliance programs. These materials are designed to help comply with the OpenChain Specification and support general open source compliance activities, and are provided under a CC-0 license so anyone can use them freely.
+
+{{< imgproc resource Fit "900x600" >}}
+<center>< OpenChain Curriculum, Source - https://www.openchainproject.org/resources ></center>
+{{< /imgproc >}}
+
+Much of the content in this guide is also based on materials published by OpenChain. Open source officers at each company are encouraged to look to OpenChain Resources first when they need policies, processes, or educational materials. These materials are also being translated into Korean. The [OpenChain Korea Work Group](https://openchain-project.github.io/OpenChain-KWG/) is leading these translation efforts. Anyone interested can [participate](https://openchain-project.github.io/OpenChain-KWG/resource/) in the Korean translation.
+
+The OpenChain Project also runs various webinars and study groups to provide additional resources:
+
+1. Webinars: The OpenChain Project regularly hosts webinars to share the latest trends and best practices in open source compliance and security. These webinars can be found on the [OpenChain website](https://openchainproject.org/webinars), with recordings also available.
+
+2. Educational Materials: The OpenChain Project provides a [comprehensive educational curriculum](https://github.com/OpenChain-Project/Reference-Material) to help companies develop internal training programs. These materials cover a wide range of topics from the basics of open source software to license compliance and security assurance.
+
+By utilizing these diverse resources, companies can build and maintain a robust open source program that complies with the ISO/IEC 5230 and ISO/IEC 18974 standards.
+
+
+## 5. Trends in ISO/IEC Standard Adoption
+
+The adoption of ISO/IEC 5230 and ISO/IEC 18974 standards is showing an increasingly expanding trend in the global software supply chain.
+
+In early 2021, news emerged that German automotive manufacturers began requiring parts suppliers to have plans to comply with ISO/IEC 5230. In response, a European open source professor stated, "It is obvious that software supply chain buyers will require suppliers to comply with ISO/IEC 5230 in the future," predicting that "it will take a position similar to ASPICE in the automotive industry."
+
+Reflecting this forecast, in May 2021, Volkswagen Group's [Scania](https://www.scania.com/) included a requirement to comply with ISO/IEC 5230 in its own corporate standard (STD 4589) that suppliers must follow.
+
+{{< imgproc scania Fit "900x600" >}}
+<center><i>linkedin, May 2021</i></center>
+{{< /imgproc >}}
+
+Also, in July 2021, automotive and industrial technology company [Bosch](https://www.bosch.com/) declared that all group companies would have programs complying with ISO/IEC 5230 by year's end. The industry predicts that it is only a matter of time before all automakers and other industries begin requiring ISO/IEC 5230 within the software supply chain.
+
+{{< imgproc bosch Fit "900x600" >}}
+<center><i>linkedin, July 2021</i></center>
+{{< /imgproc >}}
+
+In 2023, a new standard for open source security assurance, ISO/IEC 18974, was announced. This standard defines the core requirements for managing known security vulnerabilities in open source software. Together with ISO/IEC 5230, ISO/IEC 18974 helps organizations effectively manage license compliance and security assurance for open source software.
+
+As of 2024, this trend is accelerating further. For example, [KT](https://www.kt.com/) announced in October 2024 that it had obtained ISO/IEC 18974 certification. This demonstrates that domestic companies are also actively adopting international standards for open source security management.
+
+The activities of the [OpenChain Korea Work Group](https://openchain-project.github.io/OpenChain-KWG/) are also becoming more vibrant. At the 22nd regular meeting held in June 2024, discussions were held on the current state of preparations for the ISO/IEC 18974 open source security standard and guidelines for SBOM-based SW supply chain management. This shows that domestic companies are actively embracing the ISO/IEC 5230 and ISO/IEC 18974 standards.
+
+This trend is expected to continue in the future. As the complexity of software supply chains increases and security threats grow, the importance of international standards such as ISO/IEC 5230 and ISO/IEC 18974 will only become greater. By complying with these standards, companies will be able to enhance the transparency of open source use and effectively manage security risks.
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/announcelogo.png b/content/en/guide/opensource_for_enterprise/0-openchain/announcelogo.png
new file mode 100644
index 0000000000..c1dfb44894
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/announcelogo.png differ
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/bosch.png b/content/en/guide/opensource_for_enterprise/0-openchain/bosch.png
new file mode 100644
index 0000000000..634351a275
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/bosch.png differ
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/certify.png b/content/en/guide/opensource_for_enterprise/0-openchain/certify.png
new file mode 100644
index 0000000000..1ae724ae7a
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/certify.png differ
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/independent.png b/content/en/guide/opensource_for_enterprise/0-openchain/independent.png
new file mode 100644
index 0000000000..4faeeb3e2c
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/independent.png differ
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/independent2.png b/content/en/guide/opensource_for_enterprise/0-openchain/independent2.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/independent2.png
rename to content/en/guide/opensource_for_enterprise/0-openchain/independent2.png
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/iso.png b/content/en/guide/opensource_for_enterprise/0-openchain/iso.png
new file mode 100644
index 0000000000..eed9f4ea84
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/iso.png differ
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/openchainlogo.png b/content/en/guide/opensource_for_enterprise/0-openchain/openchainlogo.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/openchainlogo.png
rename to content/en/guide/opensource_for_enterprise/0-openchain/openchainlogo.png
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/pwc.png b/content/en/guide/opensource_for_enterprise/0-openchain/pwc.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/pwc.png
rename to content/en/guide/opensource_for_enterprise/0-openchain/pwc.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/question.png b/content/en/guide/opensource_for_enterprise/0-openchain/question.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/question.png
rename to content/en/guide/opensource_for_enterprise/0-openchain/question.png
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/resource.png b/content/en/guide/opensource_for_enterprise/0-openchain/resource.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/resource.png
rename to content/en/guide/opensource_for_enterprise/0-openchain/resource.png
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/scania.png b/content/en/guide/opensource_for_enterprise/0-openchain/scania.png
new file mode 100644
index 0000000000..e925c580dc
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/scania.png differ
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/sktannounce.png b/content/en/guide/opensource_for_enterprise/0-openchain/sktannounce.png
new file mode 100644
index 0000000000..9160c708ae
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/sktannounce.png differ
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/spec.png b/content/en/guide/opensource_for_enterprise/0-openchain/spec.png
new file mode 100644
index 0000000000..9f7b3f8745
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/spec.png differ
diff --git a/content/en/guide/opensource_for_enterprise/0-openchain/spec3111.png b/content/en/guide/opensource_for_enterprise/0-openchain/spec3111.png
new file mode 100644
index 0000000000..84bc989c6c
Binary files /dev/null and b/content/en/guide/opensource_for_enterprise/0-openchain/spec3111.png differ
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/supplychain.png b/content/en/guide/opensource_for_enterprise/0-openchain/supplychain.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/supplychain.png
rename to content/en/guide/opensource_for_enterprise/0-openchain/supplychain.png
diff --git a/content/en/guide/opensource_for_enterprise/4-tool/_index.md b/content/en/guide/opensource_for_enterprise/4-tool/_index.md
index 00b48b8b0f..7d3a62867d 100644
--- a/content/en/guide/opensource_for_enterprise/4-tool/_index.md
+++ b/content/en/guide/opensource_for_enterprise/4-tool/_index.md
@@ -35,6 +35,12 @@ In addition, LG Electronics has released the [FOSSLight Dependency Scanner](http
 <center><i>https://fosslight.org/ko/scanner/</i></center>
 {{< /imgproc >}}
 
+[cdxgen](https://github.com/CycloneDX/cdxgen), managed by OWASP, is an open source SBOM generation tool that supports 20+ languages and ecosystems (Java, Node.js, Python, Go, Rust, etc.) and outputs CycloneDX format SBOMs. It integrates easily with CI/CD pipelines. For installation and usage, refer to the [cdxgen guide](../../tools/5-cdxgen/).
+
+[Syft](https://github.com/anchore/syft), developed by Anchore, is an open source SBOM generation CLI tool that scans container images, filesystems, and archives to generate SBOMs in SPDX or CycloneDX format. It pairs naturally with Anchore's Grype vulnerability scanner for SBOM-based vulnerability analysis. For installation and usage, refer to the [Syft guide](../../tools/6-syft/).
+
+These dependency analysis tools help accurately identify open source components in distributed software and generate SBOMs, satisfying the requirements of ISO/IEC 5230 and ISO/IEC 18974.
+
 
 ## 3. SBOM Management Tools
 
@@ -73,6 +79,8 @@ LG Electronics has been managing the SBOM for all business units' distribution s
 <center><i>https://fosslight.org/</i></center>
 {{< /imgproc >}}
 
+[Dependency-Track](https://dependencytrack.org/), managed by OWASP, is an open source SBOM management and vulnerability analysis platform. It continuously monitors component-level vulnerabilities based on uploaded SBOMs and automatically evaluates policy violations. It integrates with NVD, OSV, and other vulnerability databases for automatic detection, and supports REST API for CI/CD pipeline integration. For installation and usage, refer to the [Dependency-Track guide](../../tools/7-dependency-track/).
+
 ## 4. Open Source Vulnerability Management Tools
 
 Companies need to track products/services that contain known vulnerabilities and resolve them. To do this, companies need to build a tool environment that automates this.
@@ -83,6 +91,9 @@ The method of managing security vulnerabilities with SW360 can be referred to in
 
 [FOSSLight](https://fosslight.org/ko/) also automatically acquires security vulnerability information and automatically checks project information where security vulnerabilities have been detected, providing notifications such as emails as needed.
 
+[OSV-SCALIBR](https://github.com/google/osv-scalibr), developed by Google, is an open source software composition analysis (SCA) library that extracts open source components from filesystems and container images and detects vulnerabilities by integrating with the OSV (Open Source Vulnerabilities) database. It supports Python, Go, Java, npm, and other major package ecosystems, and is suitable for integration into CI/CD pipelines to automatically detect vulnerabilities at build and deployment stages. For installation and usage, refer to the [OSV-SCALIBR guide](../../tools/4-osvscalibr/).
+
+These tools help companies effectively manage open source security vulnerabilities while satisfying the requirements of ISO/IEC 18974.
 
 
 ## 5. Open Source Compliance Artifact Generation Tool
diff --git a/content/en/guide/opensource_for_enterprise/_index.md b/content/en/guide/opensource_for_enterprise/_index.md
index f64cb784e8..84925169d3 100644
--- a/content/en/guide/opensource_for_enterprise/_index.md
+++ b/content/en/guide/opensource_for_enterprise/_index.md
@@ -1,8 +1,8 @@
 
 ---
-title: "ISO Standard-Based Enterprise Open Source Management Guide"
-linkTitle: "Open Source Management Guide"
-weight: 20
+title: "[2026] ISO Standard-Based Enterprise Open Source Management Guide"
+linkTitle: "2026 Open Source Management Guide"
+weight: 10
 type: docs
 description: >
   This guide introduces ways for enterprises to effectively manage open source based on ISO international standards.
@@ -10,11 +10,25 @@ description: >
 
 {{% pageinfo %}}
 
-If an organisation fails to manage open source, it may encounter risks such as license non-compliance and security breaches. Therefore, what and how should we manage it?
+Open source is an essential element of modern software development. However, without proper management, organizations can face serious risks such as license compliance violations and security vulnerability exposures.
 
-In this article, we will examine the minimum core requirements and techniques that organisations need to implement for managing open source based on ISO international standards.
+This guide presents the core requirements and concrete implementation methods that enterprises need to perform to effectively manage open source, based on ISO international standards.
 
-**Author: Haksung Jang (haksung@sktelecom.com) / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)**
+**Author: OpenChain Korea Work Group / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)**
+
+**Recent Updates (2026.3.26):**
+- Tools: New tool pages added for cdxgen, Syft, Dependency-Track, and OSV-SCALIBR
+- Policy Template: Missing ISO/IEC 5230·18974 clauses supplemented
+  (compliance artifact retention period, CVSS action deadlines, SBOM standard format declaration, etc.)
+- Process Template: SBOM procedure improvements and new contribution, release, and training processes added
+- Guide: Internal link improvements and new tool integrations
+
+**Recent Updates (2025.1.6):**
+- Added ISO/IEC 18974 (OpenChain Security Assurance Specification) content
+- Detailed open source security assurance processes and requirements
+- Enhanced SBOM (Software Bill of Materials) management content
+- Improved open source contribution and release processes
+- Added program effectiveness measurement and continuous improvement methods
 
 {{% /pageinfo %}}
 
@@ -25,31 +39,29 @@ There are two global standards for open source management:
 1. [ISO/IEC 5230](https://www.iso.org/standard/81039.html): OpenChain Specification - International standard for open source compliance.
 2. [ISO/IEC 18974](https://www.iso.org/standard/86450.html): OpenChain Security Assurance Specification - International standard for Open Source Security
 
-## OpenChain Project
-
-The international standard for managing these open sources was created by the OpenChain Project. For an introduction to this, please refer to the following page: [OpenChain Project](https://www.openchainproject.org/)
-
-## What should companies do?
+## OpenChain and ISO/IEC 5230
 
-If a company complies with the requirements of the two standards (ISO/IEC 5230, ISO/IEC 18974), it can be seen as effectively managing open source.
+ISO/IEC 5230 is the only international standard for open source compliance, defining the core requirements for organizations to build an effective open source program. For details, see the [OpenChain Overview](./0-openchain/) page.
 
-So, what should companies do to comply with the standards? It needs to have the following six components:
+## How Should Companies Manage Open Source?
 
-1. Organization
-2. Policy
-3. Process
-4. Tools
-5. Education
-6. Conformance
+By complying with the requirements of ISO/IEC 5230 and ISO/IEC 18974, companies can establish an effective open source management system. To do this, companies need the following six core elements:
 
-To comply with the standards, companies must adhere to these six components:
+1. **Organization**: Dedicated team for open source management
+2. **Policy**: Clear open source policy established and documented
+3. **Process**: Systematic processes for open source use, contribution, and distribution
+4. **Tools**: Automated tools for open source inspection, tracking, and management
+5. **Education**: Awareness and capability-building training for employees
+6. **Conformance**: Maintaining standards compliance through continuous monitoring and improvement
 
+This guide provides detailed methods and examples for how companies can implement each element.
 
 ## References
 
 {{% pageinfo %}}
 1. [OpenChain Project Website](https://www.openchainproject.org/)
-2. [OpenChain Specification 2.0](https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2.0.pdf)
-3. [OpenChain Open Source Policy Template](https://www.openchainproject.org/news/2019/01/17/openchain-open-source-policy-template-now-available)
-4. [Open Source Compliance In The Enterprise](https://www.linuxfoundation.org/compliance-and-security/2018/12/open-source-compliance-in-the-enterprise/)
+2. [OpenChain ISO/IEC 5230](https://www.openchainproject.org/license-compliance)
+3. [OpenChain ISO/IEC 18974](https://www.openchainproject.org/security-assurance)
+4. [OpenChain Open Source Policy Template](https://www.openchainproject.org/news/2019/01/17/openchain-open-source-policy-template-now-available)
+5. [Open Source Compliance In The Enterprise](https://www.linuxfoundation.org/compliance-and-security/2018/12/open-source-compliance-in-the-enterprise/)
 {{% /pageinfo %}}
diff --git a/content/en/guide/templates/1-policy/_index.md b/content/en/guide/templates/1-policy/_index.md
index 2c4f00d883..352a7b7340 100644
--- a/content/en/guide/templates/1-policy/_index.md
+++ b/content/en/guide/templates/1-policy/_index.md
@@ -166,6 +166,12 @@ All members who are responsible for the roles defined in Chapter 4 must take the
 
 The education history and evaluation results are kept in the [Learning Portal] for at least 3 years.
 
+### Assessment Evidence Retention Procedure
+
+- Evidence of competency assessment shall be collected and retained in one or more of the following forms: test scores, training completion certificates, policy awareness confirmation signatures. (ISO/IEC 5230 §3.1.3, ISO/IEC 18974 §3.1.3)
+- Evidence shall be registered in the internal document management system (e.g., Learning Portal, HR system) and maintained in a state that can be immediately produced during audits.
+- After the retention period expires, records shall be destroyed in accordance with the personal data protection policy.
+
 ## 6. Open Source Use
 
 When developing and distributing products and services using open source, you must comply with the obligations required by each open source license. This activity is called open source compliance.
@@ -193,6 +199,17 @@ Understand the combination relationship of open source and design the software a
 
 The company's [Open Source License Guide] explains the range of source code disclosure for each open source license and how to design to prevent the disclosure of our code.
 
+### (2-1) License Use Case Policy
+
+The following guidelines apply depending on how open source components are used:
+
+1. **Internal use only**: When open source is used internally without external distribution, there is no obligation to generate compliance deliverables, but SBOM records must still be maintained.
+2. **External distribution (binary)**: If licenses that require source code disclosure (e.g., GPL) are included, a source code package must be provided along with the binary, or a written offer must be included.
+3. **External distribution (SaaS/network service)**: If licenses that treat network use as distribution (e.g., AGPL) are included, a separate legal review is required.
+4. **Contribution to open source projects**: Confirm that the license applied to contributed code is compatible with the project's license.
+
+For each use case, compliance deliverables are created and managed according to the procedures in §4.3.
+
 ### (3) Creation of Open Source Compliance Deliverables
 
 The most basic of open source compliance activities is to understand the status of open source included in distributed software. This is to properly meet the core of open source compliance, which is the requirements of the open source license. In other words, you need to create a set of compliance deliverables for the open source included in the distributed software.
@@ -207,6 +224,7 @@ To collect, distribute, and store these compliance deliverables, comply with the
 - The open source notice or source code package to be disclosed is collected according to the conditions required by each license. For example, if the license requires the entire text of the license to be enclosed, you cannot just provide a link.
 - The collected deliverables are stored in a separate repository.
 - If the source code to be disclosed is provided by a written agreement, the download link is made public so that the repository of the collected deliverables can be accessed from the outside.
+- Compliance deliverables shall be retained for a minimum of 3 years from the date of the last distribution of the supplied software. If a license requires a longer retention period, that period takes precedence. (ISO/IEC 5230 §3.4.1.2)
 
 You can issue an open source notice and collect a source code package to be disclosed through the company's open source process.
 
@@ -214,6 +232,8 @@ You can issue an open source notice and collect a source code package to be disc
 
 You must create and manage the status of open source included in distributed software (BOM: Bill of Materials).
 
+- SBOMs shall be generated in one of the following standard formats: SPDX or CycloneDX. (ISO/IEC 18974 §3.3.1.2)
+
 You can create and preserve SBOM using open source tools through the company's open source process.
 
 ### (5) Compliance Issue Response Procedure
@@ -231,7 +251,9 @@ If a compliance issue is raised, the open source program manager performs the fo
 
 - We identify open source vulnerabilities and evaluate their severity.
 - Based on the analysis of open source vulnerabilities, we either fix the vulnerability or apply a security patch. The decision to address vulnerabilities takes into account the severity of the vulnerability, the importance of the system, and the availability of vulnerability fixes or security patches.
+- Remediation actions shall be completed within the following deadlines based on vulnerability severity: Critical (CVSS 9.0 or above) within 1 week, High (CVSS 7.0–8.9) within 4 weeks. (ISO/IEC 18974 §3.3.2.1)
 - We monitor the announcement of new open source security vulnerabilities and respond quickly when vulnerabilities occur. Open source vulnerability monitoring can be performed through vulnerability databases such as CVE and websites of security specialist organizations.
+- All vulnerability response records shall be retained for a minimum of 3 years from the date of the last distribution of the relevant supplied software. (ISO/IEC 18974 §3.3.2.2)
 
 ## 7. Open Source Contribution
 
@@ -295,6 +317,11 @@ However, if you are modifying existing code for purposes such as bug fixes, you
 
 When contributing to an open source project, do not use personal email, use company email. Through this, (1) members have a sense of responsibility to communicate with the community on behalf of the company, and (2) the company can improve its recognition as a company that actively contributes to the open source community.
 
+### (7) Contribution Policy Awareness Procedure
+
+1. **Mandatory policy awareness**: All program participants must be aware of the existence and content of the external open source contribution policy (§7) and internal project release policy (§8). The OSPO shall notify new participants of the contribution policy during onboarding and reconfirm it through annual training. (ISO/IEC 5230 §3.1.3)
+2. **Awareness confirmation and records**: The OSPO shall confirm policy awareness and maintain the results as records. Awareness confirmation records shall be retained for a minimum of 3 years.
+
 ## 8. Open Source Release
 
 The company respects the value of collaboration with the open source community and encourages the release of internal software to open source projects. However, there are a few rules to follow to protect the company's intellectual property and prevent unintended copyright infringement.
@@ -363,6 +390,10 @@ The Open Source Program Manager provides contact information publicly so that ou
 
 If you respond quickly and accurately to open source inquiries from outside, you can greatly reduce the risk of claims or legal litigation. To this end, the company complies with the external inquiry response procedure defined in the company's open source process to respond to external open source inquiries.
 
+### (4) Record Retention
+
+- External inquiry response records shall be retained for a minimum of 3 years from the date the inquiry is closed. (ISO/IEC 18974 §3.2.1.2)
+
 ## 10. Declaration and Maintenance of Compliance with ISO Standards
 
 The company supports the spirit of the OpenChain project of the Linux Foundation for improving the level of open source compliance in the software supply chain and actively participates.
diff --git a/content/en/guide/templates/2-process-template/_index.md b/content/en/guide/templates/2-process-template/_index.md
index 8e755e7136..7ab6abfbd8 100644
--- a/content/en/guide/templates/2-process-template/_index.md
+++ b/content/en/guide/templates/2-process-template/_index.md
@@ -84,6 +84,8 @@ The open source program manager finalizes the BOM to track the open source usage
 
 The IT manager registers the finalized BOM in the system. The BOM includes a list of open sources included in the software for distribution and the following information.
 
+SBOMs shall be written in SPDX or CycloneDX standard format, and format compliance shall be verified before registration.
+
 - Product (or service) name and version of the software for distribution
 - Open source list
   - Open source name / version
@@ -126,6 +128,8 @@ The open source program manager submits the compliance deliverables provided by
 
 The IT manager registers the compliance deliverables on the company's open source distribution site.
 
+If customers request it, the IT manager shall prepare to provide the SBOM for the relevant supplied software to the customer.
+
 ### (10) Final Verifications
 
 The open source program manager comprehensively verifies whether the compliance deliverables have been properly registered on the company's open source portal and whether they can be downloaded without issues from outside.
@@ -134,6 +138,8 @@ The open source program manager comprehensively verifies whether the compliance
 
 The open source program manager periodically checks for products with inadequate generation of open source compliance deliverables. They also operate a process to respond quickly to external inquiries. The detailed procedure for responding to external inquiries follows [2. External Inquiry Response Process].
 
+If an open source component is added, changed, or removed; a new vulnerability is discovered; or a license change is confirmed, the SBOM for the relevant supplied software shall be updated immediately.
+
 The security manager operates a process to monitor and respond to newly known vulnerabilities. The detailed procedure for responding to new security vulnerabilities follows [3. New Security Vulnerability Management Process].
 
 ## 2. New Security Vulnerability Management Process
@@ -180,6 +186,8 @@ The security manager reviews whether all serious vulnerabilities have been resol
 
 The IT manager registers the SBOM, which has resolved the open source security vulnerability, in the system.
 
+Vulnerability response records shall be retained for a minimum of 3 years from the date of the last distribution of the relevant supplied software. (ISO/IEC 18974 §3.3.2.2)
+
 ### (7) Notification
 
 The open source program manager generates an open source notice based on the SBOM that has resolved the open source security vulnerability and delivers it to the business department.
@@ -196,6 +204,21 @@ The security manager identifies whether there is risk information that needs to
 
 The IT manager registers the identified risk information on the open source website so that third parties can check it.
 
+### (9) Vulnerability Disclosure Timing Procedure (CVD)
+
+For newly discovered vulnerabilities (discovered internally or reported by external researchers), the Coordinated Vulnerability Disclosure (CVD) procedure is followed:
+
+1. **Pre-disclosure coordination**:
+    - Immediately notify the maintainers of the affected open source project privately upon discovery.
+    - As a principle, disclose within 90 days of the initial notification to allow sufficient time for patch development and deployment.
+    - The disclosure schedule may be adjusted through negotiation with maintainers, and the agreed schedule shall be documented.
+2. **Immediate disclosure exceptions**:
+    - If the vulnerability is already publicly known and being exploited, or if there is an immediate threat, it may be disclosed immediately without a coordination period.
+    - Immediate disclosure decisions shall be jointly approved by the security manager and the open source program manager.
+3. **Disclosure content and channels**:
+    - Apply for CVE ID issuance (MITRE or CNA) in parallel with disclosure.
+    - Vulnerability details, scope of impact, and patch or mitigation methods shall be posted on the company's security advisory page and relevant public databases (e.g., NVD).
+
 ## 3. External Inquiry Response Process
 
 If you respond quickly and accurately to open source compliance inquiries from outside, you can greatly reduce the risk of proceeding to litigation. To this end, companies comply with the following process to respond to external open source compliance inquiries.
@@ -213,6 +236,7 @@ The main contents of the inquiries and requests that require a response are as f
 - Explanation and source code disclosure request for open source found in the product but not specified in the open source notice
 - Request for provision of missing files and build methods in the source code disclosed due to obligations such as GPL, LGPL
 - Request for copyright notice
+- Inquiry about known or newly discovered vulnerabilities
 
 The open source program manager creates a Jira Issue for the received request and records all the response situations in detail.
 
@@ -243,4 +267,161 @@ After resolving the issue, they immediately notify the requester and provide the
 
 ### (7) Improve
 
-In case of a compliance issue, the case is reviewed through the OSRB meeting, the circumstances of the occurrence of the problem are identified, and the process is improved so that the problem does not recur.
\ No newline at end of file
+In case of a compliance issue, the case is reviewed through the OSRB meeting, the circumstances of the occurrence of the problem are identified, and the process is improved so that the problem does not recur.
+
+### (8) Record Retention
+
+The open source program manager records the entire external inquiry response process (receipt, investigation, response, resolution) in the issue tracking system. These records shall be retained for a minimum of 3 years from the date the inquiry is closed. (ISO/IEC 18974 §3.2.1.2)
+
+Records shall include the following:
+
+- Date and time of inquiry receipt and requester information
+- Inquiry content and classification (license compliance / security vulnerability)
+- Internal investigation results and response actions taken
+- Final resolution and completion date
+
+## 4. Open Source Contribution Process
+
+When program participants contribute to external open source projects, they must follow the procedures below to protect the company's intellectual property and ensure license compatibility. For detailed policy, refer to [Open Source Policy §7](../1-policy/).
+
+### (1) Intent Confirmation and Pre-Review Request
+
+Program participants must request a contribution review from the OSPO before contributing to an external open source project.
+
+Information to include in the request:
+- Name and repository URL of the target project
+- Summary of the contribution (bug fix, feature addition, etc.)
+- Source of the contributed code (self-authored or company-owned)
+- Whether any company patents are included
+
+### (2) OSPO Review and Approval
+
+The OSPO reviews the contribution request and verifies the following:
+
+1. **License compatibility**: Confirm whether the license of the contributed code is compatible with the target project's license.
+2. **Intellectual property review**: Confirm that the contributed code does not contain company patents or sensitive information. Request legal team advice if necessary.
+3. **CLA review**: If the target project requires signing a CLA (Contributor License Agreement), review the terms and confirm there are no copyright assignment clauses.
+
+After completing the review, the OSPO notifies the requester of the approval or rejection decision.
+
+### (3) Performing the Contribution
+
+For approved contributions, program participants must comply with the following when contributing:
+
+- Include the company copyright notice and SPDX license identifier at the top of each file.
+- Use the company email when contributing.
+- Contribute only code authored by the participant or code for which the company holds the rights.
+
+### (4) Contribution History Recording and Retention
+
+The OSPO records all approved contributions in the internal system.
+
+Record items:
+- Target project and date of contribution
+- Summary of contribution
+- Approver and approval date
+- Whether CLA was signed
+
+Contribution records shall be retained for a minimum of 3 years.
+
+## 5. Internal Project Release Process
+
+When releasing internally developed projects as open source, the following procedures must be followed to protect the company's intellectual property and ensure appropriate license selection. For detailed policy, refer to [Open Source Policy §8](../1-policy/).
+
+### (1) Release Review Request
+
+The department wishing to release must request a release review from the OSPO.
+
+Information to include in the request:
+- Project overview and purpose of release
+- Scope of release (code, documentation, etc.)
+- Whether any patents are included
+- List of dependent third-party libraries
+
+### (2) OSPO Review and Approval
+
+The OSPO reviews the following:
+
+1. **Intellectual property review**: Confirm that the release code does not contain company patents, trade secrets, or sensitive information. Request legal team advice if necessary.
+2. **License selection**: Select an appropriate open source license considering the purpose of release (community building, standards contribution, etc.) and intellectual property protection.
+3. **Dependency license compatibility**: Confirm that the licenses of included third-party components are compatible with the selected release license.
+
+### (3) Release Preparation
+
+After approval, the responsible department performs the following:
+
+- Remove sensitive information (API keys, internal server addresses, etc.) from the code.
+- Include copyright notice and SPDX license identifier at the top of each file.
+- Write README, contribution guide (CONTRIBUTING.md), and license file (LICENSE).
+- Register the project on a public repository such as GitHub.
+
+### (4) Post-Release Management
+
+The OSPO and responsible department perform the following for continuous maintenance of the released project:
+
+- Periodically review and respond to external contributions (Pull Requests, Issues).
+- When security vulnerabilities are reported, respond according to the §2 Security Vulnerability Management Process.
+- Periodically review the project status (active/maintenance/archived) and state it clearly in the README.
+
+### (5) Release Record Retention
+
+The OSPO retains release approval records and related review records for a minimum of 3 years.
+
+Retention items:
+- Request and approval date/time, approver
+- Selected license and rationale for selection
+- Intellectual property review results
+- Public repository URL
+
+## 6. Training and Evaluation Process
+
+To ensure that open source program participants sufficiently understand the policies and processes and maintain their competencies, training and competency evaluation are conducted according to the following procedures. For detailed policy, refer to [Open Source Policy §6](../1-policy/).
+
+### (1) Determining Training Targets and Schedule
+
+The open source program manager confirms training targets and establishes a training plan at least once a year.
+
+- **New participants**: Complete mandatory training during onboarding.
+- **Existing participants**: Complete regular training at least once a year.
+- **Role changes**: Complete additional training suited to the new role.
+
+### (2) Conducting Training
+
+The open source program manager provides training in the following ways:
+
+1. **Online training**: Complete mandatory courses on the Learning Portal; course completion is automatically recorded in the system.
+2. **Offline training**: Hold workshops or seminars when needed, recording the list of attendees and training materials.
+
+Training content must include the following topics:
+- Purpose and principles of the open source policy
+- License obligations and compliance procedures
+- SBOM creation and utilization
+- Vulnerability management procedures
+- External open source contribution policy and internal project release procedures
+
+### (3) Competency Evaluation
+
+After completing training, the open source program manager evaluates participants' competencies.
+
+- Evaluation is conducted through online tests or practical assignments.
+- Evaluation criteria (passing scores, etc.) are defined in advance when establishing the training plan.
+- Participants who do not pass are given supplemental training opportunities and re-evaluated.
+
+### (4) Recording and Retaining Evaluation Results
+
+The open source program manager records training completion and evaluation results.
+
+Record items:
+- Trainee name, role, and completion date
+- Evaluation results (score or pass/fail)
+- Supplemental training history (if applicable)
+
+Records shall be registered in the internal document management system or Learning Portal and retained for a minimum of 3 years. (ISO/IEC 5230 §3.1.3, ISO/IEC 18974 §3.1.3)
+
+### (5) Training Content Review and Improvement
+
+The open source program manager reviews training content and evaluation methods at least once a year and updates them to reflect the following:
+
+- Changes in open source-related laws and regulations
+- New vulnerability trends and case studies
+- Changes in internal policies and processes
\ No newline at end of file
diff --git a/content/en/guide/tools/3-fosslight/_index.md b/content/en/guide/tools/3-fosslight/_index.md
new file mode 100644
index 0000000000..7f88800159
--- /dev/null
+++ b/content/en/guide/tools/3-fosslight/_index.md
@@ -0,0 +1,76 @@
+---
+title: "FOSSLight"
+weight: 3
+type: docs
+categories: ["guide"]
+tags: ["fosslight"]
+---
+
+FOSSLight is an open source project led by LG Electronics. It analyzes source code, binaries, and dependencies using various scanners to generate an SBOM (Software Bill of Materials). FOSSLight Hub provides open source management, license management, and vulnerability management features to support the compliance process.
+
+- Official website: <https://fosslight.org/>
+- GitHub: <https://github.com/fosslight/fosslight_hub>
+- License: Apache-2.0
+
+### 1. Features
+
+- **Multiple scanner integration**: Integrates ScanCode Toolkit, SPDX Tools, CycloneDX, FOSSology, and other open source scanners
+- **Wide scan target support**: Source code, binaries, container images, Linux packages, and more
+- **SBOM generation and management**: Creates and manages SBOMs in various formats (SPDX, CycloneDX, Excel, Text)
+- **License detection and management**: Accurately detects and manages open source license information
+- **Vulnerability integration**: Links to external vulnerability databases such as NVD and CVE
+- **FOSSLight Hub**: Web-based UI providing open source management, license management, and vulnerability management
+
+### 2. Installation
+
+FOSSLight consists of FOSSLight Scanner and FOSSLight Hub. The easiest way to install both is using Docker Compose.
+
+**Prerequisites**: Docker and Docker Compose must be installed on your system.
+
+```bash
+# Clone the FOSSLight Hub repository
+git clone https://github.com/fosslight/fosslight_hub.git
+cd fosslight_hub
+```
+
+The repository includes a `docker-compose.yml` file. Run the following command to start FOSSLight:
+
+```bash
+docker-compose up -d
+```
+
+This starts FOSSLight Hub, FOSSLight Scanner, and the MariaDB database as Docker containers.
+
+Access `http://localhost:8080` in your browser to verify the installation.
+
+### 3. Basic Usage
+
+#### FOSSLight Hub
+
+1. Navigate to `http://localhost:8080` and log in.
+2. Create a new project under **Projects** → **New Project**.
+3. Upload scan results from FOSSLight Scanner.
+4. Review SBOM information, license details, and vulnerability data in the web UI.
+5. Generate reports in SPDX, CycloneDX, Excel, or Text format.
+
+#### FOSSLight Scanner (CLI)
+
+```bash
+# Scan a project directory and output results as JSON
+docker run --rm \
+  -v $(pwd)/upload:/home/fosslight_scanner/upload \
+  -v $(pwd)/result:/home/fosslight_scanner/result \
+  fosslight/fosslight_scanner \
+  -p /home/fosslight_scanner/upload/my_project \
+  -o /home/fosslight_scanner/result/my_sbom.json \
+  -f fosslight_json
+```
+
+Scan results are saved to the `result` directory and can be uploaded to FOSSLight Hub.
+
+### 4. References
+
+- FOSSLight Official Website: <https://fosslight.org/>
+- FOSSLight GitHub: <https://github.com/fosslight/fosslight_hub>
+- SPDX: <https://spdx.dev/>
+- CycloneDX: <https://cyclonedx.org/>
diff --git a/content/en/guide/tools/4-osvscalibr/_index.md b/content/en/guide/tools/4-osvscalibr/_index.md
new file mode 100644
index 0000000000..5a747181e1
--- /dev/null
+++ b/content/en/guide/tools/4-osvscalibr/_index.md
@@ -0,0 +1,77 @@
+---
+title: "OSV-SCALIBR"
+weight: 4
+type: docs
+categories: ["guide"]
+tags: ["OSV-SCALIBR", "SBOM", "vulnerability"]
+---
+
+OSV-SCALIBR (Open Source Vulnerabilities - Software Composition Analysis LIBRary) is an open source software composition analysis tool developed by Google.
+It scans filesystems, container images, and binaries to identify included packages and detects known vulnerabilities by cross-referencing the [OSV (Open Source Vulnerabilities)](https://osv.dev/) database. It also supports SBOM generation in SPDX format.
+
+- GitHub: <https://github.com/google/osv-scalibr>
+- License: Apache-2.0
+
+### 1. Features
+
+- **Multiple scan targets**: Local filesystem, container images, archive files
+- **Wide ecosystem support**: Go, Python, Java (Maven), JavaScript (npm), Rust, Ruby, and more
+- **OSV DB integration**: Cross-references scan results with the OSV database to provide CVE and other vulnerability information
+- **SBOM output**: Exports results in SPDX 2.3 format
+- **CLI and library**: Provided as both a standalone binary (CLI) and a Go library
+
+### 2. Installation
+
+Build with Go 1.21 or later:
+
+```bash
+git clone https://github.com/google/osv-scalibr.git
+cd osv-scalibr
+go build -o scalibr ./binary/cli/...
+```
+
+Alternatively, download pre-built binaries from the [Releases page](https://github.com/google/osv-scalibr/releases).
+
+### 3. Basic Usage
+
+#### (1) Filesystem Scan
+
+```bash
+# Scan a directory and output vulnerability results
+./scalibr scan --result=result.json /path/to/project
+
+# Generate SBOM in SPDX format
+./scalibr scan --output=sbom.spdx.json /path/to/project
+```
+
+#### (2) Container Image Scan
+
+```bash
+./scalibr scan --image=ubuntu:22.04 --result=result.json
+```
+
+#### (3) Reviewing Results
+
+```bash
+# Query vulnerability list from JSON result file
+cat result.json | jq '.findings[].adv.id'
+```
+
+### 4. CI/CD Integration
+
+OSV-SCALIBR is well-suited for integration into CI/CD pipelines to automatically detect vulnerabilities during build and deployment stages.
+
+```yaml
+# GitHub Actions example
+- name: Run OSV-SCALIBR
+  run: |
+    ./scalibr scan --result=result.json .
+    # Fail build if vulnerabilities are found
+    jq -e '.findings | length == 0' result.json
+```
+
+### 5. References
+
+- OSV-SCALIBR GitHub: <https://github.com/google/osv-scalibr>
+- OSV Database: <https://osv.dev/>
+- SPDX: <https://spdx.dev/>
diff --git a/content/en/guide/tools/5-cdxgen/_index.md b/content/en/guide/tools/5-cdxgen/_index.md
new file mode 100644
index 0000000000..e95f1e8e01
--- /dev/null
+++ b/content/en/guide/tools/5-cdxgen/_index.md
@@ -0,0 +1,86 @@
+---
+title: "cdxgen"
+weight: 5
+type: docs
+categories: ["guide"]
+tags: ["cdxgen", "SBOM", "CycloneDX"]
+---
+
+cdxgen is an open source SBOM generation tool managed by OWASP (Open Web Application Security Project).
+It analyzes source code, build artifacts, and container images to automatically generate SBOMs in [CycloneDX](https://cyclonedx.org/) format.
+
+- GitHub: <https://github.com/CycloneDX/cdxgen>
+- License: Apache-2.0
+
+## Features
+
+- **Wide language and ecosystem support**: Java (Maven/Gradle), Node.js, Python, Go, Rust, PHP, Ruby, .NET, and 20+ more
+- **Multiple scan targets**: Source code directories, container images, GitHub repositories
+- **CycloneDX standard output**: Supports CycloneDX 1.4/1.5/1.6 in JSON and XML formats
+- **REPL mode**: Interactive interface for exploring and querying SBOMs
+- **CI/CD integration**: Easy integration with GitHub Actions, GitLab CI, and other major pipelines
+
+## Installation
+
+Install with Node.js 18 or later:
+
+```bash
+npm install -g @cyclonedx/cdxgen
+```
+
+Or use the Docker image:
+
+```bash
+docker pull ghcr.io/cyclonedx/cdxgen
+```
+
+## Basic Usage
+
+### (1) Scan a Source Code Directory
+
+```bash
+# Scan current directory and generate CycloneDX JSON SBOM
+cdxgen -o sbom.json .
+
+# Specify language if auto-detection fails
+cdxgen -t java -o sbom.json /path/to/project
+```
+
+### (2) Scan a Container Image
+
+```bash
+cdxgen -t docker -o sbom.json ubuntu:22.04
+```
+
+### (3) Scan a GitHub Repository
+
+```bash
+cdxgen -t github -o sbom.json https://github.com/org/repo
+```
+
+### (4) Explore SBOM in REPL Mode
+
+```bash
+cdxgen --repl -o sbom.json .
+```
+
+## CI/CD Integration Example
+
+```yaml
+# GitHub Actions example
+- name: Generate SBOM with cdxgen
+  run: |
+    npm install -g @cyclonedx/cdxgen
+    cdxgen -o sbom.json .
+- name: Upload SBOM
+  uses: actions/upload-artifact@v4
+  with:
+    name: sbom
+    path: sbom.json
+```
+
+## References
+
+- cdxgen GitHub: <https://github.com/CycloneDX/cdxgen>
+- CycloneDX Standard: <https://cyclonedx.org/>
+- OWASP CycloneDX: <https://owasp.org/www-project-cyclonedx/>
diff --git a/content/en/guide/tools/6-syft/_index.md b/content/en/guide/tools/6-syft/_index.md
new file mode 100644
index 0000000000..d493834a70
--- /dev/null
+++ b/content/en/guide/tools/6-syft/_index.md
@@ -0,0 +1,100 @@
+---
+title: "Syft"
+weight: 6
+type: docs
+categories: ["guide"]
+tags: ["Syft", "SBOM", "SPDX", "CycloneDX"]
+---
+
+Syft is an open source SBOM generation CLI tool developed by Anchore.
+It scans container images, filesystems, and archives to identify included packages and generates SBOMs in SPDX or CycloneDX format.
+
+- GitHub: <https://github.com/anchore/syft>
+- License: Apache-2.0
+
+## Features
+
+- **Multiple scan targets**: Container images (Docker, OCI), local filesystems, tar archives
+- **Wide ecosystem support**: Alpine (apk), Debian/Ubuntu (dpkg), RPM, Python, Java, Go, Node.js, Ruby, Rust, and more
+- **Standard output formats**: SPDX 2.2/2.3 (JSON, tag-value), CycloneDX 1.4/1.5 (JSON, XML), Syft JSON
+- **Grype integration**: Pairs naturally with Anchore's Grype vulnerability scanner for SBOM-based vulnerability analysis
+- **Easy installation**: Single binary distribution, no additional runtime required
+
+## Installation
+
+### Script Installation (Linux/macOS)
+
+```bash
+curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
+```
+
+### Homebrew (macOS)
+
+```bash
+brew install syft
+```
+
+### Docker
+
+```bash
+docker pull anchore/syft
+```
+
+## Basic Usage
+
+### (1) Scan a Container Image
+
+```bash
+# Scan a Docker image and output SPDX JSON
+syft ubuntu:22.04 -o spdx-json=sbom.spdx.json
+
+# Output as CycloneDX JSON
+syft ubuntu:22.04 -o cyclonedx-json=sbom.cdx.json
+```
+
+### (2) Scan a Local Directory
+
+```bash
+syft dir:/path/to/project -o spdx-json=sbom.spdx.json
+```
+
+### (3) View Results in Terminal
+
+```bash
+# Print package list to terminal
+syft ubuntu:22.04
+
+# Output as JSON to stdout
+syft ubuntu:22.04 -o json
+```
+
+### (4) Vulnerability Scanning with Grype
+
+```bash
+# Generate SBOM with Syft and analyze vulnerabilities with Grype
+syft ubuntu:22.04 -o json | grype
+```
+
+## CI/CD Integration Example
+
+```yaml
+# GitHub Actions example
+- name: Generate SBOM with Syft
+  uses: anchore/sbom-action@v0
+  with:
+    image: myapp:latest
+    format: spdx-json
+    output-file: sbom.spdx.json
+- name: Upload SBOM
+  uses: actions/upload-artifact@v4
+  with:
+    name: sbom
+    path: sbom.spdx.json
+```
+
+## References
+
+- Syft GitHub: <https://github.com/anchore/syft>
+- Grype (vulnerability scanner): <https://github.com/anchore/grype>
+- SPDX Standard: <https://spdx.dev/>
+- CycloneDX Standard: <https://cyclonedx.org/>
diff --git a/content/en/guide/tools/7-dependency-track/_index.md b/content/en/guide/tools/7-dependency-track/_index.md
new file mode 100644
index 0000000000..e967c7c87c
--- /dev/null
+++ b/content/en/guide/tools/7-dependency-track/_index.md
@@ -0,0 +1,94 @@
+---
+title: "Dependency-Track"
+weight: 7
+type: docs
+categories: ["guide"]
+tags: ["Dependency-Track", "SBOM", "vulnerability", "CycloneDX"]
+---
+
+Dependency-Track is an open source SBOM management and vulnerability analysis platform managed by OWASP.
+It continuously monitors component-level vulnerabilities based on uploaded SBOMs (CycloneDX, SPDX) and automatically evaluates policy violations.
+
+- GitHub: <https://github.com/DependencyTrack/dependency-track>
+- Official docs: <https://docs.dependencytrack.org/>
+- License: Apache-2.0
+
+## Features
+
+- **SBOM-based continuous monitoring**: Automatically tracks the latest vulnerabilities per component after uploading SBOMs in SPDX or CycloneDX format
+- **Multiple vulnerability data sources**: NVD, OSV, GitHub Advisories, VulnDB, and more
+- **Policy engine**: Define rules for license policies, vulnerability severity thresholds, and component allowlists for automatic evaluation
+- **REST API**: Integrate with CI/CD pipelines to automatically upload SBOMs and receive feedback at build time
+- **Web UI dashboard**: View per-project risk scores, vulnerability status, and license distribution at a glance
+- **Notifications**: Send new vulnerability alerts via Slack, email, Webhook, and other channels
+
+## Installation
+
+Using Docker Compose is the simplest approach:
+
+```bash
+# Download official Docker Compose file
+curl -LO https://dependencytrack.org/docker-compose.yml
+
+# Start services
+docker compose up -d
+```
+
+By default, the API server runs on port 8081 and the frontend on port 8080.
+Default admin credentials: `admin` / `admin` (change immediately after first login)
+
+## Basic Usage
+
+### (1) Create a Project and Upload SBOM via Web UI
+
+1. Navigate to `http://localhost:8080`
+2. Click **Projects** → **Create Project**
+3. Enter project name and version, then save
+4. Open the project → **Components** tab → **Upload BOM**
+5. Upload your SBOM file (`.cdx.json` or `.spdx.json`)
+
+After upload, Dependency-Track automatically starts vulnerability analysis.
+
+### (2) Upload SBOM via API (CI/CD Integration)
+
+```bash
+# API Key: Administration > Access Management > Teams
+API_KEY="your-api-key"
+PROJECT_UUID="your-project-uuid"
+
+curl -X PUT \
+  "http://localhost:8081/api/v1/bom" \
+  -H "X-Api-Key: ${API_KEY}" \
+  -H "Content-Type: multipart/form-data" \
+  -F "project=${PROJECT_UUID}" \
+  -F "bom=@sbom.cdx.json"
+```
+
+### (3) GitHub Actions Integration Example
+
+```yaml
+- name: Upload SBOM to Dependency-Track
+  uses: DependencyTrack/gh-upload-sbom@v3
+  with:
+    serverhostname: dependency-track.example.com
+    apikey: ${{ secrets.DT_API_KEY }}
+    project: ${{ secrets.DT_PROJECT_UUID }}
+    bomfilename: sbom.cdx.json
+```
+
+## Using with cdxgen / Syft
+
+Dependency-Track is most effective when used with SBOM generation tools like cdxgen and Syft:
+
+```
+cdxgen or Syft  →  Generate SBOM  →  Upload to Dependency-Track  →  Continuous monitoring
+```
+
+- SBOM generation: Use [cdxgen](../5-cdxgen/) or [Syft](../6-syft/) to generate SBOMs at build time
+- Centralized management: Upload to Dependency-Track to manage vulnerability status across all projects
+
+## References
+
+- Dependency-Track Official Docs: <https://docs.dependencytrack.org/>
+- Dependency-Track GitHub: <https://github.com/DependencyTrack/dependency-track>
+- CycloneDX Standard: <https://cyclonedx.org/>
diff --git a/content/ko/guide/isoiec18974_guide/1-whyimportant/_index.md b/content/ko/guide/archive/isoiec18974_guide/1-whyimportant/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/1-whyimportant/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/1-whyimportant/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/2-requirements/_index.md b/content/ko/guide/archive/isoiec18974_guide/2-requirements/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/2-requirements/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/2-requirements/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/3-howto/3-1-program_foundation/_index.md b/content/ko/guide/archive/isoiec18974_guide/3-howto/3-1-program_foundation/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/3-howto/3-1-program_foundation/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/3-howto/3-1-program_foundation/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/3-howto/3-2-relevant_tasks/_index.md b/content/ko/guide/archive/isoiec18974_guide/3-howto/3-2-relevant_tasks/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/3-howto/3-2-relevant_tasks/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/3-howto/3-2-relevant_tasks/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/3-howto/3-3-oss-review-approval/_index.md b/content/ko/guide/archive/isoiec18974_guide/3-howto/3-3-oss-review-approval/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/3-howto/3-3-oss-review-approval/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/3-howto/3-3-oss-review-approval/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/3-howto/3-4-adherence/_index.md b/content/ko/guide/archive/isoiec18974_guide/3-howto/3-4-adherence/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/3-howto/3-4-adherence/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/3-howto/3-4-adherence/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/3-howto/_index.md b/content/ko/guide/archive/isoiec18974_guide/3-howto/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/3-howto/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/3-howto/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/4-compare/_index.md b/content/ko/guide/archive/isoiec18974_guide/4-compare/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/4-compare/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/4-compare/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/5-company/_index.md b/content/ko/guide/archive/isoiec18974_guide/5-company/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/5-company/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/5-company/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/6-self_certification/_index.md b/content/ko/guide/archive/isoiec18974_guide/6-self_certification/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/6-self_certification/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/6-self_certification/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/7-case_study/_index.md b/content/ko/guide/archive/isoiec18974_guide/7-case_study/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/7-case_study/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/7-case_study/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/8-conclusion/_index.md b/content/ko/guide/archive/isoiec18974_guide/8-conclusion/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/8-conclusion/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/8-conclusion/_index.md
diff --git a/content/ko/guide/isoiec18974_guide/_index.md b/content/ko/guide/archive/isoiec18974_guide/_index.md
similarity index 100%
rename from content/ko/guide/isoiec18974_guide/_index.md
rename to content/ko/guide/archive/isoiec18974_guide/_index.md
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/1-openchain-specification.md b/content/ko/guide/archive/nipa_openchain/I-openchainproject/1-openchain-specification.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/1-openchain-specification.md
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/1-openchain-specification.md
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/2-openchain-conformance.md b/content/ko/guide/archive/nipa_openchain/I-openchainproject/2-openchain-conformance.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/2-openchain-conformance.md
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/2-openchain-conformance.md
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/3-openchain-curriculum.md b/content/ko/guide/archive/nipa_openchain/I-openchainproject/3-openchain-curriculum.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/3-openchain-curriculum.md
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/3-openchain-curriculum.md
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/3rdparty.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/3rdparty.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/3rdparty.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/3rdparty.png
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/_index.md b/content/ko/guide/archive/nipa_openchain/I-openchainproject/_index.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/_index.md
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/_index.md
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/certification.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/certification.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/certification.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/certification.png
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/certilogo.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/certilogo.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/certilogo.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/certilogo.png
diff --git a/content/ko/guide/archive/nipa_openchain/I-openchainproject/independent2.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/independent2.png
new file mode 100644
index 0000000000..98ed0045fa
Binary files /dev/null and b/content/ko/guide/archive/nipa_openchain/I-openchainproject/independent2.png differ
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/openchainlogo.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/openchainlogo.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/openchainlogo.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/openchainlogo.png
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/openup2.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/openup2.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/openup2.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/openup2.png
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/organization.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/organization.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/organization.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/organization.png
diff --git a/content/ko/guide/archive/nipa_openchain/I-openchainproject/pwc.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/pwc.png
new file mode 100644
index 0000000000..27cd411470
Binary files /dev/null and b/content/ko/guide/archive/nipa_openchain/I-openchainproject/pwc.png differ
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/question.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/question.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/question.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/question.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/resource.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/resource.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/resource.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/resource.png
diff --git a/content/ko/guide/nipa_openchain/I-openchainproject/spec.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/spec.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/I-openchainproject/spec.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/spec.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/supplychain.png b/content/ko/guide/archive/nipa_openchain/I-openchainproject/supplychain.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/supplychain.png
rename to content/ko/guide/archive/nipa_openchain/I-openchainproject/supplychain.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/1-program.md b/content/ko/guide/archive/nipa_openchain/II-howtocomply/1-program.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/1-program.md
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/1-program.md
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/2-related-task.md b/content/ko/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/2-related-task.md
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/3-approval.md b/content/ko/guide/archive/nipa_openchain/II-howtocomply/3-approval.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/3-approval.md
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/3-approval.md
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/4-artifect.md b/content/ko/guide/archive/nipa_openchain/II-howtocomply/4-artifect.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/4-artifect.md
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/4-artifect.md
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/5-contribution.md b/content/ko/guide/archive/nipa_openchain/II-howtocomply/5-contribution.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/5-contribution.md
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/5-contribution.md
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/6-conformance.md b/content/ko/guide/archive/nipa_openchain/II-howtocomply/6-conformance.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/6-conformance.md
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/6-conformance.md
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/_index.md b/content/ko/guide/archive/nipa_openchain/II-howtocomply/_index.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/_index.md
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/_index.md
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/addrequest.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/addrequest.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/addrequest.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/addrequest.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/certification.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/certification.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/certification.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/certification.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/certilogo.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/certilogo.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/certilogo.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/certilogo.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/compare.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/compare.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/compare.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/compare.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/directory.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/directory.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/directory.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/directory.png
diff --git a/content/ko/guide/archive/nipa_openchain/II-howtocomply/openchainlogo.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/openchainlogo.png
new file mode 100644
index 0000000000..a039ca0546
Binary files /dev/null and b/content/ko/guide/archive/nipa_openchain/II-howtocomply/openchainlogo.png differ
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/organization.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/organization.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/organization.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/organization.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/partners.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/partners.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/partners.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/partners.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/policy01.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/policy01.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/policy01.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/policy01.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/policy02.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/policy02.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/policy02.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/policy02.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/policy03.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/policy03.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/policy03.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/policy03.png
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/process01.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/process01.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/process01.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/process01.png
diff --git a/content/ko/guide/archive/nipa_openchain/II-howtocomply/question.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/question.png
new file mode 100644
index 0000000000..f67dd0e0c3
Binary files /dev/null and b/content/ko/guide/archive/nipa_openchain/II-howtocomply/question.png differ
diff --git a/content/ko/guide/archive/nipa_openchain/II-howtocomply/resource.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/resource.png
new file mode 100644
index 0000000000..d865d56094
Binary files /dev/null and b/content/ko/guide/archive/nipa_openchain/II-howtocomply/resource.png differ
diff --git a/content/ko/guide/nipa_openchain/II-howtocomply/spec.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/spec.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/II-howtocomply/spec.png
rename to content/ko/guide/archive/nipa_openchain/II-howtocomply/spec.png
diff --git a/content/ko/guide/archive/nipa_openchain/II-howtocomply/supplychain.png b/content/ko/guide/archive/nipa_openchain/II-howtocomply/supplychain.png
new file mode 100644
index 0000000000..7cbdb08a87
Binary files /dev/null and b/content/ko/guide/archive/nipa_openchain/II-howtocomply/supplychain.png differ
diff --git a/content/ko/guide/nipa_openchain/_index.md b/content/ko/guide/archive/nipa_openchain/_index.md
similarity index 100%
rename from content/ko/guide/nipa_openchain/_index.md
rename to content/ko/guide/archive/nipa_openchain/_index.md
diff --git a/content/ko/guide/nipa_openchain/guide.png b/content/ko/guide/archive/nipa_openchain/guide.png
similarity index 100%
rename from content/ko/guide/nipa_openchain/guide.png
rename to content/ko/guide/archive/nipa_openchain/guide.png
diff --git a/content/ko/guide/opensource_for_enterprise/_index.md b/content/ko/guide/opensource_for_enterprise/_index.md
index 4418298c68..fc2891e383 100644
--- a/content/ko/guide/opensource_for_enterprise/_index.md
+++ b/content/ko/guide/opensource_for_enterprise/_index.md
@@ -1,6 +1,6 @@
 ---
-title: "[2025] ISO 표준 기반 기업 오픈소스 관리 가이드"
-linkTitle: "2025 기업 오픈소스 관리 가이드"
+title: "[2026] ISO 표준 기반 기업 오픈소스 관리 가이드"
+linkTitle: "2026 기업 오픈소스 관리 가이드"
 weight: 10
 type: docs
 description: >
@@ -16,6 +16,13 @@ description: >
 
 **Author : OpenChain Korea Work Group / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)**
 
+**최근 업데이트 사항 (2026.3.26):**
+- Tools: cdxgen, Syft, Dependency-Track, OSV-SCALIBR 도구 페이지 신규 추가
+- 정책 템플릿: ISO/IEC 5230·18974 누락 조항 보완
+  (컴플라이언스 산출물 보관기간, CVSS 조치기한, SBOM 표준형식 선언 등)
+- 프로세스 템플릿: SBOM 절차 보완 및 기여·공개·교육 프로세스 신규 추가
+- 가이드 본문: 내부 링크 정비 및 신규 도구 연계
+
 **최근 업데이트 사항 (2025.1.6):**
 - ISO/IEC 18974 (OpenChain Security Assurance Specification) 관련 내용 추가
 - 오픈소스 보안 보증 프로세스 및 요구사항 상세화
diff --git a/content/ko/guide/sbom_guide/_index.md b/content/ko/resource/SBOM_work_group/sbom_guide/_index.md
similarity index 100%
rename from content/ko/guide/sbom_guide/_index.md
rename to content/ko/resource/SBOM_work_group/sbom_guide/_index.md
diff --git a/content/ko/guide/sbom_guide/img/image 1.png b/content/ko/resource/SBOM_work_group/sbom_guide/img/image 1.png
similarity index 100%
rename from content/ko/guide/sbom_guide/img/image 1.png
rename to content/ko/resource/SBOM_work_group/sbom_guide/img/image 1.png
diff --git a/content/ko/guide/sbom_guide/img/image 2.png b/content/ko/resource/SBOM_work_group/sbom_guide/img/image 2.png
similarity index 100%
rename from content/ko/guide/sbom_guide/img/image 2.png
rename to content/ko/resource/SBOM_work_group/sbom_guide/img/image 2.png
diff --git a/content/ko/guide/sbom_guide/img/image 3.png b/content/ko/resource/SBOM_work_group/sbom_guide/img/image 3.png
similarity index 100%
rename from content/ko/guide/sbom_guide/img/image 3.png
rename to content/ko/resource/SBOM_work_group/sbom_guide/img/image 3.png
diff --git a/content/ko/guide/sbom_guide/img/image 4.png b/content/ko/resource/SBOM_work_group/sbom_guide/img/image 4.png
similarity index 100%
rename from content/ko/guide/sbom_guide/img/image 4.png
rename to content/ko/resource/SBOM_work_group/sbom_guide/img/image 4.png
diff --git a/content/ko/guide/sbom_guide/img/image.png b/content/ko/resource/SBOM_work_group/sbom_guide/img/image.png
similarity index 100%
rename from content/ko/guide/sbom_guide/img/image.png
rename to content/ko/resource/SBOM_work_group/sbom_guide/img/image.png
diff --git a/content/ko/guide/telco_sbom/_index.md b/content/ko/resource/Telco_work_group/telco_sbom/_index.md
similarity index 100%
rename from content/ko/guide/telco_sbom/_index.md
rename to content/ko/resource/Telco_work_group/telco_sbom/_index.md