SIAKAD — Academic information system (Laravel)
An academic information system holds a student’s record for years: identity, courses, grades, transcripts. It is operated by the institution, which is the data controller and is bound by its own academic and record-keeping rules.
SIAKAD is software that an organization installs and runs on its own infrastructure. The institution operating a given installation decides what data is entered into it and is the data controller for that installation. This page documents what the application itself collects and processes by design; it is the reference policy for the software, and an operator may publish additional terms on top of it. As the developer, I have no access to any production database unless an operator explicitly grants it for maintenance.
| Data | Why |
|---|---|
| Student identity | Student number, name, date and place of birth, gender, address, phone number, email, and photo — the academic record and identity documents such as transcripts require them. |
| Lecturer and staff identity | Staff number, name, contact details, and department. |
| Academic data | Course registration (KRS), class schedules, attendance, grades, GPA, and academic status. |
| Documents | Generated transcripts and grade reports (KHS) in PDF form. |
| Accounts | Usernames, hashed passwords, and role assignments. |
| Technical logs | IP address, user agent, and action timestamps — for audit and troubleshooting. |
None. The system runs on the institution’s own server. PDF generation happens server-side, with no external document service, analytics, or advertising involved.
The application uses cookies only for functionality:
There are no advertising cookies, no third-party analytics or tracking pixels, and no cross-site profiling. Clearing cookies simply logs you out.
Academic data is shared inside the institution as roles allow, with the student themselves, and with external parties (accreditation bodies, government reporting, scholarship providers) where the institution is required or authorised to report. It is never sold.
Academic records are retained according to the institution’s archival obligations — transcripts and graduation records are typically kept permanently. A request to erase them can be refused where retention is a legal or academic obligation; a request to correct inaccurate data will always be considered.
The application applies standard protections: passwords are stored as one-way hashes (never in plain text), access is limited by role, and all traffic between client and server is expected to run over HTTPS/TLS.
No system is perfectly secure. Server hardening, backups, and access management for a live installation are the responsibility of the organization operating it.
The system is used in higher and secondary education. Where a student is a minor, the institution handles consent through the parent or guardian; students never register themselves without institutional enrolment.
You have the right to ask for access to, correction of, or deletion of your personal data, and to object to certain processing.
Because your data lives in the installation run by the organization you deal with, address those requests to that organization first — they hold the data and can act on it. If you cannot reach them, or you believe the application itself is at fault, contact the developer at mhdlutfidev@gmail.com and I will assist technically.
If this policy changes, the “Last updated” date at the top of this page will be revised. Material changes will be reflected in the application release notes.
Questions, complaints, or privacy requests about this application:
I aim to respond within 7 business days.