Requirements for data SchoolSync may handle later.

1. Data roles must be agreed

Before a pilot, the school and SchoolSync must identify who determines the purposes and means of each processing activity, who acts on instructions, and which providers participate. The answer may differ for attendance, support, billing, product security, communications, and platform administration. Those roles must be reflected in the school agreement and data-processing agreement.

2. Child and guardian information

• Collect only fields required for a documented school purpose.
• Link guardian access to an explicit student relationship and approved permissions.
• Limit staff and teacher access by school, campus, class, role, and task.
• Avoid advertising profiles, public rankings, or automated disciplinary decisions using children's data.
• Define notices, parent or lawful-guardian participation, correction, access, grievance, retention, and deletion processes with legal review.

3. Staff biometrics

Face-based attendance is a confirmed product direction and a high-sensitivity workflow. Before activation, SchoolSync and each participating school must document:

• the attendance purpose and approved legal and operational basis;
• the notice shown before enrollment and the evidence retained;
• a suitable non-biometric attendance alternative;
• whether raw images are retained and why;
• template protection, key ownership, access, model version, threshold, and matching boundary;
• false-acceptance and false-rejection testing on representative people, lighting, devices, and conditions;
• retry, manual review, correction, incident, re-enrollment, exit, retention, and deletion procedures.

A failed or uncertain face match must not automatically be treated as misconduct.

4. Attendance and device records

Attendance events should identify the school, campus, subject, device, capture time, receipt time, method, processing result, and idempotency key. Corrections and exceptions should remain attributable. Device registration, loss, revocation, software updates, offline queues, clock drift, conflict resolution, and local-data minimization require operational procedures.

5. Fees, expenses, and salary

Financial records require role scope, transaction integrity, sequential receipt decisions, approval rules, reversal instead of silent rewriting, reconciliation, export controls, and an append-only audit history. Thermal printing and email delivery must originate from the same finalized receipt. Salary records must limit access and preserve calculations, approvals, disbursement references, slips, adjustments, and reversals.

6. WhatsApp and email communication

Before dues alerts or other messages are enabled, the parties must define approved recipients, templates, variables, purposes, preferences, opt-outs, protected links, provider terms, costs, rate limits, batch approval, delivery webhooks, retries, incident response, and retention. Sensitive information should be minimized in message bodies.

7. Imports, exports, and files

Imports should use versioned templates, safe file checks, a dry run, row-level errors, duplicate rules, explicit commit, and an import history. Exports should be permissioned, scoped, protected, expiring where appropriate, and audited. Files require validated type and size, safe names, malware checks where appropriate, authorized object access, retention, and deletion.

8. Security requirements

• Server-enforced tenant, campus, role, and record boundaries.
• Secure authentication, session rotation, revocation, and stronger controls for privileged roles.
• Encryption in transit and appropriate protection at rest with documented key ownership.
• Secrets outside source code and client bundles.
• Rate limits, input validation, safe database access, signed provider callbacks, and idempotent high-value operations.
• Redacted logs, security monitoring, dependency and secret scanning, incident response, and time-limited support access.
• Tested backups and restoration with production and development data separated.

9. Retention, return, and deletion

A written schedule must cover profiles, enrollments, attendance events, daily registers, biometric templates and images, financial records, salary, communications, provider logs, imports, exports, files, support records, security logs, backups, and legal holds. School exit must include export, return, account closure, deletion responsibilities, backup expiry, and evidence.

10. Requests and incidents

The school agreement must allocate responsibility for identity verification, access, correction, deletion, withdrawal, grievance, and communication with affected people and authorities. Incident roles, severity, containment, evidence preservation, notification decision, timelines, and post-incident work must be agreed and tested.

11. Evidence before public claims

SchoolSync will not describe the application as compliant, certified, India-hosted, encrypted, secure, audited, or fully offline-capable until the exact claim is supported by implementation, providers, contracts, tests, policies, and operational evidence.

12. Contact

Questions about these planned safeguards may be sent to vyapartechstudio@gmail.com. Do not include student or sensitive school data.

Planning references: Digital Personal Data Protection Act, 2023, Digital Personal Data Protection Rules, 2025, and Information Technology Act, 2000. Application and phased commencement require qualified legal review.