The Threshold Moved from "Confirmed Breach" to "Possible Breach"
Most organizations have handled incidents the same way. Spot an anomaly, investigate internally, confirm that personal data actually left the building — and only then start the notification process. The reasoning was that notifying before confirmation only creates unnecessary alarm.
The problem is that this practice increasingly conflicts with how regulators think. Under Korea's Personal Information Protection Act, breach notification to data subjects and reporting to the regulator must happen within 72 hours of becoming aware of the breach — and "becoming aware" does not mean the moment you finalize your findings. The clock starts when you recognize circumstances suggesting a breach occurred. The fact that your investigation took two weeks does not justify a late notification.
In practice, organizations get squeezed from two directions.
Neither can be improvised on the day of the incident. The only real solution is to document, in advance, which circumstances trigger a notification review. For example, "any trace of an out-of-scope account querying a personal data table, even once" is a clear line. "The admin account downloaded more than usual" is not — and vague lines guarantee an argument on the worst possible day.
System Requirements That Make the Call Possible
A threshold is useless if your systems cannot answer the question. Check these four things.
1. Do the logs actually exist?
Many teams say "yes, we log everything," but a closer look often reveals only application login records — no per-query or per-download logging. Access records tell you who came in; they do not tell you what was viewed or how much. Notification decisions depend on the latter.
At minimum, capture:
2. A minimal set of detection rules
Long before a full UEBA deployment, three to five rules catch most real-world incident patterns.
3. Retention period and integrity
Access records for personal data processing systems must be retained for at least one year — two years when handling unique identifiers, sensitive data, or the personal data of 50,000 or more data subjects. The commonly missed half of this requirement is integrity. If logs live only on a production server's local disk where operators can delete or edit them, your post-incident reconstruction will not be credible. You need at least one of: forwarding to a separate collection server, write-once storage, or hash-based tamper verification.
4. A data structure that surfaces affected data subjects quickly
The question you must answer inside 72 hours is ultimately "who was affected, and which fields were exposed." If personal data is scattered across tables with incomplete identifier linkage, answering takes days. When query logs retain the identifier range of the result set, that timeline shrinks from days to hours.
CPO Accountability and Organizational Process
As the independence and authority of the Chief Privacy Officer role expand, leaving the notification decision on an individual engineer's shoulders is a structural risk. At minimum, define:
Incidents originating at partners, cloud providers, or SaaS vendors deserve equal weight. A breach at your processor does not remove your obligation as the controller. Unless your contract specifies notification to the controller within 24 hours of awareness, along with named contacts and the scope of logs to be provided, you will spend the window waiting for a vendor to reply.
Investments That Genuinely Reduce Penalty Exposure
When penalties are calculated, the existence of preventive controls weighs as heavily as your response. You cannot prevent every incident, but evidence that controls were designed and operating works in your favor.
The vulnerabilities found in older systems are remarkably consistent.
Investment only counts if it is documented. Keep permission review minutes, quarterly account cleanup records, vulnerability assessment reports, and training completion logs — all with dates attached.
A 90-Day Assessment Roadmap
Here is a sequence you can execute without a full rebuild.
Phase 1 (Days 1–30) — Re-verify data flows and holdings
Catalog which systems hold which categories of personal data. Scope includes not just the production database but backups, log stores, the data warehouse, and anything transmitted to partners. Simply deleting data you retain but never use meaningfully shrinks your exposure at this stage.
Phase 2 (Days 31–60) — Fill the logging and detection gaps
Add query and download logging, then apply the three to five detection rules above. You do not need a full SIEM — an alert channel is enough to start.
Phase 3 (Days 61–90) — Run a notification drill
Take a hypothetical scenario and actually start a timer. Measuring how many hours it takes to get from detection to a draft notice makes it obvious whether your remaining bottleneck is technical or a decision-making one.
The priority order is clear: logging and account controls come before advanced access control. Being unable to explain what happened is the single largest risk you carry.
How POLYGLOTSOFT Can Help
POLYGLOTSOFT takes an approach that meets regulatory requirements without ripping out your legacy systems. We support you step by step — mapping personal data flows and assessing what you hold, adding a query and download logging layer, designing detection rules, and documenting the notification process. After implementation, our maintenance (SM) plans continue log monitoring and periodic assessments while accumulating the evidence you need for an audit. If you need a system assessment, reach us through our [contact page](https://polyglotsoft.dev/en/support/contact).