Legal

Data Protection Policy

How we approach data protection as an engineering discipline across client work — not just for this website, but for the platforms and data we build and handle on behalf of healthcare organizations.

Last updated: August 14, 2026

Purpose and scope

This policy describes UIT Software's approach to data protection as it applies to client engagements — the platforms, integrations, and data pipelines we design, build, and sometimes operate for healthcare organizations. It is the operational and engineering counterpart to our Privacy Policy, which covers only how this marketing website itself handles visitor information.

The commitments below describe our general engineering practice and standards. They are not a substitute for a signed data processing agreement, security addendum, or statement of work, and specific regulatory, contractual, or compliance commitments for a given engagement are confirmed directly with each client rather than asserted generically here. For the technical security architecture behind our platforms, see Security & Compliance.

Data minimization

We design systems to collect, process, and retain the minimum data required for a defined purpose. Where a workflow can be built on de-identified, aggregated, or scoped data instead of full identifiable records, we treat that as the default design choice rather than an optimization to consider later. Data models and integrations are scoped to what a feature actually needs, not to whatever a source system happens to expose.

Encryption

As an engineering standard across client projects, we design for encryption of sensitive data both in transit and at rest — using industry-standard transport security for data moving between systems, and encryption of storage layers holding sensitive or regulated data. The specific encryption standards, key management approach, and scope applied to any given system are defined in that project's architecture and can be detailed on request for a specific engagement.

Access control

We build systems around the principle that access to sensitive data should be limited to what a given role or service genuinely requires, not granted broadly by default. In practice this means role-based access control, scoped service credentials, tenant isolation in multi-tenant systems, and audit logging of access to sensitive records, sized to the specific system's risk profile and the client's own access governance requirements.

Data processing agreements

For client engagements that involve processing personal or health-related data on a client's behalf, a data processing agreement or equivalent contractual data-handling terms are available and are put in place as part of the engagement, covering the scope of processing, confidentiality obligations, and each party's responsibilities. If your engagement requires one, raise it with us directly at contact.html and we will work through it as part of scoping the project.

Sub-processor transparency

Where a client project relies on third-party infrastructure or service providers to process data — cloud hosting, for example — we are committed to being transparent with the client about which sub-processors are involved and what role each plays. We do not publish a generic, unconfirmed list of vendors on this page because the actual sub-processors involved vary by project and infrastructure choice; the accurate list for a specific engagement is documented as part of that engagement's contracting and security review.

Breach notification

We are committed to notifying affected clients in a timely manner if we identify a security incident affecting data we process on their behalf, so that they can meet their own notification obligations to regulators, patients, or other affected parties. The specific notification timeline and process for a given engagement are defined in that engagement's contract, reflecting the applicable regulatory requirements and the client's own incident response process — we do not assert a single fixed timeframe here because the correct one depends on the data involved and the jurisdictions in play.

Data residency

UIT Software is based in India, and our default engineering practices are built around that context. Where a client engagement has specific data residency requirements — data that must remain within a particular country or region — that is addressed as part of the architecture and infrastructure decisions for that engagement, not assumed by default. Discuss residency requirements with us early in scoping so the architecture can be designed around them from the start.

Compliance framing

Our engineering practices are designed to align with the general principles found in common data protection and healthcare privacy frameworks — data minimization, access control, encryption, breach response, and accountability. We do not claim GDPR compliance, HIPAA certification, SOC 2 certification, or ISO certification for UIT Software as an organization. Where a specific engagement requires a specific regulatory commitment, certification, or attestation, that is scoped, confirmed, and documented directly for that engagement — talk to us at contact.html before assuming a specific compliance posture applies.

Related pages

For the technical detail behind how we design secure systems, see Security & Compliance. For how this marketing website specifically handles visitor data, see our Privacy Policy and Cookie Policy.

Changes to this policy

We may update this policy as our practices evolve. The date at the top of this page reflects the most recent revision.

Contact

Questions about data protection for a specific engagement, or about this policy generally, can be sent to:

Discuss data protection
for your project.

We'll walk through the specifics for your engagement directly.