After You Have Seen the Account Number

In one line

What you saw because the investigation needed it and what you may leave in a report are different, and leaving unneeded personal information in a document is itself an incident.

Why this was needed

When you query bank data, personal information comes into view. Account numbers, names, resident registration numbers, phone numbers, transaction histories. The investigation needs them — to trace one transfer of a specific customer, you have to look at that account.

The problem is what comes after. When the investigation is over and you write the report, the moment you paste in the values from the query screen as they are, that document becomes a document containing personal information. That document goes around by email, is pasted into Slack, is uploaded to a wiki, and is still searchable years later. The original database has access control and logs, but the documents we make have nothing on them.

How it works

There is one criterion. Does the reader of this document need to know this value?

전문 번호 MSG-20260825-0104   필요하다. 고객사가 그 건을 다시 찾아야 한다.
계좌번호 110-4378-567278      전체는 필요 없다. 뒤 4자리면 대조가 된다.
고객 이름 정하윤              필요 없다. 전문 번호로 특정된다.
주민등록번호 711455-2930474   어떤 경우에도 필요 없다.

The reason you keep the last 4 digits when masking an account number is not generosity but the ability to match. The customer contact has to find that item in their own system and check it against our report, and if you cover everything, that is impossible. Masking is keeping the necessary minimum and covering the rest.

110-4378-567278  →  110-****-**7278

Resident registration numbers are different. Even if you cover the back part, the first 6 digits are the date of birth, and the first digit of the back part is gender and century of birth. That is, the first 6 digits alone have considerable identifying power. So you do not write it masked; you do not write it at all. If the investigation needed a resident registration number, you write only that fact and leave no value.

What it looks like in the field

First, screenshots are the most common leak path. If you capture the query screen and paste it in, not only the one cell we wanted to show but every cell on that screen comes out with it. This is why screen photography and capture are blocked at bank sites. If you must move a table, the rule is to pick only the needed columns and retype them as text.

Second, intermediate outputs are documents too. CSVs you made while investigating, temporary SQL results, and pasted Slack messages all receive the same criterion. The thought that "only the formal report needs care" creates incidents. In practice, leaks happen far more often in intermediate outputs than in formal reports.

Third, covering is not the end; you must also write that you covered. If the report has only masked values, the reader cannot tell "did they not see the original" from "they saw it and covered it." If you keep personal information handling as a separate section and write what you covered and how, and why you kept the last 4 digits, that document itself becomes evidence that the procedure was followed.

Fourth, the fact that you looked something up is itself recorded. Which account we queried remains in the customer's access log, and in a later audit they ask "why did you look at this account?" The only basis you can answer with then is the investigation record we wrote. So narrowing the scope of lookup to what is needed and writing down why that scope was needed is also self-protection.

What to check in the next quiz

It checks the criterion for masking, why resident registration numbers are not even masked, the handling of intermediate outputs, and in which direction to design an investigation in a network-separated environment.