1. Data Controller
The data controller determining the purposes and means of ProgExam's personal data processing activities is:
| Name | Assoc. Prof. Salih Bayar |
|---|---|
| Platform and website | ProgExam — https://progexam.com |
| Contact and KVKK request email | info@progexam.com |
2. General Processing Principles
Personal data is processed lawfully and fairly, kept accurate and up to date where necessary, used for specified, explicit and legitimate purposes, limited and proportionate to those purposes, and retained for the period prescribed by law or required by the relevant processing purpose.
3. Categories of Personal Data
The data processed depends on the feature, user role, course and activity. Not every category applies to every user.
| Category | Data that may be processed |
|---|---|
| Identity, profile, account and account linking | Name, username, email address, Moodle user ID, student/staff number, profile information, role, permissions, account status and course/group memberships. When a compiler account is linked, the browser visitor ID, Moodle user ID, connection-token hash, token creation/expiry/use status and Moodle session security key are processed. Passwords are stored as password hashes rather than plain text. |
| Sessions and security | Moodle and PHP session information, login/logout and failed-login records, IP address, User-Agent, accessed activity, transaction time, application and security logs. |
| Education and assessment | When a user is enrolled, course/group membership is processed; when a quiz or exam is taken, attempt, answer, timing, status, grade and feedback are processed; when an assignment is submitted, online text, submission time, uploaded file, grade and assessment data are processed. |
| Attendance and quick attendance | When attendance is used, student, activity and session IDs, attendance status, remarks, recording user/time, IP address and QR/rotating-password verification data are processed. |
| Programming questions and execution | When a programming question or compiler is run, source code, stdin, programming language, test results, compiler/runtime result, stdout, error output, duration, status and assessment result are processed. Source code, stdin and execution parameters are sent to CodeRunner/Jobe. |
| Source-code similarity and academic-review data | When an authorized teacher submits a quiz activity for similarity review, completed source-code answers to supported CodeRunner questions within that quiz are compared on a per-question basis. Data processed may include Moodle user and quiz-attempt IDs, course, quiz, question and activity IDs, programming language, pseudonymous submission ID, source code, comparison pairs, similarity scores, highest match, the teacher-defined review threshold, review status, JPlag report, scan status, technical errors, timestamps, report-integrity checksum and webhook-delivery records. The JPlag service does not decide that a student has passed, failed or committed plagiarism; it produces technical similarity results only. Academic evaluation remains the responsibility of the authorized teacher. |
| Live pair programming and AI feedback | When live pair programming is enabled and used, student ID, problem name/statement, source code, input, output, code version, last editor, editor role and timer state are processed. When experimental AI code feedback is enabled and used, student, course/activity, quiz attempt, question ID, code snippet, flag reason, matched phrase, review status and timestamps are processed; this integration may be changed or removed. |
| Compiler use | Browser visitor ID/hash, linked Moodle user ID/username, IP address, country code, language, duration, status code, first/last-seen time, free-use and rate-limit counters, limit events and usage logs. |
| Packages, credits and payments | Full name, email, Moodle user ID, internal payment ID, package and validity period, credit entitlement/use, CPU limit, feature entitlement, payment status, and Lemon Squeezy order, customer-email and variant references. |
| Communications, support and invitation tracking | When a contact/support form is submitted, name, email, message and requester IP are processed. When a payment notification is submitted, name/organization, email, amount, free-text note and IP are processed. When an invitation tracking link is opened, recipient email, opening time, IP address and User-Agent are recorded. |
| Files, documents and MÜDEK | Assignment/course files; MÜDEK programme, course and accreditation documents; teacher name; student number, first/last name and scores; question/result tables, opinions, descriptions and other free text. |
| Meetings and interviews | Where Zoom or OpenMeetings is enabled and used: name, username, email, Moodle ID, profile-image URL, role/membership, meeting/room/timing, uploaded files, participation and recording information. |
| Cookies and browser storage | Moodle session/preference cookies, PHP session cookie, compiler localStorage visitor IDs, theme/mobile preferences and tab-scoped sessionStorage values. |
| Analytics, page visits and remote resources | When the user enables optional analytics technologies, Google Analytics may process page-view and interaction events, page URL and title, referrer, language, online identifiers, cookies and basic device, browser and request information. Analytics technologies are disabled by default. When Cloudflare, CDN, remote icon or image, or exchange-rate resources load, IP address, User-Agent, referrer and requested-resource information may be sent to the relevant provider. |
| Public statistics | User, course/challenge, examination-attempt and compilation totals are published from a summary table/application cache as numeric totals only. The public endpoint does not return names, emails, Moodle user IDs, source code or individual assessment results; the source records used to create totals may still relate to identified or pseudonymous activity. |
| Affiliate and upgrade interactions | When an affiliate resource or package-upgrade element is used, visitor-ID-linked upgrade/limit counters and affiliate preferences may be processed. When a remote affiliate link is clicked, the destination provider processes IP address, User-Agent, referrer, destination link and its own cookies/identifiers. |
| Backups, logs and temporary files | Moodle and compiler logs, payment and webhook error logs, JPlag scan and webhook-delivery records, JPlag source-code scan archives and reports, account/course/file records contained in backups, temporary Jobe and JPlag workspaces, and session-associated SQLite content used by SQL exercises. |
Free-text fields, source-code comments and uploaded documents may contain additional personal data about the user or other people.
4. Processing Purposes
- Managing accounts, authentication, sessions, roles, permissions, courses and groups;
- Operating quizzes, exams, programming questions, assignments, attendance, grading, feedback and academic reports;
- Identifying source-code similarities between programming answers on a per-question basis, providing authorized teachers with comparison results and detailed JPlag reports, supporting academic-integrity review, and directing potential similarities to human review;
- Operating live pair programming and AI code feedback where enabled;
- Compiling/executing source code, producing results and applying resource or usage limits;
- Linking compiler visitors to Moodle accounts and managing credits, packages and entitlements;
- Matching payment/order records and providing purchase support;
- Conducting MÜDEK and other accreditation work;
- Responding to contact and support requests;
- Recording invitation opens, publishing public usage totals, and managing affiliate/upgrade interactions;
- Maintaining security, preventing abuse and unauthorized access, and troubleshooting errors/performance;
- Developing, maintaining and backing up the platform and ensuring service continuity;
- Providing meetings, interviews, analytics and AI Help where enabled;
- Meeting legal obligations and properly issued authority requests, and establishing, exercising or protecting rights.
5. Legal Grounds
Depending on the activity, personal data is processed under the conditions in Article 5 of Law No. 6698, including where processing is expressly provided by law; directly related to establishing or performing a contract; necessary for the controller’s legal obligation; necessary to establish, exercise or protect a right; or necessary for legitimate interests without harming fundamental rights and freedoms. Processing requiring explicit consent is handled separately from this information notice.
6. Recipients and Role-Limited Access
| Recipient/access group | Scope and purpose |
|---|---|
| Authorized teachers and MÜDEK personnel | Access limited to the relevant course, student, quiz, examination, assignment, grade, feedback, source-code similarity result, matched student/submission information, JPlag report and accreditation work. |
| Administrators and support personnel | Role-limited access for user administration, security, backups, system operation and technical support. |
| Authorized developers | Authorized software developers may access personal data only to the extent necessary for platform development, maintenance, security review, and troubleshooting. Such access is subject to authorization controls, and synthetic or anonymized data is used wherever reasonably possible. |
| Lemon Squeezy | On purchase, purchaser email, full name, Moodle user ID, internal payment ID and package data are sent to create checkout and match the order. Checkout/order/customer/variant/status data is returned. No code evidence shows card details reaching ProgExam; the provider processes card data directly. |
| Gmail/SMTP email service | Recipient/sender addresses and message content are transmitted for account/system messages and contact, support or payment notifications. |
| Cloudflare Turnstile | CAPTCHA response and requester IP are transmitted for bot/abuse checks when a contact or payment-notification form is used. |
| Google Analytics | Google Analytics is loaded only when the user enables optional analytics technologies. Where enabled, page-view events and configured interaction events may be sent. Event parameters may include page or programming language, interaction type and related technical labels. Application code does not directly add names, email addresses, Moodle user IDs or compiler visitor UUIDs to analytics calls. Google may nevertheless process online identifiers, cookies, IP address and basic device, browser and request information on the provider side. |
| ip-api.com | When a compiler run is logged, the public IP address is sent to obtain a country code. |
| Jobe and local Ollama | Jobe processes source code, stdin, language and parameters for execution. When AI Help is requested, local Ollama processes limited portions of source code, stdin and compiler output. |
| Zoom/OpenMeetings | Zoom, OpenMeetings, or similar remote-meeting services process personal data only when the relevant feature is enabled and used. These integrations remain experimental and may be changed or removed. ProgExam’s intended architecture is to operate meeting and interview services within locally controlled infrastructure wherever reasonably possible. |
| CDN, exchange-rate and affiliate providers | External style, script, icon or image requests are sent to the relevant CDN on page load; the Frankfurter exchange-rate request is made when the cost calculator loads; and a clicked affiliate link sends the link and ordinary request data to Amazon or the other named destination provider. |
| Locally hosted JPlag similarity service | For a review initiated by an authorized teacher, the relevant CodeRunner source code, pseudonymous submission identifiers, programming language and technical scan options are transmitted to the Java-based JPlag service controlled by ProgExam. The service produces similarity results and a report; the results are returned to the Moodle plugin through a signed webhook and authenticated API connection. Disclosure of academic similarity results to parties outside the service is not an ordinary part of this processing flow. |
| Authorities and professional advisers | Limited disclosure where required by law, a properly issued official request, a dispute, a security event or necessary professional support. |
7. International Transfers
During normal operation, ProgExam does not bulk-export the entire Moodle database, every course record, or all student assignment and examination submissions to third-party services. External transfers are limited to the data needed for the specific feature being used; each provider receives different data.
When a compiler package is purchased through Lemon Squeezy, full name, email address, Moodle user ID, internal payment ID and selected package data are sent for payment and access activation. Payment-card and payment-instrument data is collected directly by Lemon Squeezy on its checkout page; the reviewed ProgExam flow contains no operation that transmits card numbers to or stores them in ProgExam.
When email is sent, sender/recipient email addresses and message content are processed by Gmail/SMTP. When a contact or payment-notification form is used, Cloudflare Turnstile processes the verification token, IP address and basic request information for bot/abuse checks. When compiler use is logged, the IP address is sent to ip-api.com for a country-code lookup. When remote CDN, icon, image or exchange-rate resources load, or an affiliate link is opened, ordinary browser/request data is processed by the relevant provider.
When the user enables optional analytics technologies, Google Analytics may process page-view and interaction events, page URL and title, referrer, language, online identifiers, cookies and basic device/browser information. Analytics calls do not directly send names, email addresses, Moodle user IDs or compiler visitor UUIDs. Google’s service infrastructure may process data outside Türkiye or across multiple regions. Where analytics permission is not given, Google Analytics is not loaded and no new analytics events are sent through this integration.
Zoom, OpenMeetings, or similar remote-meeting services process meeting, user, participation, file and recording data only when the relevant feature is enabled and used. These integrations are experimental and may be changed or removed. ProgExam’s intended direction is to operate meeting and interview services within locally controlled infrastructure wherever reasonably possible; this does not mean that local meeting infrastructure is already fully implemented.
Transfers to providers processing data outside Türkiye or across multiple regions are carried out under the applicable transfer conditions and safeguards in Article 9 of Law No. 6698.
8. Collection Methods
Data is collected electronically or by non-automated electronic means through Moodle/ProgExam account creation or administrator entry, profile and course/group enrolment, quiz/exam/assignment/programming submissions, CodeRunner source-code similarity scans initiated by authorized teachers, JPlag comparison results and reports, and webhook-processing records, attendance and live pair programming, file uploads, MÜDEK documents, compiler executions, package purchases and payment webhooks, contact/support forms, invitation-tracking links, teacher grading/feedback, affiliate/upgrade interactions, cookies and browser storage, analytics/third-party resources loaded during page visits, application/server logs, and enabled Zoom/OpenMeetings, AI Help or AI code-feedback features.
9. Cookies, Sessions and Browser Storage
| Technology | Purpose and duration |
|---|---|
| Moodle session cookie | Maintains an authenticated session for the browser session or the period configured in Moodle. |
| Moodle preference and username cookies | Where enabled, remembers the username and interface preferences for the period configured in Moodle. |
| PHP/application session | Supports functions such as AI Help rate limiting and association with an SQL exercise file for the PHP session period. |
| Compiler visitor identifiers |
Pseudonymous browser visitor identifiers are stored in
localStorage to enforce code-execution
limits, prevent limit circumvention, detect misuse and
associate compiler activity with the correct visitor or
authenticated user. These records may remain until
removed by the service or the user clears browser
storage.
|
| Theme and interface preferences |
Compiler, desktop and mobile appearance preferences are
stored in localStorage until the preference
is changed or browser storage is cleared.
|
Compiler sessionStorage |
Stores technical values that reduce repeated limit logging for the duration of the browser-tab session. |
| Cookie preference record | Stores the user’s decision to accept or reject optional analytics technologies, together with the preference version and selection time. It may remain until the preference is changed, the policy version is replaced or browser storage is cleared. |
| Google Analytics | Google Analytics is loaded only when the user enables optional analytics technologies. Where enabled, page-view events and configured interaction events may be sent. Event parameters may include page or programming language, interaction type and related technical labels. Application code does not directly add names, email addresses, Moodle user IDs or compiler visitor UUIDs to analytics calls. Google may nevertheless process online identifiers, cookies, IP address and basic device, browser and request information on the provider side. |
| Cloudflare Turnstile | The provider script loads when a protected form page is opened. When the form is submitted, the verification token, IP address and basic request information are processed for security and bot-prevention purposes. |
Necessary technologies are used to maintain sessions, authenticate users, protect service security, enforce compiler usage limits, prevent abuse and remember interface preferences explicitly selected by the user.
Optional analytics technologies such as Google Analytics are disabled by default and are enabled only through an active user choice. Refusing analytics does not prevent use of ProgExam, Moodle or the compiler.
Further information about the technologies used, their categories, purposes, approximate durations and preference controls is available in the Cookie Policy.
10. Automated Processing and Code Execution
For compiler and programming-question use, source code, stdin, language and execution parameters are written to temporary Jobe files, compiled/executed under CPU, memory, process, file and output limits, and returned to the user. Jobe workspaces are normally deleted when execution completes.
When AI Help is requested, limited portions of source code, stdin and compiler output are sent to the locally configured Ollama model to produce technical assistance. Automated quiz/programming results support teaching activity; where necessary, final academic assessment is carried out by the authorized teacher.
Source-code similarity review is performed on a per-question basis for supported CodeRunner questions in the quiz activity selected by an authorized teacher. Source-code answers to the same question are tokenized and compared by the locally hosted Java-based JPlag service according to the syntax of the relevant programming language. The system produces technical similarity scores and a detailed comparison report for pairs of submissions.
A JPlag result is not, by itself, a finding of plagiarism, a disciplinary decision, a grade or an automatic failure decision. The service produces a similarity measurement only. Moodle may use the threshold selected by the teacher to display a result as requiring review or being below the threshold. The final assessment is made by the authorized teacher after considering the question structure, shared starter code, unavoidable algorithmic similarities, explanations and other relevant academic circumstances.
Scans are processed asynchronously. When processing reaches a terminal state, the JPlag service sends a signed webhook notification, and Moodle obtains the results and report from the authenticated service endpoint. Webhook-delivery state, retry count, technical error codes and timestamps may be recorded for service security, troubleshooting and processing integrity.
11. Retention and Deletion
Personal data is retained for as long as necessary for the relevant processing purpose, the operation of education and assessment processes, the resolution of objections and disputes, information security, and compliance with applicable legal obligations. Moodle account, course, assessment, submission, grade, attendance, live-pair and accreditation records are retained for the relevant educational or institutional record cycle and the associated objection, audit and legal-obligation periods. Security, application, invitation-open, AI-feedback, affiliate/upgrade and compiler logs are retained only for as long as necessary for security, abuse prevention, troubleshooting and audit purposes. Payment and package records are retained for the period required for service support, disputes and applicable financial obligations. Backups are deleted or overwritten under the defined backup and rotation schedule.
Moodle scan records, per-student similarity results, comparison pairs, uploaded scan archives and JPlag reports used for source-code similarity scans are retained for as long as necessary for the relevant quiz, educational and academic-review process, potential objections and applicable legal obligations. JPlag technical-processing, webhook-delivery and error records are retained only for as long as necessary for service security, troubleshooting, processing integrity and audit purposes.
Account-link tokens expire after 10 minutes. Pending compiler payment rows may be cleaned after five full days during later system requests. Temporary Jobe workspaces are normally deleted when processing finishes; SQL exercise files are removed on user reset or the applicable technical cleanup process. Data no longer required is deleted, destroyed or anonymized in accordance with applicable law and technical capabilities.
Temporary workspaces created during a JPlag scan are removed when processing completes or when the technical cleanup task runs. Uploaded scan archives, generated reports and database result records are removed separately in accordance with the defined retention policy. Temporary files left by failed or interrupted processing are cleaned by periodic technical-cleanup processes.
12. Rights Under Article 11 of Law No. 6698
Data subjects may ask whether personal data is processed; request information; learn the purpose and whether data is used accordingly; learn domestic or overseas recipients; request correction; request deletion/destruction under Article 7; request notification of correction/deletion to recipients; object to an adverse result produced solely by automated analysis; and claim compensation for damage caused by unlawful processing.
13. Request Procedure
Requests may be submitted to the data controller through the following channels, together with sufficient information to verify the applicant’s identity and clearly explain the request:
| Method | Address | Submission instructions |
|---|---|---|
| Email address registered with ProgExam or an appropriately signed electronic communication | info@progexam.com | To help ProgExam identify and route the request promptly, the subject line should state “KVKK Data Subject Request”. If ordinary email is used, it must be sent from the email address previously provided to and registered with ProgExam. |
The subject label helps separate the request from ordinary support messages and route it promptly. Its absence will not by itself prevent assessment where the message content clearly constitutes a request under KVKK.
Requests are concluded free of charge as soon as possible and no later than thirty days, depending on their nature. Where the operation creates an additional cost, a fee may be charged in accordance with the tariff determined by the Turkish Personal Data Protection Board.
Information to include in an email request
- Full name;
- For Turkish citizens, Turkish identity number; for foreign applicants, nationality, passport number or available identity number;
- Address for service of notices;
- Available telephone number and contact email address;
- The KVKK right being exercised and a clear description of the request;
- Relevant supporting information or documents, such as the applicable account, course, examination, transaction or record.
Where a request is submitted on behalf of another person, evidence of representation, guardianship, custody or other authority may be required.
Only information needed for the request should be submitted. Applicants should not include Moodle passwords, payment-card information or unrelated sensitive documents.
14. Changes and Effective Version
This notice may be updated when ProgExam’s personal-data processing activities, technologies, services or applicable legal requirements change. The current version is published at https://progexam.com/privacy/.
Depending on their nature and impact on users, material changes may also be announced through the website, Moodle, an in-platform notice, a login-screen notice or another available and appropriate communication method. ProgExam does not undertake to send an automatic email for every change to this notice.
Effective date: 23 July 2026
Version: 1.0