GuideJuly 28, 20267 min read

Personal Data Classification under UU PDP: Specific vs General

UU PDP Article 4 splits personal data into two categories, and the distinction drives most of your obligations. What counts as specific personal data, what counts as general, and why the boundary matters operationally.

Two categories, set by Article 4

UU PDP Article 4 divides personal data into two categories: data that is specific in nature, and data that is general in nature. Almost every downstream obligation, from consent handling to security measures to breach severity, keys off which category the data falls into.

Specific personal data is data whose processing can cause a greater impact on the data subject, such as discrimination or significant harm. The law names health data and information, biometric data, genetic data, criminal records, data about children, personal financial data, and other data designated by legislation.

General personal data covers items such as full name, sex, nationality, religion, marital status, and personal data that is combined in a way that identifies a person. That last clause is the one organizations most often overlook.

The combination rule

General personal data includes data combined to identify a person. This means classification is not purely a property of a single field. A postcode on its own is unremarkable; a postcode combined with date of birth and job title may identify an individual, and at that point the combined set is personal data.

The practical consequence is that data classification has to be done at the dataset level, not only the field level. Analytics tables, exports to spreadsheets, and log files assembled from multiple systems are common places where individually harmless fields combine into something that identifies people.

This is also why de-identification claims need testing rather than assertion. If a dataset can be re-identified by combining its own fields, it has not left the scope of the law.

Why the boundary matters operationally

The classification changes what you owe. Processing specific personal data at scale as a core activity is one of the three conditions that makes appointing a data protection officer mandatory under Article 53. It also raises the bar on the security measures expected, because the law asks for protection proportionate to risk, and specific data carries higher risk by definition.

For Indonesian financial institutions this matters immediately: personal financial data is explicitly named as specific personal data. A bank's core processing activity is therefore large-scale processing of specific personal data, with the obligations that follow.

Health providers, insurers handling medical underwriting, and any organization using biometric authentication are in the same position. Fingerprint and face scan data used for login is biometric data, and it does not stop being specific personal data because it is used for security purposes.

Turning classification into a working control

A classification scheme only helps if it reaches the people handling the data. The common failure is a well-drafted policy that classifies data into tiers, paired with a workforce that has never been told which tier the file in front of them belongs to.

Practical steps that work: label the systems rather than asking staff to classify individual records, restrict export paths from systems holding specific personal data, and make the handling rules concrete enough to follow. Instructions like handle sensitive data appropriately do not change behaviour.

Then measure. If a member of staff will forward a spreadsheet of customer financial data to a personal email address, or hand over credentials to a convincing phishing email, the classification scheme has not changed the outcome.

Evidence a reviewer will ask for

In a data protection review, classification tends to be probed in three ways: can you show what categories of personal data you hold and where, can you show that access is limited accordingly, and can you show that the people with access have been trained on handling it.

The third question is where documentation is usually thinnest. Training completion records answer it weakly. Behavioural evidence, showing that staff handling specific personal data are measurably more resistant to social engineering than they were a year ago, answers it well.

Claro supports this directly: role-aware and department-aware awareness training, phishing simulation targeting the teams that handle the most sensitive data, per-user risk scoring, and exports mapped to UU PDP, OJK and ISO 27001 expectations.

Key takeaways

  • UU PDP Article 4 splits personal data into specific and general categories, and the split drives most downstream obligations.
  • Specific personal data includes health, biometric, genetic, criminal records, children's data and personal financial data.
  • General personal data includes data combined to identify a person, so classification must be assessed at dataset level, not just per field.
  • Large-scale processing of specific personal data as a core activity triggers the mandatory data protection officer requirement under Article 53.
  • Personal financial data is explicitly specific, which places Indonesian banks and fintechs in the higher-obligation category by default.

Frequently asked questions

  • Personal data whose processing can have a greater impact on the data subject, such as discrimination or significant harm. Article 4 names health data and information, biometric data, genetic data, criminal records, data about children, personal financial data, and other data designated by legislation.

Build a program that sticks

Claro helps you run simulation, training, and reporting in one place.

Request a demo