South Korea software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in South Korea, five regimes decide most of what you must prove. The Personal Information Protection Act (PIPA) sets safety measures, a 72-hour breach clock and cross-border transfer rules for anyone handling personal data. The Act on Promotion of Information and Communications Network Utilization and Information Protection (the Network Act) makes ISMS certification mandatory for designated providers and requires an intrusion report within 24 hours. Public sector cloud runs on CSAP until a single NIS-led verification replaces it from the second half of 2027, financial firms answer to the Financial Services Commission under the Electronic Financial Transactions Act, and the Framework Act on Artificial Intelligence has been in force since 22 January 2026. All of this is moving: the government announced an overhaul of ISMS-P on 10 April 2026, and the FSC promised a full review of financial security after 16 firms were breached in October 2026.

None of these laws says "SBOM". All of them ask questions a software inventory answers: which components run your personal data systems, which versions are exposed when an advisory lands, and how fast you can tell the regulator. This guide takes each rule from its primary text, shows the evidence a supervisor or auditor asks for, and ends with a 30/60/90-day plan that works with the tools you already have. It is a practical reading of public documents, not legal advice. Where a rule needs interpretation for your entity, take it to counsel or to the regulator.

Key takeaways

• PIPA is the horizontal rule. Article 29 requires technical safety measures. A leak must be notified to data subjects within 72 hours and, for 1,000 or more people, sensitive or unique identifiers, or any unauthorised external access, reported to the PIPC or KISA within 72 hours. Penalty surcharges can reach 3% of total sales.
• ISMS certification is mandatory for large providers, and ISMS-P is being rebuilt. Article 47 of the Network Act requires ISMS for designated providers. The 10 April 2026 reform tightens revocation from late 2026 and makes ISMS-P mandatory for large controllers, with penetration testing in audits, from 2027.
• Network Act intrusion reports are due within 24 hours of awareness (Enforcement Decree Article 58-2).
• Public sector cloud is moving from CSAP to a single NIS-led verification, with revised guidance in 2026, a one-year grace period and full operation from the second half of 2027. Existing CSAP certificates stay valid for their term.
• Financial firms follow the Electronic Financial Transactions Act under the FSC and the Financial Supervisory Service. Since 20 April 2026, SaaS is a named exception to network separation, subject to conditions.
• The AI Basic Act is in force from 22 January 2026. It adds transparency, safety and high-impact AI duties, with a grace period of at least one year for fines and fact-finding investigations.
• SBOMs are guidance, not law, for now. Software Supply Chain Security Guideline 1.0 (May 2024) and the June 2026 roadmap from MSIT and the NIS promote SBOM-based management; no statute requires private firms to deliver one.
• Safeguard capabilities in this guide are all GA: SBOM generation and analysis, SCA and vulnerability management, reachability analysis, autonomous remediation (ships switched off), policies and gates, license compliance, the Compliance and GRC suite, TPRM, CSAF and VEX upload, Package Firewall, AI-BOM discovery, AI-SPM, AI Gateway, MCP Guardrail, agent identity, Trust Center, the CLI and local runner, Zero AI mode, bring your own model, and on-prem and air-gapped deployment.

Who this applies to in South Korea

Korea has no single cyber law. Obligations stack by what you do and who you serve.

Everyone who handles personal information. PIPA applies to every "personal information controller", public or private, and since the 2023 overhaul the special rules that used to apply only to online service providers were folded into the general rules. The Personal Information Protection Commission (PIPC, 개인정보보호위원회) supervises, investigates breaches and imposes penalty surcharges.

Information and communications service providers above the thresholds. The Network Act is administered by the Ministry of Science and ICT (MSIT, 과학기술정보통신부), with the Korea Internet and Security Agency (KISA, 한국인터넷진흥원) operating certification and incident response. Designated providers must hold ISMS certification, and providers must designate a chief information security officer.

Financial companies and electronic financial businesses. Under the Electronic Financial Transactions Act (전자금융거래법), the FSC (금융위원회) sets the rules, the Financial Supervisory Service (FSS, 금융감독원) inspects, and the Financial Security Institute (금융보안원) runs threat sharing and security evaluations.

Cloud providers selling to the public sector. Today they need CSAP and then an NIS security verification (국가정보원, NIS); a single NIS-led route is coming.

Anyone developing or deploying AI in Korea, including from abroad. The AI Basic Act applies to AI business operators whose activity affects the Korean market, with extra duties for high-impact AI and generative AI.

Software vendors outside these groups are usually pulled in through contracts. A bank, an ISMS-certified platform or a public agency that buys your product has to show its auditor that it identified, assessed and controlled you as an external party. Your SBOM, your patch record and your incident terms become their evidence.

The rules, regulator by regulator

Personal Information Protection Act (개인정보 보호법) and the PIPC

PIPA was substantially amended by Act No. 19234 of 14 March 2023. Four parts matter to software teams.

Safety measures, Article 29. Controllers must take the technical, managerial and physical measures set by Presidential Decree, "such as establishing an internal management plan and preserving access records", so that personal information is not lost, stolen, divulged, forged, altered or damaged. The PIPC's Standards for Measures to Ensure the Safety of Personal Information (개인정보의 안전성 확보조치 기준) set out the detailed technical measures; check the current notice for retention periods and update duties. That is where open source and third-party components enter. In the largest PIPA sanction to date, described below, the PIPC listed an unapplied security patch for a known operating system vulnerability among the safety measure failures.

Outsourcing, Article 26. Entrusting processing to another party needs a written document covering purpose limits, technical and managerial safeguards and the other matters in the decree, and the controller must supervise the processor. A SaaS tool that stores customer records is an entrusted processor.

Breach notification, Article 34. On becoming aware of a leak, the controller must notify affected data subjects "without delay" of what leaked, when and how, how they can limit the damage, what the controller has done, and who to contact. Article 39 of the Enforcement Decree sets that at 72 hours, with a first notice allowed before every detail is known. Article 40 requires a report to the PIPC or KISA within 72 hours where the leak affects 1,000 or more data subjects, involves sensitive or unique identifying information, or results from unauthorised external access. The last one matters: a hacking incident is reportable whatever the number of records.

Cross-border transfer, Article 28-8. Transfer abroad, which the Act defines to include provision, entrusted processing and storage, is allowed only on a listed basis: separate consent, a statute or treaty, necessity for a contract with the data subject where the transfer is disclosed, a PIPC-recognised certification held by the recipient, or a PIPC decision that the destination's protection is equivalent. For a security tool, this is the question of where source code, SBOMs, logs and findings that might contain personal data are stored.

Penalties have teeth. Article 64-2 allows penalty surcharges of up to 3/100 of total sales for listed violations, which include leaks caused by failing to take Article 29 safety measures.

Network Act: mandatory ISMS, CISO and the 24-hour incident report

The Act on Promotion of Information and Communications Network Utilization and Information Protection (정보통신망 이용촉진 및 정보보호 등에 관한 법률) is MSIT's main lever over online services.

Article 47 creates the information security management system (ISMS) certification and makes it mandatory for designated providers. Who is designated is set in the Enforcement Decree; check the current decree for whether it covers you.

Article 45-3 requires providers to designate a chief information security officer and report the designation to MSIT.

Article 48-3 requires a provider to report an intrusion incident (침해사고) to MSIT or KISA, and Article 58-2 of the Enforcement Decree sets the timing: within 24 hours of becoming aware, stating when and how it happened, the damage, the response so far and a contact point, with anything learned later reported within 24 hours of confirming it. MSIT's investigation reports on the SK Telecom and Coupang incidents both found the report came after 24 hours.

ISMS-P certification criteria (KISA)

KISA runs ISMS and ISMS-P certification under a joint MSIT and PIPC notice. ISMS-P uses the ISMS criteria for the management system and protection measures and adds requirements for each stage of personal information processing. Software supply chain evidence lives mostly in the protection measures. The relevant areas, described in our own words rather than by KISA's criterion numbers:

• Asset identification. Assets in scope are identified, classified and kept current; for applications, that means a component inventory.
• External party security. External parties are listed, security requirements go into contracts, and their compliance is checked.
• Security in system introduction and development. Security requirements are defined and tested, environments are separated, source programs are managed and changes reach production under control.
• Patch management. Patches are applied after reviewing their impact, with compensating controls where a patch cannot be applied.
• Vulnerability inspection. Technical vulnerabilities are inspected regularly and remediated.

Check the exact wording and numbering against KISA's current certification criteria.

Auditors certify the management system, not a product, and ask for the record that each control runs: an asset list that matches reality, contracts with security terms, dated patch decisions and remediation tracked to closure.

The 2026 overhaul. Breaches at certified companies in 2025 led MSIT and the PIPC to announce, on 10 April 2026, measures to strengthen the certification. The release describes a shift from paper-based "snapshot" audits to tracking how controls actually operate:

• ISMS-P becomes mandatory for major public system operators, mobile carriers, identity verification agencies and large personal information controllers, phased in.
• Certification splits into enhanced, standard and simplified tiers.
• Audits add vulnerability assessment and penetration testing by specialists using scanners and code analysis tools, plus on-site demonstrations of controls.
• A preliminary review checks core items first, including CISO and CPO authority, identification of externally exposed assets, password and encryption controls, and vulnerability and patch management.
• Revocation is tied to a defined "critical defect" standard, with certification revoked if defects are not fixed in time.

Post-certification checks and revocation start in the second half of 2026. Mandatory scope, tiers and enhanced criteria start in 2027, through revised decrees, notices and guidelines. Expect audits to test patch and exposure records live.

CSAP for public sector cloud

The Cloud Security Assurance Program (CSAP, 클라우드 보안인증) is MSIT's certification of cloud services under the Cloud Computing Development and User Protection Act (클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률) and the MSIT notice on cloud security certification, which a January 2023 revision split into upper, middle and lower grades. Until now a provider entering the public market needed CSAP first and then a separate NIS security verification.

On 20 April 2026, MSIT and the NIS announced that the two steps become a single NIS-led verification. Their joint release says the national cloud computing security guideline will be revised in the first half of 2026, followed by a one-year grace period, with full operation from the second half of 2027. CSAP certificates issued before the new system starts stay valid for their term. For the private sector, MSIT plans to fold general-purpose cloud security into ISMS as a voluntary certification area. A public and private verification review committee will assess NIS verification results.

Whatever the route, the certificate evaluates the cloud service provider. If you are a public body using software from a certified provider, it does not cover the open source and third-party components inside your own applications; those remain yours under public sector security rules.

Electronic Financial Transactions Act, FSC and FSS

The Electronic Financial Transactions Act puts the security duty on financial companies and electronic financial business operators. The articles software teams meet most often:

• Article 21 requires them to keep electronic financial transactions safe and to meet the standards the FSC sets for information technology, personnel, facilities and operations. It is also the legal base for network separation, detailed in Article 15 of the supervisory regulation.
• Article 21-2 requires the appointment of a chief information security officer.
• Article 21-3 requires analysis and assessment of vulnerabilities in electronic financial infrastructure, a remediation plan based on the results, and lets the FSC inspect both.
• Article 21-5 requires that infringement incidents are notified to the FSC without delay, and that the firm analyses the cause and limits the damage.

The Regulation on Supervision of Electronic Financial Transactions (전자금융감독규정) and its enforcement rules carry the detail, including network separation. Korea's financial sector has run some of the strictest network separation anywhere, which kept SaaS and AI services away from internal systems. That is changing in steps:

• 13 August 2024. The FSC's network separation improvement roadmap allowed generative AI, wider SaaS use and easier R&D environments through regulatory sandbox designations with security conditions. For the long term it set out a move to principle-based rules under "autonomous security, outcome responsibility", with heavier accountability for CEOs and boards, and a separate Digital Financial Security Act (디지털 금융보안법) to be prepared.
• 20 April 2026. Amended enforcement rules made SaaS a named exception to network separation on internal business networks, without a separate sandbox review, except where unique identifiers or personal credit information are processed. Conditions include using only SaaS evaluated by a body such as the Financial Security Institute, protecting access devices, and a half-yearly compliance check reported to the information protection committee chaired by the CISO.
• 22 June 2026. The revised Financial Sector AI Guidelines took effect. They are self-regulation; AI Basic Act duties apply separately.
• 14 October 2026. After the breaches described below, the FSC announced a full review of financial security: a complete inventory of external connection points, stricter authentication, clearer CEO, CISO and CIO responsibility, and vulnerability assessments at large firms moving from at least once a year to at least twice. Scope and schedule were still to be agreed with the industry.

Each step away from physical isolation moves more of the assurance onto software controls: knowing which components and services sit in a system, and showing the supervisor how each one is governed and patched.

Framework Act on Artificial Intelligence (AI Basic Act)

The Framework Act on the Development of Artificial Intelligence and Establishment of Trust (인공지능 발전과 신뢰 기반 조성 등에 관한 기본법) passed the National Assembly in December 2024. The Cabinet approved its Enforcement Decree on 20 January 2026 and the act took effect on 22 January 2026. MSIT is the lead ministry. What MSIT's announcement on korea.kr confirms:

• Transparency. Providers of products or services that use high-impact or generative AI must tell users in advance, and outputs such as deepfakes must be marked so users can clearly recognise them. Visible labels or invisible watermarks are allowed for other generated content.
• Safety duties above a compute threshold. Extra duties apply only where all three conditions hold: cumulative training compute of at least 10 to the 26th power floating point operations, use of cutting-edge technology, and risk that could broadly and seriously affect fundamental rights.
• High-impact AI. Classification weighs whether the AI is used in fields the law lists and how severe the risk is. Systems where a person makes the final decision are treated as controllable and excluded.
• Grace period. MSIT is deferring regulation for at least one year: a grace period applies to fines, and fact-finding investigations happen only in extreme cases such as loss of life or serious human rights harm.

Legal commentaries also describe a domestic agent duty for some foreign operators and administrative fines of up to KRW 30 million; check those provisions in the statute text.

The act does not ask for an AI bill of materials by name. Its documentation, risk management and incident duties are easier to meet when you know which models, AI SDKs, prompts and agents run in which product.

Software supply chain guideline and roadmap (MSIT and NIS)

On 13 May 2024, MSIT, the NIS and the Digital Platform Government Committee published Software Supply Chain Security Guideline 1.0 (소프트웨어 공급망 보안 가이드라인 1.0), a practical manual for SBOM-based supply chain management drawn from domestic SBOM pilots and the Pangyo testbed, downloadable from KISA among others. The government said then that SBOM institutionalisation was needed but would proceed gradually.

On 24 June 2026, MSIT and the NIS followed with a software supply chain security roadmap for the AI era. It builds security into development and supply, spreads the SBOM-based management model, widens vulnerability discovery channels such as bug bounties and coordinated disclosure, and sets up a way to verify security risks in ICT products supplied to the public sector, alongside a government-wide supply chain security council. KISA's 2026 support programme funds SBOM-based supply chain models for companies.

None of this is a statute. No Korean law in force today requires private companies to deliver an SBOM. Public buyers and regulated firms are moving that way, and the guideline is the reference they cite.

What the rules ask of software and open source

Read side by side, the Korean rules ask for the same seven things. The table maps each one to the source and the evidence that a supervisor, a KISA auditor or a customer's vendor risk team usually asks for.

Two points follow. The clocks are short: a 24-hour report needs you to answer "which systems run the vulnerable version?" within hours, and you cannot build that inventory during the incident. And from 2026 Korean auditors test operation over time, so an SBOM produced once for the audit fails the control it was meant to satisfy.

Real public incidents in or affecting South Korea

These come from official releases. They show what regulators examined; they are not judgements about what the organisations should have done beyond what the regulators said.

SK Telecom USIM data breach, 2025. MSIT's final investigation results, released on 4 July 2025, say the joint public and private team checked all 42,605 of the carrier's servers, found 33 types of malware on 28 of them, and confirmed a leak of 25 types of USIM data (9.82 GB, about 26.96 million IMSI records). It named weak account management, an inadequate response to an earlier intrusion and insufficient encryption as causes. The carrier detected abnormal outbound traffic at 23:20 on 18 April and reported to KISA at 16:46 on 20 April. On 27 August 2025 the PIPC imposed a penalty surcharge of KRW 134,791,000,000 and a KRW 9.6 million fine for late notification, affecting about 23.24 million users. Its findings include internet access to internal management servers, unprotected credentials, an unapplied patch for a known operating system vulnerability and plaintext authentication keys, and it recommended extending ISMS-P to the network systems involved.

Coupang account data breach, 2025. MSIT's investigation results of 10 February 2026 put the exposed accounts at about 33.67 million names and email addresses. The attacker, a former back-end engineer, used a signing key that had not been renewed after he left to forge access passes and reach accounts without a normal login. MSIT found the KISA report came more than 24 hours after the internal report to the CISO and imposed a fine for the delay.

Financial sector breaches, October 2026. After a customer information leak at Shinhan Bank, the FSC held emergency meetings on 2 and 4 October 2026. On 14 October it said 16 firms across banking, savings banks, credit finance, electronic payments, online investment and virtual assets had confirmed intrusions, with about 100,000 records leaked. Of 555 firms that completed a 12-item checklist, 130 reported shortcomings, mostly in patching and monitoring. The weaknesses it named include missing patches, unsupported systems, no round-the-clock monitoring and gaps in external access control, including missing MFA. Our incident write-up separates what the FSC confirmed from press reporting.

In all three, investigators reconstructed which systems were exposed, what they ran and when the organisation knew. Those are the records the rules ask you to keep in advance.

The personas who own the problem

Korean rules name some of these roles in law, which is unusual and useful. The CISO is a statutory post under the Network Act and the Electronic Financial Transactions Act, and the privacy officer (개인정보 보호책임자, CPO) is a statutory post under PIPA Article 31.

The CISO. Owns the certificate, the 24-hour report and, in finance, the EFTA vulnerability assessment. Needs board-reportable risk: internet-facing systems with known exploited vulnerabilities, how long they have been open, and which exceptions were signed. Triggers: the surveillance audit, an FSS inspection, or a sector alert like the FSC's October 2026 directives.

The privacy officer (CPO). Owns PIPA safety measures, the 72-hour clock, processor contracts and transfers abroad. Needs to know which systems process personal data and where every tool, including security tooling, sends it. Triggers: a PIPC inquiry, a breach, or a new SaaS or AI tool. The SK Telecom decision shows the PIPC expects CPO oversight to reach beyond IT.

The head of AppSec or VP of Engineering. Owns the ISMS-P development and patch management criteria in practice. Needs one process that produces audit evidence as a side effect of shipping. Triggers: a patch management finding or a critical advisory in a common library.

The GRC or compliance lead. Owns the audit calendar and the map from clauses to controls. Needs dated evidence by clause, and a plan for the 2027 ISMS-P tiers. Trigger: the audit window.

Procurement and vendor risk. Owns the ISMS-P external party criteria and PIPA Article 26 in practice. Needs a repeatable way to request supplier SBOMs and vulnerability statements and follow up. Triggers: a renewal, a supplier breach, or a public buyer asking for an SBOM.

The AI governance owner. Often the CPO. Owns AI Basic Act notices and the high-impact question. Needs an inventory of models, SDKs and agents. Trigger: a generative feature launch.

A practical 30/60/90-day plan

This plan works with whatever tools you have. It assumes an organisation in scope for PIPA and either ISMS-P or the EFTA.

Days 1 to 30: know what you have and fix the clocks

1. Write down which regimes apply. For each legal entity, record PIPA (always), Network Act ISMS (check the Enforcement Decree), ISMS-P (if you hold it, or will be mandated in 2027), EFTA, CSAP (if you sell cloud to the public sector) and the AI Basic Act. Name the owner of each.
2. Inventory applications and generate SBOMs. List every application in scope with its owner, repositories and where it runs, marking internet-facing ones. Generate a CycloneDX or SPDX SBOM per release, including transitive dependencies and container base images.
3. Find the worst first. Match SBOMs against advisories and the CISA Known Exploited Vulnerabilities catalog, starting with internet-facing systems holding personal or financial data.
4. Rewrite the incident runbook around three clocks. Network Act: 24 hours from awareness. PIPA: 72 hours to data subjects and, above the thresholds or for any hacking incident, to the PIPC or KISA. EFTA: without delay to the FSC. Record who decides "awareness" and where the timestamp is kept.
5. List AI in production. Models, AI SDKs, hosted inference endpoints, agents and the data they see. Note which features produce generated content shown to users.

Template you can use today, one row per application:

Days 31 to 60: turn inventory into decisions

1. Set patch timeframes and an exception path. Define timeframes by severity and exposure, require senior approval for exceptions, and require a compensating control for each. This is the record ISMS-P auditors ask for on patch management.
2. Gate new risk at build time. Add a policy check to CI that fails or warns on new critical vulnerabilities, disallowed licenses and missing SBOMs, with exceptions that expire.
3. Ask key suppliers for SBOMs and vulnerability statements. Start with suppliers whose software processes personal data or runs in internet-facing systems. Add SBOM delivery and vulnerability notification terms at the next renewal, in line with the ISMS-P external party criteria and PIPA Article 26.
4. Review cross-border flows. For every tool that sends code, logs or data abroad, record the PIPA Article 28-8 basis.
5. Classify AI features. Decide, with counsel, whether any feature falls into a high-impact area. Add generative AI notices and output labels where the AI Basic Act calls for them.

Days 61 to 90: make it repeatable and auditable

1. Automate SBOM refresh on every release and keep the history, so you can show an auditor the inventory at any past date.
2. Rehearse the 24-hour report. Run a tabletop with a real library advisory: find affected systems, decide awareness time, draft the KISA report and the PIPA notice. Time each step.
3. Map controls to evidence. For each ISMS-P criterion, PIPA safety measure and EFTA requirement in scope, name the evidence and where it lives. Fill gaps before the audit window.
4. Report to the board or management. Three numbers work: open critical or exploited findings on internet-facing systems, median age of those findings, and the share of in-scope applications with a current SBOM.

Illustrative scenario: a card company finds that 9 of its 30 internet-facing applications have no current SBOM because they are built by a contractor. It records them as external party assets for ISMS-P, makes SBOM delivery a renewal condition, and scans the deployed container images in the meantime. The numbers are invented.

How Safeguard does this

Everything below comes from Safeguard's offering documentation and docs.safeguard.sh, and every capability named is GA. Safeguard helps a team produce and keep the evidence that these rules ask for. It does not make an organisation compliant, and it holds no Korean certification of its own, including ISMS-P and CSAP.

1. Choose where Safeguard runs. SaaS is multi-region (US, EU and Gov); there is no Korea region. To keep code and data inside your own perimeter, which answers the PIPA Article 28-8 question and suits network separation, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped deployment with the AI models running inside your environment and signed offline snapshot delivery.
2. Keep source code on your machines. The Safeguard CLI (GA) installs with curl -fsSL https://cli.safeguard.sh/install | bash. The local runner (GA) runs scans on your own machine and uploads only the SBOM and findings, never source code. Zero AI mode (GA) runs the whole platform with no LLM in the loop, and bring your own model (GA) lets you use a model already on your approved list.
3. Generate SBOMs for every in-scope application. SBOM generation and analysis (GA) produces SPDX and CycloneDX from connected repositories, container registries, uploaded manifests and AI models, and scans continuously. That is the inventory behind ISMS-P asset identification and the PIPA safety measures.
4. Turn on the Korea framework pages. In Compliance, the Korea ISMS-P and South Korea PIPA frameworks are on unless you switch them off in Compliance › Manage. Each product scan checks Safeguard's own scan requirements against what it found. For ISMS-P these include KR-ISMSP-ASSET (component inventory), KR-ISMSP-DEV (integrity of acquired software), KR-ISMSP-OPS (versions for patch and change control), KR-ISMSP-VULN (identifiers that match advisories) and KR-ISMSP-OUT (suppliers of components). For PIPA they include KR-PIPA-29-INV (knowing the components of processing systems), KR-PIPA-26 (named suppliers for outsourced processing oversight) and KR-PIPA-34 (versions for breach scoping). These are Safeguard's identifiers, not KISA's or the PIPC's numbering. The Compliance and GRC suite (GA) keeps controls, evidence, risks and vendors in one place. There is no framework page for the EFTA or the AI Basic Act; map those yourself.
5. Rank and fix vulnerabilities. SCA with deep transitive dependency scanning (GA) and vulnerability management with EPSS and CISA KEV enrichment (GA) give you the list. Reachability analysis (GA) ranks findings by whether your code actually calls the vulnerable path. Autonomous remediation (GA) opens tested, policy-gated upgrade pull requests, single or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own.
6. Gate releases and record exceptions. Policies, gates and guardrails (GA) evaluate scans with Block, Warn and Notify actions, and approvals run through time-boxed exceptions. That is the dated exception record ISMS-P auditors look for on patching. License compliance (GA) covers SPDX expressions and attribution.
7. Collect supplier SBOMs. In the Third-Party Risk Manager (GA), SBOM requests go to one vendor or many with format requirements and reminders, and a received SBOM is validated and scanned. CSAF and VEX upload (GA) puts a supplier's exploitability statements next to the findings. This supports ISMS-P 2.3 and PIPA Article 26 oversight.
8. Stop risky packages at install. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build.
9. Inventory and govern AI. AI-BOM discovery (GA) finds AI SDK imports, model files, prompts, MCP server configuration, inference endpoints and agents, and assembles them into an AI-BOM. AI-SPM (GA) scans model artifacts. AI Gateway (GA) lets you define prompt injection, jailbreak and PII egress guardrail policies for LLM use, MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access.
10. Answer customers once. Trust Center (GA) publishes your security posture and handles questionnaires, which helps suppliers answering ISMS-P external party questions. Safeguard's own posture wording is "SOC 2 Type II audit in progress" and "designed for FedRAMP High".

What Safeguard does not do

• It does not file reports for you. The 24-hour Network Act report, the PIPA notice and report and the EFTA report to the FSC are your organisation's duties. Safeguard can hold the versions, findings and timestamps that feed a report; a person files it.
• It does not certify you. KISA auditors certify ISMS and ISMS-P, and KISA evaluates CSAP. Safeguard holds no Korean certification, and its framework pages map requirements to evidence rather than grant anything.
• It has no Korea SaaS region. If you need everything inside your own environment, use private VPC or dedicated tenancy, on-prem or air-gapped deployment, or the local runner.
• It does not decide whether your AI is high-impact. That is a legal judgement for you and counsel, with MSIT confirmation available under the act.
• It does not replace physical, network or personnel controls, which many ISMS-P criteria cover and no software scan sees.
• It does not replace the vulnerability assessments and penetration tests that financial firms and, from 2027, ISMS-P audits require from qualified specialists. Safeguard's scanners support that work.
• It does not interpret the law. Whether a clause applies to you is a question for counsel or the regulator.

Common mistakes

• Treating ISMS-P as a one-off project. From the second half of 2026, post-certification checks and revocation tighten. An SBOM produced once for the audit fails the next one.
• Starting the clock at confirmation. The Network Act and PIPA clocks run from awareness. Decide who declares awareness and record the time.
• Assuming a small breach is not reportable. A leak caused by unauthorised external access is reportable to the PIPC or KISA whatever the number of people.
• Forgetting that security tools move data. A scanner that stores code or logs abroad raises a PIPA Article 28-8 question and, in finance, a network separation one.
• Leaving contractors out of scope. ISMS-P's external party criteria and the EFTA put externally built and operated systems inside your responsibility.
• Leaving AI out of the asset list. Models, prompts and agents are software and processors like any other.

FAQ

Is an SBOM mandatory in South Korea?

Not by statute for private companies today. Software Supply Chain Security Guideline 1.0 (MSIT, the NIS and the Digital Platform Government Committee, May 2024) and the June 2026 roadmap promote SBOM-based management. In practice an SBOM is how teams evidence asset identification, patching and vulnerability inspection under ISMS-P and PIPA.

Who must have ISMS or ISMS-P certification in Korea?

ISMS is mandatory under Article 47 of the Network Act for providers designated in its Enforcement Decree. ISMS-P adds personal information criteria and is voluntary today; under the 10 April 2026 reform it becomes mandatory from 2027 for major public system operators, mobile carriers, identity verification agencies and large personal information controllers.

How fast must a cyber incident be reported in Korea?

Under the Network Act, within 24 hours of awareness to MSIT or KISA. Under PIPA, data subjects within 72 hours, and the PIPC or KISA within 72 hours for 1,000 or more people, sensitive or unique identifiers, or any external hacking. Financial firms notify the FSC without delay.

What is happening to CSAP?

MSIT and the NIS announced on 20 April 2026 that public cloud entry moves from CSAP plus NIS verification to a single NIS-led verification, fully operating from the second half of 2027 after a one-year grace period. Existing CSAP certificates stay valid for their term.

When did Korea's AI Basic Act take effect, and what does it require?

On 22 January 2026. It requires advance notice and output marking for generative and high-impact AI, adds safety duties above a training compute threshold of 10 to the 26th power operations, and gives at least a one-year grace period for fines and fact-finding investigations.

Can a Korean bank use SaaS under network separation rules?

Since 20 April 2026, SaaS on internal business networks is a named exception, provided the service was evaluated by a body such as the Financial Security Institute, access devices are protected and compliance is checked every half year. It does not apply where unique identifiers or personal credit information are processed.

Does PIPA restrict sending source code or SBOMs abroad?

PIPA governs personal information, not code. Code, logs and findings can contain personal information, and then Article 28-8 requires a lawful basis for transfer, which includes storage abroad.

Can Safeguard run without our code leaving Korea?

Yes, through deployment rather than a Korea region. The local runner scans on your machines and uploads only SBOMs and findings, never source code. On-prem and air-gapped deployments keep the whole platform, including the AI models, inside your environment, and Zero AI mode removes LLMs from the loop.

Before you fix anything

Every rule in this guide ends at the same question: when a component in an in-scope system is vulnerable, how fast does the fix reach production, and what do you do when no fix exists yet? The section below covers how Safeguard closes both gaps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session that fixes a vulnerable dependency in a repository. It reads the finding and advisory, asks before any command that changes something, edits the manifest, runs the install and tests with approval, and pushes nothing. That is the shape of a patch decision you can show an ISMS-P auditor on patch management.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it, and scans from the terminal. For Korean banks working under network separation, and for any team weighing the PIPA cross-border question, this is how SBOMs and findings are produced while source code stays on your systems.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It shows the kind of scoped agent access worth recording in the AI inventory the AI Basic Act assumes you keep.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• KLRI: Personal Information Protection Act, English translation through Act No. 19234
• Korea Law Information Center: Enforcement Decree of the Personal Information Protection Act
• PIPC: Personal information leak reporting
• Korea Law Information Center: Network Act
• KLRI: Electronic Financial Transactions Act, Korean and English
• PIPC: Sanction on the SK Telecom personal information leak, 28 August 2025
• MSIT via KDI EIEC: SK Telecom intrusion final investigation results, 4 July 2025
• Korea.kr: SK Telecom intrusion final investigation results
• Korea.kr: Coupang intrusion investigation results, 10 February 2026
• PIPC and MSIT: Overhaul of the ISMS and ISMS-P certification, 10 April 2026
• Korea.kr: Personal information protection certification overhaul
• MSIT and NIS: Improving public cloud market entry procedures, 20 April 2026
• FSC: Financial sector network separation improvement roadmap, 13 August 2024
• FSC: SaaS on internal business networks from 20 April 2026
• FSC: Financial sector AI guidelines revision, June 2026
• FSC: Second emergency response meeting on financial sector intrusions, 14 October 2026
• Korea.kr: AI Basic Act takes effect on 22 January 2026
• Korea.kr: Software Supply Chain Security Guideline 1.0, May 2024
• Korea.kr: Software supply chain security roadmap, June 2026
• Safeguard docs: Korea ISMS-P framework
• Safeguard docs: South Korea PIPA framework
• Safeguard docs: Safeguard CLI
• Safeguard docs: Local runner
• Safeguard docs: Air-gapped deployment
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: AI-BOM discovery

Related reading: South Korea cybersecurity regulations overview, How PIPA shapes software supply chain and SBOM practice and South Korea says 16 financial firms were breached.

To try it, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.