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

Compliance requirements made clear before data work begins.

We help clients translate regulatory expectations, internal policies, and contractual obligations into practical requirements for data consulting, analytics, AI, cloud data, and managed-service engagements.

  • Engagement-specific assessment of laws, frameworks, client policies, systems, and data types
  • Clear allocation of client, consultant, and shared responsibilities
  • Contractual alignment through NDAs, DPAs, security schedules, and scoped control requirements
  • Transparent limitations: no blanket compliance claim and no substitute for legal advice
Discuss compliance requirements Review the applicability matrix

Applicability depends on the client, location, data, systems, contractual role, and engagement scope. This page is not legal advice.

Executive summary

A practical approach to data consulting compliance

Compliance in a consulting engagement is not a single badge or universal checklist. It depends on who the parties are, where they operate, what data is involved, which systems are used, what the consultant is asked to do, and which laws, policies, contracts, or industry rules apply.

Our role is to provide accurate information about our services, understand client requirements, implement agreed operational controls, document dependencies, and avoid unsupported claims. The client remains responsible for determining its legal obligations, providing lawful instructions, and approving the systems and data made available to us.

Requirement identification

How regulatory and contractual requirements are identified

The assessment begins with the actual engagement rather than assumptions about a client, industry, or technology.

Understand the engagement

We identify the services, delivery locations, stakeholders, platforms, data flows, integrations, and expected outputs involved in the proposed work.

Classify data and system context

We ask what categories of data may be accessed, whether special-category, health, payment-card, employee, customer, or confidential information is in scope, and which systems will be used.

Map requirements

Applicable client policies, contractual obligations, privacy requirements, sector rules, and control frameworks are mapped to the proposed scope, where relevant.

Document agreed controls

Responsibilities, limitations, access conditions, evidence expectations, data-handling terms, and approval dependencies are recorded in the relevant agreement or project documentation.

Shared responsibility

Compliance responsibility model

Effective compliance requires coordinated decisions. The following model distinguishes typical responsibilities, while the signed agreement remains controlling.

AreaClient responsibilityOur responsibilityShared responsibility
Legal applicabilityDetermines legal obligations with qualified counsel and identifies mandatory requirements.Provides factual service information and supports implementation of agreed operational controls.Confirm which requirements apply to the engagement and document assumptions.
Data classificationIdentifies data sensitivity, ownership, permitted uses, and restricted categories.Handles data according to the agreed scope, instructions, and access model.Validate data minimisation, access boundaries, retention expectations, and transfer conditions.
Technology environmentApproves platforms, accounts, infrastructure, integrations, and security requirements.Uses approved environments and follows documented access and delivery practices.Review configuration dependencies, logging, authentication, and change controls where applicable.
Policies and evidenceProvides relevant policies, questionnaires, contractual clauses, and evidence requests.Responds with available, accurate documentation and identifies gaps or engagement-specific dependencies.Resolve open items before work involving regulated or sensitive data begins.
Ongoing complianceMaintains organisational compliance decisions, notices, permissions, and lawful basis.Performs the contracted services within agreed instructions and escalates material scope changes.Review changes to data, systems, jurisdictions, vendors, or deliverables that may affect applicability.
Framework awareness

Regulations and control frameworks considered where applicable

These summaries explain how requirements may shape an engagement. They do not claim certification, audit completion, universal applicability, or legal status.

GDPR awareness

For engagements involving personal data connected to the European Economic Area or United Kingdom, we can support data minimisation, purpose limitation, access control, processor instructions, retention expectations, transfer discussions, and DPA alignment. Applicability and lawful basis remain client-led legal determinations.

CCPA, CPRA, and other privacy-law awareness

Where United States state privacy laws or other privacy regimes may apply, we can clarify service-provider roles, data-use restrictions, contractual instructions, deletion or access workflows, and engagement-specific operational requirements.

ISO 27001-aligned concepts

Our discussions may reference risk assessment, access control, asset management, supplier oversight, incident handling, business continuity, and continual improvement concepts associated with information-security management systems. This does not state or imply ISO 27001 certification.

SOC 2 control awareness

When clients use SOC 2 criteria in supplier reviews, we can discuss relevant practices around security, availability, confidentiality, processing integrity, and privacy. This page does not claim that we have completed a SOC 2 audit or hold a SOC 2 report.

HIPAA considerations

HIPAA-related requirements are considered only when protected health information, a covered entity, a business associate relationship, and an applicable service scope are confirmed. A Business Associate Agreement and specific safeguards may be required before access is permitted.

PCI DSS considerations

PCI DSS is considered only when payment-card data or systems affecting the cardholder-data environment are in scope. We generally seek to avoid direct card-data access and use client-approved, appropriately scoped environments and processes.

Industry and client-specific requirements

Financial services, healthcare, education, public sector, ecommerce, employment, and other sectors may impose additional rules. Client security standards, acceptable-use policies, records requirements, and vendor controls can also become contractual requirements.

Applicability matrix

When a regulation or framework may become relevant

This matrix supports early discussion. It cannot replace a legal, privacy, security, or sector-specific assessment.

Regulation or frameworkTypical relevanceServices potentially affectedImportant limitations
GDPR / UK GDPRPersonal data linked to EEA or UK individuals, organisations, processing activities, or transfers.Analytics, BI, data engineering, AI/ML, cloud data, managed data teams, database and reporting services.Role, lawful basis, territorial reach, controller/processor status, and transfer mechanism require client and legal confirmation.
CCPA / CPRA and US state privacy lawsPersonal information of residents covered by applicable state law and qualifying businesses or service relationships.Customer analytics, CRM data work, marketing data, support operations, data platforms, automation, and managed services.Thresholds, exemptions, role definitions, contractual restrictions, and consumer-rights workflows vary by law.
ISO/IEC 27001 conceptsClients using information-security management controls in due diligence or contract schedules.Potentially relevant across all technology and data services.Alignment with selected concepts is not certification, accreditation, or proof of a complete ISMS.
SOC 2 Trust Services CriteriaSupplier assessments that evaluate security, availability, processing integrity, confidentiality, or privacy controls.Cloud data, managed teams, platform administration, engineering, analytics operations, and support services.Control awareness is not a SOC 2 examination, attestation, Type I report, or Type II report.
HIPAAUS healthcare engagements involving protected health information and a qualifying covered-entity or business-associate relationship.Healthcare analytics, data engineering, reporting, database, cloud, automation, and AI services involving PHI.No PHI should be shared until applicability, permitted use, BAA requirements, safeguards, and approved systems are confirmed.
PCI DSSPayment-card data or systems that store, process, transmit, or can affect cardholder-data security.Ecommerce analytics, payment reporting, platform integration, database, cloud, and automation work.Scope should be minimised. Direct card-data handling requires explicit review and client-approved controls.
Client and sector requirementsIndustry rules, internal policies, contractual controls, geographic restrictions, or customer obligations.Any engagement where the client imposes additional requirements.Requirements must be supplied, reviewed, accepted, and operationally feasible within the agreed scope.
Contractual alignment

Controls documented through agreements and project records

Compliance commitments should be explicit, reviewable, and connected to the real service scope rather than left to informal assumptions.

Confidentiality and NDAs

Confidentiality obligations can be documented through mutual or client-provided NDAs, subject to review and agreement.

Data Processing Agreements

Where a processor relationship is established, a DPA can define instructions, processing details, subprocessors, transfers, assistance obligations, and deletion or return expectations.

Security schedules

Security addenda may record access controls, approved environments, incident escalation, personnel obligations, vulnerability expectations, evidence rights, and other agreed measures.

Statements of work

The statement of work can identify data types, systems, deliverables, exclusions, responsibilities, acceptance criteria, and change-control requirements.

Personnel and supplier terms

Engagement-specific requirements may address confidentiality, least-privilege access, training expectations, background checks where lawful and agreed, and third-party dependencies.

Incident and change obligations

Notification routes, cooperation expectations, material changes, scope expansion, and issue escalation can be defined contractually rather than assumed.

Evidence and documentation

How compliance information requests are handled

Procurement, legal, privacy, and security teams can submit structured requests for available information relevant to a proposed engagement.

01

Submit the request

Share the questionnaire, required documents, contractual clauses, review deadline, intended engagement, and responsible client contact.

02

Confirm scope and ownership

We identify which questions relate to company-wide practices, engagement-specific controls, client-managed systems, or third-party platforms.

03

Prepare accurate responses

Available documentation and factual responses are compiled. Unsupported statements are not added merely to satisfy a questionnaire.

04

Review sensitive material

Legal, privacy, security, or executive review may be required before certain documents or commitments can be released.

05

Resolve gaps and conditions

Open items are documented with proposed mitigations, client dependencies, scope restrictions, or contract language where appropriate.

06

Maintain an engagement record

Approved requirements and evidence references can be retained with project documentation for onboarding and future scope reviews.

What this means for clients

What clients can expect during due diligence

  • ✓Questions are answered according to the proposed service and available verified information.
  • ✓Company-wide practices are distinguished from engagement-specific options and client-controlled systems.
  • ✓Unconfirmed certifications, audits, controls, guarantees, and contractual commitments are not represented as facts.
  • ✓Dependencies, limitations, and unresolved items are surfaced before sensitive access or regulated processing begins.
  • ✓Material scope changes can trigger a fresh privacy, security, contractual, or compliance review.
Frequently asked questions

Compliance questions from buyers, legal teams, and security reviewers

These answers clarify our approach while preserving the engagement-specific nature of compliance decisions.

Is DataConsultant fully compliant with every regulation listed on this page?

No. Regulations and frameworks apply differently depending on the client, legal entities, locations, data categories, systems, service model, and engagement scope. This page explains our awareness and approach; it is not a blanket compliance statement.

Does this page provide legal advice?

No. The information is operational and informational. Clients should obtain advice from qualified legal, privacy, tax, regulatory, or industry professionals when determining their obligations.

How do you decide which compliance requirements apply to a project?

We review the service scope, client instructions, jurisdictions, data types, systems, users, industry context, contractual terms, and client policies. The client remains responsible for confirming legal applicability with appropriate advisers.

Can you sign an NDA or Data Processing Agreement?

NDAs and DPAs can be reviewed and agreed where appropriate. The final terms depend on the engagement, processing role, data involved, operational feasibility, and legal approval.

Are you ISO 27001 certified?

This page does not claim ISO 27001 certification. We may discuss security-management concepts aligned with the standard where they are relevant to client requirements or project controls.

Do you have a SOC 2 report?

This page does not claim that DataConsultant has completed a SOC 2 examination or holds a SOC 2 report. We can discuss relevant control expectations and provide available evidence subject to review.

Can you work with personal data covered by GDPR or UK GDPR?

Potentially, subject to scope review, client instructions, role definition, lawful processing decisions, transfer requirements, approved systems, contractual terms, and appropriate operational controls.

Can you support CCPA or CPRA requirements?

We can support engagement-specific operational and contractual requirements such as data-use restrictions, service-provider terms, deletion workflows, access support, and documentation. Legal applicability and consumer-rights obligations remain client-led decisions.

Can you handle protected health information under HIPAA?

Only after confirming that HIPAA applies, defining the permitted use, agreeing any required Business Associate Agreement, approving systems and safeguards, and completing the necessary privacy and security review. PHI should not be shared before that process is complete.

Can you process payment-card data under PCI DSS?

The preferred approach is to keep payment-card data outside our access wherever possible. Any work that could affect a cardholder-data environment requires explicit scoping, approved systems, client controls, and a clear allocation of PCI DSS responsibilities.

What compliance documents can procurement or security teams request?

Teams may request available policies, questionnaires, contractual schedules, processing details, supplier information, data-flow descriptions, access-control explanations, incident contacts, or other evidence relevant to the proposed engagement. Availability and disclosure may depend on confidentiality and approval.

What happens if a requirement cannot be met?

We identify the gap, explain the operational constraint, and discuss alternatives such as scope reduction, client-managed environments, additional controls, contractual clarification, or exclusion of particular data or activities.

How are new compliance requirements handled after a project starts?

Material changes to data, systems, locations, vendors, legal requirements, client policies, or deliverables should be raised through change control. The impact can then be assessed before the revised activity proceeds.

Compliance review

Discuss your compliance requirements

Share the proposed scope, data categories, systems, locations, client policies, questionnaire, and required documents. Our Trust Team can help identify the next review steps and any information needed before delivery begins.

Contact the Trust Team