Data and technical assets
Source datasets, transformed data, schemas, queries, pipelines, dashboards, models, prompts, code, architecture notes, logs, test outputs, and configuration details.
Trust Center · Confidentiality
Confidential information deserves clear boundaries throughout the engagement.
We approach client data, source code, credentials, intellectual property, reports, models, and business information as responsibilities that must be scoped, limited, exchanged, and closed out deliberately.
This page describes a general approach. Engagement-specific obligations are established only in signed contracts and approved project documentation.
Executive summary
Confidentiality is a shared, engagement-specific responsibility.
Strong handling begins before sensitive information is shared. The parties should identify what is confidential, who needs access, which tools are approved, where work will occur, who owns outputs, and what happens at completion.
- Terms before transfer.
Confidentiality clauses, NDAs, data-handling terms, and ownership provisions should reflect the actual engagement. - Access follows responsibility.
Assigned personnel should receive only the information and permissions reasonably required for their role. - Approved channels matter.
Exchange, storage, collaboration, and remote-work methods should match the sensitivity and client requirements.
Information categories
What confidential client information may include
The applicable contract controls the definition. In data consulting and Data & AI work, confidentiality commonly extends across technical, commercial, personal, and proprietary materials.
Business and operational information
Commercial plans, financial information, product strategy, customer or supplier information, internal reports, forecasts, policies, and process documentation.
Personal and stakeholder information
Information about employees, customers, applicants, users, partners, or other individuals, handled according to the agreed scope and applicable requirements.
Intellectual property and know-how
Proprietary methods, inventions, designs, research, trade secrets, product concepts, documentation, training materials, and other protected client knowledge.
Contractual foundation
NDA support and contractual confidentiality
We can discuss bilateral or one-way NDAs, confidentiality clauses, statement-of-work terms, data-processing provisions, intellectual-property language, and client-specific supplier requirements. Documents are subject to legal and commercial review before acceptance.
Terms should identify the parties, covered information, permitted purpose, recipients, exclusions, compelled disclosure, duration, ownership, return or deletion, and any engagement-specific restrictions. This page is not a substitute for those terms and does not provide legal advice.
People and access
Workforce obligations and need-to-know access
Confidentiality depends on both contractual duties and practical access decisions. Controls should reflect who is assigned, what they must do, and which systems they genuinely need.
Workforce confidentiality obligations
Personnel involved in confidential engagements should be bound through relevant employment, contractor, policy, platform, or project terms. Additional client acknowledgements may be considered where appropriate.
Need-to-know access
Information and permissions are intended to be limited to assigned responsibilities. Access should be reviewed when roles, phases, systems, or project scope change.
Project separation
Separate workspaces, repositories, folders, channels, accounts, permissions, and delivery records may be used to reduce unnecessary cross-project exposure.
Information classification
Handling should reflect sensitivity, purpose, and context
Labels and requirements may differ by client. A practical classification discussion helps teams decide how information may be viewed, shared, stored, copied, and retained.
| Illustrative level | Examples | Typical handling consideration | Client decision |
|---|---|---|---|
| Public | Published webpages, approved marketing content, public datasets. | Normal business handling; source and licence terms still apply. | Confirm that release is authorised. |
| Internal | Routine project notes, internal operating information, non-public drafts. | Limit to authorised project participants and approved channels. | Define whether onward sharing is allowed. |
| Confidential | Client datasets, code, architecture, financials, roadmaps, reports. | Need-to-know access, controlled exchange, defined workspace, closure plan. | Specify tools, locations, recipients, and retention. |
| Highly restricted | Production credentials, sensitive personal data, trade secrets, regulated records. | Additional controls or client-hosted work may be required; access may be narrowly restricted. | Approve handling before transfer and confirm legal/security requirements. |
Illustrative only. The client’s classification policy and the signed engagement terms take precedence.
Communication and document exchange
Use agreed channels and avoid unnecessary copies
Project teams should establish approved communication, repository, file-transfer, password-management, ticketing, and collaboration tools. Sensitive information should not be moved to personal accounts, consumer applications, removable media, or unapproved AI services.
Where applicable, the client may provide managed accounts, virtual desktops, repositories, cloud workspaces, or data platforms. Tool configuration, licensing, identity administration, backup, logging, and access revocation responsibilities should be explicit.
Shared responsibility
Clients should avoid sending live credentials or highly sensitive data before the approved method is confirmed. They should also remove obsolete access, notify us of classification requirements, and communicate changes that affect handling.
Distributed delivery
Confidentiality in remote and distributed work
Remote delivery can support global collaboration, but it requires clear expectations for location, devices, workspaces, access, conversations, screen sharing, printing, storage, and disposal.
Location and environment
Client restrictions on countries, work locations, public spaces, co-working areas, travel, or home environments should be identified before assignment.
Device and session practices
Device, browser, screen-lock, session, download, printing, recording, and local-storage expectations should follow the agreed environment and client requirements.
Meetings and communication
Participants should confirm audiences before sharing screens or files, avoid discussing confidential matters where they may be overheard, and use approved channels.
High-value project assets
Handling credentials, code, datasets, models, reports, and business information
The correct approach depends on the asset, sensitivity, client environment, and work being performed. The following are practical scoping points rather than universal guarantees.
Credentials and access tokens
Credentials should be shared only through an agreed method, limited to the required purpose, and rotated or withdrawn when access is no longer needed. Client administrators retain responsibility for account ownership and access revocation unless the contract states otherwise.
Source code and repositories
Repository access, branches, deployment permissions, code review, and contribution workflows are defined for the engagement. We avoid copying code into unapproved locations and separate client code from reusable, non-client materials.
Datasets and data extracts
We seek to use the minimum data reasonably required for the agreed work. De-identification, masking, synthetic data, restricted samples, or client-hosted analysis may be considered where appropriate and feasible.
Models, prompts, and analytical outputs
Model artefacts, prompts, evaluation results, notebooks, reports, and derived insights are treated according to the engagement terms, data classification, approved environment, and ownership provisions.
Reports and business documents
Briefs, presentations, financial files, operating documents, and strategic materials are limited to assigned contributors and exchanged through agreed channels.
Cloud platforms and client systems
Where work occurs in a client environment, access follows the client’s account, logging, network, approval, and change-management requirements, subject to the agreed delivery model.
Intellectual property
Ownership of inputs, deliverables, and reusable know-how
The signed contract should distinguish client materials, project-specific deliverables, pre-existing tools and methods, third-party content, open-source components, licensed software, generic templates, and knowledge that is independently developed without using client confidential information.
Where ownership is transferred or licensed, the terms should define scope, timing, payment dependencies, permitted use, attribution, moral rights where relevant, and any exclusions. Confidentiality and ownership are related but separate legal concepts.
Confidentiality lifecycle
A structured path from initial discussion to engagement closure
The sequence creates decision points for legal, procurement, security, privacy, technical, and delivery stakeholders.
Agree
Define confidentiality terms, information types, approved tools, access boundaries, ownership, retention, and engagement-specific responsibilities.
Classify
Identify sensitivity and handling expectations so that access and exchange methods reflect the information involved.
Limit
Provide assigned personnel with only the access reasonably required for their role and remove access when responsibilities change.
Exchange
Use approved project channels and avoid unnecessary duplication, personal accounts, or unapproved storage locations.
Review
Revisit access, workspace, deliverables, and open items during project changes, handovers, or completion.
Close
Return, transfer, retain, or delete information according to the contract, applicable obligations, and technically feasible process.
Engagement completion
Return, transfer, retention, or deletion of client information
At closure, the parties should confirm final deliverables, client access, account ownership, repositories, open credentials, retained records, deletion requests, legal holds, backups, and any continuing support needs.
Deletion may be subject to technically feasible processes, system and backup cycles, legal or financial record requirements, dispute preservation, security records, and other obligations. Where evidence of completion is required, the form and scope should be agreed contractually.
What this means for clients
Due diligence should connect written terms to the actual delivery model
Your review can focus on
- Who will access information and from where.
- Which systems, repositories, and collaboration tools will be used.
- Whether production, personal, regulated, or highly restricted data is necessary.
- How ownership, third-party tools, AI use, retention, and deletion are addressed.
- What evidence or documentation is needed before approval.
Your team remains responsible for
- Providing accurate classification, restrictions, policies, and legal requirements.
- Approving access, accounts, environments, data extracts, and exchange methods.
- Minimising shared information and removing obsolete permissions.
- Ensuring it has authority to disclose data and materials for the project.
- Promptly reporting changes, concerns, or suspected mishandling.
Scope and limitations
Exceptions, legal obligations, and important considerations
Confidentiality is not absolute. Signed terms and applicable law may permit or require limited use, retention, or disclosure in defined circumstances.
Common contractual exceptions
Information may be excluded if it is public without breach, already lawfully known, independently developed, lawfully received without restriction, or approved for release.
Required disclosure
A court, regulator, law-enforcement body, tax authority, or other lawful process may require disclosure. Notice and cooperation rights depend on law and contract.
No universal guarantee
This page does not promise a specific control, certification, legal outcome, deletion timeframe, or technical configuration for every engagement.
Related Trust Center pages
Continue your due-diligence review
Review related topics together because confidentiality, security, privacy, data protection, and ownership obligations often overlap.
Frequently asked questions
Confidentiality questions from legal, procurement, security, and technical teams
These answers provide general due-diligence context. Signed contracts and approved project documentation take precedence.
What information do you treat as confidential?
Confidential information may include data, source code, credentials, models, reports, business plans, personal information, system details, research, intellectual property, and other non-public information identified by the client or reasonably understood to be confidential. The applicable contract ultimately defines the scope.
Will you sign a non-disclosure agreement before reviewing our materials?
We can discuss an NDA or confidentiality terms before sensitive information is shared. The appropriate document and timing depend on the opportunity, jurisdiction, parties, and intended engagement. Any commitment becomes binding only when agreed in writing by authorised representatives.
Are employees, contractors, and specialists subject to confidentiality obligations?
Personnel assigned to confidential work should be subject to relevant confidentiality obligations through employment, contractor, platform, policy, or project terms as applicable. The precise structure should be confirmed for the proposed delivery model.
How do you apply need-to-know access?
Access is intended to be limited to people who require the information for their assigned responsibilities. The practical method may include project membership, role-based permissions, client-controlled accounts, repository permissions, workspace restrictions, and access removal when work changes or ends.
Can our work be separated from other client projects?
Project separation can include distinct workspaces, folders, repositories, accounts, communication channels, permissions, and delivery records. The exact controls depend on the tools, hosting model, client requirements, and agreed scope.
How should we send datasets, credentials, or source code?
The parties should agree an approved exchange method before sensitive material is sent. Depending on the engagement, this may involve client-managed repositories, secure file-sharing tools, controlled cloud environments, password managers, or other approved channels. Avoid sending credentials in ordinary email or chat unless expressly approved.
Can work remain inside our cloud or technology environment?
Where technically and commercially feasible, an engagement may use client-managed accounts, repositories, virtual desktops, analytics platforms, or cloud environments. This option depends on access, licensing, architecture, support, performance, and contractual requirements.
How do you handle confidential information in remote delivery?
Remote delivery requires clear workspace, device, communication, access, screen-sharing, storage, and location expectations. Engagement-specific controls should be agreed where the sensitivity of the information or client policy requires additional restrictions.
Who owns the deliverables and intellectual property?
Ownership is determined by the signed contract. Terms should distinguish client-provided materials, project-specific deliverables, third-party components, open-source software, pre-existing tools or know-how, and general skills or methods that are not derived from client confidential information.
Do you use client information to train public AI models?
No blanket statement should be assumed across every tool or engagement. Use of AI-enabled services, model providers, prompts, retention settings, and training controls must be reviewed and agreed for the specific project. Sensitive information should not be entered into an unapproved AI service.
What happens to our information when the engagement ends?
The contract or closure plan should define whether information is returned, transferred, retained, archived, or deleted. Some limited retention may be necessary for legal, financial, dispute, backup, security, or record-keeping purposes. Technical deletion may also follow system and backup cycles.
Can you provide evidence for a procurement or legal review?
We can discuss available policies, process descriptions, contractual terms, questionnaires, and supporting documentation relevant to the proposed engagement. Availability, confidentiality, and level of detail may vary, and documentation should not be treated as a certification unless expressly identified as one.
Are there exceptions to confidentiality?
Contracts commonly address information that is public, independently developed, lawfully received from another source, already known without restriction, approved for release, or required to be disclosed by law. Exact exceptions and notification rights depend on the signed terms and applicable law.
Does this webpage create a legal obligation or guarantee?
No. This page explains a general approach for due diligence and discussion. Binding duties, warranties, service levels, remedies, and engagement-specific controls arise only from executed contracts and approved project documentation.
Confidentiality discussion
Request an NDA or discuss your information-handling requirements.
Share the proposed scope, information categories, delivery environment, stakeholders, and review requirements. We can then identify the contractual and operational questions that need resolution before sensitive materials are exchanged.
Do not include confidential data, credentials, personal information, source code, or proprietary documents in an initial contact message.