DataConsultant’s compliance approach is built around traceability: understand what requirement applies, translate it into an operational expectation, assign responsibility, identify proportionate controls, retain appropriate evidence and review change over time. The exact obligations depend on the engagement, jurisdiction, data, technology, contract and client context.
This page is an assurance overview for due diligence. It is not legal advice, a certification statement, an audit opinion or a guarantee of compliance with every law, standard, contract or client policy.
Conceptual assurance model. Actual controls and evidence are engagement-specific and must be validated against the relevant obligation and operating context.
Data, analytics and AI projects can cross legal, contractual, security, privacy, sector, technology and client-policy boundaries. Compliance becomes operational only when teams know what applies, who owns the decision, how the requirement is implemented and what evidence supports it.
The goal is not to collect more frameworks. It is to create traceable decisions and controls that can be reviewed against the actual engagement.
Share the proposed service, jurisdictions, data context, client standards or questionnaire so the review can focus on what actually applies.
Compliance is broader than regulation alone. Depending on the engagement, the applicable requirement set can include contractual, privacy, security, delivery, AI, quality, supplier and client-specific expectations.
A useful compliance view separates obligation sources, applicability triggers, evidence expectations and the limits of what can be inferred from a general Trust Center page.
| Requirement class | Typical trigger | What should be determined | Evidence direction | Important limitation |
|---|---|---|---|---|
| Statutory / regulatory | Jurisdiction, regulated activity, personal data or sector | Applicability, role, scope, implementation obligations and decision owner | Policies, process records, contractual terms and control evidence as applicable | No legal conclusion from this page |
| Contractual | Executed client or supplier agreement | Binding obligations, responsibilities, deadlines, dependencies and remedies | Signed terms, schedules, project records and review evidence | Contract governs |
| Client policy / standard | Procurement, security, privacy, architecture or vendor onboarding | Feasibility, gaps, exceptions, required evidence and approved implementation | Questionnaire responses, mappings and agreed controls | Client-specific |
| External framework | Risk management, assurance or internal control reference | Which concepts are useful, who owns implementation and what evidence is relevant | Control mapping or internal assessment where actually performed | Framework ≠ certification |
| Technology-provider requirement | Cloud, SaaS, model, data or platform dependency | Provider responsibilities, configuration choices, contract terms and residual risk | Provider documentation plus client/DataConsultant configuration evidence | Provider-controlled |
| Internal delivery requirement | Project governance, quality, access, change or handover | Expected process, owner, review point, evidence and escalation route | Project plan, decision log, acceptance or review record | Operational evidence |
This conceptual model shows how compliance questions can move from external obligations into project decisions without implying that every layer is controlled by DataConsultant.
The specific governance model depends on the engagement, but a review should make clear who interprets requirements, who approves risk decisions, who operates controls, who supplies evidence and who owns remediation.
A compliance mapping is useful only when a reviewer can understand the basis of the decision and its operating boundary.
Not every requirement can be implemented in the same way. A credible compliance process makes exceptions visible, evaluates impact, records the decision and tracks corrective action.
The examples below are context for compliance discussions. Applicability must be determined for the actual engagement, and a framework name does not establish that DataConsultant holds a certification or attestation to it.
| Example | What it can inform | When it may be relevant | How to treat it on this page | Assurance boundary |
|---|---|---|---|---|
| Digital Personal Data Protection Act, 2023 & Digital Personal Data Protection Rules, 2025 | Personal-data governance, roles, notices, security, rights, records and related responsibilities. | India-linked processing where the legislation applies, subject to commencement and project context. | Regulatory context requiring engagement-specific assessment. | Not a legal opinion |
| ISO/IEC 27001:2022 | Information-security management requirements and risk-based control governance. | Security due diligence, client control mapping or internal assurance discussions. | Useful framework concepts can be considered where relevant. | Not a certification claim |
| NIST Cybersecurity Framework 2.0 | High-level cybersecurity risk outcomes, governance and communication. | Client security reviews, risk discussions and control taxonomy mapping. | Voluntary framework context when requested by the client or useful to the engagement. | Framework reference |
| NIST AI Risk Management Framework 1.0 | AI risk governance, lifecycle decisions, trustworthiness considerations and risk treatment. | AI-enabled engagements where the client needs a structured AI risk discussion. | Voluntary framework context, noting that NIST has announced revision work. | Framework reference |
| Client / sector requirements | Industry-specific controls, internal standards, contractual restrictions and assurance evidence. | Any engagement where the client imposes additional requirements. | Review, map, accept or document exceptions before treating the requirement as agreed. | Client-specific |
External requirements change over time. Current applicability, commencement, interpretation and contractual effect should be confirmed with the appropriate legal, compliance, privacy, security or risk stakeholders before relying on a requirement for a specific engagement.
Procurement and risk teams often need progressively deeper evidence. The appropriate level depends on sensitivity, confidentiality, the proposed engagement and whether the requested material exists and can be disclosed.
Trust Center pages and public legal notices suitable for initial review.
Open accessExpanded explanations of governance, process, responsibility and control concepts.
Initial due diligenceSupporting material relevant to a particular control or process, subject to availability and review.
Request may be requiredSecurity-sensitive or confidential material that may require controlled disclosure and appropriate safeguards.
Access controlledQuestionnaires, mappings and contract-specific evidence for a defined procurement or risk decision.
Engagement-specificA compliance claim is useful only when the reviewer understands its scope, evidence and limitations.
| Review dimension | Low confidence | Improving | Review-ready | Evidence question |
|---|---|---|---|---|
| Applicability | Assumed | Requirement identified | Scope and basis recorded | Why does this requirement apply to this engagement? |
| Control mapping | No mapping | Control described | Requirement-to-control traceability | Which control or process addresses the requirement? |
| Ownership | Unclear | Team identified | Accountable owner assigned | Who can implement, approve and evidence the control? |
| Evidence | Statement only | Artefact exists | Current reviewable evidence | What evidence demonstrates the control or decision? |
| Exceptions | Informal | Gap recorded | Decision and treatment tracked | What residual risk remains and who accepted it? |
| Change review | Ad hoc | Periodic discussion | Trigger-based reassessment | What change causes the requirement to be revisited? |
Use the Trust Team route so the request can be matched to the relevant service, evidence level and responsible stakeholders.
A one-time mapping can become stale as services, data, systems, providers, contracts, client policies and external requirements change. Review should therefore be triggered by material change and by the needs of the engagement.
New deliverables, managed operations, production access or support responsibilities can change the control boundary.
New personal, sensitive, regulated or cross-border data can introduce different legal, privacy or contractual considerations.
A new cloud service, AI model, integration or supplier can alter shared responsibilities and evidence requirements.
New schedules, questionnaire commitments or internal client standards may require remapping and approval.
Material findings can expose a control weakness and create remediation, evidence or governance actions.
These answers provide general Trust Center context. Project-specific obligations and binding commitments should be confirmed through the relevant agreement and approved assurance material.
Compliance means identifying the obligations that are relevant to the engagement, translating those obligations into practical requirements, assigning responsibility, connecting requirements to appropriate controls and evidence, and reviewing issues through an agreed governance process. The exact obligations depend on the service, data, systems, jurisdictions, industry, contract and client requirements.
No. A law, standard or framework may be useful context without being a DataConsultant certification. Certification, attestation or audit status should be treated as verified only when current supporting evidence is explicitly provided through an approved DataConsultant source.
Client-specific requirements should be identified during scoping or due diligence, assessed for applicability and feasibility, assigned to the appropriate party, and reflected in the relevant contract, statement of work, security schedule, data-processing terms, architecture or delivery plan where applicable.
Responsibility is divided according to operational control. DataConsultant is responsible for agreed activities and environments under its control; clients remain responsible for their systems, data classifications, approvals, policies and decisions; technology providers remain responsible for provider-operated services and controls. The engagement documents should clarify shared responsibilities.
A material exception should be recorded, assessed for impact, assigned to an accountable owner, given a proportionate treatment decision, and tracked through remediation or formal acceptance where appropriate. Closure should be based on reviewable evidence rather than an unsupported statement that the issue is resolved.
Public Trust Center information can support an initial review. Additional control, process or client-specific evidence may be discussed through the Trust Team and can be subject to confidentiality, relevance, availability and disclosure restrictions. This page does not imply that a particular restricted document exists.
Yes. Use the Contact Trust Team page to describe the proposed engagement, review scope, questionnaire or evidence request, relevant deadline and stakeholders. Do not submit passwords, credentials, private keys or unnecessary sensitive security information through a general web form.
Where personal data is involved, privacy and data-protection requirements may affect purpose, access, security, sharing, retention, deletion, records and contractual responsibilities. Applicability depends on the processing context, jurisdiction and role of each party. The Data Privacy Trust Center page provides more detail.
AI engagements may require additional review of intended use, data, human oversight, model or provider risk, evaluation, transparency, security, privacy and applicable legal or policy requirements. The Responsible AI Trust Center page explains this lifecycle in more detail.
No. This page is an assurance overview for initial due diligence. It does not provide legal advice, create a warranty, certify compliance or replace executed agreements, approved policies, regulatory interpretation or project-specific control documentation.
Share the proposed service, applicable jurisdictions, data types, client standards, questionnaire, contractual requirement or evidence question. The Trust Team can help route the request to the appropriate review path without treating a general framework reference as a company certification.
For website and business-contact privacy information, review the DataConsultant Privacy Policy. Do not send passwords, credentials, private keys or unnecessary sensitive security information through a general enquiry.
