May students’ full names be announced publicly? Can a university unit post a list of scholarship recipients on its website? What about student ID numbers (NIM), photographs, grades, or research data? This page helps every directorate, faculty, study program, and work unit at Telkom University identify which data may be published, which data must be restricted, and who is responsible for making those decisions.
Key message: Personal data is not automatically prohibited from being published. However, publication is not unrestricted: it must have a lawful basis for processing, a clear purpose, the minimum relevant data, authorization from the business process owner, and appropriate safeguards and retention arrangements. If these requirements have not been met, do not publish the information yet.
Start with your question:
1. Which data may be published, published conditionally, or kept out of the public domain?
| Example of information | Recommendation | Practical rationale |
|---|---|---|
| Full name + study program of a recipient of a merit-based scholarship | Conditional | May be announced if publication is part of a program with a documented lawful basis, adequate notice, and clear internal publication approval. |
| Name of a recipient of financial-need-based assistance | Prefer restricted channels | Could reveal personal financial or social circumstances. Deliver individual results through an authenticated portal or account. |
| Name + full student ID (NIM) + GPA/grades + mobile phone number | Not for public disclosure | Combines identifiers and personal information unnecessary for an ordinary announcement. |
| Statistics on the number of recipients by faculty/study program | May be published | Ensure that aggregated data cannot be used to re-identify individuals. |
| Photographs of award recipients on social media | Conditional | Review the promotional purpose, notice, and lawful basis; specific consent is recommended for optional promotional activities. |
Note: “Conditional” does not mean automatically permitted. The final decision must be made by the business process owner under the applicable review procedure, not merely because the information has appeared online before.
2. Understand two different concepts: personal data status and information classification
A common misunderstanding is that because a full name is personal data, it must always be classified as Confidential. In fact, personal data status and classification as an information asset are two separate assessments.
| Dimension | Question to be answered | Example |
|---|---|---|
| Personal data status (Indonesian PDP Law) | Does this information identify an individual, or could it be used to identify one? Is it general or specific personal data? | A full name is general personal data. Health data, biometric data, genetic data, children’s data, and personal financial data fall under the specific personal data category under the PDP Law. |
| Information asset classification (PU.018/2025) | Who may access this version of the data, and what would be the impact of unauthorized disclosure? | Public, Internal, or Confidential. |
For example, a student’s name in the academic database must continue to be managed with appropriate access controls. However, the name and study program required for an official announcement may form part of an approved publication version, without making the entire database Public.
Legal basis: Law No. 27 of 2022, Article 4 (personal data categories), Article 16 (processing principles, including announcement/dissemination), and Article 20 (lawful bases for processing); Telkom University Regulation PU.018/LGL03/PTI/2025, Articles 4–5 (classification and handling of information assets).
3. Example data matrix: what may appear on public websites and social media?
The table below is an illustrative guide for initial assessment, not a definitive list of permissions. Each directorate/unit must adapt it to its approved data matrix, context, lawful basis, and publication risks.
| Business process / information | Public websites & social media | Alternative / control |
|---|---|---|
| Student Affairs — name + study program of merit-based scholarship recipients | Conditional | Documented publication approval and lawful basis; disclose only the minimum necessary data. |
| Student Affairs — recipients of financial-need-based scholarships | Not recommended | Provide individual notifications through an SSO portal; publish only program-level statistics externally. |
| Academic Affairs — individual study result reports (KHS), grades, GPA, transcripts | Not for public disclosure | Authenticated portal with role-based access restrictions. |
| Academic Affairs — graduation lists and academic achievements | Conditional | Use minimum necessary data, adequate notice, and an official approval process. |
| Admissions — prospective students’ selection results | Prefer restricted channels | Provide individual results through the admissions portal; conduct a separate assessment if a public list is proposed. |
| Human Resources — lecturers’ names, qualifications, titles, and affiliations | Conditional | May be included in an official professional directory where justified and relevant. |
| Human Resources — personal mobile numbers, home addresses, family details | Not for public disclosure | Do not display in public profiles or contact cards. |
| Research/Community Service — researchers’ names, affiliations, titles of published works | Conditional | Verify publication status, intellectual property rights, and personal data minimization. |
| Research/Community Service — unpublished proposals and internal evaluation details | Not automatically public | Remove internal identities, review notes, and sensitive information before preparing a public summary. |
| Finance — bank account details, payment amounts, individual income | Not for public disclosure | Restrict access according to business needs and authorized roles. |
| Communications — photographs documenting campus events | Conditional | Consider context, notice, consent where necessary, and children or vulnerable individuals. |
| PuTI — accounts, passwords, tokens, penetration-testing results, individual activity logs | Not for public disclosure | Apply strict access controls; consider publishing only sanitized summaries. |
| Management — aggregated unit performance statistics | May be published upon approval | Remove unnecessary identifying and internal information; assess re-identification risks. |
Important: Full student ID numbers (NIM), national identifiers, health information, financial documents, and system access data should not be included in routine announcements. “Not for public disclosure” does not prevent lawful processing by authorized parties through restricted channels.
4. Case study: announcing student scholarship recipients
A. Merit-based scholarships — official announcement
Full names and study programs may be included in official announcements when disclosure is necessary for the program’s purpose, the lawful basis has been established, students have received adequate information, and the unit has approved the public-facing version. Student consent is not the only lawful basis for processing under the PDP Law, but publication for optional promotional activities should preferably rely on genuinely freely given and specific consent.
| Name (fictional examples) | Study program | Description |
|---|---|---|
| Student A | Bachelor’s in Informatics | 2026 Merit Scholarship Recipient |
| Student B | Bachelor’s in Information Systems | 2026 Merit Scholarship Recipient |
Do not automatically include: full student ID numbers (NIM), telephone numbers, home addresses, dates of birth, GPA, bank account numbers, or selection documents.
B. Financial-need-based scholarships
Public announcements linking students’ identities to financial hardship can increase privacy risks and stigma. Recommendation: communicate acceptance status individually through a login-protected portal; public communications should be limited to safely aggregated numbers of recipients, program coverage, and outcomes.
C. Republishing on Instagram, Facebook, and other external channels
Social media increases the risk of copying, saving, and further redistribution. Do not automatically copy the entire recipient list from operational documents. Assess whether social media publication is necessary, which data may be shown, the lawful basis, and the display period; obtain appropriate permission for optional promotional materials.
5. Answer these six questions before publishing data
- What is the purpose of publication? Does everyone need to know, or should the information be available only to relevant participants or employees?
- What is the lawful basis for processing personal data? For example, applicable program terms, a legal obligation that genuinely applies, valid explicit consent, or another basis under Article 20 of the PDP Law.
- Is the data limited to what is necessary? Remove unnecessary identification numbers, personal contact details, financial information, grades, and attachments.
- Has the sensitivity been assessed? Consider specific personal data, children’s data, financial information, selection results, and risks arising from linking different pieces of information.
- Who is authorized to approve publication? Obtain authorization from the business process owner and involve Legal/DPO in cases requiring a specialized assessment.
- Where will it be published, and for how long? Specify the website, social media platform, or SSO portal; publication period; approval record; and procedures for correction or removal.
Decision rule: If one or more answers are unclear, postpone public publication. Obtain a decision from the business process owner and consult Legal/DPO where necessary. Use a restricted channel as an alternative.
6. Every directorate’s responsibility: a business-process-based data matrix
Proposed operational requirement, subject to formal approval: “Every directorate/unit that owns a business process must establish a data matrix based on its business processes, using consistent guidelines and review procedures.” YPT and the Legal Division have provided an institution-wide framework/guideline. The mandatory wording above is a proposed implementing requirement, not a statement that the obligation to prepare this new matrix format has already been enacted in the regulations reviewed.
The overarching policy cannot reasonably cover every variation of scholarship announcements, graduation lists, lecturer profiles, admissions, employment, and IT services. Therefore, each business process owner should prepare a Data Classification, Use, and Publication Matrix to support auditable decisions.
Minimum information required in each unit’s matrix
| Component | Information to record |
|---|---|
| Business process and owning unit | Example: scholarship selection and announcement — Directorate of Student Affairs |
| Dataset / data elements | Name, study program, acceptance status, supporting data (list each element separately) |
| Personal data status and classification | General/specific personal data where applicable; Public/Internal/Confidential |
| Purpose and lawful basis for processing | Operational purpose; lawful basis under Article 20 of the PDP Law |
| Publication channel and permitted public data | Website, social media, internal email, or SSO portal; minimum information permitted for disclosure |
| RACI and approval | Business process owner, approving official, Legal/DPO reviewer, publishing team, IT support |
| Retention, RoPA, and evidence | Retention/publication period, RoPA record reference, approval documentation, audit trail |
| Safeguards and incident handling | Access controls, encryption, content takedown, reporting, and escalation following an erroneous publication |
Important distinction: the publication matrix guides unit-level decisions, whereas the Record of Processing Activities (RoPA) records personal data processing activities more comprehensively. They complement rather than replace each other.
Sample matrix entries across directorates
| Process owner | Dataset / activity | Permitted publication (proposed) | Approval and review |
|---|---|---|---|
| Student Affairs | Merit-based scholarship recipients | Name + study program + award, subject to conditions | Program owner; Legal/DPO where specific risks arise |
| Academic Affairs | Student grades | Not for public disclosure; SSO portal | Academic business process owner and service manager |
| Human Resources | Lecturers’ professional profiles | Name + qualifications + position + relevant work contact details, subject to conditions | HR business process owner |
| PuTI | IT service performance reports | Aggregated indicators and summaries without sensitive information | PuTI business process owner; Security where necessary |
7. Who does what? Example RACI for data publication
The RACI assignments below are a recommended model. Final accountability and approval levels must align with the applicable organizational structure (SOTK), YPT rules, and Legal/DPO authority. A business process owner under an internal RACI is not necessarily the same as the legal Personal Data Controller .
| Activity | Business process owner | Legal / DPO | PuTI / Security | Channel administrator |
|---|---|---|---|---|
| Determine purpose and minimum data | A/R | C | C | I |
| Assess lawful basis / special risks | R | C | C | I |
| Establish classification & unit matrix | A/R | C | C | I |
| Approve public-facing content | A | C | C | R |
| Publish approved content | A | I | C | R |
| Secure access, logs, and hosting | C | C | A/R | C |
A = Accountable (decision owner); R = Responsible (implementer); C = Consulted; I = Informed. For legal assessments, decision-making authority remains subject to the formal responsibilities of Legal/DPO.
PuTI’s role: ensure that websites, portals, storage, access controls, logs, application security, and publication takedown processes are secure. The decision on why particular data must be published rests with the business process owner under the approved governance framework.
FAQ: Questions Frequently Asked by University Units
May students’ full names and study programs be published?
Yes, subject to conditions. Publication must have a lawful basis, a clear purpose, use only the minimum necessary data, and receive publication approval from the authorized unit.
Does announcing scholarship recipients constitute a personal data breach?
Not necessarily. An official announcement that complies with legal requirements is not automatically a data breach. However, excessive or unauthorized disclosure may violate personal data protection rules.
May student ID numbers (NIM), academic grades, and mobile phone numbers be announced?
They should generally not be made publicly available. Such individual information should be restricted according to need. Where it is required for academic services, use authenticated internal systems such as SSO.
Who decides whether data may be published?
The business process owner is responsible for determining the purpose, necessity, and scope of publication within their authority. The Legal Division or personal data protection function should be consulted for legal assessment when necessary, while PuTI provides technical security controls.
Must each directorate maintain a data classification and publication matrix?
This is recommended for adoption as a formal obligation. Each directorate should prepare a matrix based on its business processes, covering data types, classification, lawful basis for processing, intended use, publication permissions, distribution channels, and accountable roles. This obligation must be formally approved by the competent university authority.
9. Preventing data leaks and reporting incidents
Store all operational documents and data only through channels approved by the university. Apply the principle of least privilege, MFA, encryption appropriate to the classification, periodic access reviews, and adequate activity logging. Do not publish raw files that still contain Internal/Confidential information or rely on hidden URLs or a noindex tag to keep information confidential.
If information is sent to the wrong recipient, uploaded in error, an account is compromised, or data misuse is suspected, report it promptly through e-Ticket PuTI (SATU). Include the affected system/channel, time, types of data involved, and initial measures taken; avoid sharing sensitive data through uncontrolled reporting channels.
10. Data leakage prevention infographics
The four infographics below are previously published PuTI awareness materials. Use them as reminders of secure practices; for decisions on personal data publication, follow the guidance and business process matrix on this page.
Previous resource: Data Leakage Prevention Infographics (PuTI).
11. Legal basis, internal documents, and next steps
- Law No. 27 of 2022 on Personal Data Protection, particularly Articles 4, 16, and 20 — official text on the Ministry’s legal documentation website (JDIH Komdigi).
- Telkom University Regulation No. PU.018/LGL03/PTI/2025 on Data Leakage Prevention (Articles 4–7 and related provisions).
- YPT Group Personal Data Protection Governance Regulation and applicable implementing provisions/rector’s decisions; use the approved final versions available through official YPT/TelU document channels.
- ISO/IEC 27001:2022: Annex A controls 5.12, 5.13, 5.14, 5.34, and 8.12 as references for information security.
Next steps for every directorate: inventory data by business process → determine classification and lawful basis → prepare a data use/publication matrix + RACI → consult Legal/DPO/PuTI as needed → obtain authorization in accordance with institutional authority → implement, document RoPA, and review periodically. The requirement for a directorate-level matrix must be formally established by the competent university authority before it becomes binding.
This page provides educational guidance and proposed governance implementation measures. If it differs from any duly enacted regulation, the officially applicable regulation prevails. For case-specific or high-risk decisions, seek an assessment from Legal/DPO and the relevant business process owner.