Privacy Policy — Draft

Operator: [COMPANY LEGAL NAME]; registration number: [REGISTRATION NUMBER]; address: [LEGAL ADDRESS]; privacy contact: [PRIVACY EMAIL]; security contact: [SECURITY EMAIL]; effective date: [EFFECTIVE DATE].

The audited product is a web-based learning management application with global administrator accounts and course-level teacher, teaching-assistant, and student roles.

The final policy must identify [PRODUCT NAME], the legal operator, customer model, and whether the operator or an educational institution decides each use of personal data.

Account data includes IDs, names, email addresses, password hashes, administrator and enrollment roles, password-change state, and timestamps.

Academic and course data includes courses, memberships, assignments, dates, text/link/file submissions, attempt history, grades, feedback, course content, announcements, discussions, quiz questions, answers, results, authors, graders, and timestamps.

File records include names, storage keys, MIME types, sizes, uploader or submitter identity, timestamps, and the uploaded bytes.

No attendance record, payment record, subscription record, external analytics event, advertising profile, AI prompt/output, guardian record, age record, precise location, biometric record, or health-data model was found.

Administrators create user accounts and assign course roles. Teachers and teaching assistants create learning content, assignments, discussions, files, quizzes, grades, and feedback. Students submit work, files, discussion replies, and quiz answers.

The public contact form accepts typed name, institution, work email, and role in the browser, but it prevents submission and does not transmit or store that information.

A production host may create request, device, IP-address, referrer, error, and security logs. The actual fields, provider, purpose, region, and duration need deployment review.

Account and enrollment data authenticate users, select the correct role experience, and enforce administrator and course permissions. Academic records deliver assignments, submissions, quizzes, grades, feedback, course communication, and activity views.

Password-change and session-start data force replacement of administrator-set passwords and invalidate sessions created before a password change.

External marketing analytics, behavioral advertising, email marketing, payment processing, AI training, and automated recommendations are not implemented.

[LEGAL REVIEW REQUIRED] The operator and participating institutions must document the lawful basis or authority for every purpose after jurisdictions, users, and responsibility roles are confirmed.

The application does not store consent records, guardian authority, privacy-notice acceptance, or purpose-specific opt-ins.

Global administrators can view users and rosters. Authorized course staff can view rosters, submissions, grades, feedback, and quiz results. Students can view their own academic records and shared course content. Course files are available to active course members; submission files are limited to the submitting student and authorized staff.

Confirmed runtime components are Auth.js, Next.js, Prisma, PostgreSQL, and the local-disk file-storage adapter. No email, analytics, payment, AI, OAuth, or production object-store provider is integrated.

The active PostgreSQL host is set by secret configuration and was not identified.

Before launch, publish each actual provider, purpose, data, location, retention, and contract only after those facts are verified.

Local Docker PostgreSQL and local-disk file storage are configured for development.

No production database, file, backup, log, support, or disaster-recovery region is confirmed.

[LEGAL REVIEW REQUIRED] Add [PRIMARY REGION], [BACKUP REGION], [REMOTE ACCESS LOCATIONS], and any transfer mechanism only after vendor and jurisdiction review.

Records include creation, update, submission, and grading timestamps. Versioned assignment and quiz attempts preserve academic history, and restrictive database relations prevent some hard deletions.

No account deletion, data export, or retention workflow is implemented. There is also no approved expiry job, backup overwrite period, legal-hold process, or deletion-verification workflow.

Insert [ACCOUNT RETENTION], [ACADEMIC RECORD RETENTION], [FILE RETENTION], [LOG RETENTION], [BACKUP RETENTION], and [DELETION TIMELINE] only after owner and legal approval.

The product has no user-facing access, correction, export, restriction, objection, or account-deletion request workflow. A signed-in user can change a known password, which is not a complete privacy-rights process.

[LEGAL REVIEW REQUIRED] The final policy must identify applicable rights, identity verification, academic-record exceptions, response rules, appeal routes, and [PRIVACY REQUEST METHOD].

Auth.js uses cookie-based JWT sessions for sign-in and protected access. The portal also stores the eduflow-rail sidebar preference in local storage until it is changed or browser storage is cleared.

Exact authentication-cookie names, attributes, scope, and duration require a deployed runtime capture because they are not explicitly configured.

No external analytics, advertising, or cross-site tracking SDK was found.

See the Cookie and Browser Storage Policy. Any future non-essential tracking needs approval and an updated notice before use.

Implemented controls include bcrypt password hashing, a 15-character password minimum, generic login errors, forced temporary-password replacement, password-change session invalidation, server-side role checks, scoped queries, input validation, sanitized Markdown, immutable submitted attempts, path-contained storage keys, and private attachment downloads.

Launch-readiness gaps remain across authentication hardening, security operations, platform defenses, production file handling, and infrastructure resilience. Exact findings stay in the internal security review rather than this public policy summary.

A published policy must describe only controls operating in the selected production environment and cannot guarantee absolute security.

The product is designed for education and includes student academic records.

It has no age gate, date of birth, guardian relationship, parental authorization, child-specific notice, or safeguarding-report workflow.

[LEGAL REVIEW REQUIRED] Confirm [MINIMUM AGE], target education levels, institution or guardian authority, direct-signup rules, and child-safety obligations before live use.

Privacy requests: [PRIVACY EMAIL OR PORTAL]. Operator: [COMPANY LEGAL NAME], [LEGAL ADDRESS], [PHONE IF REQUIRED]. Add any required representative, regulator, complaint route, and response expectations only after jurisdiction review.

The application does not record policy versions, acceptance, or notifications for policy changes.

The final process must define [NOTICE METHOD], [NOTICE PERIOD], effective-date rules, version history, and whether renewed acceptance is required.

The product does not implement sale/share opt-outs, sensitive-data limitation requests, automated-decision appeals, or universal privacy signals.

[LEGAL REVIEW REQUIRED] Final positions on sale or sharing, advertising, de-identified data, automated decisions, third-party links, corporate changes, and governing law must be approved. Do not state absolute restrictions until leadership, contracts, and technical controls support them.