Data processing overview

This page explains Fairhelm's intended approach to contracted data processing. It is not a signed Data Processing Addendum, does not appoint Fairhelm as a processor, and does not create instructions or service obligations by itself.

A production engagement that involves personal data should include a scope-appropriate agreement reviewed against the actual product, data flows, roles, locations, providers, risks, and applicable law.

The parties' roles depend on the facts of the engagement. Where Fairhelm processes personal data for a customer, it intends to act only on documented, lawful instructions and for the agreed service purpose. Fairhelm may act in another role for limited business administration or legal obligations where the applicable agreement and law permit.

The agreement should identify relevant people and data categories rather than rely on a generic list. Depending on the service, these may include institutional contacts, staff, students, parents or guardians, applicants, vendors, operational records, usage events, and support communications.

Sensitive or high-risk data should not be included unless it is necessary, explicitly approved, and protected by controls appropriate to the context.

A signed agreement may define confidentiality, access control, security measures, assistance, audit information, incident communication, subprocessors, transfer arrangements, return or deletion, and end-of-service handling. The exact obligations must match the service actually delivered.

This public page does not promise a particular certification, data location, deletion period, recovery target, or incident-notification deadline.

Customers remain responsible for the lawfulness of their collection and instructions, required notices and permissions, data accuracy, authorized-user administration, role assignments, configuration decisions, and responding to people where the customer holds that responsibility.

Cloud and specialist providers may support a contracted service. The applicable agreement should identify the relevant subprocessors or an update mechanism, the purpose of their processing, and the agreed location or transfer safeguards where required.

No India-only or other residency commitment should be inferred from this public website; residency is an architectural and contractual decision for the specific engagement.

Retention and deletion should follow documented customer instructions, service needs, legal requirements, and technically reasonable backup cycles. Incident responsibilities, contacts, investigation cooperation, and notification expectations should be stated in the signed agreement.

Organizations evaluating a pilot or production engagement may contact hello@fairhelmsystems.com to discuss the actual data flow and the documents required. A final DPA should follow technical discovery rather than precede it with invented assurances.