diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md
new file mode 100644
index 000000000..481cbb4c9
--- /dev/null
+++ b/content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md
@@ -0,0 +1,153 @@
+---
+title: "§4.1.1 정책"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "정책"]
+description: >
+---
+
+## 1. 조항 개요
+
+§4.1.1은 ISO/IEC 5230 §3.1.1(라이선스 컴플라이언스 정책)과 대응하는 조항이지만,
+초점이 **보안 보증**으로 전환된다. 오픈소스 컴포넌트의 알려진 취약점과 새로
+발견되는 취약점을 체계적으로 관리하는 정책이 문서화되어 있어야 하며, 그 정책이
+조직 내부에 전파되어야 한다. ISO/IEC 5230 §3.1.1과의 핵심 차이점은 **정책과
+전파 절차 자체에 대한 정기 검토 프로세스**를 요구한다는 점이다. 정책을 수립하는
+것에 그치지 않고, 정책이 항상 유효하고 최신 상태를 유지하도록 검토 체계를
+갖추어야 한다.
+
+## 2. 해야 할 활동
+
+- 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 관리하는 정책을
+ 문서화하고 공식화한다.
+- 정책에 취약점 탐지·평가·대응·통보 원칙과 CVD(Coordinated Vulnerability
+ Disclosure) 방침을 포함한다.
+- 프로그램 참여자(개발자·보안 담당·법무·IT 등)에게 정책을 전파하는 절차를
+ 수립하고 문서화한다.
+- **정책과 전파 절차 자체를 정기적으로 검토하여 최신 상태를 유지하는 검토
+ 프로세스**를 정책 내에 명시한다.
+- 검토 완료 일자, 검토자, 변경 이력을 문서에 기록한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §4.1.1 | 배포용 소프트웨어의 오픈소스 소프트웨어 보안 보증을 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다. **정책과 전달 방법은 항상 유효하고 최신 상태를 유지하기 위한 검토 프로세스를 가져야 한다.** | **4.1.1.1** 문서화된 오픈소스 소프트웨어 보안 보증 정책
**4.1.1.2** 프로그램 참여자가 보안 보증 정책을 인식하도록 하기 위한 문서화된 절차 |
+
+영문 원문 보기
+
+> **§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.1.2.2** 각 역할에 대한 역량을 식별하는 문서
**4.1.2.3** 참여자 목록 및 해당 역할 ★
**4.1.2.4** 각 프로그램 참여자에 대해 평가된 역량에 대한 문서화된 증거
**4.1.2.5** 주기적인 검토 및 프로세스 변경에 대한 문서화된 증거 ★
**4.1.2.6** 이러한 프로세스가 회사 내부 모범 사례와 일치하며 최신 상태를 유지하고 있는지, 그리고 이를 확인하는 담당자가 지정되었는지에 대한 문서화된 증거 ★ |
+
+★ = 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.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.1.4.2** 프로그램이 개선하기 위해 달성해야 하는 메트릭 세트 ★
**4.1.4.3** 지속적인 개선을 입증하기 위한 각 검토, 업데이트 또는 감사에서 얻은 문서화된 증거 ★ |
+
+★ = 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.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.2.1.2** 제3자의 알려진 취약점 또는 새로 발견된 취약점 문의에 응답하기 위한 내부 문서화된 절차 |
+
+영문 원문 보기
+
+> **§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.2.2.2** 식별된 프로그램 역할이 적절히 인력 배치되었으며 충분한 예산이 제공되었음을 나타내는 문서
**4.2.2.3** 식별된 알려진 취약점을 해결하기 위해 이용 가능한 전문성을 명시한 문서 ★
**4.2.2.4** 보안 보증을 위해 내부 책임을 할당하는 절차를 문서화한 자료 |
+
+★ = ISO/IEC 5230 §3.2.2.3(법률 자문)과 다름 — 보안 전문성으로 초점 전환
+
+영문 원문 보기
+
+> **§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.3.1.2** 문서화된 절차가 올바르게 수행되었음을 입증하는 공급 소프트웨어에 대한 오픈소스 소프트웨어 컴포넌트 기록 |
+
+영문 원문 보기
+
+> **§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.3.2.2** 각 오픈소스 소프트웨어 컴포넌트에 대해 식별된 알려진 취약점 및 취해진 조치(조치가 필요하지 않은 경우도 포함)에 대한 기록이 유지 관리되어야 함 |
+
+영문 원문 보기
+
+> **§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.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.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.
+
+