Korea's safety-measures notice: which staff stay offline?

Somewhere in your company is an engineer who can pull a customer's 주민등록번호 out of production this afternoon. If you handle personal data in Korea and your systems serve a million users a day, a notice in force since 1 July decides whether that engineer's laptop keeps its internet connection — and it decides it in the first six characters of Article 6-2(2). Most summaries of the exemption skip those six characters, and the same sentence that grants it names what claiming it will cost you.

The rule that did not move

개인정보의 안전성 확보조치 기준 (고시 제2026-9호), the notice setting out the technical safeguards Korea's Personal Information Protection Act requires, took effect the day it was issued: 1 July 2026. Its Article 6-2(1) applies to any 개인정보처리자 whose systems held an average of a million users a day over the last three months of the previous year. Above that line, two categories of staff must have their internet access cut:

Anyone who can set access permissions on the personal-data system.
Anyone who can download or destroy personal data from it.

A proviso adapts paragraph (1) for cloud tenants: if you run the system on a 클라우드컴퓨팅서비스, you block everything except access to that service. Nothing else about paragraph (1) is negotiable — no risk analysis, no exceptions.

This is a distinct obligation from the 망분리 Korean financial firms argue about, which lives in 전자금융감독규정 and which this notice never mentions.

The exemption reaches one group

Paragraph (2) is where the change sits, and it is narrower than the summaries suggest:

개인정보의 안전성 확보조치 기준, Article 6-2(2): ② 제1항제2호에도 불구하고 개인정보처리자는 내부 관리계획에서 정한 위험 분석 결과가 다음 각 호의 어느 하나에 해당하는 경우에는 제1항에 따른 인터넷망 차단 조치를 하지 아니할 수 있다. 다만, […]
제1호 위험 분석 결과 확인된 위험이 현저히 낮은 경우
제2호 위험 분석 결과 확인된 위험을 감소시킬 수 있는 보호조치를 적용한 경우

Those six characters are 제1항제2호 — paragraph (1), item 2 — and the 에도 불구하고 that follows them means notwithstanding. The exemption reaches only the download-and-destroy group. Your permission-setters stay offline whatever your analysis concludes.

And the escape route runs through a document. The risk analysis has to be the one defined in your 내부 관리계획, your internal management plan — so it exists before the regulator asks, and it says what you decided and why.

Sensitive data closes the door again

That 다만 I elided above is a 단서, and it takes back most of what the sentence had just given:

고시 제6조의2② 단서: the exemption does not apply to the computers of staff who can download or destroy 민감정보 under Article 23 of the Act, or the personal data listed in Article 7(1) and 7(2) of this notice.

Article 7 is the encryption article. Its paragraph (2) lists the ordinary furniture of a Korean consumer business — 주민등록번호, 여권번호, 운전면허번호, 외국인등록번호, 신용카드번호, 계좌번호, 생체인식정보 — and paragraph (1) adds passwords and biometric authentication data.

So the staff most likely to be handling data worth protecting are the staff the exemption will not cover. A company that reads paragraph (2) and starts turning the internet back on has misread which of its people it describes.

A decision flow drawn in glowing lines on dark slate, for staff at a Korean data processor with over a million daily users. Three tests run down the spine — can they set access permissions, do they handle sensitive or ID-number data, does the risk analysis clear them — and every blocking answer converges on one amber conclusion: the internet must be blocked, Art. 6-2(1). Only the last

Build the exemption before you claim it

A defensible exemption is four artifacts, and all four have to exist before anyone invokes Article 6-2(2):

Sort every 개인정보취급자 into the two categories in paragraph (1). One list of the people who can set access permissions, one of the people who can download or destroy personal data. Anyone on both lists stays offline — paragraph (2) never reaches item 1.
Inventory which of them can reach 민감정보 or the Article 7 data. Those names come straight back off the first list, and the 단서 puts every one of them outside the exemption whatever the risk analysis concludes.
Record the risk analysis in your 내부 관리계획. It has to reach one of the notice's two findings — the risk is 현저히 낮음, or you applied controls that reduce it — and it has to say what you decided and on what basis.
Measure those controls against the [별표]. Where you claim the second finding, the notice requires you to consider the examples in the annex published alongside it.

An internal management plan lying open on a sunlit desk, a fountain pen across its pages. The right-hand page, headed

That is evidence work, and it is the part a compliance checklist cannot do for you. Deciding that a risk is 현저히 낮음 is a claim someone will eventually test.

Which of your engineers can download personal data today — and could you name them, and say which of them touch a 주민등록번호, without opening a ticket?

References

개인정보보호위원회 — 개인정보의 안전성 확보조치 기준 (고시 제2026-9호)
국가법령정보센터 — 개인정보 보호법 (제23조 민감정보, 제29조 안전조치의무)