How does South Korea's PIPA affect software supply chain and SBOM work?

South Korea's Personal Information Protection Act does not mention an SBOM. It does require safeguards against loss, theft and leaks, a written contract when processing is outsourced, a privacy officer and breach notice. Dependency and vendor inventories are how engineering teams show those duties are met.

Which text did we read?

We read the English statute at the Korea Legislation Research Institute, amended through Act No. 16930 of 4 February 2020, and it states that translations are for reference and not legally effective. PIPA has been amended since, so confirm article numbers and thresholds against the current Korean text.

What does the Act ask of a controller?

• Article 29, duty of safeguards: technical, managerial and physical measures such as an internal management plan and preserved access records, so that personal information is not lost, stolen, divulged, forged, altered or damaged.
• Article 26, outsourcing: the controller must outsource processing through a document that states prevention of use for other purposes, technical and managerial safeguards and other matters set by Presidential Decree.
• Article 31: designate a privacy officer who takes charge of personal information processing and builds the internal control system against divulgence and misuse.
• Article 34: notify data subjects without delay on learning of a leak, with what was divulged, when and how, how to limit damage, countermeasures taken and a contact point.

In the 2020 text, Article 39-4 sets a special case for information and communications service providers: notification to users and a report to a specialised institution within 24 hours of becoming aware, unless there is just cause for delay. Check whether later amendments changed this for your business type.

How do these map to software?

Take a constructed case. A Korean food delivery startup uses a third party map SDK, a hosted customer chat tool and its own backend with 400 open source packages.

• The chat tool receives names and order histories. That is outsourcing, so Article 26 calls for a written document with purpose limits and safeguards.
• The map SDK is code in the app. It is not outsourcing, but a flaw in it can still cause the leak that Article 29 is about.
• The backend packages are the likely place where an unpatched flaw becomes the breach that Article 34 forces you to disclose.

What records help in practice?

Access records and an internal management plan are named in Article 29. A component inventory with versions and a vulnerability check history fits the same logic: a plan, and the records that show it was followed. Nothing in the text we read mandates a particular SBOM format.

A fast notification clock makes the inventory more valuable. If you learn at 09:00 that a library in production is exploited, the question "which services use it?" must be answerable within hours.

How to check or apply this

1. Map each processor, whether outsourced or not, to the data fields it receives.
2. Check that every outsourcing contract states purpose limits and safeguards.
3. Name the privacy officer and give them read access to the inventory.
4. Generate a component inventory per release and keep the previous ones.
5. Write a breach runbook with clocks matching your current legal advice.
6. Rehearse the runbook with a mock library vulnerability once a year.

Quick check

This is not legal advice.

Sources

• Personal Information Protection Act, English translation, KLRI
• NIST SP 800-218, Secure Software Development Framework

Last reviewed: 18 October 2026.