Follow us on
+91 7065013200 support@dataconsultant.in
Hire Data Expert
Skip to main content
Trust Center · Data Privacy

Privacy-aware data consulting starts with clear purpose, limited use, and shared responsibility.

This page explains our approach to handling personal and business information across data consulting, analytics, business intelligence, engineering, cloud, AI, reporting, automation, and managed-data engagements.

Submit a Privacy Enquiry Review the data lifecycle

This is a transparency overview, not a legally binding privacy notice or legal advice. Engagement-specific terms may define additional responsibilities.

Executive summary

Our privacy approach is shaped by the engagement, the data, and the parties’ roles.

Privacy requirements are not identical across every project. A website enquiry, a dashboard implementation, a cloud-data migration, an AI prototype, and an ongoing managed-data team can involve different information, purposes, legal roles, platforms, access patterns, and retention needs.

  • Clarity: define the purpose, data types, roles, systems, and expected outputs before material processing begins.
  • Proportionality: use information that is relevant to the agreed objective and reduce unnecessary exposure where practical.
  • Accountability: document important decisions, assumptions, limitations, access needs, and close-out requirements.
Information categories

Information that may be collected or received

The information involved depends on how someone interacts with us and what a client chooses to include in an agreed engagement.

Contact and account information

Names, business contact details, roles, account identifiers, communication preferences, and information needed to manage an enquiry or client relationship.

Engagement and commercial information

Project requirements, proposals, contracts, statements of work, billing details, procurement records, service communications, and delivery documentation.

Client-provided project data

Datasets, reports, dashboards, schemas, source extracts, model inputs, technical logs, or other materials supplied for an agreed consulting purpose.

Website and device information

Browser, device, referral, page-interaction, cookie, and similar technical information where collected through our website or approved digital services.

Communications and support records

Emails, meeting notes, support requests, feedback, approvals, decisions, and records that help us coordinate and evidence project delivery.

Security and access information

Authentication, access, audit, incident, or system-administration records where applicable to the service environment and permitted by contract or law.

Purposes of processing

Information should have a defined and explainable use.

We seek to connect collection and use to a practical business, service, legal, security, or administrative purpose. Additional uses should be assessed rather than assumed.

Why this matters: project teams can make better decisions about fields, access, environments, suppliers, and retention when the purpose is specific.

  1. Responding to enquiries and evaluating whether we can support a requested service.
  2. Scoping, contracting, delivering, managing, and improving agreed consulting or managed-service engagements.
  3. Providing analytics, data engineering, BI, AI, cloud, database, reporting, automation, or governance work requested by a client.
  4. Operating our website, maintaining business records, supporting users, and protecting systems and accounts.
  5. Meeting accounting, tax, legal, regulatory, dispute-management, or contractual recordkeeping needs where applicable.
  6. Communicating relevant service information or marketing where permitted and subject to available choices.
Data minimisation and lifecycle

A practical privacy lifecycle for consulting work

The lifecycle below shows how purpose, minimisation, access, retention, and close-out decisions can be considered throughout an engagement.

STEP 01

Define the purpose

We clarify what information is needed, why it is needed, who will use it, and which deliverables or decisions it supports.

STEP 02

Limit collection

We seek to use the minimum practical information for the agreed scope, favouring masked, sampled, aggregated, or synthetic data where suitable.

STEP 03

Control access and use

Access and processing arrangements are determined by project role, client instructions, approved systems, and engagement-specific requirements.

STEP 04

Review retention

Retention needs are considered against delivery, support, contractual, legal, financial, and dispute-management requirements.

STEP 05

Return, delete, or retain

At the appropriate stage, information may be returned, deleted, anonymised, or retained where a documented need or obligation applies.

Lawful and transparent handling

Roles, instructions, and lawful grounds should be clear.

Privacy responsibilities depend on who decides why and how personal information is processed. For project data, the client may determine the purpose and key means, while we act within documented instructions. For our own business administration, we may make separate decisions about processing.

  • Define controller, processor, independent-controller, or other relevant roles in the appropriate documents.
  • Identify the applicable lawful ground or authorisation before relying on personal information.
  • Use notices, contracts, project records, and escalation routes to explain material processing.
Retention and deletion

Retention should reflect a documented need—not indefinite convenience.

Project information may need to remain available during delivery, review, support, transition, invoicing, audit, legal, or dispute periods. The relevant contract or retention schedule should define exact expectations wherever possible.

  • Identify operational, contractual, legal, financial, and backup dependencies.
  • Agree return, deletion, anonymisation, archive, or transition steps at close-out.
  • Document exceptions where immediate deletion is not feasible or permitted.
Project-specific privacy responsibilities

A shared-responsibility view for client engagements

This matrix is a planning aid. The applicable agreement, law, project design, and actual roles take precedence.

Topic Client responsibility Our approach Shared action
Purpose and lawful basis Confirm why project data is being used and that the client is authorised to provide it. Use information for the agreed service purpose and seek clarification where instructions appear incomplete or inconsistent. Record scope, roles, dependencies, and material changes.
Data selection and minimisation Avoid supplying unnecessary, excessive, or unrelated personal data. Request only information reasonably required and suggest lower-risk alternatives where practical. Review fields, samples, environments, and access before delivery work begins.
Accuracy and quality Provide accurate source information, definitions, and relevant context. Apply agreed validation, transformation, documentation, and quality checks without treating source data as inherently accurate. Resolve anomalies, assumptions, limitations, and ownership of corrections.
Rights and individual requests Lead responses where the client controls the data and determines the purpose of processing. Provide reasonable contractual assistance where applicable and within the agreed role and scope. Use a documented contact and escalation path.
Retention and closure Confirm required return, deletion, archive, or transition instructions. Apply agreed close-out steps subject to technical, legal, contractual, and backup considerations. Document exceptions, dependencies, and completion evidence where required.
Privacy by design

Privacy considerations for data, analytics, cloud, and AI delivery

Privacy by design is not a single control. It is a set of practical decisions that should be revisited as data, architecture, users, outputs, or purposes change.

Purpose and field review

Challenge whether each requested data field, identifier, feature, or output is necessary for the defined business objective.

Lower-identification options

Consider masking, tokenisation, aggregation, pseudonymisation, sampling, or synthetic data where these approaches remain useful for the task.

Environment separation

Where applicable, distinguish development, test, demonstration, and production uses and avoid moving live personal data unnecessarily.

AI data-use review

Clarify model purpose, data provenance, permitted uses, human review, output limitations, and whether personal or sensitive data is appropriate.

Role-based participation

Limit project access to relevant personnel and document responsibilities across client, consulting, cloud, platform, and specialist teams.

Decision and limitation records

Capture assumptions, exclusions, retention decisions, known data-quality issues, and material privacy dependencies in project documentation.

Data subject and client rights

Requests should follow a verified and role-aware process.

Available rights depend on applicable law, the nature of the information, our role, exemptions, and identity verification. Where a client controls project data, the client may need to lead the response.

  • Access to personal information, subject to applicable law and identity verification.
  • Correction of inaccurate or incomplete personal information.
  • Deletion or restriction requests where the relevant conditions apply.
  • Objection to certain processing or withdrawal of consent where consent is relied upon.
  • Portability requests where applicable and technically relevant.
  • Complaints or questions about how personal information has been handled.

Cookies and website technologies

Our website may use technologies that are necessary for operation and, where configured, technologies for preferences, measurement, communications, or marketing. The cookie notice or consent interface should describe the tools actually deployed, their purposes, duration, providers, and available choices.

Publication dependency: verify the live website’s cookie inventory before publishing specific categories, providers, or retention periods.

International and cross-border considerations

Data consulting can involve stakeholders, personnel, cloud platforms, approved suppliers, or service locations in different countries. Before cross-border access or transfer, the parties should identify the relevant jurisdictions, roles, transfer mechanism, contractual terms, client restrictions, and technical design.

The appropriate safeguard depends on the actual transfer and applicable law; this page does not claim that one mechanism applies universally.

Formal notices and related pages

Continue your privacy and due-diligence review

Use the resources below to review formal notices, contractual documents, and related Trust Center information. Availability may vary by engagement.

Verify URL before publication

Privacy Policy

Read the formal privacy notice describing website and business-level privacy information.

Open resource
Availability may depend on engagement

Data Processing Addendum

Review or request contractual data-processing terms for eligible client engagements.

Open resource
Related Trust Center page

Information Security

Understand the security approach and engagement-specific controls that may support data handling.

Open resource
Related Trust Center page

Responsible AI

Explore the principles used to frame responsible data and AI project decisions.

Open resource

Important scope and limitations

This overview is intended to support initial due diligence. It does not replace the formal Privacy Policy, Cookie Notice, Data Processing Addendum, contract, statement of work, security documentation, or legal advice. Exact practices may depend on the project scope, data type, system architecture, jurisdiction, client instructions, service providers, and verified company procedures.

Any statement about a specific lawful basis, retention period, transfer safeguard, subprocessor, security control, certification, audit, response time, or deletion method should be published only after the relevant owner confirms it.

Frequently asked questions

Data privacy questions from buyers, legal teams, and technical reviewers

These answers provide general guidance. The applicable agreement and formal privacy documentation should be used for project-specific decisions.

Is this page the formal DataConsultant Privacy Policy?

No. This page is a practical Trust Center overview of our approach to privacy in data consulting and related services. The formal privacy notice should be reviewed for legally required information about specific processing activities.

What personal data might be involved in a consulting engagement?

The answer depends on the project. Contact details, stakeholder communications, account information, technical logs, or personal data contained in client-provided datasets may be involved. We encourage clients to exclude information that is not necessary for the agreed purpose.

Do you act as a controller or a processor?

Our role depends on the activity and the parties’ decisions. We may determine purposes for ordinary business administration, while processing client project data on documented client instructions in other situations. Contractual documents should define the applicable roles.

How do you minimise data used in analytics or AI projects?

Our approach is to clarify the use case, remove unnecessary fields, limit identifiers, and consider masked, aggregated, pseudonymised, sampled, or synthetic data where those options remain suitable for the project objective.

Can we use anonymised or synthetic data instead of production data?

Often this is worth evaluating, particularly during discovery, prototyping, demonstrations, testing, or training. Suitability depends on whether the alternative data preserves the patterns, edge cases, and accuracy required for the task.

How long is project data retained?

Retention should be based on the service scope, support period, contractual terms, legal or financial recordkeeping needs, dispute requirements, and technical constraints. Exact periods should be confirmed in the relevant agreement or approved retention schedule.

Can project data be deleted or returned when an engagement ends?

Return, deletion, anonymisation, or continued retention may be available depending on the agreed role, contract, technical environment, backup design, legal requirements, and client instructions. Project close-out terms should define the expected process.

How are individual privacy-rights requests handled?

Requests should be directed through the published privacy contact. When we process data for a client, the client may need to lead the response, and we may provide reasonable assistance where required by the applicable agreement and law.

Do you use cookies or analytics technologies on the website?

The website may use essential and optional technologies for operation, preferences, measurement, or communications. The formal cookie notice or consent interface should identify the technologies actually in use and the available choices.

Will data be transferred internationally?

Cross-border access or transfer may arise where clients, personnel, approved suppliers, cloud platforms, or service locations are in different countries. Applicable safeguards and transfer responsibilities should be assessed for the specific engagement.

Do subcontractors or cloud providers process client information?

They may do so where a service depends on an approved platform, specialist, or supplier. The applicable contract, architecture, client requirements, and supplier arrangements should determine whether and how third parties are used.

Does this page confirm compliance with every privacy law?

No. Privacy obligations vary by jurisdiction, role, data type, sector, and project design. This page does not provide legal advice or state that every framework applies to every engagement. Clients should obtain appropriate legal guidance for their circumstances.

Privacy contact

Submit a Privacy Enquiry

Ask about our privacy approach, request an available document, clarify project roles, or raise a concern. We may need to verify identity, authority, client relationship, or project context before disclosing information or acting on a request.

Submit an enquiry Return to Trust Center