Collection
Define the purpose, source, expected fields and minimum data required before information is received.
Trust Center · Data Protection
Protecting data through clear controls, limited access and shared responsibility.
Our data-protection approach considers how information is collected, transferred, stored, accessed, used, retained and deleted across data consulting, analytics, engineering, AI, reporting and managed-service engagements.
Safeguards vary by engagement, data classification, client environment, selected technology, contractual terms and applicable requirements. This page describes our approach and is not a certification statement or legal advice.
Executive summary
Practical protection starts with scope clarity.
Data safeguards are most effective when technical controls, delivery practices and contractual responsibilities are designed together. Before work begins, relevant stakeholders should understand what data is involved, why it is needed, where it may be processed and who controls each environment.
Our role is engagement-specific. We may operate inside a client environment, use an agreed platform, provide recommendations or manage defined delivery activities. Controls must therefore reflect the actual operating model rather than a generic checklist.
- ✓Purpose limitation
Use data for defined delivery objectives. - ✓Data minimisation
Request only information needed for the scope. - ✓Least privilege
Restrict access by role, task and duration. - ✓Approved locations
Use agreed repositories and transfer channels. - ✓Lifecycle awareness
Plan retention, return and deletion early. - ✓Documented dependencies
Record platform and client responsibilities.
Data protection across the lifecycle
Each stage introduces different decisions. The appropriate measures depend on sensitivity, purpose, access model, architecture and client requirements.
Transfer
Select approved transfer methods and confirm the intended sender, recipient, location and access conditions.
Storage
Use agreed repositories and configurations suited to the sensitivity, engagement scope and selected platforms.
Access
Limit access according to role, task and duration, with client-controlled permissions where the client owns the environment.
Use
Use information only for agreed delivery activities, analysis, development, reporting or support purposes.
Retention
Align retention with contractual, operational, legal and client requirements rather than retaining data without purpose.
Deletion
Apply agreed deletion or return steps at milestones, account closure or engagement completion, subject to system constraints.
Safeguards considered in data and AI delivery
These measures are platform-neutral and should be confirmed against the systems, service tiers and responsibilities selected for each engagement.
Encryption considerations
Where supported by the selected systems, data may be protected in transit and at rest using platform or client-configured encryption capabilities. Exact methods depend on the architecture, service tier and contractual scope.
Why this matters: Helps reduce exposure if data is intercepted or storage is accessed without authorisation.
Keys and credentials
Credentials should be individual, purpose-limited and stored through approved secret or credential-management methods. Shared credentials, embedded secrets and unnecessary long-lived access should be avoided where practical.
Why this matters: Reduces reliance on informal credential sharing and improves accountability.
Secure file transfer
Transfer channels are selected according to data sensitivity and client requirements. Approved managed portals, client repositories or protected platform features may be used instead of uncontrolled personal channels.
Why this matters: Keeps file movement within known, reviewable workflows.
Database and warehouse safeguards
Safeguards may include role-based access, separate service accounts, network restrictions, logging, environment separation, query controls and change review, depending on the systems selected for the engagement.
Why this matters: Protects high-value structured data and limits broad or persistent access.
Cloud configuration
Cloud storage and data-platform settings should be reviewed for identity access, public exposure, sharing rules, region choices, logging, lifecycle rules and client-defined governance requirements.
Why this matters: Many cloud risks arise from configuration choices rather than the platform alone.
Backup and recovery
Backup arrangements are defined by the system owner and service design. Where included, backup access, retention, restoration testing and deletion dependencies should be considered in the engagement plan.
Why this matters: Supports recoverability while recognising that backups can extend the data lifecycle.
Masking and de-identification
Data masking, anonymisation or pseudonymisation may be applied where appropriate to the use case. The selected technique depends on whether identity must be reversible, linkable or fully removed.
Why this matters: Can reduce exposure of direct identifiers during analysis, sharing or testing.
Development and testing
Production data should not be copied into development or testing by default. Where its use is necessary and approved, the scope, access, masking, retention and cleanup requirements should be documented.
Why this matters: Test environments often have different users, tools and retention patterns.
Secure disposal
Deletion or return activities should cover working files, exports, temporary copies, collaboration locations and applicable backups, subject to platform behaviour and contractual retention obligations.
Why this matters: Reduces residual exposure after the information is no longer needed.
What this means for clients
Our approach is designed to make due diligence and delivery decisions clearer, while recognising that effective protection depends on all parties.
Better scoping
Data categories, locations, access paths and responsibilities can be discussed before technical work begins.
Controlled access
Access can be matched to delivery needs, with client approval for client-owned platforms and sensitive systems.
Clear evidence requests
Procurement and security teams can request available policies, process descriptions or engagement-specific documentation.
Shared accountability
Client, consultant and provider obligations can be documented instead of being assumed or left implicit.
Important considerations
This page describes general practices and decision areas. It does not confirm that every control is implemented in every engagement, platform or client environment.
- Exact encryption, logging, backup and deletion behaviour depends on selected systems and configurations.
- Client instructions must be lawful, authorised and consistent with applicable contractual obligations.
- Anonymisation is context-dependent and should not be assumed merely because direct identifiers are removed.
- Copies held in backups, archives or third-party systems may follow separate lifecycle rules.
Information to confirm during due diligence
- Data categories, sensitivity, ownership and intended purpose.
- Processing locations, approved tools and transfer mechanisms.
- Required access roles, authentication and account ownership.
- Retention, legal hold, return and deletion expectations.
- Incident contacts, escalation paths and evidence requirements.
- Any sector-specific, contractual or regulatory constraints.
Related Trust Center pages
Review connected topics that may be relevant to supplier evaluation, privacy review and delivery planning.
Data protection questions
Answers for procurement, legal, privacy, security and technical stakeholders evaluating a potential engagement.
What does data protection for data consulting cover?
It covers the practical and contractual handling of information across collection, transfer, storage, access, use, sharing, retention, backup, return and deletion. The exact safeguards depend on the data, platforms, engagement model and client requirements.
Do you guarantee that client data is completely secure?
No organisation can responsibly promise absolute security. Our approach is to define appropriate safeguards, reduce unnecessary access, use approved systems and document dependencies and shared responsibilities.
Is data encrypted in transit and at rest?
Encryption may be used where supported and configured in the selected client, cloud or collaboration systems. The exact protocols, key ownership and coverage must be confirmed for each engagement and platform.
Can we require work to remain inside our environment?
Yes, this can be considered during scoping. Feasibility depends on the tools, access methods, licensing, performance needs, delivery model and whether the client environment supports the required work.
How is production-data access controlled?
Production access should be limited to approved people, purposes and time periods. Client-owned environments normally remain under client account and permission controls, while consultant access follows the agreed delivery process.
Do you use production data for development or testing?
Production data should not be used by default. Where its use is necessary, the reason, approval, environment, access, masking, retention and cleanup steps should be documented before use.
What is the difference between masking, anonymisation and pseudonymisation?
Masking changes how values are displayed or used. Pseudonymisation replaces identifiers while allowing controlled re-linking. Anonymisation aims to prevent identification. Suitability depends on the dataset and intended use.
Who manages encryption keys and credentials?
Ownership depends on the architecture. Keys and credentials may be controlled by the client, the selected platform or an approved engagement-specific process. Responsibilities should be documented before access is provided.
How are files transferred securely?
The agreed method may use a client repository, managed transfer portal, protected cloud location or another approved system. Uncontrolled personal channels should be avoided for confidential or sensitive information.
How long is client data retained?
Retention is engagement-specific and should reflect contract terms, operational needs, legal requirements, client instructions and system limitations. A single retention period should not be assumed for every project.
Can data be deleted immediately when requested?
Deletion timing depends on where the data exists, contractual obligations, legal holds, account controls, backups and platform behaviour. The practical deletion process should be agreed and documented.
Can procurement or security teams request supporting documentation?
Yes. Available documentation can be discussed during due diligence. Any policy, architecture, control evidence or contractual material shared must be current, approved and appropriate for the proposed engagement.
Request a Data Protection Discussion
Share your data categories, proposed systems, delivery model and due-diligence questions. We can discuss the intended scope, available documentation, responsibilities and engagement-specific safeguards without making assumptions about your requirements.