diff --git a/content/ko/guide/TODO.md b/content/ko/guide/TODO.md
index f82396b37..a025e5129 100644
--- a/content/ko/guide/TODO.md
+++ b/content/ko/guide/TODO.md
@@ -55,4 +55,35 @@ draft: true
 - [x] #22 4-tool에 Dependency-Track 소개 및 링크 추가
 - [x] #23 4-tool에 cdxgen 소개 및 링크 추가
 - [x] #24 4-tool에 Syft 소개 및 링크 추가
+
+---
+## iso5230_guide 작성 작업 (브랜치: guide/iso-compliance-guides)
+
+### 루트
+- [x] _index.md (가이드 소개 / 체크리스트 / 인증 절차)
+
+### §3.1 프로그램 기반
+- [x] 1-policy/_index.md (§3.1.1 정책)
+- [x] 2-competence/_index.md (§3.1.2 역량)
+- [x] 3-awareness/_index.md (§3.1.3 인식)
+- [x] 4-scope/_index.md (§3.1.4 프로그램 범위)
+- [x] 5-license-obligations/_index.md (§3.1.5 라이선스 의무)
+
+### §3.2 관련 업무
+- [x] 1-access/_index.md (§3.2.1 외부 문의 대응)
+- [x] 2-resourced/_index.md (§3.2.2 효과적 리소스)
+
+### §3.3 콘텐츠 검토 및 승인
+- [x] 1-sbom/_index.md (§3.3.1 SBOM)
+- [x] 2-license-compliance/_index.md (§3.3.2 라이선스 컴플라이언스)
+
+### §3.4 컴플라이언스 산출물
+- [x] 1-compliance-artifacts/_index.md (§3.4.1 산출물)
+
+### §3.5 커뮤니티 참여
+- [x] 1-contributions/_index.md (§3.5.1 기여)
+
+### §3.6 규격 준수
+- [x] 1-conformance/_index.md (§3.6.1 적합성)
+- [x] 2-duration/_index.md (§3.6.2 지속 기간)
 ---
diff --git a/content/ko/guide/archive/_index.md b/content/ko/guide/archive/_index.md
index f6877ab32..dd045147d 100644
--- a/content/ko/guide/archive/_index.md
+++ b/content/ko/guide/archive/_index.md
@@ -1,6 +1,6 @@
 ---
-title: "아카이브"
-linkTitle: "아카이브"
+title: "Archive"
+linkTitle: "Archive"
 weight: 900
 type: docs
 description: >
diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md
new file mode 100644
index 000000000..f7bb7d552
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md
@@ -0,0 +1,179 @@
+---
+title: "§3.1.1 정책"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "정책"]
+description: >
+---
+
+## 1. 조항 개요
+
+오픈소스 정책이 없는 기업은 개발자가 오픈소스 라이선스 의무를 인지하지 못한 채
+소프트웨어를 배포하게 되며, 이는 저작권 침해 소송, 소스코드 강제 공개, 거래처 계약
+해지 등 심각한 법적·사업적 위험으로 이어질 수 있다. §3.1.1은 이러한 위험을 예방하기
+위해 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 정책을 수립하고, 조직 내
+모든 프로그램 참여자가 정책의 존재를 인식할 수 있도록 전파할 것을 요구한다. 이 조항은
+ISO/IEC 5230 프로그램 전체의 기반이 되며, 이후 모든 조항(역량·프로세스·산출물 등)은
+이 정책 위에서 작동한다.
+
+## 2. 해야 할 활동
+
+- 오픈소스 라이선스 컴플라이언스를 관리하는 정책 문서를 작성하고 공식화한다.
+- 정책에 적용 범위(외부 배포 소프트웨어, 기여 활동, 사내 공개 등)를 명확히 정의한다.
+- 정책 내에 오픈소스 사용·기여·배포·SBOM 관리·보안 취약점 대응 원칙을 포함한다.
+- 프로그램 참여자(개발자·법무·IT·보안 등)에게 정책을 전파하는 절차를 수립하고 문서화한다.
+- 전파 사실을 증명할 수 있는 기록(교육 이수, 공지 이력 등)을 보관한다.
+- 정기적으로 정책을 검토하고 변경 시 재전파하는 절차를 정책 내에 포함한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.1.1 | 공급 소프트웨어의 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다. | **3.1.1.1** 문서화된 오픈소스 정책<br>**3.1.1.2** 프로그램 참여자가 오픈소스 정책의 존재를 알 수 있게 하는 문서화된 절차 (교육, 내부 위키, 혹은 기타 실질적인 전달 방법 등) |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.1.1 Policy**
+> A written open source policy shall exist that governs open source license compliance
+> of the supplied software. The policy shall be internally communicated.
+>
+> **Verification Material(s):**
+> 3.1.1.1 A documented open source policy.
+> 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).
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.1.1.1 문서화된 오픈소스 정책
+
+**준수 방법**
+
+오픈소스 정책은 기업이 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한
+원칙과 절차를 담은 공식 문서다. 정책 문서에는 목적, 적용 범위, 역할과 책임,
+오픈소스 사용·기여·배포 원칙, SBOM 관리, 보안 취약점 대응, 교육 및 검토 주기 등
+핵심 항목이 포함되어야 한다. 이 문서 자체가 입증자료 3.1.1.1에 해당하므로 반드시
+공식 문서로 관리해야 하며, 버전과 승인 이력을 기록해야 한다.
+
+정책 수립 시에는 회사의 비즈니스 환경과 소프트웨어 공급망 특성을 반영해야 한다.
+예를 들어 외부에 소프트웨어를 배포하는 제품 기업과 서비스 기업은 컴플라이언스 산출물
+생성 의무 범위가 다를 수 있으므로, 적용 범위를 명확하게 정의한다. 정책은 법무팀 또는
+OSRB(Open Source Review Board)의 검토를 거쳐 최고 경영진 또는 권한 있는 부서장이
+승인하는 절차를 거쳐야 한다.
+
+정책은 한 번 수립한 뒤 방치하는 문서가 아니다. ISO/IEC 5230 요구사항 변경, 새로운
+라이선스 유형의 등장, 법적 환경 변화 등을 반영하여 최소 연 1회 정기 검토를 실시하고,
+변경 이력을 문서에 기록해야 한다.
+
+**고려사항**
+
+- **포함 항목**: 오픈소스 사용, 외부 기여, 사내 프로젝트 공개, SBOM 관리,
+  보안 취약점 대응 원칙을 정책에 모두 포함한다.
+- **적용 범위 명시**: 외부 배포 소프트웨어, 내부 사용 소프트웨어, 기여 활동 등
+  정책이 적용되는 범위를 명확하게 구분한다.
+- **승인 절차**: OSRB 또는 법무팀장 이상이 최종 승인하고, 승인 날짜와 승인자를
+  문서에 기록한다.
+- **버전 관리**: 문서 버전 번호와 변경 이력을 유지하여 감사 시 이전 버전과
+  비교할 수 있도록 한다.
+- **정기 검토**: 연 1회 이상 정책을 검토하며, 검토 완료 날짜와 검토자를 기록한다.
+
+**샘플**
+
+아래는 오픈소스 정책 문서의 목적 및 적용 범위 샘플이다. 이 텍스트 자체가
+입증자료 3.1.1.1(문서화된 오픈소스 정책)의 핵심 구성 요소가 된다.
+
+```
+## 1. 목적 및 적용 범위
+
+### 1.1 목적
+
+이 정책은 회사가 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한 원칙과
+절차를 제공합니다. 정책의 주요 목적은 다음과 같습니다:
+
+1. 오픈소스 라이선스 컴플라이언스:
+   공급 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 의무를 준수하고,
+   관련 법적 요구사항을 충족합니다.
+2. 오픈소스 보안 보증:
+   공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 식별하고,
+   적절한 대응 조치를 통해 보안 위험을 최소화합니다.
+
+이러한 원칙은 ISO/IEC 5230(오픈소스 라이선스 컴플라이언스) 및
+ISO/IEC 18974(오픈소스 보안 보증)의 요구사항을 충족하도록 설계되었습니다.
+
+### 1.4 적용 범위
+
+이 정책은 회사가 개발, 배포, 또는 사용하는 모든 소프트웨어 프로젝트에 적용됩니다.
+
+- 외부로 제공하거나 배포하는 모든 공급 소프트웨어.
+- 외부 오픈소스 프로젝트에 기여하는 활동.
+- 내부 프로젝트를 오픈소스로 공개하는 활동.
+
+단, 내부 사용 목적으로만 사용되는 오픈소스는 별도의 검토 절차를 통해
+정책 적용 여부를 결정할 수 있습니다.
+
+정책의 적용 범위는 회사의 비즈니스 환경 변화에 따라 정기적으로 검토되고 갱신됩니다.
+```
+
+---
+
+### 3.1.1.2 정책 인식 방법 문서화
+
+**준수 방법**
+
+정책 문서를 작성하는 것만으로는 부족하다. 프로그램 참여자(소프트웨어 개발·배포·기여에
+관여하는 모든 직원)가 정책의 존재를 실제로 인식할 수 있도록 전파 절차를 수립하고
+문서화해야 한다. 전파 절차 문서에는 어떤 채널을 통해, 언제, 누구에게 정책을 전달하는지
+구체적으로 명시해야 한다. 이 전파 절차 문서 자체가 입증자료 3.1.1.2다.
+
+전파 방법은 복수의 채널을 조합하는 것이 효과적이다. 신규 입사자에게는 온보딩 과정에
+오픈소스 정책 안내를 포함하고, 기존 직원에게는 사내 위키 게시와 이메일 공지를
+활용한다. 정책 변경 시에는 변경 내용을 즉시 공지하는 절차도 포함해야 한다. 전파
+사실을 증명하기 위해 공지 발송 이력, 교육 이수 기록, 정책 인식 확인 서명 등의 증거를
+최소 3년간 보관한다.
+
+**고려사항**
+
+- **복수 채널 활용**: 사내 위키, 이메일 공지, 온보딩 교육 등 둘 이상의 채널을
+  활용하여 전파 효과를 높인다.
+- **신규 입사자**: 온보딩 프로세스에 오픈소스 정책 안내를 필수 항목으로 포함한다.
+- **정책 변경 시**: 변경 사항을 프로그램 참여자에게 즉시 공지하는 별도 절차를 수립한다.
+- **증거 보관**: 공지 이력, 교육 이수 확인서, 정책 인식 확인 서명을 최소 3년간 보관한다.
+- **접근성**: 정책 문서를 사내 포털이나 위키에 항시 게시하여 참여자가 언제든
+  확인할 수 있도록 한다.
+
+**샘플**
+
+아래는 정책 전파 공지 이메일 샘플이다. 전송 이력을 보관하면 입증자료 3.1.1.2의
+증거로 활용할 수 있다.
+
+```
+제목: [오픈소스] 오픈소스 정책 안내 및 숙지 요청
+
+수신: 전체 개발/배포 관련 임직원
+발신: 오픈소스 프로그램 매니저
+
+안녕하세요.
+
+당사의 오픈소스 정책이 제정(또는 개정)되었습니다.
+오픈소스 소프트웨어를 사용, 기여, 또는 배포하는 업무에 관여하는
+모든 임직원은 아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.
+
+- 정책 문서: [사내 포털 링크]
+- 주요 내용: 오픈소스 사용 원칙, 라이선스 컴플라이언스 절차,
+             SBOM 관리, 보안 취약점 대응 원칙
+- 정책 버전: v1.0 (시행일: YYYY-MM-DD)
+
+정책 내용에 대한 문의는 오픈소스 프로그램 매니저(oss@company.com)에게
+연락해 주십시오.
+
+감사합니다.
+오픈소스 프로그램 매니저
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 2. 정책](../../../opensource_for_enterprise/2-policy/)
+- 관련 템플릿: [오픈소스 정책 템플릿](../../../templates/1-policy/)
diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md
new file mode 100644
index 000000000..721b8a80f
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md
@@ -0,0 +1,188 @@
+---
+title: "§3.1.2 역량"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "역량"]
+description: >
+---
+
+## 1. 조항 개요
+
+오픈소스 프로그램이 실제로 작동하려면 관련 역할을 맡은 사람들이 그 역할을 수행할
+역량을 갖추어야 한다. 역할과 책임이 문서에만 적혀 있고 담당자가 오픈소스 라이선스나
+보안 취약점 관리에 대한 기본 지식도 없다면, 정책과 프로세스는 유명무실해진다.
+§3.1.2는 프로그램에 관여하는 역할을 식별하고 각 역할에 필요한 역량을 정의하며,
+참여자가 실제로 그 역량을 갖추었는지 평가하고 기록하도록 요구한다. 이 조항은
+§3.1.1 정책에서 정의한 역할 구조를 구체적인 역량 체계로 발전시키는 단계다.
+
+## 2. 해야 할 활동
+
+- 오픈소스 프로그램의 성과에 영향을 미치는 역할과 각 역할의 책임을 목록으로 작성한다.
+- 각 역할을 수행하는 데 필요한 역량(지식·기술·경험)을 구체적으로 정의하고 문서화한다.
+- 각 프로그램 참여자가 해당 역할에 필요한 역량을 갖추었는지 평가한다.
+- 역량이 미흡한 경우 교육·훈련·멘토링 등 역량 확보 조치를 취한다.
+- 역량 평가 결과와 후속 조치 이력을 문서화하여 보관한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.1.2 | 조직은 다음을 수행해야 한다: <br>- 프로그램의 성과와 효율에 영향을 미치는 역할과 그 책임을 확인한다 <br>- 각 역할을 수행할 프로그램 참여자가 갖춰야 할 필요 역량을 결정한다 <br>- 프로그램 참여자가 적절한 교육·훈련·경험을 바탕으로 자격을 갖춘 자임을 확인한다 <br>- 해당되는 경우 필요한 역량을 확보하기 위해 조치한다 <br>- 역량 보유를 증명하기 위한 정보를 문서화하여 유지한다 | **3.1.2.1** 프로그램의 여러 참여자에 대한 역할과 각 역할의 책임을 나열한 문서<br>**3.1.2.2** 각 역할을 위해 필요한 역량을 기술한 문서<br>**3.1.2.3** 각 프로그램 참여자의 역량을 평가한 문서화된 증거 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.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):**
+> 3.1.2.1 A documented list of roles with corresponding responsibilities for the
+> different participants in the program.
+> 3.1.2.2 A document that identifies the competencies for each role.
+> 3.1.2.3 Documented evidence of assessed competence for each program participant.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.1.2.1 역할과 책임 목록 문서
+
+**준수 방법**
+
+프로그램에 관여하는 모든 역할을 열거하고, 각 역할이 어떤 책임을 지는지 명확하게
+정의한 문서를 작성해야 한다. 일반적으로 오픈소스 프로그램 매니저, 법무 담당,
+IT 담당, 보안 담당, 개발 문화 담당, 사업 부서가 핵심 역할에 해당한다. 기업 규모나
+조직 구조에 따라 역할을 겸임하거나 OSRB(Open Source Review Board) 형태의 가상
+조직으로 운영하는 것도 가능하다.
+
+역할 정의 시 추상적인 서술보다 구체적인 책임 항목을 나열하는 것이 감사 시 입증에
+유리하다. 예를 들어 "오픈소스 관리"가 아니라 "공급 소프트웨어에 사용된 오픈소스
+컴포넌트의 라이선스 검토 및 SBOM 생성 감독"처럼 명확하게 기술한다. 이 문서는
+오픈소스 정책 문서(§3.1.1.1)의 역할 및 책임 섹션에 포함하거나 별도 Appendix로
+관리할 수 있다.
+
+**고려사항**
+
+- **역할 식별 범위**: 개발·법무·IT·보안·구매 등 소프트웨어 공급망에 관여하는
+  모든 조직의 역할을 포함하며, 외주 개발 및 벤더 관리 담당도 검토한다.
+- **책임 구체화**: 역할별 책임은 추상적 서술이 아닌 구체적 활동 단위로 기술한다.
+- **겸임 명시**: 한 사람이 여러 역할을 겸임하는 경우 해당 사실을 문서에 명기한다.
+- **갱신 주기**: 조직 변경·인사 이동 발생 시 즉시 문서를 갱신하고 버전을 업데이트한다.
+
+**샘플**
+
+아래는 오픈소스 정책 Appendix의 역할·책임 목록 샘플이다.
+[오픈소스 정책 템플릿 Appendix 1](../../../templates/1-policy/appendix/)에서
+전체 양식을 확인할 수 있다.
+
+```
+| 역할 | 책임 |
+|------|------|
+| 오픈소스 프로그램 매니저 | 회사의 오픈소스 프로그램 총괄 / SBOM 생성 감독 /
+                            외부 문의 대응 / 내부 모범 사례 관리 |
+| 법무 담당 | 오픈소스 라이선스 의무 해석 및 검토 /
+             라이선스 호환성 검토 / 법적 위험 평가 및 자문 |
+| IT 담당 | 오픈소스 분석 도구 운영 및 CI/CD 파이프라인 통합 /
+            SBOM 생성 자동화 지원 |
+| 보안 담당 | 알려진 취약점 및 새로 발견된 취약점 대응 /
+             DevSecOps 환경 통합 및 보안 조치 수행 |
+| 개발 문화 담당 | 오픈소스 커뮤니티 참여 장려 / 교육 프로그램 운영 |
+| 사업 부서 | 오픈소스 정책 및 프로세스 준수 / 오픈소스 식별 및 신고 |
+```
+
+---
+
+### 3.1.2.2 역할별 필요 역량 문서
+
+**준수 방법**
+
+각 역할을 수행하기 위해 필요한 지식·기술·경험을 구체적으로 정의하고 문서화해야 한다.
+역량 정의는 해당 역할을 새로 맡은 사람이 "내가 무엇을 알아야 하는가"를 명확히
+파악할 수 있는 수준으로 작성한다. 단순히 "오픈소스 지식 필요"처럼 모호하게 쓰지 않고,
+"주요 오픈소스 라이선스(MIT, Apache-2.0, GPL-2.0 등)의 의무 사항 및 호환성 이해"처럼
+구체적으로 기술한다.
+
+역량 수준을 "기본 이해", "실무 적용 가능", "전문가" 등으로 세분화하면 평가 기준이
+명확해지고 교육 계획을 수립하기 쉬워진다. 이 문서는 오픈소스 정책 문서에 포함하거나
+별도 역량 정의서로 관리할 수 있으며, 정기적으로 검토하여 기술 환경 변화를 반영해야 한다.
+
+**고려사항**
+
+- **구체성**: 역량 항목은 측정 가능한 수준으로 기술하여 평가 기준으로 활용할 수 있게 한다.
+- **역량 수준 구분**: "기본 이해 / 실무 적용 / 전문가" 등 수준을 정의하면
+  평가와 교육 설계가 용이해진다.
+- **갱신 주기**: 새로운 도구·라이선스·보안 기술 등장 시 역량 항목을 업데이트한다.
+- **교육 연계**: 정의된 역량을 기반으로 역할별 교육 커리큘럼을 설계한다.
+
+**샘플**
+
+아래는 역할별 필요 역량 정의표 샘플이다.
+
+```
+| 역할 | 필요 역량 |
+|------|-----------|
+| 오픈소스 프로그램 매니저 | 주요 오픈소스 라이선스 의무 및 호환성 이해 /
+                            소프트웨어 개발 프로세스 이해 /
+                            SBOM 생성·관리 지식 / 커뮤니케이션 스킬 |
+| 법무 담당 | 소프트웨어 저작권법 전문 지식 /
+             오픈소스 라이선스 해석 능력 / 법적 위험 평가 능력 |
+| IT 담당 | 오픈소스 분석 도구(FOSSology, ORT, Syft 등) 운용 /
+            CI/CD 파이프라인 이해 / IT 인프라 전문 지식 |
+| 보안 담당 | DevSecOps 이해 / 취약점 분석 도구 운용 /
+             CVSS 점수 해석 및 위험 평가 능력 |
+| 개발 문화 담당 | 오픈소스 정책 이해 / 교육 설계 능력 /
+                  오픈소스 커뮤니티 참여 경험 |
+| 사업 부서 | 오픈소스 컴플라이언스 기본 지식 /
+              오픈소스 라이선스 기본 이해 / 오픈소스 정책 이해 |
+```
+
+---
+
+### 3.1.2.3 역량 평가 증거
+
+**준수 방법**
+
+각 프로그램 참여자가 정의된 역량을 실제로 갖추었는지 평가하고, 그 결과를 문서화하여
+보관해야 한다. 평가 방법은 온라인 교육 이수 확인, 자격증 보유 여부 확인, 필기·실기
+시험, 담당 업무 수행 실적 검토, 면담 등 다양한 방식을 조합할 수 있다. 중요한 것은
+평가 결과가 기록으로 남아야 한다는 점이다. 이 기록 자체가 입증자료 3.1.2.3이다.
+
+평가 결과 미흡한 역량이 발견되면 교육 수강, 외부 컨설팅, 멘토링 등 보완 조치를 취하고
+그 완료 기록도 함께 보관한다. 평가는 최소 연 1회 정기적으로 실시하고, 담당자 변경
+시에는 신규 담당자에 대해 즉시 초기 평가를 수행한다. 평가 기록은 사내 학습 관리
+시스템(LMS) 또는 문서 시스템에 저장하여 감사 시 즉시 제출 가능한 상태로 유지한다.
+
+**고려사항**
+
+- **평가 방법 다양화**: 온라인 교육 이수, 시험, 실무 수행 실적 등 복수의 방법을
+  조합하여 역량을 종합적으로 평가한다.
+- **정기 평가 주기**: 최소 연 1회 실시하며, 담당자 변경 시 즉시 신규 평가를 수행한다.
+- **미흡 역량 보완**: 평가 결과 미흡 항목에 대해 교육 계획을 수립하고 이수 후
+  재평가를 실시한다.
+- **기록 보관 기간**: 평가 기록은 최소 해당 담당자 재직 기간 동안 보관하며,
+  퇴직 후에도 감사 목적으로 일정 기간 유지한다.
+
+**샘플**
+
+아래는 역량 평가 기록부 샘플이다. 역할별로 작성하여 LMS 또는 문서 시스템에 보관한다.
+
+```
+| 이름 | 역할 | 평가 항목 | 평가 방법 | 평가 결과 | 평가일 | 비고 |
+|------|------|-----------|-----------|-----------|--------|------|
+| 홍길동 | 오픈소스 프로그램 매니저 | 라이선스 의무 이해 | 온라인 교육 이수 | 완료 (95점) | 2026-01-15 | - |
+| 홍길동 | 오픈소스 프로그램 매니저 | SBOM 관리 지식 | 실무 평가 | 완료 | 2026-01-15 | - |
+| 김철수 | 보안 담당 | DevSecOps 이해 | 외부 교육 이수 | 완료 | 2026-02-03 | 수료증 보관 |
+| 이영희 | 법무 담당 | 오픈소스 라이선스 해석 | 면담 평가 | 완료 | 2026-01-20 | - |
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 1. 조직](../../../opensource_for_enterprise/1-teams/)
+- 관련 템플릿: [오픈소스 정책 템플릿 — Appendix 1. 담당자 현황](../../../templates/1-policy/appendix/)
diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md
new file mode 100644
index 000000000..49d3ca12e
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md
@@ -0,0 +1,118 @@
+---
+title: "§3.1.3 인식"
+weight: 30
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "인식"]
+description: >
+---
+
+## 1. 조항 개요
+
+역할과 역량을 갖춘 참여자라도 오픈소스 프로그램의 목적과 자신의 기여가 전체
+컴플라이언스 체계에 어떤 의미를 갖는지 인식하지 못하면 형식적 참여에 그치게 된다.
+§3.1.3은 프로그램 참여자가 프로그램의 목표, 자신의 기여 방법, 그리고 프로그램을
+준수하지 않을 경우 발생하는 결과를 실제로 인식하고 있음을 평가하고 기록할 것을
+요구한다. 이 조항은 §3.1.2 역량(지식·기술 보유)의 다음 단계로, 참여자가 보유한
+역량을 프로그램 목적과 연결하여 실질적 동기를 형성하는 단계다.
+
+## 2. 해야 할 활동
+
+- 프로그램 참여자가 오픈소스 프로그램의 목표(라이선스 컴플라이언스, 보안 보증 등)를
+  이해하고 있는지 확인한다.
+- 각 참여자가 자신의 역할이 전체 프로그램 운영에 어떻게 기여하는지 인식하고 있는지
+  평가한다.
+- 프로그램 요구사항을 미준수할 경우 발생할 수 있는 법적·사업적 영향에 대해
+  참여자가 인식하고 있는지 확인한다.
+- 인식 평가를 주기적으로 실시하고, 그 결과를 문서로 기록하여 보관한다.
+- 인식이 미흡한 참여자에 대해서는 추가 교육을 실시하고 재평가 결과를 보관한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.1.3 | 조직은 프로그램 참여자가 다음 사항을 인식하도록 해야 한다: 오픈소스 정책의 존재와 위치 / 오픈소스 관련 목표 / 프로그램 효과에 대한 자신의 기여 방법 / 프로그램 요구사항을 따르지 않을 경우 발생하는 영향 | **3.1.3.1** 프로그램의 목표, 프로그램 내에서의 참여자 기여 방법 및 프로그램을 준수하지 않을 경우 미치는 영향에 대한 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.1.3 Awareness**
+> The organization shall ensure that the program participants are aware of:
+> - The open source policy and where to find it;
+> - Relevant open source objectives;
+> - Their contribution to the effectiveness of the program; and
+> - The implications of not following the program's requirements.
+>
+> **Verification Material(s):**
+> 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.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.1.3.1 참여자 인식 평가 증거
+
+**준수 방법**
+
+프로그램 참여자가 세 가지 핵심 내용을 인식하고 있음을 평가하고 그 결과를 기록해야
+한다. 세 가지 핵심 내용은 ①프로그램의 목표(오픈소스 라이선스 컴플라이언스 및
+보안 보증), ②자신의 역할이 프로그램에 기여하는 방법, ③프로그램을 준수하지 않을
+경우 발생하는 법적·사업적 영향이다.
+
+평가 방법은 온라인 퀴즈, 오프라인 설문, 교육 후 이수 확인, 인터뷰 등 다양하게
+조합할 수 있다. 중요한 것은 평가 결과가 문서로 남아야 한다는 점이다. 이 기록이
+입증자료 3.1.3.1에 해당한다. 평가는 최소 연 1회 정기적으로 실시하고, 신규 참여자는
+프로그램 합류 시 즉시 초기 평가를 수행한다. 인식이 미흡한 참여자에 대해서는
+추가 교육을 실시하고 재평가 결과를 함께 보관한다.
+
+**고려사항**
+
+- **평가 범위**: 세 가지 핵심 인식(목표·기여·영향)을 모두 포함하는 평가 문항을
+  설계한다.
+- **평가 주기**: 최소 연 1회 정기 평가를 실시하고, 신규 참여자는 합류 즉시
+  초기 평가를 수행한다.
+- **증거 형식**: 퀴즈 결과, 서명된 정책 인식 확인서, 교육 이수 증명 등 감사 시
+  제출 가능한 형식으로 보관한다.
+- **미흡자 조치**: 평가 결과 미흡한 참여자에 대해 추가 교육을 실시하고 재평가
+  기록을 남긴다.
+- **접근성**: 평가에 활용되는 정책 문서 및 교육 자료를 사내 포털에 항상 접근
+  가능한 상태로 유지한다.
+
+**샘플**
+
+아래는 참여자 인식 평가 기록부 샘플이다. 교육 이수 시 작성하여 LMS 또는 문서
+시스템에 보관한다.
+
+```
+| 이름 | 역할 | 평가 항목 | 평가 방법 | 결과 | 평가일 | 비고 |
+|------|------|-----------|-----------|------|--------|------|
+| 홍길동 | 오픈소스 프로그램 매니저 | 프로그램 목표 이해 | 온라인 퀴즈 | 완료 (90점) | 2026-01-15 | - |
+| 홍길동 | 오픈소스 프로그램 매니저 | 미준수 영향 인식 | 온라인 퀴즈 | 완료 (90점) | 2026-01-15 | - |
+| 김철수 | 개발자 | 프로그램 목표 이해 | 온라인 퀴즈 | 완료 (85점) | 2026-01-20 | - |
+| 이영희 | 보안 담당 | 자신의 기여 방법 인식 | 인터뷰 | 완료 | 2026-01-22 | 면담 기록 보관 |
+```
+
+아래는 정책 인식 확인서 샘플이다. 교육 완료 후 서명을 받아 보관하면 입증자료로
+활용할 수 있다.
+
+```
+[오픈소스 정책 인식 확인서]
+
+본인은 다음 사항을 숙지하였음을 확인합니다:
+
+1. 당사 오픈소스 정책의 존재와 해당 문서의 위치
+2. 오픈소스 라이선스 컴플라이언스 및 보안 보증 프로그램의 목표
+3. 본인의 역할이 오픈소스 프로그램 운영에 기여하는 방법
+4. 오픈소스 정책 및 프로세스를 준수하지 않을 경우 발생할 수 있는
+   법적·사업적 위험
+
+이름: ________________  역할: ________________
+서명: ________________  날짜: ________________
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 5. 교육](../../../opensource_for_enterprise/5-training/)
+- 관련 템플릿: [오픈소스 정책 템플릿 — §6 교육 및 인식 제고](../../../templates/1-policy/)
diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/4-scope/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/4-scope/_index.md
new file mode 100644
index 000000000..6acb839a2
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/1-program-foundation/4-scope/_index.md
@@ -0,0 +1,114 @@
+---
+title: "§3.1.4 프로그램 범위"
+weight: 40
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "프로그램 범위"]
+description: >
+---
+
+## 1. 조항 개요
+
+오픈소스 프로그램이 조직 전체에 적용되는지, 특정 제품군이나 사업 단위에만
+적용되는지 명확하지 않으면 컴플라이언스 활동의 경계가 모호해지고 책임 소재가
+불분명해진다. §3.1.4는 오픈소스 프로그램이 어떤 소프트웨어·조직 단위·배포
+채널에 적용되는지, 그리고 어디까지가 적용 범위 밖인지를 명확하게 정의한
+문서화된 진술을 요구한다. 적용 범위는 조직의 규모와 비즈니스 모델에 따라
+다를 수 있으며, 이 조항은 그 선택을 명시적으로 기록하도록 한다.
+
+## 2. 해야 할 활동
+
+- 오픈소스 프로그램이 적용되는 소프트웨어 유형(외부 배포 제품, 서비스, 내부
+  시스템 등)을 결정한다.
+- 프로그램이 적용되는 조직 범위(전사, 특정 사업부, 특정 제품군 등)를 정의한다.
+- 적용 범위에서 명시적으로 제외되는 항목이 있다면 해당 예외 사항과 그 근거를
+  함께 기록한다.
+- 적용 범위 진술을 문서화하여 오픈소스 정책 또는 별도 문서로 공식 관리한다.
+- 비즈니스 환경 변화(신규 사업 진출, 인수합병 등) 시 적용 범위를 재검토하고
+  갱신한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.1.4 | 공급자의 필요와 비즈니스 모델에 따라 프로그램의 적용 범위가 다를 수 있다. 범위는 전체 조직, 특정 사업 단위, 특정 제품군, 특정 제품, 또는 단일 오픈소스 컴포넌트가 될 수 있다. 범위의 정의는 명확해야 한다. | **3.1.4.1** 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.1.4 Program Scope**
+> 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.
+>
+> **Verification Material(s):**
+> 3.1.4.1 A written statement that clearly defines the scope and limits of
+> the program.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.1.4.1 프로그램 적용 범위 진술
+
+**준수 방법**
+
+프로그램이 어디에 적용되고 어디에 적용되지 않는지를 명확하게 서술한 문서를
+작성해야 한다. 이 진술은 오픈소스 정책 문서(§3.1.1.1)의 적용 범위 섹션에
+포함하거나 별도 문서로 관리할 수 있다. 핵심은 경계가 명확해야 한다는 점이다.
+예를 들어 "외부에 배포하는 모든 소프트웨어 제품"처럼 명확하게 기술하거나,
+"A 사업부가 개발하는 임베디드 소프트웨어에 한정"처럼 범위를 구체적으로
+한정할 수 있다.
+
+적용 범위를 결정할 때는 소프트웨어 배포 형태(바이너리 제품, SaaS, 내부 도구),
+오픈소스 사용 방식(직접 사용, 간접 의존성), 외부 기여 활동 등을 종합적으로
+고려한다. 내부 사용 목적 소프트웨어에 대한 처리 방침도 명시하는 것이 바람직하다.
+적용 범위 진술은 비즈니스 환경 변화에 따라 정기적으로 검토하고 버전을 관리해야 한다.
+
+**고려사항**
+
+- **배포 형태 구분**: 외부 배포 제품, SaaS 서비스, 내부 시스템 등 소프트웨어
+  배포 유형별로 적용 여부를 명시한다.
+- **조직 범위 명시**: 전사 적용인지, 특정 사업부·제품군에만 적용되는지 명확하게
+  기술한다.
+- **예외 항목 기록**: 적용 범위에서 제외되는 항목이 있다면 예외 사유와 함께
+  문서에 명기한다.
+- **갱신 주기**: 신규 사업 진출, 인수합병, 제품 포트폴리오 변경 시 즉시 재검토하고
+  버전을 업데이트한다.
+- **정책 연계**: 적용 범위 진술은 오픈소스 정책 §1.4 적용 범위 섹션과 일관성을
+  유지한다.
+
+**샘플**
+
+아래는 오픈소스 정책 내 적용 범위 진술 샘플이다. 이 텍스트 자체가 입증자료
+3.1.4.1에 해당한다.
+
+```
+## 프로그램 적용 범위
+
+본 오픈소스 프로그램은 다음 범위에 적용된다:
+
+**적용 대상**
+- 회사가 외부에 배포하거나 판매하는 모든 소프트웨어 제품 (임베디드 소프트웨어
+  포함)
+- 외부 오픈소스 프로젝트에 대한 기여 활동
+- 내부 프로젝트를 오픈소스로 공개하는 활동
+
+**적용 제외**
+- 외부에 배포되지 않고 사내에서만 사용되는 소프트웨어 (단, 별도 검토 절차
+  적용 가능)
+- 제3자로부터 도입하는 상용 소프트웨어 (단, 오픈소스 포함 여부 검토 필요)
+
+**조직 범위**
+본 프로그램은 [회사명] 전 사업부에 적용되며, 자회사 및 계열사는 별도 협의를
+통해 적용 여부를 결정한다.
+
+이 적용 범위는 비즈니스 환경 변화에 따라 연 1회 이상 검토하며,
+변경 시 오픈소스 프로그램 매니저가 개정 버전을 공표한다.
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 2. 정책](../../../opensource_for_enterprise/2-policy/)
+- 관련 템플릿: [오픈소스 정책 템플릿 — §1.4 적용 범위](../../../templates/1-policy/)
diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md
new file mode 100644
index 000000000..5d8488758
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md
@@ -0,0 +1,128 @@
+---
+title: "§3.1.5 라이선스 의무"
+weight: 50
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "라이선스 의무"]
+description: >
+---
+
+## 1. 조항 개요
+
+오픈소스 컴포넌트를 소프트웨어에 포함할 때 가장 핵심적인 작업은 해당 컴포넌트에
+적용된 라이선스가 부과하는 의무·제한·권리를 정확히 파악하는 것이다. 라이선스
+의무를 검토하지 않고 배포하면 소스코드 강제 공개, 저작권 고지 누락, 특허 조항
+위반 등 심각한 법적 리스크가 발생할 수 있다. §3.1.5는 식별된 모든 라이선스에
+대해 의무·제한·권리를 검토하고 기록하는 절차를 수립하도록 요구한다. 이 절차는
+§3.3.2 라이선스 컴플라이언스 프로세스의 토대가 된다.
+
+## 2. 해야 할 활동
+
+- 소프트웨어에 사용된 오픈소스 컴포넌트의 라이선스를 식별하고 목록화한다.
+- 각 라이선스가 부과하는 의무(고지 의무, 소스코드 공개 의무 등), 제한(상업적
+  사용 제한, 특허 사용 제한 등), 권리(사용·수정·재배포 권리 등)를 검토한다.
+- 검토 결과를 라이선스별로 문서화하고 기록을 유지한다.
+- 라이선스 해석에 불확실성이 있는 경우 법무 담당에게 검토를 의뢰하는 절차를
+  수립한다.
+- 신규 라이선스 등장 또는 기존 라이선스 해석 변경 시 절차를 갱신한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.1.5 | 식별된 라이선스가 부과하는 의무, 제한 및 권리를 결정하기 위해 식별된 라이선스를 검토하는 프로세스가 존재해야 한다. | **3.1.5.1** 각 식별된 라이선스에 의해 부여된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.1.5 License Obligations**
+> A process shall exist for reviewing the identified licenses to determine
+> the obligations, restrictions and rights granted by each license.
+>
+> **Verification Material(s):**
+> 3.1.5.1 A documented procedure to review and document the obligations,
+> restrictions, and rights granted by each identified license.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.1.5.1 라이선스 의무 검토 절차
+
+**준수 방법**
+
+각 오픈소스 라이선스의 의무·제한·권리를 검토하고 기록하는 절차를 문서화해야 한다.
+절차에는 ①라이선스 식별, ②의무·제한·권리 분석, ③검토 결과 기록, ④불확실
+사항에 대한 법무 검토 의뢰, ⑤기록 보관의 단계가 포함되어야 한다. 이 절차 문서
+자체가 입증자료 3.1.5.1이다.
+
+라이선스별 의무는 사전에 정리된 라이선스 데이터베이스(SPDX License List 등)를
+활용하면 효율적으로 관리할 수 있다. 주요 라이선스(MIT, Apache-2.0, GPL-2.0,
+GPL-3.0, LGPL-2.1, AGPL-3.0 등)에 대한 의무 요약표를 미리 작성해 두고, 신규
+라이선스 발견 시 즉시 추가 검토하는 방식이 실무적으로 효과적이다. 복잡한 라이선스
+조합이나 법적 판단이 필요한 경우 법무 담당에게 에스컬레이션하는 기준도 절차에
+명시한다.
+
+**고려사항**
+
+- **SPDX 활용**: SPDX License List를 기준 라이선스 목록으로 사용하면 식별과
+  분류가 표준화된다.
+- **의무 유형 구분**: 고지 의무, 소스코드 공개 의무, 특허 조항, 상표 제한 등
+  의무 유형을 구분하여 기록한다.
+- **배포 형태별 검토**: 바이너리 배포, SaaS, 내부 사용 등 배포 형태에 따라
+  라이선스 의무가 달라질 수 있으므로 형태별로 검토한다.
+- **에스컬레이션 기준**: 법무 검토가 필요한 상황(라이선스 충돌, 비표준 라이선스,
+  상업적 제한 조항 등)을 절차에 명시한다.
+- **갱신 주기**: 신규 라이선스 채택 또는 기존 라이선스 해석 변경 시 즉시 절차와
+  기록을 갱신한다.
+
+**샘플**
+
+아래는 주요 오픈소스 라이선스 의무 요약표 샘플이다. 라이선스 검토 절차의 일환으로
+작성하여 보관하면 입증자료로 활용할 수 있다.
+
+```
+| 라이선스 | 고지 의무 | 소스코드 공개 | 수정본 동일 라이선스 | 특허 조항 | 상업적 사용 |
+|----------|-----------|--------------|----------------------|-----------|-------------|
+| MIT | O | X | X | X | O |
+| Apache-2.0 | O | X | X | O (특허 허여) | O |
+| GPL-2.0 | O | O (배포 시) | O | X | O |
+| GPL-3.0 | O | O (배포 시) | O | O (특허 허여) | O |
+| LGPL-2.1 | O | O (라이브러리) | O (라이브러리) | X | O |
+| AGPL-3.0 | O | O (네트워크 포함) | O | O (특허 허여) | O |
+| MPL-2.0 | O | O (파일 단위) | O (파일 단위) | O (특허 허여) | O |
+| BSD-2-Clause | O | X | X | X | O |
+| BSD-3-Clause | O | X | X | X | O |
+```
+
+아래는 라이선스 의무 검토 절차 개요 샘플이다.
+
+```
+[라이선스 의무 검토 절차]
+
+1. 라이선스 식별
+   - SBOM 생성 도구(FOSSology, ORT 등)를 통해 오픈소스 컴포넌트 및
+     라이선스를 식별한다.
+
+2. 의무·제한·권리 분석
+   - 사전 작성된 라이선스 의무 요약표를 참조하여 해당 라이선스의
+     의무·제한·권리를 확인한다.
+   - 요약표에 없는 라이선스는 SPDX License List 및 라이선스 원문을
+     검토하여 신규 항목을 추가한다.
+
+3. 법무 검토 의뢰 (해당 시)
+   - 라이선스 충돌, 비표준 라이선스, 상업적 제한 조항이 포함된 경우
+     법무 담당에게 검토를 의뢰한다.
+
+4. 검토 결과 기록
+   - 검토 결과를 SBOM 또는 라이선스 검토 기록서에 기록하고
+     오픈소스 관리 시스템에 보관한다.
+
+5. 의무 이행 확인
+   - 배포 전 라이선스 의무(고지문 포함, 소스코드 공개 등)가 완료되었는지
+     확인한다.
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/)
+- 관련 템플릿: [오픈소스 프로세스 템플릿](../../../templates/2-process-template/)
diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/_index.md
new file mode 100644
index 000000000..a50e3e782
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/1-program-foundation/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.1 프로그램 기반"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "프로그램 기반"]
+description: >
+---
diff --git a/content/ko/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md b/content/ko/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md
new file mode 100644
index 000000000..d9199d3bc
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md
@@ -0,0 +1,154 @@
+---
+title: "§3.2.1 외부 문의 대응"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "외부 문의"]
+description: >
+---
+
+## 1. 조항 개요
+
+소프트웨어를 배포하는 기업은 제3자(고객, 오픈소스 저작권자, 연구자 등)로부터
+오픈소스 라이선스 컴플라이언스에 관한 문의를 받을 수 있다. 이 문의에 제때
+응답하지 못하면 저작권 침해 분쟁으로 확대될 위험이 있다. §3.2.1은 외부
+문의를 접수할 수 있는 공개된 연락 수단을 마련하고, 내부적으로는 문의에 체계적으로
+대응하기 위한 절차를 문서화하도록 요구한다. 이 조항은 공개 채널(입증자료 3.2.1.1)과
+내부 대응 절차(입증자료 3.2.1.2) 두 가지를 모두 갖출 것을 요구한다.
+
+## 2. 해야 할 활동
+
+- 제3자가 오픈소스 라이선스 컴플라이언스 문의를 보낼 수 있는 공개 연락처(이메일
+  주소, 웹폼 등)를 제품 또는 웹사이트에 명시한다.
+- 외부 문의 접수부터 검토·답변·종결까지의 내부 대응 절차를 문서화한다.
+- 문의 유형별 담당자(오픈소스 프로그램 매니저, 법무 담당 등)와 에스컬레이션
+  경로를 절차에 포함한다.
+- 문의 접수 및 대응 이력을 기록하고 보관한다.
+- 정기적으로 공개 연락처 유효성과 내부 절차의 최신성을 점검한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.2.1 | 외부의 오픈소스 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제3자가 오픈소스 컴플라이언스 문의를 할 수 있는 수단을 공개적으로 밝혀야 한다. | **3.2.1.1** 제3자가 오픈소스 라이선스 컴플라이언스에 대해 문의할 수 있는 공개된 방법<br>**3.2.1.2** 제3자의 오픈소스 라이선스 컴플라이언스 문의에 대응하기 위한 내부의 문서화된 절차 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.2.1 Access**
+> 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.
+>
+> **Verification Material(s):**
+> 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).
+> 3.2.1.2 An internal documented procedure for responding to third party open
+> source license compliance inquiries.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.2.1.1 공개된 외부 문의 채널
+
+**준수 방법**
+
+제3자가 오픈소스 라이선스 컴플라이언스에 관한 문의를 보낼 수 있는 수단을
+공개적으로 명시해야 한다. 가장 일반적인 방법은 전용 이메일 주소(예:
+oss@company.com)를 제품 설명서, 소프트웨어 오픈소스 고지문, 또는 회사 웹사이트에
+게시하는 것이다. 이 공개 연락처 자체가 입증자료 3.2.1.1이다.
+
+연락처는 담당자 개인 이메일이 아닌 역할 기반 주소(role-based address)를 사용하는
+것이 좋다. 담당자가 변경되더라도 주소가 유지되며, 문의가 누락되지 않도록 팀
+메일함으로 관리하는 것이 바람직하다. OpenChain Conformance 웹사이트에 연락처를
+등록하는 방법도 활용할 수 있다.
+
+**고려사항**
+
+- **역할 기반 주소 사용**: 개인 이메일 대신 oss@company.com과 같은 역할 기반
+  주소를 사용하여 담당자 변경에 대비한다.
+- **게시 위치**: 제품 매뉴얼, 오픈소스 고지문(NOTICES 파일), 회사 웹사이트 등
+  제3자가 쉽게 찾을 수 있는 위치에 게시한다.
+- **응답 가능성 확인**: 게시된 연락처가 실제로 수신되고 모니터링되는지 정기적으로
+  점검한다.
+- **다국어 고려**: 글로벌 제품의 경우 영문 연락처도 함께 제공한다.
+
+**샘플**
+
+아래는 제품 오픈소스 고지문 또는 웹사이트에 게시하는 공개 연락처 샘플이다.
+
+```
+오픈소스 라이선스 컴플라이언스 문의
+
+이 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 컴플라이언스에 관한
+문의는 아래 이메일로 연락해 주십시오.
+
+- 이메일: oss@company.com
+- 응답 기간: 영업일 기준 14일 이내
+
+Open Source License Compliance Inquiry
+
+For inquiries regarding open source license compliance of this software,
+please contact: oss@company.com
+```
+
+---
+
+### 3.2.1.2 내부 외부 문의 대응 절차
+
+**준수 방법**
+
+외부 문의가 접수되었을 때 어떻게 처리할지를 정의한 내부 절차를 문서화해야 한다.
+절차에는 ①문의 접수 및 분류, ②담당자 배정, ③검토 및 답변 작성, ④법무 검토
+(필요 시), ⑤답변 발송, ⑥기록 보관의 단계가 포함되어야 한다. 이 절차 문서가
+입증자료 3.2.1.2다.
+
+답변 기한은 합리적인 범위에서 설정하고 절차에 명시한다. 일반적으로 14일 이내
+초기 응답, 60일 이내 최종 답변을 기준으로 삼는 경우가 많다. 문의 접수·처리·
+종결 이력은 사내 시스템에 기록하여 감사 시 제출할 수 있도록 보관한다.
+
+**고려사항**
+
+- **담당자 및 에스컬레이션**: 1차 담당자(오픈소스 프로그램 매니저)와 법무 검토
+  에스컬레이션 경로를 절차에 명시한다.
+- **응답 기한**: 초기 응답과 최종 답변의 기한을 절차에 명시하고 준수한다.
+- **기록 보관**: 문의 내용, 검토 과정, 최종 답변을 기록하고 최소 3년간 보관한다.
+- **유형별 대응**: 라이선스 고지 요청, 소스코드 제공 요청, 저작권 침해 주장 등
+  문의 유형별 대응 방법을 절차에 포함한다.
+
+**샘플**
+
+아래는 외부 문의 대응 절차 개요 샘플이다.
+
+```
+[외부 오픈소스 문의 대응 절차]
+
+1. 접수 및 분류 (1영업일 이내)
+   - oss@company.com 수신함을 매일 확인한다.
+   - 문의를 유형별로 분류한다:
+     A. 오픈소스 고지문 또는 소스코드 제공 요청
+     B. 라이선스 의무 준수 여부 확인 요청
+     C. 저작권 침해 주장 또는 법적 경고
+
+2. 담당자 배정 및 초기 응답 (3영업일 이내)
+   - 오픈소스 프로그램 매니저가 문의를 검토하고 수신 확인 답변을 발송한다.
+   - C유형(법적 경고)은 즉시 법무 담당에게 에스컬레이션한다.
+
+3. 검토 및 답변 작성 (14영업일 이내)
+   - 관련 SBOM, 라이선스 기록, 컴플라이언스 산출물을 검토한다.
+   - A유형: 고지문 또는 소스코드를 확인하여 제공한다.
+   - B유형: 컴플라이언스 이행 증거를 검토하여 답변한다.
+   - 필요 시 법무 담당에게 답변 초안 검토를 의뢰한다.
+
+4. 답변 발송 및 종결
+   - 최종 답변을 발송하고 문의를 종결 처리한다.
+
+5. 기록 보관
+   - 문의 내용, 검토 과정, 최종 답변을 문서화하여 최소 3년간 보관한다.
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/)
+- 관련 템플릿: [오픈소스 정책 템플릿 — §9 외부 문의 대응](../../../templates/1-policy/)
diff --git a/content/ko/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md b/content/ko/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md
new file mode 100644
index 000000000..be695f576
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md
@@ -0,0 +1,268 @@
+---
+title: "§3.2.2 효과적 리소스"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "리소스"]
+description: >
+---
+
+## 1. 조항 개요
+
+오픈소스 프로그램이 실제로 작동하려면 역할을 정의하는 것만으로는 부족하다.
+각 역할을 담당할 실제 인원이 배정되고, 업무 수행에 필요한 시간과 예산이
+충분히 지원되어야 한다. §3.2.2는 프로그램 역할별 담당자를 문서로 명시하고,
+인원 배치와 예산이 적절히 이루어졌음을 확인하며, 법률 자문 접근 방법과 내부
+책임 할당 절차, 미준수 사례 처리 절차를 갖출 것을 요구한다. 이 조항은 5개의
+입증자료 항목으로 구성되어 §3.1 프로그램 기반에서 정의한 역할 구조를 실제
+운영 체계로 구현하는 단계다.
+
+## 2. 해야 할 활동
+
+- 프로그램 내 각 역할(오픈소스 프로그램 매니저, 법무 담당, IT 담당 등)을 맡은
+  담당자의 이름 또는 직무를 문서에 기재한다.
+- 각 역할 담당자가 업무를 수행할 수 있도록 충분한 시간과 예산이 배정되었음을
+  확인하고 기록한다.
+- 오픈소스 라이선스 컴플라이언스 관련 법적 문제 발생 시 이용할 수 있는 내부
+  또는 외부 법률 자문 수단을 식별하고 문서화한다.
+- 오픈소스 컴플라이언스 내부 책임을 각 역할에 할당하는 절차를 문서화한다.
+- 컴플라이언스 미준수 사례를 발견했을 때 검토하고 시정하는 절차를 문서화한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.2.2 | 프로그램 업무를 식별하고 리소스를 제공한다: 프로그램 업무의 성공적 수행을 위한 책임을 할당한다 / 프로그램 업무에 충분한 리소스(시간·예산)를 제공한다 / 법적 전문성에 접근할 수 있는 방법을 확보한다 / 미준수 사례 검토 및 시정 프로세스를 마련한다 | **3.2.2.1** 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서<br>**3.2.2.2** 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 함<br>**3.2.2.3** 오픈소스 라이선스 컴플라이언스 문제 해결을 위해 내부 또는 외부의 전문 법률 자문을 이용할 수 있는 방법<br>**3.2.2.4** 오픈소스 컴플라이언스에 대한 내부 책임을 할당하는 문서화된 절차<br>**3.2.2.5** 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.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:
+>   - Time to perform the tasks has been allocated;
+>   - Adequate funding has been allocated;
+>   - A process exists for the review and resolution of open source license
+>     compliance failures;
+>   - Legal expertise pertaining to open source license compliance is
+>     accessible to those that may need such guidance; and
+>   - A process exists for the escalation of open source license compliance
+>     issues.
+>
+> **Verification Material(s):**
+> 3.2.2.1 A document with the names of the persons, group or function in
+> program role(s) identified.
+> 3.2.2.2 The identified program roles have been properly staffed and adequate
+> funding provided.
+> 3.2.2.3 Identification of legal expertise available to address open source
+> license compliance matters which could be internal or external.
+> 3.2.2.4 A documented procedure that assigns internal responsibilities for
+> open source compliance.
+> 3.2.2.5 A documented procedure for handling the review and remediation of
+> non-compliant cases.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.2.2.1 역할 담당자 명시 문서
+
+**준수 방법**
+
+프로그램의 각 역할을 실제로 담당하는 인원의 이름, 그룹명, 또는 직무명을
+기재한 문서를 작성해야 한다. 이 문서는 §3.1.2.1의 역할·책임 목록 문서에
+담당자 정보를 추가하는 형태로 관리하거나, 오픈소스 정책 Appendix에 담당자
+현황표로 포함할 수 있다. 특정 개인 이름 대신 직무명(오픈소스 프로그램 매니저,
+법무팀장 등)을 사용해도 무방하며, 조직 변경 시 즉시 갱신해야 한다.
+
+**고려사항**
+
+- **개인명 또는 직무명**: 이름 대신 직무명을 사용하면 인사 변동 시에도 문서를
+  자주 갱신할 필요가 줄어든다.
+- **겸임 명시**: 한 사람이 여러 역할을 담당하는 경우 모든 역할에 해당 사실을
+  기재한다.
+- **갱신 관리**: 조직 변경·인사 이동 발생 시 즉시 문서를 업데이트하고 버전을
+  기록한다.
+
+**샘플**
+
+아래는 역할 담당자 현황표 샘플이다.
+[오픈소스 정책 템플릿 Appendix 1](../../../templates/1-policy/appendix/)에서
+전체 양식을 확인할 수 있다.
+
+```
+| 역할 | 담당자 | 연락처 |
+|------|--------|--------|
+| 오픈소스 프로그램 매니저 | 홍길동 (개발팀장) | oss@company.com |
+| 법무 담당 | 김법무 (법무팀장) | legal@company.com |
+| IT 담당 | 이인프라 (인프라팀) | it-oss@company.com |
+| 보안 담당 | 박보안 (보안팀) | security@company.com |
+| 개발 문화 담당 | 최문화 (HR팀) | culture@company.com |
+```
+
+---
+
+### 3.2.2.2 인원 배치 및 예산 지원 확인
+
+**준수 방법**
+
+각 역할 담당자가 오픈소스 프로그램 업무를 수행할 수 있도록 충분한 시간과
+예산이 배정되었음을 확인하고 그 근거를 기록해야 한다. 별도의 전담 조직이
+없는 경우에도 겸임 담당자가 해당 업무에 투입할 수 있는 시간이 확보되었는지,
+도구 구매나 교육비 등 필요 예산이 편성되었는지를 확인하는 내부 기록이 있어야
+한다. 경영진 승인이 포함된 예산 계획서나 업무 분장 문서가 이 입증자료에 해당할
+수 있다.
+
+**고려사항**
+
+- **전담 여부 명시**: 전담 인원인지 겸임인지를 기록하고, 겸임의 경우 투입
+  비율(예: 업무 시간의 20%)을 명시한다.
+- **예산 근거 보관**: 도구 구매 계약서, 교육비 집행 내역, 외부 컨설팅 계약 등
+  예산 지원을 증명하는 기록을 보관한다.
+- **경영진 확인**: 인원 배치와 예산 지원에 대한 경영진 승인 또는 확인 기록을
+  유지한다.
+
+**샘플**
+
+```
+[오픈소스 프로그램 리소스 배정 확인서]
+
+프로그램 연도: 2026년
+승인자: [임원명] / 승인일: 2026-01-10
+
+| 역할 | 담당자 | 투입 비율 | 연간 예산 |
+|------|--------|-----------|-----------|
+| 오픈소스 프로그램 매니저 | 홍길동 | 50% | - |
+| 법무 담당 | 김법무 | 20% | - |
+| IT 담당 (도구 운영) | 이인프라 | 10% | 도구 라이선스 비용 포함 |
+| 교육 예산 | - | - | 연간 OOO만 원 |
+| 외부 법률 자문 예산 | - | - | 필요 시 집행 |
+```
+
+---
+
+### 3.2.2.3 법률 자문 접근 방법
+
+**준수 방법**
+
+오픈소스 라이선스 컴플라이언스와 관련된 법적 문제가 발생했을 때 전문 법률
+자문을 받을 수 있는 방법을 식별하고 문서화해야 한다. 내부 법무팀이 있는 경우
+해당 팀의 연락처와 에스컬레이션 절차를 기록하고, 내부 법무팀이 없거나 전문성이
+부족한 경우 외부 법무법인 또는 오픈소스 컨설팅 전문가를 활용하는 방법을
+문서에 명시한다.
+
+**고려사항**
+
+- **내부 vs. 외부**: 내부 법무팀 활용 방법과 외부 자문 의뢰 기준을 모두 명시한다.
+- **에스컬레이션 기준**: 어떤 상황에서 법률 자문을 받아야 하는지(저작권 침해
+  주장, 비표준 라이선스, 특허 조항 등) 기준을 절차에 포함한다.
+- **외부 자문 목록 관리**: 오픈소스 전문 외부 법무법인 또는 컨설턴트 정보를
+  최신 상태로 유지한다.
+
+**샘플**
+
+```
+[법률 자문 접근 방법]
+
+내부 법무팀:
+- 담당: 법무팀 (legal@company.com)
+- 에스컬레이션 기준: 저작권 침해 주장 접수, GPL 계열 라이선스 의무
+  해석 불확실, 비표준 라이선스 검토 필요 시
+
+외부 법률 자문:
+- 활용 기준: 내부 법무팀에서 판단이 어려운 복잡한 법적 분쟁 발생 시
+- 계약 현황: [외부 법무법인명] (연간 자문 계약 체결)
+- 오픈소스 전문 컨설팅: OpenChain 파트너사 목록 참조
+```
+
+---
+
+### 3.2.2.4 내부 책임 할당 절차
+
+**준수 방법**
+
+오픈소스 컴플라이언스와 관련된 내부 책임을 각 역할에 명확히 할당하는 절차를
+문서화해야 한다. 이 절차는 누가 무엇을 책임지는지를 정의하며, 오픈소스 사용
+승인, SBOM 생성, 라이선스 검토, 컴플라이언스 산출물 배포 등 각 업무 단계별
+책임자를 명시한다. 이 절차 문서는 오픈소스 정책 또는 프로세스 문서에 포함할
+수 있다.
+
+**고려사항**
+
+- **업무 단계별 책임 명시**: 오픈소스 도입, 검토, 승인, 배포 각 단계마다
+  책임자를 지정한다.
+- **RACI 활용**: 역할별 책임(Responsible, Accountable, Consulted, Informed)을
+  RACI 매트릭스로 정의하면 명확성이 높아진다.
+- **갱신 주기**: 조직 변경 또는 프로세스 변경 시 절차를 즉시 갱신한다.
+
+**샘플**
+
+```
+| 업무 | 오픈소스 PM | 법무 담당 | IT 담당 | 보안 담당 | 개발자 |
+|------|------------|-----------|---------|-----------|--------|
+| 오픈소스 사용 승인 | A | C | - | C | R |
+| 라이선스 의무 검토 | R | A | - | - | I |
+| SBOM 생성 | A | - | R | - | C |
+| 취약점 모니터링 | I | - | C | A/R | I |
+| 컴플라이언스 산출물 배포 | A | C | R | - | I |
+| 외부 문의 대응 | A/R | C | - | - | - |
+
+R: 실행 책임 / A: 최종 책임 / C: 협의 / I: 정보 공유
+```
+
+---
+
+### 3.2.2.5 미준수 사례 검토 및 시정 절차
+
+**준수 방법**
+
+오픈소스 컴플라이언스 미준수 사례(라이선스 의무 불이행, SBOM 누락, 무승인
+오픈소스 사용 등)가 발견되었을 때 이를 검토하고 시정하는 절차를 문서화해야
+한다. 절차에는 ①미준수 사례 식별 및 보고, ②심각도 평가, ③원인 분석,
+④시정 조치, ⑤재발 방지 대책, ⑥기록 보관이 포함되어야 한다.
+
+미준수 사례는 내부 감사, 외부 문의, 자동화 도구 알림 등 다양한 경로로
+발견될 수 있다. 심각도에 따라 긴급 조치(배포 중단, 소스코드 즉시 공개 등)와
+일반 조치를 구분하여 처리 기한을 다르게 설정하는 것이 효과적이다.
+
+**고려사항**
+
+- **심각도 분류**: 미준수 사례의 법적 리스크에 따라 심각도(높음/중간/낮음)를
+  분류하고 처리 기한을 다르게 설정한다.
+- **에스컬레이션**: 심각도가 높은 사례는 경영진 보고 및 법무 검토를 의무화한다.
+- **재발 방지**: 시정 조치 완료 후 동일 유형의 미준수가 재발하지 않도록
+  프로세스 개선 방안을 도출하고 기록한다.
+- **기록 보관**: 미준수 사례 이력과 시정 완료 기록을 최소 3년간 보관한다.
+
+**샘플**
+
+```
+[미준수 사례 처리 절차]
+
+1. 식별 및 보고
+   - 내부 감사, 외부 문의, CI/CD 도구 알림 등을 통해 미준수 사례를 식별한다.
+   - 오픈소스 프로그램 매니저에게 즉시 보고한다.
+
+2. 심각도 평가
+   - 높음: 배포된 소프트웨어의 GPL 소스코드 미공개, 저작권 침해 주장 접수
+     → 48시간 이내 긴급 검토 착수
+   - 중간: SBOM 누락, 라이선스 고지문 불완전
+     → 7영업일 이내 시정 조치 완료
+   - 낮음: 내부 프로세스 미준수 (승인 절차 생략 등)
+     → 30일 이내 시정 조치 완료
+
+3. 원인 분석 및 시정 조치
+   - 미준수 원인을 파악하고 시정 방안을 수립한다.
+   - 높음·중간 사례는 법무 담당과 협의 후 조치한다.
+
+4. 재발 방지
+   - 프로세스 또는 교육 개선 방안을 도출하고 이행한다.
+
+5. 기록 보관
+   - 사례 내용, 조치 경과, 완료 일자를 기록하고 최소 3년간 보관한다.
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 1. 조직](../../../opensource_for_enterprise/1-teams/)
+- 관련 템플릿: [오픈소스 정책 템플릿 — Appendix 1. 담당자 현황](../../../templates/1-policy/appendix/)
diff --git a/content/ko/guide/iso5230_guide/2-relevant-tasks/_index.md b/content/ko/guide/iso5230_guide/2-relevant-tasks/_index.md
new file mode 100644
index 000000000..fe5b71e65
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/2-relevant-tasks/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.2 관련 업무"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "관련 업무"]
+description: >
+---
diff --git a/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md b/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md
new file mode 100644
index 000000000..266bc18b1
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md
@@ -0,0 +1,178 @@
+---
+title: "§3.3.1 SBOM"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "SBOM"]
+description: >
+---
+
+## 1. 조항 개요
+
+공급 소프트웨어에 어떤 오픈소스 컴포넌트가 포함되어 있는지 파악하지 못하면
+라이선스 의무를 이행할 수 없고 보안 취약점 대응도 불가능하다. §3.3.1은 공급
+소프트웨어를 구성하는 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는
+절차를 수립하고, 그 절차가 실제로 이행되었음을 입증하는 컴포넌트 기록(SBOM)을
+유지하도록 요구한다. 이 조항은 오픈소스 라이선스 컴플라이언스와 보안 보증의
+핵심 인프라인 SBOM을 운영하는 기반이 된다.
+
+## 2. 해야 할 활동
+
+- 공급 소프트웨어에 포함된 오픈소스 컴포넌트를 자동화 도구(FOSSology, ORT,
+  Syft, cdxgen 등)를 활용하여 식별하고 목록화한다.
+- 오픈소스 컴포넌트 정보(컴포넌트명, 버전, 라이선스, 출처 등)를 추적하고
+  검토·승인·보관하는 절차를 문서화한다.
+- 각 공급 소프트웨어 릴리스에 대한 SBOM을 생성하고 관리한다.
+- SBOM 데이터를 SPDX 또는 CycloneDX 표준 형식으로 작성하여 상호 운용성을
+  확보한다.
+- 소프트웨어 변경(신규 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거) 시
+  SBOM을 즉시 갱신한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.3.1 | 공급 소프트웨어를 구성하는 각 오픈소스 컴포넌트(및 식별된 라이선스)를 포함하는 소프트웨어 구성 목록을 작성하고 관리하기 위한 프로세스가 존재해야 한다. | **3.3.1.1** 공급 소프트웨어를 구성하는 오픈소스 컴포넌트에 대한 정보를 식별, 추적, 검토, 승인 및 보관하는 문서화된 절차<br>**3.3.1.2** 문서화된 절차가 적절히 준수되었음을 보여주는 공급 소프트웨어에 대한 오픈소스 컴포넌트 기록 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.3.1 Bill of Materials**
+> 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.
+>
+> **Verification Material(s):**
+> 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.
+> 3.3.1.2 Open source component records for the supplied software that
+> demonstrates the documented procedure was followed.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.3.1.1 오픈소스 컴포넌트 관리 절차
+
+**준수 방법**
+
+공급 소프트웨어에 포함된 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는
+일련의 절차를 문서화해야 한다. 절차는 소프트웨어 개발 주기 전반에 걸쳐
+오픈소스가 어떻게 관리되는지를 다루며, ①컴포넌트 식별, ②라이선스 확인,
+③의무 검토, ④사용 승인, ⑤SBOM 생성 및 등록, ⑥배포 시 SBOM 제공,
+⑦변경 시 SBOM 갱신, ⑧SBOM 보관의 단계를 포함해야 한다. 이 절차 문서 자체가
+입증자료 3.3.1.1이다.
+
+SBOM은 SPDX(ISO/IEC 5962) 또는 CycloneDX 형식을 채택하여 표준화하는 것을
+권장한다. 자동화 도구를 CI/CD 파이프라인에 통합하면 컴포넌트 변경 시 SBOM이
+자동으로 갱신되어 최신성을 유지하기 쉽다.
+
+**고려사항**
+
+- **자동화 도구 통합**: FOSSology, ORT, Syft, cdxgen 등을 CI/CD에 통합하여
+  SBOM 생성을 자동화한다.
+- **표준 형식 채택**: SPDX 또는 CycloneDX 형식으로 SBOM을 작성하여 공급망
+  파트너와의 상호 운용성을 확보한다.
+- **갱신 트리거 정의**: 신규 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거,
+  라이선스 변경 발생 시 SBOM 갱신을 의무화한다.
+- **승인 절차 명시**: 새로운 오픈소스 컴포넌트 도입 시 오픈소스 프로그램 매니저
+  또는 OSRB의 승인 절차를 절차에 포함한다.
+- **보관 기간**: SBOM은 해당 소프트웨어 배포 후 최소 [N]년간 보관한다.
+
+**샘플**
+
+아래는 오픈소스 컴포넌트 관리 절차 개요 샘플이다.
+[오픈소스 프로세스 템플릿](../../../templates/2-process-template/)에서
+전체 프로세스 양식을 확인할 수 있다.
+
+```
+[오픈소스 컴포넌트 관리 절차 개요]
+
+(1) 식별
+    - 개발자는 오픈소스 컴포넌트 도입 시 오픈소스 관리 시스템에 신고한다.
+    - CI/CD 파이프라인의 SCA 도구(Syft, ORT 등)가 컴포넌트를 자동 탐지한다.
+
+(2) 라이선스 확인 및 의무 검토
+    - 식별된 컴포넌트의 라이선스를 SPDX License List 기준으로 확인한다.
+    - 라이선스 의무 요약표를 참조하여 배포 형태에 따른 의무를 검토한다.
+    - 불확실한 경우 법무 담당에게 검토를 의뢰한다.
+
+(3) 사용 승인
+    - 오픈소스 프로그램 매니저가 검토 결과를 바탕으로 사용을 승인한다.
+    - 라이선스 정책에 반하는 컴포넌트는 대안 검토 후 반려한다.
+
+(4) SBOM 생성 및 등록
+    - 승인된 컴포넌트를 SBOM에 등록한다 (형식: SPDX 또는 CycloneDX).
+    - SBOM에는 컴포넌트명, 버전, 라이선스, 출처(URL), 저작권 고지를 포함한다.
+
+(5) 배포 및 SBOM 제공
+    - 소프트웨어 배포 시 SBOM을 함께 제공하거나 요청 시 제공한다.
+
+(6) 변경 시 갱신
+    - 컴포넌트 추가·업그레이드·제거·라이선스 변경 발생 시 SBOM을 즉시 갱신한다.
+
+(7) 보관
+    - SBOM은 소프트웨어 배포 후 최소 [N]년간 버전별로 보관한다.
+```
+
+---
+
+### 3.3.1.2 오픈소스 컴포넌트 기록 (SBOM)
+
+**준수 방법**
+
+3.3.1.1에서 정의한 절차가 실제로 이행되었음을 보여주는 컴포넌트 기록을
+공급 소프트웨어별로 유지해야 한다. 이 기록이 SBOM(Software Bill of Materials)이며
+입증자료 3.3.1.2에 해당한다. SBOM에는 최소한 각 오픈소스 컴포넌트의 이름·버전·
+라이선스·출처가 포함되어야 하며, SPDX 또는 CycloneDX 형식으로 작성하면 감사
+시 즉시 제출 가능한 형태가 된다.
+
+SBOM은 소프트웨어 릴리스 버전별로 관리하고, 과거 버전의 SBOM도 보관하여
+특정 시점의 컴포넌트 구성을 언제든 확인할 수 있어야 한다. SBOM 생성 도구의
+출력 결과를 그대로 활용하거나, 오픈소스 관리 시스템(SW360, Dependency-Track 등)에
+저장·관리하는 방식을 사용할 수 있다.
+
+**고려사항**
+
+- **필수 포함 항목**: 컴포넌트명, 버전, 라이선스 식별자(SPDX ID), 출처(패키지
+  레지스트리 URL 또는 소스 저장소), 저작권 고지를 포함한다.
+- **버전별 관리**: 소프트웨어 릴리스 버전별로 SBOM을 별도 관리하고 과거 버전도
+  보관한다.
+- **관리 도구 활용**: SW360, Dependency-Track 등 오픈소스 관리 시스템을 활용하면
+  SBOM의 생성·추적·배포를 체계적으로 관리할 수 있다.
+- **고객 제공**: 고객 또는 공급망 파트너가 SBOM을 요청하는 경우 즉시 제공할 수
+  있도록 접근 가능한 형태로 보관한다.
+
+**샘플**
+
+아래는 SPDX 형식 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. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/)
+- 관련 템플릿: [오픈소스 프로세스 템플릿](../../../templates/2-process-template/)
+- 관련 도구: [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/ko/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md b/content/ko/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md
new file mode 100644
index 000000000..dcfd6bebc
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md
@@ -0,0 +1,130 @@
+---
+title: "§3.3.2 라이선스 컴플라이언스"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "라이선스 컴플라이언스"]
+description: >
+---
+
+## 1. 조항 개요
+
+오픈소스 컴포넌트는 배포 형태(바이너리·소스코드), 수정 여부, 다른 컴포넌트와의
+결합 방식에 따라 라이선스 의무가 달라진다. §3.3.2는 공급 소프트웨어에 포함된
+오픈소스 컴포넌트에 대해 자주 발생하는 라이선스 사용 사례들을 처리할 수 있는
+능력을 프로그램이 갖추도록 요구한다. 이 조항은 단순히 라이선스를 식별하는 것을
+넘어, 다양한 배포 시나리오별로 의무 이행 방법을 정의한 절차를 마련하도록 한다.
+
+## 2. 해야 할 활동
+
+- 바이너리 형태 배포, 소스코드 형태 배포, 수정된 오픈소스 배포 등 주요 라이선스
+  사용 사례를 식별하고 각 사례별 처리 절차를 수립한다.
+- 라이선스 충돌(비호환 라이선스 컴포넌트 결합)이 발생했을 때의 처리 방법을
+  절차에 포함한다.
+- 고지 의무(저작권 고지문, 라이선스 전문 포함)가 필요한 라이선스에 대한
+  처리 방법을 정의한다.
+- GPL 등 소스코드 공개 의무가 있는 라이선스가 포함된 소프트웨어의 배포 절차를
+  수립한다.
+- 절차를 문서화하고 정기적으로 검토하여 새로운 라이선스 유형에 대응한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.3.2 | 프로그램은 공급 소프트웨어의 오픈소스 컴포넌트에 대한 일반적인 오픈소스 라이선스 사용 사례를 처리할 수 있어야 한다. 처리해야 할 사용 사례는 바이너리 형태 배포 / 소스코드 형태 배포 / 추가 라이선스 의무를 유발할 수 있는 다른 오픈소스와의 통합 / 수정된 오픈소스 포함 / 공급 소프트웨어 내 다른 컴포넌트와 비호환 라이선스 포함 / 저작권 고지 요건이 있는 오픈소스 포함 등을 포함할 수 있다. | **3.3.2.1** 공급 소프트웨어 내의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리하기 위한 문서화된 절차 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.3.2 License Compliance**
+> 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 (note that the list is not exhaustive and
+> some of the below use cases may not apply):
+> - 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; and/or
+> - contains open source with attribution requirements.
+>
+> **Verification Material(s):**
+> 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.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.3.2.1 라이선스 사용 사례별 처리 절차
+
+**준수 방법**
+
+공급 소프트웨어에 오픈소스가 포함되는 다양한 시나리오별로 라이선스 의무를
+어떻게 이행하는지 정의한 절차를 문서화해야 한다. 이 절차 문서가 입증자료
+3.3.2.1이다. ISO/IEC 5230은 아래 6가지 주요 사용 사례를 예시로 제시하며,
+조직의 비즈니스 환경에 따라 해당되는 사례를 선택하여 처리 절차를 수립한다.
+
+각 사용 사례별 절차에는 ①해당 사례 해당 여부 판단 기준, ②라이선스 의무 항목,
+③의무 이행 방법, ④담당자, ⑤산출물(고지문, 소스코드 패키지 등)이 포함되어야
+한다. 라이선스 충돌이 발생하는 경우 법무 담당에게 에스컬레이션하는 경로도
+명시한다.
+
+**고려사항**
+
+- **사용 사례 범위 확정**: 조직의 소프트웨어 배포 방식에 맞는 사용 사례를
+  선택하여 절차를 수립한다 (모든 사례가 모든 조직에 해당되지 않을 수 있다).
+- **라이선스 충돌 대응**: GPL과 Apache-2.0 등 비호환 라이선스 조합 발생 시
+  처리 방법을 미리 정의해 둔다.
+- **고지문 관리**: 저작권 고지 의무가 있는 라이선스에 대해 NOTICES 파일 또는
+  제품 설명서 내 고지문 작성 절차를 수립한다.
+- **소스코드 공개 절차**: GPL 계열 라이선스의 소스코드 공개 요청 대응 절차를
+  별도로 정의한다.
+- **갱신 주기**: 신규 라이선스 유형 도입 또는 배포 형태 변경 시 절차를 갱신한다.
+
+**샘플**
+
+아래는 라이선스 사용 사례별 처리 절차 요약표 샘플이다.
+
+```
+| 사용 사례 | 라이선스 예시 | 주요 의무 | 처리 방법 |
+|-----------|--------------|-----------|-----------|
+| 바이너리 형태 배포 | MIT, Apache-2.0 | 저작권 고지문 포함 | NOTICES 파일 또는 앱 내 고지 화면에 고지문 포함 |
+| 바이너리 형태 배포 | GPL-2.0, GPL-3.0 | 소스코드 공개 또는 제공 약정서 포함 | 소스코드 패키지 배포 또는 written offer 동봉 |
+| 소스코드 형태 배포 | 모든 라이선스 | 원본 라이선스 파일 및 저작권 고지 보존 | 라이선스 파일과 저작권 고지를 그대로 유지 |
+| 수정된 오픈소스 포함 | GPL-2.0, LGPL-2.1 | 수정 사항 명시, 수정본 동일 라이선스 적용 | 수정 내역 기록, 수정본 소스코드 공개 |
+| 비호환 라이선스 결합 | GPL-2.0 + Apache-2.0 | 라이선스 충돌 해소 | 법무 검토 후 컴포넌트 대체 또는 구조 변경 |
+| 저작권 고지 요건 | BSD-3-Clause, Apache-2.0 | 제품 문서 또는 UI에 저작권 고지 포함 | 제품 설명서 또는 About 화면에 고지문 추가 |
+```
+
+아래는 배포 형태별 라이선스 의무 처리 절차 개요 샘플이다.
+
+```
+[바이너리 배포 시 라이선스 의무 처리 절차]
+
+1. SBOM 확인
+   - 배포 소프트웨어의 최신 SBOM을 기준으로 포함된 오픈소스 목록을 확인한다.
+
+2. 라이선스 의무 분류
+   - 고지문 의무: MIT, Apache-2.0, BSD 등 → NOTICES 파일 작성
+   - 소스코드 공개 의무: GPL-2.0, GPL-3.0 → 소스코드 패키지 준비
+   - LGPL: 동적 링크 여부에 따라 의무 범위 판단 (필요 시 법무 검토)
+
+3. 컴플라이언스 산출물 준비
+   - NOTICES 파일: 모든 오픈소스의 저작권 고지문 및 라이선스 전문 포함
+   - 소스코드 패키지: GPL 컴포넌트의 수정된 소스코드 및 빌드 스크립트 포함
+
+4. 검토 및 승인
+   - 오픈소스 프로그램 매니저가 산출물의 완전성을 최종 검토한다.
+   - 라이선스 충돌 또는 불확실한 사항은 법무 담당에게 에스컬레이션한다.
+
+5. 배포
+   - 컴플라이언스 산출물을 소프트웨어와 함께 제공한다.
+   - 산출물 사본을 보관한다 (§3.4.1 참조).
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/)
+- 관련 템플릿: [오픈소스 프로세스 템플릿](../../../templates/2-process-template/)
diff --git a/content/ko/guide/iso5230_guide/3-content-review/_index.md b/content/ko/guide/iso5230_guide/3-content-review/_index.md
new file mode 100644
index 000000000..88165150d
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/3-content-review/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.3 콘텐츠 검토 및 승인"
+weight: 30
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "콘텐츠 검토"]
+description: >
+---
diff --git a/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md b/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md
new file mode 100644
index 000000000..5ad27777d
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md
@@ -0,0 +1,150 @@
+---
+title: "§3.4.1 산출물"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "컴플라이언스 산출물"]
+description: >
+---
+
+## 1. 조항 개요
+
+라이선스 의무를 이행하려면 실제로 고지문, 소스코드 패키지 등 컴플라이언스
+산출물을 준비하여 소프트웨어와 함께 제공해야 한다. §3.4.1은 식별된 라이선스가
+요구하는 컴플라이언스 산출물을 준비하고 공급 소프트웨어와 함께 배포하는 절차,
+그리고 산출물 사본을 일정 기간 보관하는 절차를 수립하도록 요구한다. 이 조항은
+§3.3 검토·승인 단계의 결과물을 실제 배포와 보관으로 연결하는 단계다.
+
+## 2. 해야 할 활동
+
+- 라이선스별로 요구되는 컴플라이언스 산출물(NOTICES 파일, 소스코드 패키지,
+  written offer 등)의 유형을 정의한다.
+- 산출물을 준비하여 공급 소프트웨어와 함께 제공하는 절차를 문서화한다.
+- 배포된 산출물의 사본을 일정 기간 보관하는 절차를 수립하고 문서화한다.
+- 산출물 보관 기간을 정책에 명시한다 (업계 관행: 마지막 배포 후 최소 3년).
+- 보관 절차가 올바르게 수행되었음을 입증하는 기록을 유지한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.4.1 | 공급 소프트웨어에 대해 식별된 컴플라이언스 산출물을 생성하기 위한 프로세스가 존재해야 한다. | **3.4.1.1** 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고, 이를 공급 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차<br>**3.4.1.2** 공급 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차. 이러한 절차가 올바르게 수행되었음을 입증하는 기록이 존재해야 함 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.4.1 Compliance Artifacts**
+> A process shall exist for creating the identified compliance artifacts for
+> the supplied software.
+>
+> **Verification Material(s):**
+> 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.
+> 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.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.4.1.1 컴플라이언스 산출물 준비 및 배포 절차
+
+**준수 방법**
+
+라이선스 의무에 따른 컴플라이언스 산출물을 준비하고 공급 소프트웨어와 함께
+제공하는 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.4.1.1이다.
+절차에는 ①산출물 유형 결정, ②산출물 작성, ③검토 및 승인, ④소프트웨어와
+함께 제공, ⑤기록 보관의 단계가 포함되어야 한다.
+
+컴플라이언스 산출물의 유형은 배포하는 라이선스에 따라 달라진다. 일반적으로
+고지 의무 라이선스(MIT, Apache-2.0 등)는 NOTICES 파일이 필요하고, GPL 계열
+라이선스는 소스코드 패키지 또는 written offer가 필요하다. 산출물 형태는
+제품에 동봉, 패키지에 포함, 웹사이트 게시, 요청 시 제공 등 다양한 방식으로
+제공할 수 있다.
+
+**고려사항**
+
+- **산출물 유형 정의**: 라이선스별로 어떤 산출물이 필요한지 미리 정의하여
+  배포 준비 시 빠르게 대응할 수 있도록 한다.
+- **NOTICES 파일 품질**: 모든 오픈소스 컴포넌트의 저작권 고지문과 라이선스
+  전문이 누락 없이 포함되었는지 검토한다.
+- **소스코드 패키지**: GPL 컴포넌트의 경우 수정된 소스코드와 빌드 스크립트를
+  포함한 완전한 소스코드 패키지를 준비한다.
+- **제공 방식**: 산출물을 소프트웨어에 동봉할지, 웹사이트에 게시할지, 요청 시
+  제공할지를 라이선스 요건에 맞게 결정한다.
+- **최종 검토**: 배포 전 오픈소스 프로그램 매니저가 산출물의 완전성을 최종
+  확인한다.
+
+**샘플**
+
+아래는 컴플라이언스 산출물 준비 및 배포 절차 개요 샘플이다.
+
+```
+[컴플라이언스 산출물 준비 및 배포 절차]
+
+1. 산출물 유형 결정
+   - SBOM을 기준으로 포함된 라이선스 목록을 확인한다.
+   - 라이선스별 의무에 따라 필요한 산출물을 결정한다:
+     · 고지 의무 라이선스 → NOTICES 파일
+     · GPL-2.0/3.0 → 소스코드 패키지 또는 written offer
+     · LGPL → 동적 링크 구조 증명 문서 또는 소스코드
+
+2. 산출물 작성
+   - NOTICES 파일: 자동화 도구(FOSSology, ORT 등)로 생성하거나 수동 작성.
+     컴포넌트명, 버전, 라이선스 전문, 저작권 고지문 포함.
+   - 소스코드 패키지: GPL 컴포넌트의 수정된 소스코드와 빌드 스크립트 포함.
+
+3. 검토 및 승인
+   - 오픈소스 프로그램 매니저가 산출물의 완전성과 정확성을 검토한다.
+   - 불완전한 항목은 수정 후 재검토한다.
+
+4. 소프트웨어와 함께 제공
+   - 제품 패키지에 동봉하거나 설치 시 표시되는 화면에 포함한다.
+   - 웹사이트 게시 또는 요청 시 제공하는 경우 해당 URL 또는 절차를 명시한다.
+   - written offer를 사용하는 경우 3년간 유효한 서면 약정을 포함한다.
+```
+
+---
+
+### 3.4.1.2 컴플라이언스 산출물 보관 절차
+
+**준수 방법**
+
+배포된 공급 소프트웨어의 컴플라이언스 산출물 사본을 일정 기간 보관하는 절차를
+문서화하고, 그 절차가 실제로 이행되었음을 입증하는 기록을 유지해야 한다.
+이 절차 문서와 보관 기록이 입증자료 3.4.1.2다.
+
+보관 기간은 해당 소프트웨어의 마지막 배포 시점으로부터 합리적인 기간이어야
+하며, 업계 관행상 최소 3년을 권장한다. 보관 대상은 NOTICES 파일, 소스코드
+패키지, written offer 사본, SBOM 등 배포 시 제공한 모든 산출물이다. 소프트웨어
+버전별로 산출물을 체계적으로 관리하여 특정 버전의 산출물을 즉시 검색·제출할
+수 있어야 한다.
+
+**고려사항**
+
+- **보관 기간 명시**: 정책 또는 절차 문서에 보관 기간(최소 3년)을 명시한다.
+- **버전별 관리**: 소프트웨어 릴리스 버전과 산출물을 연결하여 버전별로 보관한다.
+- **보관 위치**: 사내 파일 서버, 문서 관리 시스템, 소스코드 저장소 등 접근
+  가능하고 안전한 위치에 보관한다.
+- **보관 기록 유지**: 어떤 버전의 산출물을 언제 보관했는지 이력을 기록한다.
+- **접근성**: 감사 또는 외부 문의 발생 시 즉시 산출물을 제출할 수 있도록
+  검색 가능한 형태로 보관한다.
+
+**샘플**
+
+아래는 컴플라이언스 산출물 보관 기록부 샘플이다.
+
+```
+| 소프트웨어명 | 버전 | 배포일 | 산출물 유형 | 보관 위치 | 보관 기한 | 담당자 |
+|-------------|------|--------|------------|-----------|-----------|--------|
+| MyProduct | v1.0.0 | 2024-03-01 | NOTICES 파일, GPL 소스코드 패키지 | /archive/myproduct/v1.0.0/ | 2027-03-01 | 홍길동 |
+| MyProduct | v1.1.0 | 2024-09-15 | NOTICES 파일 | /archive/myproduct/v1.1.0/ | 2027-09-15 | 홍길동 |
+| FirmwareX | v2.3.0 | 2025-01-10 | NOTICES 파일, LGPL 소스코드 패키지, SBOM | /archive/firmwarex/v2.3.0/ | 2028-01-10 | 이인프라 |
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/)
+- 관련 템플릿: [오픈소스 프로세스 템플릿](../../../templates/2-process-template/)
diff --git a/content/ko/guide/iso5230_guide/4-artifacts/_index.md b/content/ko/guide/iso5230_guide/4-artifacts/_index.md
new file mode 100644
index 000000000..dcc23d0f2
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/4-artifacts/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.4 컴플라이언스 산출물"
+weight: 40
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "컴플라이언스 산출물"]
+description: >
+---
diff --git a/content/ko/guide/iso5230_guide/5-community/1-contributions/_index.md b/content/ko/guide/iso5230_guide/5-community/1-contributions/_index.md
new file mode 100644
index 000000000..3afbd607f
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/5-community/1-contributions/_index.md
@@ -0,0 +1,216 @@
+---
+title: "§3.5.1 기여"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "기여"]
+description: >
+---
+
+## 1. 조항 개요
+
+많은 기업이 외부 오픈소스 프로젝트에 코드·문서·버그 리포트 등을 기여한다.
+기여 활동은 커뮤니티 신뢰를 높이고 기술 영향력을 확대하지만, 회사 코드나
+특허가 의도치 않게 공개될 수 있는 리스크도 수반한다. §3.5.1은 조직이
+외부 오픈소스 기여를 허용하는 경우, 기여를 규율하는 문서화된 정책과 절차를
+수립하고 프로그램 참여자가 그 존재를 인식하도록 할 것을 요구한다. 이 조항은
+기여를 허용하지 않는 조직에는 적용되지 않으나, 허용하는 경우 세 가지 입증자료를
+모두 갖추어야 한다.
+
+## 2. 해야 할 활동
+
+- 조직의 외부 오픈소스 기여 허용 여부를 결정하고 정책에 명시한다.
+- 기여를 허용하는 경우 기여 유형(코드, 문서, 버그 리포트 등), 승인 절차,
+  저작권·특허 처리 방침 등을 포함한 기여 정책을 문서화한다.
+- 기여 제안부터 승인·제출·기록까지 실제 기여를 관리하는 절차를 수립하고
+  문서화한다.
+- 기여 정책의 존재를 프로그램 참여자에게 전파하는 절차를 마련한다.
+- 기여 이력을 기록하고 보관한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.5.1 | 조직이 오픈소스 프로젝트로의 기여를 고려하는 경우: 오픈소스 프로젝트 기여를 규율하는 문서화된 정책이 존재해야 한다 / 정책은 내부에 전파되어야 한다 / 오픈소스 기여를 관리하는 문서화된 절차가 존재해야 한다 | **3.5.1.1** 문서화된 오픈소스 기여 정책<br>**3.5.1.2** 오픈소스 기여를 관리하는 문서화된 절차<br>**3.5.1.3** 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.5.1 Contributions**
+> 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; and
+> - A documented procedure shall exist that governs open source contributions.
+>
+> **Verification Material(s):**
+> 3.5.1.1 A documented open source contribution policy;
+> 3.5.1.2 A documented procedure that governs open source contributions; and
+> 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).
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.5.1.1 오픈소스 기여 정책
+
+**준수 방법**
+
+외부 오픈소스 프로젝트에 기여하는 행위를 규율하는 정책을 문서화해야 한다.
+이 정책 문서가 입증자료 3.5.1.1이다. 기여 정책에는 ①기여 허용 범위(코드,
+문서, 버그 리포트 등), ②기여 승인 절차, ③저작권 처리(회사 소유 vs. 개인
+소유), ④특허 처리 방침, ⑤CLA(Contributor License Agreement) 서명 기준,
+⑥기여 금지 항목(영업 비밀, 미공개 특허 등)이 포함되어야 한다.
+
+정책은 오픈소스 정책 문서의 별도 섹션으로 포함하거나 독립된 기여 정책 문서로
+관리할 수 있다. 기여를 완전히 금지하는 조직도 "기여를 허용하지 않는다"는
+정책을 명시적으로 문서화하는 것이 바람직하다.
+
+**고려사항**
+
+- **기여 범위 정의**: 허용되는 기여 유형(버그 수정, 기능 추가, 문서 작성 등)을
+  구체적으로 열거한다.
+- **저작권 귀속**: 기여물의 저작권이 회사에 귀속되는지, 개인에게 귀속되는지
+  정책에 명시한다.
+- **특허 리스크 관리**: 기여물에 회사 특허가 포함될 수 있는 경우 법무 검토를
+  의무화한다.
+- **CLA 처리**: 외부 프로젝트가 CLA를 요구하는 경우 서명 권한자와 절차를
+  정책에 명시한다.
+- **기여 금지 항목**: 영업 비밀, 미등록 특허, 제3자 지식재산이 포함된 코드는
+  기여를 금지한다.
+
+**샘플**
+
+아래는 오픈소스 기여 정책 핵심 항목 샘플이다.
+
+```
+## 오픈소스 기여 정책
+
+### 기여 허용 범위
+회사는 임직원이 업무 목적으로 외부 오픈소스 프로젝트에 기여하는 것을 허용한다.
+허용되는 기여 유형은 다음과 같다:
+- 버그 수정 및 패치 제출
+- 문서 개선
+- 기능 추가 (사전 승인 필요)
+- 버그 리포트 및 이슈 제기
+
+### 저작권 및 특허
+- 업무 시간에 회사 자원을 사용하여 작성한 기여물의 저작권은 회사에 귀속된다.
+- 기여물에 회사 특허가 포함될 가능성이 있는 경우 법무 담당의 사전 검토를 받아야 한다.
+
+### 기여 금지 항목
+다음 항목이 포함된 코드는 기여할 수 없다:
+- 영업 비밀 또는 기밀 정보
+- 제3자의 지식재산
+- 회사의 미공개 특허 기술
+
+### CLA (Contributor License Agreement)
+외부 프로젝트가 CLA 서명을 요구하는 경우 오픈소스 프로그램 매니저에게
+사전 보고하고 승인을 받아야 한다.
+```
+
+---
+
+### 3.5.1.2 오픈소스 기여 관리 절차
+
+**준수 방법**
+
+실제 기여 활동을 어떻게 처리하는지 단계별로 정의한 절차를 문서화해야 한다.
+이 절차 문서가 입증자료 3.5.1.2다. 절차에는 ①기여 제안 및 승인 요청,
+②법무·특허 검토(필요 시), ③승인, ④기여 제출, ⑤기여 이력 기록의 단계가
+포함되어야 한다. 기여 규모나 유형에 따라 간소화된 절차(소규모 버그 수정)와
+정식 절차(대규모 기능 추가)를 구분하여 운영할 수 있다.
+
+**고려사항**
+
+- **기여 규모별 절차 구분**: 소규모 버그 수정은 간소 승인, 대규모 기능 추가는
+  정식 법무 검토를 거치도록 규모별 기준을 설정한다.
+- **기여 기록 보관**: 기여 제안서, 승인 기록, 제출 링크(PR/커밋 URL)를 기록하고
+  보관한다.
+- **에스컬레이션**: 특허 또는 저작권 이슈가 발생하는 경우 법무 담당에게
+  에스컬레이션하는 경로를 절차에 포함한다.
+
+**샘플**
+
+아래는 오픈소스 기여 관리 절차 개요 샘플이다.
+
+```
+[오픈소스 기여 관리 절차]
+
+1. 기여 제안
+   - 임직원이 기여하고자 하는 내용(프로젝트명, 기여 유형, 내용 요약)을
+     오픈소스 프로그램 매니저에게 보고한다.
+
+2. 검토 및 승인
+   - 소규모 기여 (버그 수정, 문서 개선):
+     오픈소스 프로그램 매니저가 정책 적합성을 확인 후 승인한다.
+   - 대규모 기여 (기능 추가, 핵심 모듈 기여):
+     법무 담당의 특허·저작권 검토 후 오픈소스 프로그램 매니저가 최종 승인한다.
+
+3. CLA 처리 (해당 시)
+   - 외부 프로젝트가 CLA를 요구하는 경우 승인된 CLA 서명 양식에 따라 처리한다.
+
+4. 기여 제출
+   - 승인된 내용에 한정하여 기여를 제출한다.
+   - 회사 이메일 또는 회사가 승인한 계정으로 기여한다.
+
+5. 기여 기록
+   - 기여 내용, 승인자, 제출일, 기여 URL(PR/커밋 링크)을 기록하고 보관한다.
+```
+
+---
+
+### 3.5.1.3 기여 정책 인식 절차
+
+**준수 방법**
+
+모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식할 수 있도록 전파하는
+절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.5.1.3이다. §3.1.1.2의
+오픈소스 정책 전파 절차에 기여 정책을 포함하는 방식으로 통합 관리할 수 있다.
+
+전파 방법은 신규 입사자 온보딩 시 기여 정책 안내, 사내 위키 게시, 이메일 공지
+등을 조합하는 것이 효과적이다. 전파 사실을 증명하기 위해 공지 이력, 교육 이수
+기록 등을 보관한다.
+
+**고려사항**
+
+- **온보딩 포함**: 신규 입사자 온보딩 과정에 기여 정책 안내를 필수 항목으로
+  포함한다.
+- **정책 갱신 시 재전파**: 기여 정책이 변경된 경우 프로그램 참여자에게 즉시
+  공지한다.
+- **증거 보관**: 공지 발송 이력, 교육 이수 확인서 등을 최소 3년간 보관한다.
+- **정책 접근성**: 기여 정책을 사내 포털 또는 위키에 항시 게시하여 언제든
+  확인할 수 있도록 한다.
+
+**샘플**
+
+아래는 기여 정책 전파 공지 이메일 샘플이다.
+
+```
+제목: [오픈소스] 오픈소스 기여 정책 안내
+
+수신: 전체 개발 관련 임직원
+발신: 오픈소스 프로그램 매니저
+
+안녕하세요.
+
+당사 오픈소스 기여 정책을 안내드립니다.
+외부 오픈소스 프로젝트에 기여하는 업무에 관여하는 모든 임직원은
+아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.
+
+- 정책 문서: [사내 포털 링크]
+- 주요 내용: 기여 허용 범위, 승인 절차, 저작권·특허 처리 방침
+- 정책 버전: v1.0 (시행일: YYYY-MM-DD)
+
+기여를 희망하는 경우 반드시 사전 승인 절차를 거쳐 주십시오.
+문의: 오픈소스 프로그램 매니저 (oss@company.com)
+
+감사합니다.
+오픈소스 프로그램 매니저
+```
+
+## 5. 참고
+
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 6. 기여](../../../opensource_for_enterprise/6-contribution/)
+- 관련 템플릿: [오픈소스 정책 템플릿 — §3 오픈소스 기여](../../../templates/1-policy/)
diff --git a/content/ko/guide/iso5230_guide/5-community/_index.md b/content/ko/guide/iso5230_guide/5-community/_index.md
new file mode 100644
index 000000000..5afbea23e
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/5-community/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.5 커뮤니티 참여"
+weight: 50
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "커뮤니티", "기여"]
+description: >
+---
diff --git a/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md b/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md
new file mode 100644
index 000000000..4da8bbcc1
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md
@@ -0,0 +1,104 @@
+---
+title: "§3.6.1 적합성"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "적합성"]
+description: >
+---
+
+## 1. 조항 개요
+
+ISO/IEC 5230 인증을 받으려면 §3.1.4에서 정의한 프로그램이 이 규격의 모든
+요구사항을 충족한다는 사실을 문서로 확인해야 한다. §3.6.1은 앞서 §3.1부터
+§3.5까지의 모든 조항을 충족하였음을 공식적으로 선언하는 단계다. 이 조항은
+규격 준수를 완결 짓는 최종 확인 절차로, 프로그램이 ISO/IEC 5230:2020 버전
+2.1의 모든 요구사항을 만족한다는 조직의 공식 확인이 필요하다.
+
+## 2. 해야 할 활동
+
+- §3.1부터 §3.5까지 모든 조항의 입증자료(24개 항목)가 갖추어졌는지 자체
+  점검한다.
+- 프로그램이 §3.1.4에서 정의한 적용 범위 내에서 ISO/IEC 5230의 모든 요구사항을
+  충족함을 확인하는 문서를 작성한다.
+- 확인 문서에 검토자, 승인자, 확인 날짜를 기록한다.
+- 자가 인증, 독립 평가, 또는 제3자 인증 중 적합한 인증 방법을 선택하여 진행한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.6.1 | 프로그램이 이 규격을 준수하는 것으로 간주되려면, 조직은 프로그램이 이 문서(버전 2.1)에 제시된 요구사항을 충족한다고 확인해야 한다. | **3.6.1.1** §3.1.4에서 명시한 프로그램이 이 규격의 모든 요구사항을 충족함을 확인하는 문서 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§3.6.1 Conformance**
+> 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).
+>
+> **Verification Material(s):**
+> 3.6.1.1 A document affirming the program specified in §3.1.4 satisfies all
+> the requirements of this specification.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 3.6.1.1 규격 준수 확인 문서
+
+**준수 방법**
+
+§3.1.4에서 정의한 프로그램의 적용 범위 내에서 ISO/IEC 5230:2020의 모든
+요구사항을 충족한다는 사실을 확인하는 문서를 작성해야 한다. 이 문서가
+입증자료 3.6.1.1이다. 이 문서는 24개 입증자료 항목 각각에 대해 준수 여부를
+확인하는 체크리스트 형태, 또는 전반적인 준수 선언문 형태로 작성할 수 있다.
+
+작성 전 이 가이드의 [전체 조항 체크리스트](../../)를 활용하여 모든 입증자료가
+갖추어졌는지 점검한다. 문서에는 확인 대상 프로그램의 적용 범위, 확인 기준
+규격 버전(ISO/IEC 5230:2020 버전 2.1), 확인 날짜, 검토자 및 승인자가 반드시
+포함되어야 한다.
+
+**고려사항**
+
+- **자체 점검 선행**: 문서 작성 전 24개 입증자료 항목 전체를 자체 점검하여
+  누락 항목이 없는지 확인한다.
+- **규격 버전 명시**: 준수를 확인한 규격 버전(ISO/IEC 5230:2020 버전 2.1)을
+  문서에 명시한다.
+- **승인 절차**: 오픈소스 프로그램 매니저의 검토와 경영진 또는 OSRB의 승인을
+  거쳐 문서를 공식화한다.
+- **갱신 주기**: 규격 새 버전 발행 후 18개월 이내에 최신 버전 기준으로
+  재확인해야 한다 (§3.6.2 참조).
+
+**샘플**
+
+아래는 ISO/IEC 5230 규격 준수 확인 문서 샘플이다.
+
+```
+[ISO/IEC 5230 규격 준수 확인서]
+
+프로그램 명칭: [회사명] 오픈소스 컴플라이언스 프로그램
+적용 범위: [§3.1.4에서 정의한 범위 기재]
+준수 확인 규격: ISO/IEC 5230:2020 (버전 2.1)
+확인 날짜: YYYY-MM-DD
+
+본 문서는 위 프로그램이 ISO/IEC 5230:2020의 §3.1부터 §3.6까지
+모든 요구사항을 충족함을 확인한다.
+
+준수 확인 항목 요약:
+- §3.1 프로그램 기반 (5개 조항, 8개 입증자료): 충족 ✓
+- §3.2 관련 업무 (2개 조항, 7개 입증자료): 충족 ✓
+- §3.3 콘텐츠 검토 및 승인 (2개 조항, 3개 입증자료): 충족 ✓
+- §3.4 컴플라이언스 산출물 (1개 조항, 2개 입증자료): 충족 ✓
+- §3.5 커뮤니티 참여 (1개 조항, 3개 입증자료): 충족 ✓
+- §3.6 규격 준수 (2개 조항, 2개 입증자료): 충족 ✓
+
+검토자: [오픈소스 프로그램 매니저 이름]
+승인자: [경영진 또는 OSRB 책임자 이름]
+승인일: YYYY-MM-DD
+```
+
+## 5. 참고
+
+- ISO/IEC 5230 자가 인증: [https://certification.openchainproject.org/](https://certification.openchainproject.org/)
+- 전체 조항 체크리스트: [ISO/IEC 5230 준수 가이드](../../)
diff --git a/content/ko/guide/iso5230_guide/6-conformance/2-duration/_index.md b/content/ko/guide/iso5230_guide/6-conformance/2-duration/_index.md
new file mode 100644
index 000000000..0e64a1dff
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/6-conformance/2-duration/_index.md
@@ -0,0 +1,117 @@
+---
+title: "§3.6.2 지속 기간"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "지속 기간"]
+description: >
+---
+
+## 1. 조항 개요
+
+ISO/IEC 5230 인증은 한 번 취득으로 영구히 유효하지 않다. 규격의 새 버전이
+발행되면 이전 버전 기준으로 인증을 받은 프로그램은 새 버전 발행 후 18개월까지만
+적합성이 유지된다. §3.6.2는 프로그램이 적합성 인증을 취득한 날로부터 최근
+18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서를 유지하도록
+요구한다. 이 조항은 오픈소스 컴플라이언스 프로그램이 형식적 인증에 그치지 않고
+지속적으로 운영되는지 확인하는 장치다.
+
+## 2. 해야 할 활동
+
+- 적합성 인증 취득 날짜를 기록하고 관리한다.
+- 인증 취득 후 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을
+  재확인하고 문서화한다.
+- 새로운 버전의 규격이 발행된 경우 18개월 이내에 최신 버전 기준으로
+  프로그램을 갱신하고 재확인한다.
+- 정기적인 내부 감사를 통해 프로그램의 지속적 준수 여부를 점검한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §3.6.2 | 이 규격을 준수하는 프로그램은, 규격의 새 버전이 발행된 후 18개월이 경과할 때까지 이전에 준수하던 규격 버전에 대해서도 계속 준수하는 것으로 간주된다. 준수 프로그램이 최신 버전의 규격을 준수하도록 업데이트하는 것을 권장한다. | **3.6.2.1** 프로그램이 적합성 인증을 획득한 후 지난 18개월 동안 이 규격 버전의 모든 요구사항을 충족하고 있음을 확인하는 문서 |
+
+<details><summary>영문 원문 보기</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. 입증자료별 준수 방법 및 샘플
+
+### 3.6.2.1 18개월 이내 요구사항 충족 확인 문서
+
+**준수 방법**
+
+적합성 인증 취득 후 18개월 이내에 프로그램이 규격의 모든 요구사항을 여전히
+충족하고 있음을 확인하는 문서를 유지해야 한다. 이 문서가 입증자료 3.6.2.1이다.
+가장 간단한 방법은 §3.6.1.1의 규격 준수 확인 문서를 정기적으로(최소 연 1회)
+재검토하고 갱신하는 것이다. 갱신 시마다 검토 날짜와 검토자를 기록하여 최근
+18개월 이내에 검토가 이루어졌음을 증명할 수 있도록 한다.
+
+새로운 버전의 ISO/IEC 5230이 발행된 경우 18개월의 유예 기간 내에 최신 버전
+기준으로 프로그램을 갱신하고 재확인 문서를 작성한다. 유예 기간을 초과하면
+인증 효력이 만료되므로, 규격 개정 동향을 모니터링하고 적시에 대응하는 것이
+중요하다.
+
+**고려사항**
+
+- **정기 재확인 일정 수립**: 최소 연 1회 정기 내부 감사를 통해 모든 입증자료
+  항목의 유효성을 재확인하고 문서화한다.
+- **규격 개정 모니터링**: OpenChain 프로젝트의 규격 개정 공지를 정기적으로
+  확인하고, 새 버전 발행 시 18개월 이내에 대응 계획을 수립한다.
+- **인증 만료 관리**: 인증 취득일과 유효 기간(18개월)을 캘린더 또는 관리
+  시스템에 등록하여 만료 전 갱신 알림을 받도록 설정한다.
+- **변경 사항 반영**: 조직 구조, 제품 포트폴리오, 프로세스 변경 발생 시 즉시
+  프로그램에 반영하고 재확인 문서를 갱신한다.
+
+**샘플**
+
+아래는 ISO/IEC 5230 규격 준수 정기 재확인 기록 샘플이다.
+
+```
+[ISO/IEC 5230 규격 준수 정기 재확인 기록]
+
+프로그램 명칭: [회사명] 오픈소스 컴플라이언스 프로그램
+최초 인증 취득일: YYYY-MM-DD
+준수 확인 규격: ISO/IEC 5230:2020 (버전 2.1)
+
+| 재확인 날짜 | 확인 결과 | 변경 사항 | 검토자 | 비고 |
+|------------|-----------|-----------|--------|------|
+| 2025-01-10 | 전체 충족 | 담당자 변경 반영 (§3.2.2.1 갱신) | 홍길동 | - |
+| 2026-01-08 | 전체 충족 | 없음 | 홍길동 | 다음 재확인 예정: 2027-01-08 |
+
+다음 재확인 예정일: YYYY-MM-DD (최근 재확인일로부터 12개월 이내)
+18개월 유효 기한: YYYY-MM-DD (최근 재확인일로부터 18개월)
+```
+
+아래는 규격 새 버전 발행 시 대응 체크리스트 샘플이다.
+
+```
+[ISO/IEC 5230 새 버전 발행 대응 체크리스트]
+
+새 버전 발행일: YYYY-MM-DD
+대응 기한 (18개월): YYYY-MM-DD
+
+□ 새 버전과 현행 버전의 요구사항 변경 사항 파악
+□ 변경된 요구사항에 따른 프로그램 갱신 계획 수립
+□ 갱신 작업 완료 및 새 버전 기준 입증자료 정비
+□ 새 버전 기준 규격 준수 확인 문서 작성 및 승인
+□ 자가 인증 또는 인증 갱신 절차 진행
+```
+
+## 5. 참고
+
+- OpenChain 규격 최신 버전 확인: [https://www.openchainproject.org/license-compliance](https://www.openchainproject.org/license-compliance)
+- 자가 인증 갱신: [https://certification.openchainproject.org/](https://certification.openchainproject.org/)
+- §3.6.1 적합성: [이전 조항 바로가기](../1-conformance/)
diff --git a/content/ko/guide/iso5230_guide/6-conformance/_index.md b/content/ko/guide/iso5230_guide/6-conformance/_index.md
new file mode 100644
index 000000000..57279468d
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/6-conformance/_index.md
@@ -0,0 +1,8 @@
+---
+title: "§3.6 규격 준수"
+weight: 60
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "규격 준수", "적합성"]
+description: >
+---
diff --git a/content/ko/guide/iso5230_guide/_index.md b/content/ko/guide/iso5230_guide/_index.md
new file mode 100644
index 000000000..817906860
--- /dev/null
+++ b/content/ko/guide/iso5230_guide/_index.md
@@ -0,0 +1,131 @@
+---
+title: "ISO/IEC 5230 준수 가이드"
+linkTitle: "ISO/IEC 5230 준수 가이드"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 5230", "라이선스 컴플라이언스", "OpenChain"]
+description: >
+  ISO/IEC 5230의 24개 입증자료 항목을 조항별로 풀어서 설명하는 준수 가이드다.
+---
+
+이 가이드는 ISO/IEC 5230(OpenChain License Compliance)의 각 요구사항 조항을 하나씩
+풀어서 설명한다. 각 조항이 요구하는 입증자료가 무엇인지, 어떻게 준수할 수 있는지,
+바로 활용할 수 있는 샘플 문서는 무엇인지 안내한다.
+
+**Author : OpenChain Korea Work Group / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)**
+
+## 대상 독자
+
+- 오픈소스 컴플라이언스 담당자 및 오픈소스 프로그램 매니저
+- ISO/IEC 5230 인증 취득을 준비 중인 기업의 담당자
+- 기존 오픈소스 관리 체계를 ISO 표준 기준으로 점검하고 싶은 실무자
+
+## 이 가이드의 활용 방법
+
+{{% alert title="기업 오픈소스 관리 가이드와의 관계" color="success" %}}
+
+**[기업 오픈소스 관리 가이드](../opensource_for_enterprise/)** 는 오픈소스를
+어떻게 관리할지 실무 구현 방법(정책·프로세스·도구·조직)을 설명한다.
+
+**이 가이드(ISO/IEC 5230 준수 가이드)** 는 인증을 위해 무엇을 입증해야 하는지
+조항 단위로 정리한다.
+
+| 가이드 | 중점 | 활용 상황 |
+|--------|------|-----------|
+| 기업 오픈소스 관리 가이드 | 실무 구현 방법 (How to implement) | 오픈소스 관리 체계를 처음 구축할 때 |
+| ISO/IEC 5230 준수 가이드 | 조항별 입증자료 기준 (What to prove) | 인증 준비 또는 자체 점검 시 |
+
+두 가이드는 상호 보완적이다. 각 조항 페이지는 기업 오픈소스 관리 가이드의
+대응 섹션으로 교차 링크를 제공한다.
+
+{{% /alert %}}
+
+## 전체 조항 체크리스트
+
+ISO/IEC 5230은 총 **13개 조항, 24개 입증자료 항목**으로 구성된다.
+
+### §3.1 프로그램 기반
+
+| 조항 | 제목 | 입증자료 | 상세 |
+|------|------|:---:|------|
+| §3.1.1 | 정책 (Policy) | 2건 | [바로가기](./1-program-foundation/1-policy/) |
+| §3.1.2 | 역량 (Competence) | 3건 | [바로가기](./1-program-foundation/2-competence/) |
+| §3.1.3 | 인식 (Awareness) | 1건 | [바로가기](./1-program-foundation/3-awareness/) |
+| §3.1.4 | 프로그램 범위 (Program Scope) | 1건 | [바로가기](./1-program-foundation/4-scope/) |
+| §3.1.5 | 라이선스 의무 (License Obligations) | 1건 | [바로가기](./1-program-foundation/5-license-obligations/) |
+
+### §3.2 관련 업무
+
+| 조항 | 제목 | 입증자료 | 상세 |
+|------|------|:---:|------|
+| §3.2.1 | 외부 문의 대응 (Access) | 2건 | [바로가기](./2-relevant-tasks/1-access/) |
+| §3.2.2 | 효과적 리소스 (Effectively Resourced) | 5건 | [바로가기](./2-relevant-tasks/2-resourced/) |
+
+### §3.3 콘텐츠 검토 및 승인
+
+| 조항 | 제목 | 입증자료 | 상세 |
+|------|------|:---:|------|
+| §3.3.1 | SBOM | 2건 | [바로가기](./3-content-review/1-sbom/) |
+| §3.3.2 | 라이선스 컴플라이언스 (License Compliance) | 1건 | [바로가기](./3-content-review/2-license-compliance/) |
+
+### §3.4 컴플라이언스 산출물
+
+| 조항 | 제목 | 입증자료 | 상세 |
+|------|------|:---:|------|
+| §3.4.1 | 컴플라이언스 산출물 (Compliance Artifacts) | 2건 | [바로가기](./4-artifacts/1-compliance-artifacts/) |
+
+### §3.5 커뮤니티 참여
+
+| 조항 | 제목 | 입증자료 | 상세 |
+|------|------|:---:|------|
+| §3.5.1 | 기여 (Contributions) | 3건 | [바로가기](./5-community/1-contributions/) |
+
+### §3.6 규격 준수
+
+| 조항 | 제목 | 입증자료 | 상세 |
+|------|------|:---:|------|
+| §3.6.1 | 적합성 (Conformance) | 1건 | [바로가기](./6-conformance/1-conformance/) |
+| §3.6.2 | 지속 기간 (Duration) | 1건 | [바로가기](./6-conformance/2-duration/) |
+
+**합계: 13개 조항 / 24개 입증자료 항목**
+
+## ISO/IEC 5230 인증 절차
+
+ISO/IEC 5230 준수 여부를 공식적으로 인정받는 방법은 세 가지다.
+
+{{% pageinfo %}}
+
+**1단계. 자가 인증 (Self-Certification)**
+
+OpenChain 프로젝트가 제공하는 온라인 체크리스트를 작성하여 자체적으로 준수 여부를
+선언한다. 비용이 없으며 즉시 시작할 수 있다.
+
+- 체크리스트: [https://certification.openchainproject.org/](https://certification.openchainproject.org/)
+- 적합 대상: 인증을 처음 준비하거나 내부 점검 용도
+
+---
+
+**2단계. 독립 평가 (Independent Assessment)**
+
+외부 전문가 또는 컨설팅 기관이 오픈소스 프로그램을 평가한다. 자가 인증보다 신뢰도가
+높으며, 공급망 파트너에게 준수 수준을 입증하는 데 활용된다.
+
+- 파트너 목록: [Open Compliance Directory](https://www.openchainproject.org/find-a-partner)
+
+---
+
+**3단계. 제3자 인증 (Third-party Certification)**
+
+OpenChain이 공인한 인증 기관이 심사하여 공식 인증서를 발급한다. 가장 높은 신뢰도를
+가지며, 글로벌 공급망 요구사항 충족에 적합하다.
+
+- 공인 인증 기관 (2024년 기준): ORCRO, PwC, TÜV SÜD, Synopsys, Bureau Veritas
+
+{{% /pageinfo %}}
+
+{{% alert title="단계적 접근 권장" color="success" %}}
+처음 인증을 준비하는 기업은 **자가 인증 → 독립 평가 → 제3자 인증** 순서로
+단계적으로 진행하는 것을 권장한다. 자가 인증만으로도 많은 공급망 파트너가 요구하는
+준수 수준을 충족할 수 있다.
+{{% /alert %}}