Trust Center · Infrastructure and Technology
Technology choices shaped by your data, risk, architecture, and operating needs.
We use a practical, engagement-specific approach to cloud, data, analytics, AI, development, access, and operational tooling. This page explains the technology categories and technical practices that may support delivery—without presenting a fixed stack or promising universal availability.
Technology selection, hosting, access, monitoring, support, and responsibility allocation are confirmed for each engagement.
Executive summary
A transparent view of the technical foundation
Our data consulting technology infrastructure is not a single predefined product. It may combine client-owned systems, cloud services, databases, analytics platforms, engineering tools, model services, repositories, and operational controls selected for a specific business need.
Before delivery, the parties should clarify where work will occur, who controls the environment, which data may be used, what access is required, how changes are reviewed, and who is responsible after handover.
Technology categories
Platforms and environments that may support delivery
The following names are representative examples. They are not endorsements, exclusive partnerships, certifications, reseller claims, or guarantees that a specific technology will be available for an engagement.
Public-cloud, private-cloud, hybrid, and client-controlled environments may support storage, processing, orchestration, analytics, and application workloads.
- Amazon Web Services
- Microsoft Azure
- Google Cloud
- Client-managed private or hybrid environments
Selection consideration: Platform choice depends on the client’s architecture, residency requirements, commercial model, operating capability, and existing contracts.
Databases, warehouses, and lakehouses
Engagements may use relational, document, analytical, distributed, warehouse, lake, or lakehouse technologies to organise and serve data.
- PostgreSQL and MySQL
- Microsoft SQL Server and Oracle
- Snowflake, BigQuery, Redshift, and Azure data services
- Databricks and open data-lake technologies
Selection consideration: Selection is based on workload shape, scale, governance, latency, interoperability, cost, and the client’s support model.
Analytics and business intelligence
Reporting, semantic modelling, dashboards, exploration, and decision-support solutions may be delivered using client-approved analytics platforms.
- Microsoft Power BI
- Tableau
- Looker and Looker Studio
- Qlik, Apache Superset, and custom reporting interfaces
Selection consideration: Availability depends on licensing, data access, integration constraints, user roles, and the intended operating model.
AI and machine learning platforms
AI work may involve model development, managed AI services, notebooks, feature pipelines, model APIs, evaluation tools, and human-review workflows.
- Azure AI and Azure Machine Learning
- Google Vertex AI
- AWS AI and machine learning services
- Open-source frameworks and client-approved model providers
Selection consideration: Model, data, provider, and deployment choices require engagement-specific review of use case, risk, privacy, licensing, human oversight, and client policy.
Development and collaboration environments
Teams may use local, virtual, cloud-hosted, containerised, notebook, or client-provided environments for engineering and analytical work.
- Visual Studio Code and approved IDEs
- Jupyter-based environments
- Containers and reproducible development workspaces
- Client-managed virtual desktops or secure workstations
Selection consideration: Environment design is adapted to access restrictions, data sensitivity, delivery scope, segregation needs, and client controls.
Version control and CI/CD
Where suitable, source code, configuration, infrastructure definitions, and data transformation logic may be managed through controlled repositories and deployment workflows.
- Git-based repositories
- Pull or merge request review
- Automated testing and quality checks
- Approval-based deployment pipelines
Selection consideration: Branching, review, testing, release, and rollback practices are agreed according to the project and the client’s delivery standards.
Technical practices
Controls that support maintainable and accountable delivery
These practices are applied where relevant to the scope and environment. They should not be interpreted as universal controls or as evidence of a certification or audit.
Monitoring and logging
Where included in scope, monitoring may cover workload health, job execution, error conditions, data-quality signals, service dependencies, and operational logs. Alert ownership, retention, access, and escalation are agreed for each environment.
Identity and access
Access should be role-based, limited to the work required, and aligned with client approval processes. Authentication, account lifecycle, privileged access, and review frequency depend on the hosting and operating model.
Secrets management
Credentials, tokens, certificates, and connection details should not be embedded in source code. Approved vaults, environment variables, managed identities, or client-controlled secret stores may be used where applicable.
Environment separation
Development, test, staging, and production environments may be separated to reduce accidental change and support controlled promotion. The exact pattern depends on scope, risk, client architecture, and operational maturity.
Technology selection
How a suitable option is evaluated
A documented selection process helps stakeholders distinguish technical preference from business necessity, contractual obligation, and operating reality.
Clarify
Define the use case, users, outcomes, constraints, and decision criteria.
Assess
Review architecture, data, access, risk, privacy, security, and operations.
Compare
Evaluate feasible options for fit, cost, maintainability, and dependency.
Approve
Confirm client approval, licensing, provider terms, responsibilities, and scope.
Document
Record assumptions, configuration boundaries, handover, and review points.
Decision checklist
Criteria used to challenge and justify a technology choice
Business and user outcome
The technology must support a defined analytical, operational, regulatory, or customer outcome rather than exist as an isolated technical choice.
Architecture fit
Compatibility with current platforms, integration patterns, data models, identity systems, networking, and support processes is considered.
Security and privacy needs
Data classification, location, access, logging, segregation, provider terms, and client policy influence the available options.
Scale and performance profile
Volume, velocity, concurrency, latency, resilience, and batch or real-time requirements are evaluated without making unsupported performance guarantees.
Cost and commercial model
Licensing, consumption, support, data movement, operational effort, and expected lifecycle cost should be understood before selection.
Skills and maintainability
The client’s delivery capability, documentation needs, handover model, support capacity, and risk of avoidable lock-in are considered.
Hosting and operational model
Client-hosted and consultant-managed environments
The preferred model should be agreed before data, code, credentials, or production access is provided.
| Area | Client-hosted environment | Consultant-managed environment | Decision required |
|---|---|---|---|
| Account and platform control | Normally controlled by the client under its existing tenancy, network, identity, and policy structure. | May be administered by us or an approved provider within a separately agreed scope. | Confirm owner, administrator, billing account, permitted services, and termination process. |
| Data location and access | Client determines approved data stores, user access, and connection methods. | Location, access, permitted data, transfer method, and retention require explicit approval. | Document data classification, residency needs, access route, and prohibited data. |
| Security configuration | Client controls baseline configuration; we follow assigned permissions and project requirements. | Configuration responsibilities must be allocated between us, the client, and the provider. | Define identity, logging, secrets, hardening, patching, backup, and review ownership. |
| Deployment and operations | Client release, change, incident, and operational processes normally apply. | Deployment, monitoring, support, escalation, and handover are included only if contracted. | Agree approval gates, support window, incident route, and post-delivery ownership. |
| End of engagement | Client retains its environment and determines account removal and artifact retention. | Export, transfer, deletion, access removal, and closure should follow agreed instructions. | Confirm deliverables, repository ownership, credential revocation, and retention actions. |
Shared responsibility
Cloud and technology providers remain part of the control environment
Using a platform does not transfer every obligation to that provider. Responsibility depends on the service model, configuration, contract, data, user access, and the activities allocated to each party.
Technology provider
Operates the underlying service according to its own documentation, terms, security model, regional availability, and service boundaries. Provider controls should be assessed rather than assumed.
Client
Retains responsibility for business decisions, account ownership, lawful use, data classification, user approval, configuration choices, policies, and acceptance of the proposed architecture.
Our delivery team
Is responsible for the work, access, configuration, code, documentation, and operational duties explicitly assigned to us, subject to the approved environment and engagement terms.
Important considerations and limitations
Technology names are examples, not a complete catalogue. Capabilities, provider services, licensing, regional availability, terms, prices, APIs, and product features can change. Final architecture and control statements must be verified for the specific engagement. This page does not constitute a contractual commitment, security certification, legal opinion, uptime promise, performance guarantee, or representation that every listed platform is currently available.
Related Trust Center pages
Continue your technical and supplier review
Frequently asked questions
Infrastructure and technology due-diligence questions
These answers provide general context. Engagement-specific architecture, controls, responsibilities, and documentation take precedence.
Do you use a fixed technology stack for every data consulting engagement?
No. We select technologies according to the client’s existing environment, objectives, data sensitivity, architecture, commercial constraints, support capability, and agreed scope. The examples on this page are illustrative and do not guarantee availability for every engagement.
Can you work inside our existing cloud or technology environment?
Where access, contractual terms, security controls, and technical prerequisites allow, work may be completed in a client-hosted environment. Roles, permissions, connectivity, logging, software installation, and support responsibilities should be agreed before delivery begins.
Can you provide a consultant-managed environment?
A consultant-managed environment may be considered where appropriate, but it is not assumed. The decision depends on the engagement, data classification, hosting arrangement, approved providers, access model, cost allocation, retention requirements, and contractual terms.
Which cloud platforms do you support?
Engagements may involve major public-cloud platforms, private-cloud systems, hybrid environments, or client-managed infrastructure. Support is subject to current team capability, required services, client approvals, licensing, and the agreed statement of work.
How do you choose between a database, warehouse, data lake, or lakehouse?
The choice depends on the data types, workload, scale, latency, governance, analytical needs, integration requirements, operating model, and cost. A combination may be appropriate, and the recommendation should be documented against the client’s priorities.
Do you support Power BI, Tableau, Looker, or other BI platforms?
We may support these and other analytics platforms where the required skills, access, licensing, and project conditions are available. The page lists examples rather than endorsements, exclusive partnerships, or guaranteed capability.
Can generative AI or external model providers be used with our data?
Only where the use case, client approval, provider terms, data handling, privacy implications, access model, retention settings, and human oversight are considered acceptable for the engagement. Sensitive or restricted data should not be sent to an unapproved service.
How are credentials and secrets handled?
Our approach is to avoid placing secrets in code or documentation and to use approved secret-management methods where applicable. The actual control depends on whether the environment is client-hosted, consultant-managed, or provided by a technology vendor.
Do you separate development, test, and production environments?
Environment separation may be used to support controlled change and reduce unintended impact. The number of environments, access boundaries, data used in each, deployment method, and approval process are defined according to scope and risk.
Do you provide monitoring and ongoing operational support?
Monitoring, alerting, incident handling, maintenance, and managed support are included only when explicitly agreed. The responsible party, service window, escalation route, tooling, log access, and retention should be documented in the engagement terms.
Who is responsible for cloud-provider or software-provider security?
Responsibility is shared. Technology providers operate their services under their own terms and controls; clients retain responsibilities for their accounts, configurations, data, users, and policies; and we are responsible for the activities assigned to us within the agreed scope.
Can you follow our coding, repository, and deployment standards?
Yes, where the standards are supplied, technically workable, and included in scope. Repository access, code review, testing, documentation, release approval, and deployment rights should be clarified during onboarding.
Do the technologies listed mean you are certified partners or authorised resellers?
No. A technology name on this page is an example of a platform category that may be relevant to delivery. It does not state partnership, certification, endorsement, reseller status, or guaranteed availability.
What technical documentation can be requested during procurement?
Subject to relevance, availability, confidentiality, and approval, clients may request architecture notes, responsibility assignments, environment assumptions, access requirements, technology selections, data-flow information, delivery procedures, or other engagement-specific documentation.
Technical review
Contact the Trust Team
Discuss Technical Requirements
Share your current environment, approved platforms, data classification, access constraints, architecture standards, operational expectations, and procurement questions. We can use that context to define a suitable technical approach and identify the documentation needed for review.
Documentation is provided subject to relevance, availability, confidentiality, and approval.