Clear answers for confident data consulting decisions.

Our approach is to identify engagement risks, limit access to what is required, use agreed working environments, apply appropriate authentication and account practices, protect confidential information, and maintain review and escalation procedures. Specific safeguards must be validated for each delivery model and client environment.

Access should be role-based, time-bounded where practical, approved by authorised stakeholders, and limited to the systems and information needed for assigned work. Client-managed identity, single sign-on, multifactor authentication, privileged-access controls, or access logs may be used where available and agreed.

Multifactor authentication may be used for supported company or client platforms where available and appropriate. Because authentication options differ across tools and client environments, the required method should be documented during onboarding rather than assumed from this general FAQ.

Cloud security responsibilities are defined by the selected platform, account ownership, architecture, service configuration, and operating model. We can work within client-controlled environments and follow agreed configuration, identity, logging, network, backup, and change-management requirements, subject to scope and access.

Privacy roles should be established from the processing purpose, decision-making authority, data flows, contractual structure, and applicable law. Depending on the engagement, the client may act as controller or business, while we may act as a processor, service provider, independent controller, or another defined role. Legal review is required where necessary.

Our approach is to use only the data reasonably needed for the agreed purpose and to consider masked, pseudonymised, aggregated, synthetic, sampled, or otherwise reduced datasets where they can meet the project objective. The appropriate method depends on technical feasibility, accuracy needs, and client decisions.

Retention and deletion expectations should be defined by contract, project plan, client policy, legal requirements, platform capability, and operational need. Data and working files should not be retained indefinitely without a purpose. Verified retention periods and deletion evidence must be confirmed for the specific engagement.

Where we process relevant personal data on a client’s instructions, we can discuss reasonable assistance for locating, exporting, correcting, restricting, or deleting in-scope information. The client normally remains responsible for validating the request, legal basis, identity, response decision, and statutory deadline.

No certification, audit, attestation, or compliance status should be inferred from this page. Any current certification or independent assurance must be confirmed through approved evidence. Where a client requires alignment to a framework, the applicable scope, responsibilities, gaps, and evidence should be assessed before commitment.

We can review engagement-relevant requirements and incorporate agreed controls, documentation, approvals, and reporting into the delivery plan where feasible. Regulatory accountability remains shared and depends on the client’s industry, jurisdiction, data, systems, policies, and legal interpretation.

No. Cloud services can provide useful security and compliance capabilities, but compliance depends on how services are selected, configured, governed, accessed, monitored, and used. Responsibilities must be mapped across the client, cloud provider, our team, and any other participating suppliers.

We can review questionnaires relevant to a genuine opportunity or active engagement. Responses depend on the requested scope, available verified evidence, confidentiality constraints, and internal approval. We avoid answering “yes” where a control is engagement-specific or where evidence has not been confirmed.

Responsible AI means considering intended use, affected stakeholders, data suitability, privacy, security, explainability, human oversight, testing, limitations, and misuse risks throughout the AI lifecycle. The depth of assessment should match the use case and potential impact.

No. AI systems can produce incorrect, incomplete, inconsistent, or biased outputs. We can help define evaluation criteria, test representative scenarios, document known limitations, and introduce human review, but clients must assess whether outputs are suitable for their operational, legal, or decision-making context.

Client data should not be submitted to public or third-party AI services without an approved purpose, suitable terms, authorised configuration, and client agreement where required. The exact position depends on the selected tool and engagement. Approved AI-use rules should be documented before processing sensitive data.

Human oversight can include use-case approval, data review, prompt and model evaluation, output verification, exception handling, escalation, and final decision authority. The appropriate checkpoints depend on whether the system supports analysis, content, prediction, automation, recommendation, or a higher-impact decision process.

Confidential information should be accessed only for authorised work, shared on a need-to-know basis, handled through approved channels, and protected under applicable contractual and organisational obligations. Engagement-specific requirements may include restricted workspaces, client-controlled environments, named personnel, or additional handling instructions.

Personnel may be subject to contractual confidentiality obligations appropriate to their role and working arrangement. The exact form, coverage, and flow-down requirements should be confirmed for engagements with specific legal, regulatory, or procurement conditions.

We can review a mutual or client-provided non-disclosure agreement through the appropriate commercial and legal process. Acceptance depends on the terms, parties, jurisdiction, scope, duration, permitted disclosures, remedies, and consistency with the proposed engagement.

Separation may be supported through distinct accounts, repositories, workspaces, permissions, naming conventions, client-controlled environments, or procedural controls. The appropriate approach depends on the platform, service model, and sensitivity of the information. Specific isolation requirements should be agreed before work begins.

Work may be performed in client-controlled systems, approved cloud platforms, company-managed tools, or a combination agreed for the engagement. Delivery location, remote access, data residency, and permitted tools should be defined during onboarding when they are material to security, privacy, or compliance.

Files should be exchanged through agreed channels appropriate to their sensitivity and size. Options may include client portals, approved cloud storage, managed collaboration platforms, secure transfer services, or client-controlled repositories. Email should not be assumed suitable for sensitive datasets.

Where our scope includes production changes, the process may include documented requests, peer or client review, testing, approval, controlled deployment, rollback planning, and post-change validation. The exact workflow depends on environment ownership, project maturity, urgency, and client change-management requirements.

Often, yes, where the client provides suitable access, tools, capacity, and support. Working in a client environment can reduce data movement, but it does not remove the need for clear access, configuration, monitoring, support, and shared-responsibility arrangements.

Suspected incidents should be reported promptly through the designated escalation route, assessed for scope and impact, contained where feasible, documented, and coordinated with relevant client contacts. Notification duties, evidence preservation, communications, and remediation depend on the facts and contractual requirements.

No general notification time is promised on this page. Any binding notification requirement must be stated in the applicable agreement and supported by an operational process. Practical timing may depend on when an event is detected, verified, linked to the engagement, and assessed as reportable.

Use the approved security or trust contact specified in the engagement documentation or contact the Trust Team through this page. Do not include sensitive evidence in an unapproved channel. Provide a concise description, affected service, observed time, and a safe method for follow-up.

Where appropriate, incident closure may include root-cause analysis, corrective actions, control improvements, documentation updates, owner assignments, and follow-up validation. The depth of review should reflect the event’s severity, evidence, client requirements, and our role in the affected service.

Our approach is to identify critical delivery dependencies, establish practical communication and recovery arrangements, and reduce single points of failure where proportionate to the service. Continuity requirements differ between short projects and ongoing managed services and should be agreed accordingly.

No. Backup responsibility depends on who owns the environment, data, code repository, platform, and service operations. Client-managed systems may remain under the client’s backup process. Any backup scope, frequency, retention, restoration testing, and ownership must be explicitly defined.

Options may include documented procedures, shared repositories, peer review, cross-training, named backup contacts, structured handover, and team-based delivery. The appropriate level depends on engagement duration, complexity, service criticality, commercial scope, and availability of suitably skilled personnel.

No. This page does not provide an uptime or uninterrupted-service guarantee. Any service level, support window, recovery objective, or continuity commitment must be agreed in writing for the relevant managed service and depends on defined responsibilities and technical dependencies.

Third-party platforms, service providers, specialists, or subcontractors may be used where appropriate to the engagement. Their involvement should be assessed against the service, information access, contractual conditions, client requirements, and applicable legal obligations. Material restrictions should be raised during procurement.

Evaluation may consider service fit, security and privacy information, contractual terms, data handling, access needs, location, resilience, reputation, support, and dependency risk. The depth of review should be proportionate to the third party’s role and the sensitivity of information involved.

Notification or approval requirements depend on the contract, processing role, service model, and applicable law. Where a client requires a named supplier list, advance notice, objection process, or prior approval, that requirement should be documented during contracting.

Yes, restrictions can be discussed during scoping and procurement. Feasibility depends on whether suitable alternatives exist and whether the restriction affects cost, schedule, architecture, collaboration, or service quality. Approved and prohibited tools should be recorded for the delivery team.

Quality assurance may include requirement confirmation, design review, source-to-output reconciliation, code review, testing, documentation, stakeholder validation, and delivery checks. The plan should reflect the service type, business impact, data quality, technical complexity, and agreed acceptance criteria.

Testing can include schema checks, row counts, transformations, business rules, duplicate and null handling, reconciliation, performance, access, failure scenarios, and user acceptance. The exact tests and tolerances should be defined from data characteristics and business requirements.

Approval responsibilities should be named in the project plan or statement of work. Our team can perform internal review and provide evidence, while the client typically confirms business rules, source-data meaning, user acceptance, operational readiness, and final acceptance.

Issues should be logged, assessed against agreed requirements, prioritised, assigned, corrected, and retested. Whether a change is a defect, clarification, enhancement, or new scope depends on the approved requirements and acceptance criteria. Revision terms should be defined commercially.

Useful inputs include the service description, intended systems, data categories, user locations, access needs, delivery model, regulatory context, required frameworks, questionnaire, evidence deadline, and contracting route. Clear scope helps avoid generic or inaccurate answers.

Relevant documents may be shared where available, appropriate, approved, and subject to confidentiality restrictions. Document availability and content can change. Requests should identify the decision being supported so that the most relevant current material can be provided.

Service levels, support arrangements, deliverables, acceptance criteria, dependencies, exclusions, and responsibilities should be documented in the applicable proposal, statement of work, order, or agreement. General website content is informative and does not override signed terms.

No. This FAQ is general information intended to support early evaluation. It is not legal advice, a warranty, a certification, a service-level commitment, or a substitute for signed contractual documents. Clients should obtain independent legal and professional advice where appropriate.