Clear answers for enterprise trust and due diligence.

Information-security decisions should be based on the actual service, systems, data sensitivity, access model, delivery environment and responsibilities involved. The review may cover least-necessary access, approved working environments, authentication, confidential information handling, change controls, escalation and engagement-specific evidence. The applicable safeguards should be confirmed during scoping, onboarding and technical review rather than assumed from a general website statement.

Access should be authorised, linked to an assigned role and limited to the systems and information needed for the work. Depending on the environment, controls may include client-managed identities, single sign-on, multifactor authentication, privileged-access controls, logging or time-bounded access. The client remains responsible for approvals and configuration within client-controlled systems, while engagement-specific access expectations should be documented before use.

The preferred approach is to use only the information reasonably needed for the agreed purpose. Where technically and operationally suitable, teams can consider masked, pseudonymised, aggregated, sampled, synthetic or otherwise reduced datasets. The appropriate method depends on the use case, accuracy needs, legal context, platform capability and client decisions, so minimisation should be confirmed against the actual project rather than treated as one universal technique.

Retention and deletion should be defined from the applicable contract, project plan, client policy, legal requirements, operational need and platform capability. Working copies and project artefacts should not be assumed to have an indefinite retention period. Any specific retention period, deletion method or deletion evidence should be treated as engagement-specific until it has been confirmed by the relevant owners.

No. Laws, contractual requirements and recognised frameworks can apply differently depending on legal entities, locations, data categories, systems, service model and scope. Referencing a regulation or framework does not by itself establish a DataConsultant certification or a universal compliance status. Applicability and evidence should be reviewed for the specific engagement, with legal advice obtained where appropriate.

A useful review pattern is Requirement → Policy or Principle → Control → Owner → Evidence → Monitoring → Review. This helps teams identify what the obligation is, who is responsible, how it is addressed, what evidence is relevant and how exceptions or remediation are handled. The exact mapping depends on the client requirement and agreed delivery model.

Confidential information should be used only for authorised work, shared on a need-to-know basis and handled through approved channels appropriate to its sensitivity. Engagement-specific requirements can include client-controlled environments, restricted repositories, named personnel, information-classification rules or additional handling instructions. Signed confidentiality terms and approved project documentation take precedence over this general FAQ.

An NDA can be reviewed through the appropriate commercial and legal process. Acceptance depends on the parties, jurisdiction, scope, duration, permitted disclosures, remedies and consistency with the proposed engagement. A general Trust Center statement should not be treated as acceptance of a particular client template or as a substitute for an executed agreement.

Continuity planning should consider critical activities, dependencies, people, technology providers, client-controlled systems, communications and recovery responsibilities. The relevant approach depends on service scope and operational impact. Any recovery objective, test frequency, uptime target or service commitment should be treated as contract-specific unless explicitly verified for the service being reviewed.

No. This Trust Center does not provide an uninterrupted-service guarantee, recovery guarantee or universal uptime commitment. Availability and recovery depend on the service model, architecture, providers, client responsibilities and written commercial terms. Where service levels or recovery objectives are important, they should be agreed explicitly for the relevant engagement.

A suspected issue should be raised promptly through an agreed project, security or Trust Team route. The initial report should focus on useful facts such as what was observed, when it was observed, affected systems or information if known, and any immediate business impact. Do not post sensitive details publicly or send passwords, secrets, private keys or unnecessary confidential data in the initial message.

No universal notification time is stated by this page. Notification duties can depend on confirmed facts, applicable law, contractual terms, the parties’ roles and the affected data or systems. Incident handling should establish facts, ownership, containment needs, evidence and communication responsibilities before making unsupported commitments.

Work may take place in client-controlled systems, approved cloud platforms, company-managed tools or a combination agreed for the engagement. Hosting location, remote access, data residency, identity, network restrictions and permitted tools can materially affect the design. These decisions should be confirmed during onboarding when they matter to security, privacy, compliance or operational risk.

It may be possible when the client provides suitable access, tools, capacity and support. Working within a client-controlled environment can reduce unnecessary data movement, but it does not remove the need for clear access rules, approved tools, configuration decisions, monitoring, change control and shared-responsibility arrangements. Feasibility should be confirmed during solution design.

Where DataConsultant’s scope includes production changes, the delivery process may include a documented change request, technical or client review, testing, approval, controlled deployment, rollback planning and post-change validation. The exact workflow depends on environment ownership, client procedures, urgency, project maturity and the responsibilities agreed for the engagement.

Quality assurance may include requirement confirmation, source-to-output checks, design or code review, testing, documentation review, stakeholder validation, issue tracking and delivery checks. The depth of review should reflect the deliverable, business impact, data quality, technical complexity and agreed acceptance criteria. Quality controls reduce risk but do not guarantee the absence of every error or future change.

Approval responsibilities should be named in the project plan, statement of work or other agreed delivery document. DataConsultant can perform internal review and provide relevant evidence, while the client commonly retains responsibility for business rules, source-data meaning, user acceptance, operational readiness and final acceptance within areas under the client’s control.

Responsible AI means considering intended use, affected stakeholders, data suitability, privacy, security, explainability, evaluation, human oversight, limitations, monitoring and potential misuse throughout the AI lifecycle. The depth of review should be proportionate to the use case and impact, and responsibilities should be clear across the client, DataConsultant and technology providers.

No. AI outputs can contain errors, omissions, bias, uncertainty or context limitations. Appropriate evaluation, human review, business validation and monitoring should be designed for the use case. This FAQ does not create a guarantee that an AI system is error-free, unbiased or suitable for a particular high-impact decision without further assessment.

Third-party review should consider what service the provider supplies, what information or systems it can access, where processing may occur, what dependencies it creates, what controls are relevant and whether client restrictions apply. The depth of review should be proportionate to risk and scope. A vendor’s certification or platform capability should not be presented as a DataConsultant certification or control.

Restrictions can be discussed during scoping and procurement. Feasibility depends on whether suitable alternatives exist and whether the restriction changes architecture, delivery method, schedule, cost, collaboration or service quality. Approved and prohibited tools should be recorded for the engagement rather than assumed from a general technology list.

No. Public links should be shown only where an approved live document exists. Other assurance material may be available on request, restricted, confidential or engagement-specific. Access can depend on relevance, confidentiality obligations, internal approval and the decision being supported. This page does not create or imply the existence of unverified certificates, audit reports or policies.

Useful context includes the service under consideration, systems and data involved, access needs, locations, delivery model, relevant client policies, regulatory context, required frameworks, questionnaire format, evidence expectations and target decision date. Clear scope helps distinguish organisation-level information from engagement-specific commitments.

Questionnaires relevant to a genuine opportunity or active engagement can be reviewed through the Trust Team route. Responses depend on the scope, verified evidence, confidentiality constraints and appropriate internal review. Where a requested control is engagement-specific or unverified, the response should explain the dependency instead of giving an unsupported universal “yes”.

No. These FAQs are general information for early due diligence. They are not legal advice, a warranty, a certification, a service-level commitment or a substitute for an executed agreement. Signed contracts, statements of work, approved project documents and engagement-specific requirements take precedence where they address the same subject.