Alif Cloud

Legal

Student Data Privacy Addendum

Last updated 2026-07-26 · Effective 2026-07-26

In plain language

This Addendum is for schools. It is the document to send to a board, a procurement reviewer, or a parent who asks what the vendor is allowed to do with student records.

It is a binding part of our agreement with every school, automatically. A school does not need to negotiate or sign anything separate for it to apply.

The short version: the records belong to the school. We hold them, we protect them, we use them only to run the service for that school, and we hand them back or delete them when the school says so.

1. Scope and precedence

This Student Data Privacy Addendum ("Addendum") supplements the Alif Cloud Terms of Use between the school ("School") and TayoPro LLC, a Minnesota limited liability company doing business as Alif Cloud ("Provider", "we"). It applies automatically wherever the School uses the Service to process Student Data, with no separate signature required.

Where this Addendum conflicts with the Terms of Use or the Privacy Policy in respect of Student Data, this Addendum controls. Where a School has signed a separate negotiated data protection agreement with us, that agreement controls to the extent of any conflict.

2. Definitions

  • "Student Data" means personally identifiable information relating to a student or a student's family that the School or its users submit to, or generate through, the Service. It includes education records as defined by FERPA.
  • "Education Records" has the meaning given in 20 U.S.C. § 1232g and 34 C.F.R. Part 99.
  • "De-identified" means information from which all direct and indirect personal identifiers have been removed, and which cannot reasonably be used to identify an individual, whether alone or in combination with other information reasonably available.
  • "Subprocessor" means a third party we engage to process Student Data on our behalf.
  • "Security Incident" means a confirmed unauthorized access to, acquisition of, disclosure of, alteration of, or destruction of Student Data.

3. Ownership and control

The School owns and controls all Student Data. Nothing in our agreement transfers ownership of Student Data to us, and we acquire no rights in it beyond the limited licence needed to provide the Service.

The School is the data controller. We are a processor and service provider acting only on the School's documented instructions. The School determines which data fields to enable, which to require, what to collect, from whom, and for what purpose.

The School is responsible for providing any notice, and obtaining any consent or authorization, that the law requires before collecting Student Data — including notices to parents and guardians and, where applicable, consent under the Children's Online Privacy Protection Act.

4. FERPA school official designation

To the extent the School is subject to FERPA, the School designates Provider as a "school official" with a "legitimate educational interest" in Education Records, under 34 C.F.R. § 99.31(a)(1)(i)(B). Provider accordingly:

  • performs an institutional service or function for which the School would otherwise use its own employees;
  • is under the direct control of the School with respect to the use and maintenance of Education Records;
  • uses Education Records only for the purposes authorized by the School and set out in our agreement;
  • does not redisclose Education Records to any third party except as the School authorizes, as this Addendum permits in respect of Subprocessors, or as the law requires; and
  • restricts internal access to Education Records to personnel with a need to access them for a defined purpose.

Where the School is not subject to FERPA — for example a private religious school that receives no applicable federal funding — the substantive commitments in this Addendum still apply in full. We do not condition them on FERPA coverage.

The School remains responsible for its own FERPA obligations, including its annual notification of rights and its handling of parental requests to inspect and review Education Records.

5. Permitted and prohibited uses

We may use Student Data only to

  • provide, operate and deliver the Service to the School;
  • maintain, support, troubleshoot and secure the Service;
  • prevent, detect and investigate fraud, abuse and security incidents;
  • improve and develop the Service, provided that any use for improvement is limited to what is necessary and does not involve disclosing Student Data outside our permitted processing; and
  • comply with law, or respond to a lawful request from a public authority.

We will not, under any circumstances

  • sell, rent, trade or licence Student Data;
  • use or disclose Student Data for targeted advertising, behavioural advertising, or any advertising purpose, whether on or off the Service;
  • use Student Data to amass a profile of a student, except in furtherance of the School's educational purposes;
  • use Student Data to train machine-learning or artificial-intelligence models that serve anyone other than the School that supplied it;
  • disclose Student Data to a data broker, advertising network, or analytics provider for that provider's own purposes;
  • use Student Data for our own commercial purposes unrelated to providing the Service; or
  • change how we use Student Data in a way that materially reduces the protections in this Addendum without the School's consent.

De-identified data

We may create and use De-identified data to operate, secure, evaluate and improve the Service, and to produce aggregate statistics. We will not attempt to re-identify it, will not disclose it in a form that identifies a School or a student without permission, and will contractually prohibit re-identification by any recipient.

6. Subprocessors

We use a limited set of Subprocessors to deliver the Service. Each is bound by a written contract imposing data protection obligations no less protective than those in this Addendum, and we remain responsible for their performance.

Our current Subprocessors that may process Student Data are:

  • Stripe — processing tuition and fee payments (United States).
  • Twilio — delivering SMS to parents, guardians and staff (United States).
  • Expo — delivering mobile push notifications (United States).
  • Google — calendar and public holiday feeds; analytics only where the School supplies its own tracking identifier.
  • Cloudways — managed application and database hosting (United States).
  • Postmark — delivery of notification and campaign email (United States).

We will give the School at least 30 days' notice before adding or replacing a Subprocessor that processes Student Data, by email to account administrators or by prominent in-product notice. If the School reasonably objects on data protection grounds, it may terminate the affected part of the Service without penalty and receive a pro-rata refund of prepaid fees.

We do not transfer Student Data outside the United States other than as necessary for a Subprocessor listed above to perform its function.

7. Security measures

We maintain administrative, technical and physical safeguards designed to protect Student Data against unauthorized access, disclosure, alteration and destruction, appropriate to its sensitivity. These include:

  • encryption of Student Data in transit using industry-standard TLS;
  • encryption of Student Data at rest using industry-standard encryption, provided at the platform level by our managed hosting provider, Cloudways;
  • one-way hashing of passwords, so that we cannot read them;
  • role-based access control configured by the School, restricting each user to the records their role requires;
  • an emailed verification code when an account is accessed from an unrecognized country or city, and one-time codes for phone-based parent sign-in;
  • an audit log recording which user took which action on which record, and when;
  • restriction of Provider personnel access to those with a need to access, subject to confidentiality obligations;
  • logically separated storage of each School's data, so that one School cannot access another's; and
  • daily automated backups of the application database, held on a rolling cycle.

We will not materially reduce these safeguards during the term. Security is shared: the School must keep credentials confidential, deactivate accounts promptly when staff leave or change roles, and configure permissions on a least-privilege basis.

8. Security incident notification

If we confirm a Security Incident affecting a School's Student Data, we will notify that School without undue delay and in any event within seven days of confirmation, using the administrative contact on the account and, where the incident is significant, by telephone as well.

Our notice will describe, to the extent then known: what happened and when; the categories and approximate volume of Student Data involved; the students or families affected or likely affected; what we have done to contain and remediate it; what we recommend the School do; and a contact for follow-up. We will provide updates as the investigation progresses.

We will cooperate with the School's investigation and will provide the information the School reasonably needs to meet its own notification obligations. The School, as controller, determines whether and how to notify affected individuals, regulators, and others, and is responsible for making those notifications. We will not notify the School's families or a regulator about the School's data without the School's prior written consent, unless the law requires us to.

We will take reasonable steps to remediate the cause and will bear our own costs of investigation and remediation.

9. Requests from parents, students and authorities

Requests from a parent, guardian or student to access, inspect, correct, or delete Student Data must be handled by the School. If we receive such a request directly, we will not respond to it substantively; we will refer the requester to their School and notify the School promptly.

On the School's request we will assist the School in locating, exporting, correcting or deleting Student Data so the School can respond within its own legal deadlines.

If we receive a subpoena, warrant, court order or other legally binding demand for a School's Student Data, we will, unless legally prohibited, notify the School promptly before disclosing anything, so the School may seek a protective order or otherwise respond. We will disclose only what the demand requires.

10. Export, return and deletion

The School may export its Student Data at any time during the term using the Service's export features, and we will provide reasonable assistance on request. Exports are provided in a commonly used, machine-readable format.

On termination, or at any time on the School's written request, we will delete or, at the School's election, return Student Data. We will retain it for 90 days after termination so the School can retrieve it, and will delete or de-identify it promptly after that period.

Deletion extends to copies held by Subprocessors, which we will instruct accordingly. Copies in routine encrypted backups are deleted as those backups age out of their normal cycle, and are not restored to production except as part of a disaster recovery in which case they are re-deleted.

We may retain Student Data beyond these periods only where the law requires, and only for as long as required, after which we will delete it. We will tell the School if this applies.

On request we will provide written confirmation of deletion.

11. Records and assurance

On reasonable written request, and no more than once in any twelve-month period unless a Security Incident has occurred, we will provide the School with information reasonably necessary to demonstrate our compliance with this Addendum, including a description of our security measures, our current Subprocessor list, and responses to a reasonable security questionnaire.

We will cooperate reasonably with a School's own regulatory or funder audit obligations to the extent they extend to us.

12. Personnel

Provider personnel with access to Student Data are subject to written confidentiality obligations that survive the end of their engagement, receive guidance appropriate to their role on handling Student Data, and have their access revoked promptly when it is no longer needed.

13. Term and survival

This Addendum takes effect when the School first submits Student Data to the Service and continues for as long as we hold any Student Data of the School.

Sections 3, 5, 8, 9, 10 and 12 survive termination for as long as we retain Student Data.

14. Contact

Questions about this Addendum, requests for our Subprocessor list, deletion requests, and security questionnaires: privacy@alifcloud.com

TayoPro LLC (doing business as Alif Cloud), 4951 W 77th St Suite 133, Edina, MN 55435