Credentials & access tokens
Use an agreed transfer method, limit to the required purpose and plan rotation or withdrawal when access is no longer needed.
Client administrators retain account responsibilities unless agreed otherwise Trust Center · Confidentiality
Confidentiality for Responsible Data, Analytics and AI Delivery
DataConsultant approaches confidential client information as an engagement responsibility that should be defined before transfer, limited to an approved purpose, accessed on a need-to-know basis, exchanged through agreed channels and addressed deliberately at project close.
Contractual confidentiality and NDA review
Need-to-know access aligned to assigned work
Project separation and approved collaboration
Return, retention or deletion decisions at close
This page describes a general confidentiality approach for due diligence. Binding obligations, technical measures and retention requirements are established through applicable law, signed agreements and approved engagement documentation.
Confidentiality Handling LifecycleEngagement specific
Why confidentiality matters
Sensitive information can lose protection through ordinary delivery decisions.
Confidentiality risk is not limited to deliberate disclosure. It can arise through excessive access, unapproved tools, unnecessary copies, unclear ownership, cross-project exposure, remote-working practices or incomplete closure.
Unclear handling
creates exposure
creates exposure
Excessive access
Unapproved sharing
Code copied outside scope
Credential mishandling
Restricted data used in AI
Access not closed out
Defined boundaries
support confidence
support confidence
From uncertainty to controlled handling
Make confidentiality decisions before sensitive material enters the workflow.
A structured approach reduces ambiguity for legal, procurement, security, privacy and delivery teams.
Current state · high uncertainty
Informal sharing
- Classification is not explicit
- Recipients and purpose are unclear
- Tools and locations are assumed
- Retention is left until project close
Target state · discussion ready
Defined handling
- Covered information is identified
- Need-to-know access is agreed
- Approved environments are recorded
- Return, deletion or retention is planned
Scope and assurance framework
What confidentiality can cover—and the decisions that govern it.
The exact definition comes from the applicable contract. In data, analytics and AI work, confidentiality can span technical, commercial, personal and proprietary material.
Datasets & extracts
Source code & repositories
Credentials & tokens
Architecture & configurations
Models, prompts & evaluations
Reports & business documents
Stakeholder information
Intellectual property & know-how
Cloud & platform records
Audit, review & project evidence
Purpose & scopeWhy the information is needed and what work it supports
Contractual termsNDA, confidentiality clauses and client requirements
People & accessAssigned roles, approvals and need-to-know boundaries
Approved environmentsRepositories, systems, channels and client-controlled workspaces
Confidentiality
Assurance
Assurance
Sharing & disclosureAuthorised recipients, onward sharing and required disclosure
Third partiesPlatform, supplier and specialist involvement where applicable
Retention & closureReturn, deletion, retention, access removal and ownership
Review & evidenceProject records, due-diligence responses and exception decisions
Classification and handling
Handling should become more deliberate as sensitivity increases.
This illustrative matrix supports scoping discussions. The client’s classification policy and signed engagement terms take precedence.
| Illustrative level | Examples | Handling consideration | Access / sharing decision | Closure decision |
|---|---|---|---|---|
| Public | Published webpages, approved marketing material, public datasets | Normal business handling; source, licence and release status still matter | Confirm that publication or onward use is authorised | Follow ordinary record or project requirements |
| Internal | Non-public drafts, routine project notes, internal operating information | Limit to relevant project participants and approved channels | Define whether external or onward sharing is permitted | Remove obsolete access and unnecessary working copies |
| Confidential | Client datasets, code, roadmaps, architecture, financials, reports | Need-to-know access, controlled exchange and defined workspace | Specify tools, locations, recipients and permitted purpose | Apply agreed return, deletion or retention treatment |
| Highly restricted | Production credentials, sensitive personal data, trade secrets, regulated records | Additional controls or client-hosted work may be required before transfer | Narrow access; confirm legal, security and contractual conditions first | Document access removal and any retained dependency or obligation |
Illustrative only. This page does not assert a universal DataConsultant classification standard or a fixed control set for every engagement.
From business requirement to handling decision
Translate what the project needs into explicit confidentiality requirements.
Useful due diligence connects the business purpose to concrete decisions about information, people, systems, contracts and evidence.
Business purposeWhat are we trying to achieve?
InformationWhat data, code, records or intellectual property are genuinely needed?
ClassificationHow sensitive is it and what client policy applies?
PeopleWho needs access, and for which responsibilities?
EnvironmentWhere may the work, storage and collaboration occur?
ContractWhich NDA, confidentiality, IP or data terms control?
Third partiesWhich platforms, providers or specialists are involved?
ClosureWhat should be returned, deleted, retained or de-provisioned?
EvidenceWhat does procurement, legal, privacy or security need to review?
Confidentiality-ready means defined before transfer
Request a Confidentiality Review →
Do not use sensitive information to discover the handling rules.
Start with scope, classifications, contractual requirements and environment choices. Then agree how confidential material can enter the engagement.
Governance and shared responsibility
Confidentiality depends on coordinated responsibilities, not one party acting alone.
The signed agreement remains controlling. This matrix shows common responsibility areas for a data, analytics or AI engagement.
| Area | Client | DataConsultant | Technology provider / other third party | Shared review |
|---|---|---|---|---|
| Classification Sensitivity and restrictions | Defines client classifications, restrictions and authority to disclose | Uses supplied classification and engagement requirements to shape handling | Provides platform capabilities and contractual conditions relevant to use | ✓ Confirm categories before material access |
| Access Accounts and permissions | Approves client-system access and removes obsolete access where client controlled | Seeks access appropriate to assigned responsibilities and approved work | Operates underlying identity or platform controls where provider managed | ✓ Review changes in role, phase or scope |
| Environment Repositories and tools | Identifies required or prohibited platforms and client-hosted environments | Uses agreed delivery environments and avoids unapproved destinations | Provides infrastructure or product capabilities according to its service | ✓ Clarify logging, backup, storage and admin responsibilities |
| Contract NDA, IP and confidentiality | Provides client-specific legal and procurement requirements | Reviews proposed terms and works within agreed obligations | May impose separate service terms, licences or data-use conditions | ✓ Resolve conflicts before sensitive work begins |
| Closure Return, retention, disposal | Provides instructions and removes client-managed permissions | Addresses close-out actions within agreed responsibilities | May retain provider-controlled backups or records under separate terms | ✓ Record outstanding dependencies and ownership |
Secure collaboration model
Confidentiality controls should follow the information through the working environment.
The diagram is a conceptual assurance model—not a representation of one fixed DataConsultant production architecture.
Users / Client Stakeholders
Client / Enterprise Systems
High-value project assets
Different information types create different confidentiality questions.
The right handling pattern depends on the asset, sensitivity, environment, contract and work being performed.
Source code & repositories
Define repository access, contribution workflow, branch permissions and where code may be copied or processed.
Separate client code from reusable non-client materialDatasets & extracts
Use only the information reasonably required for the agreed work and consider masking, sampling, aggregation, synthetic data or client-hosted analysis where practical.
Minimise unnecessary production-data exposureModels, prompts & analytical outputs
Align model artefacts, prompts, evaluation results and derived insights with approved tools, data classifications, ownership terms and client instructions.
AI use should not bypass confidentiality restrictionsReports & business documents
Limit strategic, financial, operational and project documents to relevant contributors and approved exchange channels.
Audience and onward sharing should be explicitClient systems & cloud platforms
Where work occurs in a client environment, handling should follow the agreed account, logging, network, change and access model.
Do not imply control of provider- or client-operated infrastructure
Disclosure, exceptions and escalation
Confidentiality is governed by the contract and applicable law—not by an absolute promise.
Questions about permitted disclosure, suspected mishandling, compelled disclosure or scope changes should be routed for review rather than resolved informally.
01
Identify
Record the information, event or requested disclosure.
02
Contain
Limit further sharing or access where appropriate and authorised.
03
Assess
Review contract, client instructions, legal context and affected systems.
04
Coordinate
Involve the relevant client, legal, privacy, security or delivery stakeholders.
05
Close & learn
Document decisions, remediation and any required process change.
Retention, return and close-out
Closure should be designed into the engagement—not treated as an afterthought.
Retention and disposal decisions depend on contracts, client instructions, legal or operational obligations, ownership and technology dependencies. This page does not claim a universal retention period.
1Confirm scope completionIdentify completed work and remaining obligations
2Review accessAccounts, permissions, repositories and shared workspaces
3Classify remaining materialDeliverables, records, code, data and evidence
4Apply instructionsReturn, deletion, retention or anonymisation where agreed
5Address dependenciesBackups, third parties, legal records or support needs
6Record completionDocument outstanding items and responsible owners
7Review changesCapture lessons for future engagement handling
Assurance access and due diligence
Provide enough information for review without exposing unnecessary security-sensitive detail.
Different reviewers need different evidence depths. Some information can be public; other material may require relevance review, confidentiality terms or client-specific discussion.
Public informationTrust Center explanations suitable for unrestricted review
Trust Center detailExpanded handling, responsibility and lifecycle explanations
Process evidenceAvailable supporting information that may require review before disclosure
Restricted assuranceSecurity-sensitive or confidential material where controlled access may be appropriate
Client-specific due diligenceQuestionnaires, contractual requirements and engagement-specific review
How a confidentiality assurance request can progress
Use the Trust Team route to explain the decision your organisation needs to make. Avoid sending sensitive evidence in the initial message.
1 · State the review purposeProcurement, legal, security, privacy, architecture or supplier due diligence
2 · Identify the engagementService scope, information categories, systems, locations and stakeholder group
3 · Request the right levelQuestionnaire response, document discussion or clarification of a confidentiality requirement
Engagement checkpoints
Revisit confidentiality when the work, people, systems or data change.
Confidentiality decisions can become stale as an engagement evolves. Review points should follow meaningful changes rather than rely on one initial approval.
1ScopePurpose, information, legal and client requirements
2OnboardPeople, accounts, environments and approved channels
3AccessPermissions, data transfer and working boundaries
4ChangeNew data, systems, third parties or work locations
5ReviewIssues, exceptions, evidence and stakeholder questions
6HandoverDeliverables, ownership and remaining information
7CloseAccess removal, return, deletion, retention and record
Related Trust Center topics
Continue the review across security, privacy, delivery and evidence.
Confidentiality overlaps with—but does not replace—security, privacy, secure delivery and formal due-diligence review.
Frequently asked questions
Confidentiality questions from legal, procurement, security and delivery teams.
These answers support initial review. Engagement-specific requirements should be confirmed through the appropriate contractual and technical process.
What does confidentiality cover in a DataConsultant engagement?
Confidentiality can apply to client data, source code, credentials, architecture, reports, models, prompts, project documentation, intellectual property, commercial information and other non-public material covered by the applicable agreement or client instruction. The signed contract controls the precise definition for an engagement.
Can DataConsultant discuss or sign an NDA?
Yes. Mutual or client-provided non-disclosure terms can be reviewed through the appropriate commercial and legal process. Acceptance depends on the parties, scope, permitted purpose, exclusions, duration, disclosure obligations and other contract terms.
How is access to confidential information approached?
Our approach is to align access with the work a person is assigned to perform and to avoid unnecessary access. Exact account, permission, approval and review arrangements depend on the client environment, delivery model and agreed responsibilities.
How can information be separated between client engagements?
Separation may use distinct repositories, workspaces, folders, accounts, permissions, channels, client-controlled environments or procedural boundaries. The appropriate method depends on the platform, sensitivity, service model and client requirements.
Can highly restricted information be used in an engagement?
Potentially, but it should not be shared until the need, classification, approved environment, access model, contractual terms and handling requirements have been reviewed. A lower-risk alternative such as masking, sampling, synthetic data or client-hosted analysis may be preferable where practical.
What happens to confidential information at project close?
Return, deletion, retention, access removal and ownership decisions should be addressed according to the signed agreement, client instructions, project records and any applicable legal or operational requirements. No universal deletion period is represented on this page.
How are third parties considered?
Where a platform, provider, specialist or other third party may receive access to confidential information, its role should be identified and reviewed in the context of the engagement. Client approval, contract terms, technical design and supplier controls may affect whether and how that third party is used.
What should we send in an initial confidentiality enquiry?
Share the proposed engagement, the categories of information involved, the intended delivery environment, relevant client requirements and the review question. Do not send passwords, access tokens, source code, confidential datasets or other sensitive evidence through an initial general enquiry.
Does this page create a confidentiality guarantee?
No. This page explains a general approach for due diligence and scoping. Binding confidentiality obligations, technical measures, retention requirements, permitted disclosures and remedies are established only through applicable law, signed agreements and approved engagement documentation.
Next assurance step
Discuss confidentiality before sharing sensitive client information.
Provide the proposed scope, information categories, delivery environment, stakeholders and review requirements. The Trust Team can help identify the contractual and operational questions that need resolution.
Do not include confidential data, credentials, private keys, source code, personal information or proprietary documents in an initial contact message.