Skip to main content
Trust Center · Information Security

Security-conscious data consulting, explained with clarity.

Our approach is designed to help clients understand how access, data, devices, cloud environments, delivery workflows and shared responsibilities are considered across data consulting and Data & AI engagements.

This page describes general practices and considerations. Project-specific controls, contractual commitments and client-managed safeguards may differ.

Executive summary

Security is addressed through context, proportionate controls and accountable delivery.

Data analytics, engineering, business intelligence, AI, database, automation and managed-team work can involve different risk profiles. We therefore seek to understand the engagement before defining access, environments, data use and operational responsibilities.

  • Controls are selected according to the service, technology, data sensitivity and client requirements.
  • Client-controlled systems remain subject to client identity, configuration, approval and governance decisions.
  • Additional safeguards can be scoped where the engagement requires stronger restrictions or evidence.
Information security principles

A measured approach built around practical delivery decisions

These principles guide conversations about access, data, infrastructure, workforce behaviour and client dependencies.

Risk-aware by design

We consider access, data sensitivity, delivery environment and client requirements during scoping rather than treating security as a final-stage check.

Access with purpose

Access is intended to be limited to people and systems that need it for an approved delivery purpose, subject to the engagement model and available controls.

Data minimisation

We seek to use only the information reasonably required for the agreed work and encourage masking, sampling or synthetic data where practical.

Confidentiality in delivery

Confidential information is handled according to agreed scope, contractual terms, authorised workflows and client instructions.

Reviewable practices

We support security review through clear scoping, documented responsibilities and available evidence rather than unsupported assurance statements.

Shared responsibility

Security outcomes depend on both parties. Clients retain responsibilities for their environments, identities, permissions, configurations and decisions.

Operational and technical safeguards

How key security areas are considered

The following descriptions distinguish general practices from controls that depend on platform support, project scope or client configuration.

Identity and access management

Why this matters: Access decisions should connect a known identity to an approved business purpose.

  • Named user access is preferred where supported.
  • Access requirements are considered during onboarding and role changes.
  • Client-managed identities and access policies remain under client control.

Least privilege and role-based controls

Why this matters: Permissions should be proportionate to assigned work and reviewed when scope changes.

Multi-factor authentication

Why this matters: Additional authentication factors can reduce reliance on passwords alone.

  • MFA is used where supported by the relevant platform and account model.
  • Client-controlled systems follow client authentication configuration.
  • Exceptions or unsupported environments should be discussed during security review.

Endpoint and device security

Why this matters: Devices used for delivery should be maintained with practical safeguards appropriate to their use.

  • Operating system and software updates are expected to be managed.
  • Device access controls and screen locking are expected.
  • Local data storage should be limited and governed by engagement needs.

Network and cloud security

Why this matters: Cloud and network safeguards depend on architecture, provider capabilities and the agreed responsibility model.

  • Environment boundaries and access routes are considered during setup.
  • Client cloud configurations remain subject to client ownership and approval.
  • Project-specific controls may be defined for sensitive or regulated workloads.

Logging, monitoring and review

Why this matters: Relevant activity records can support oversight, investigation and operational review.

  • Logging depends on the platform, permissions and client environment.
  • Security-relevant events may be reviewed within the applicable operational process.
  • Retention, alerting and investigation duties should be agreed where material.

Workforce responsibilities

Why this matters: People remain central to secure delivery and are expected to follow approved handling practices.

  • Confidentiality and acceptable-use expectations apply to project work.
  • Security awareness is reinforced through role-appropriate guidance.
  • Suspected issues should be escalated through designated channels.

Backup and recovery safeguards

Why this matters: Recovery planning should reflect data ownership, system criticality and the chosen hosting model.

  • Backup responsibility is identified during solution and delivery planning.
  • Client-hosted systems generally remain subject to client backup controls.
  • Restore expectations and dependencies should be documented where relevant.
Secure development and delivery lifecycle

Security checkpoints from scope to handover

The level of formality varies by engagement, but the lifecycle helps teams identify decisions that should not be left implicit.

STEP 01

Scope and classify

Identify intended outcomes, data types, access needs, environments, dependencies and security-sensitive assumptions.

STEP 02

Approve access

Request proportionate access through the client or project process and record material responsibilities.

STEP 03

Build and review

Apply maintainable delivery practices, peer review, testing and change controls appropriate to the work.

STEP 04

Operate with visibility

Use available logs, issue tracking and review points to support delivery oversight and problem investigation.

STEP 05

Validate and hand over

Review agreed outputs, access, documentation, known limitations and ownership before transition or closure.

STEP 06

Close or continue securely

Remove or revise access where appropriate and agree ongoing support, retention, recovery and operational responsibilities.

What this means for clients

Security discussions can begin with concrete questions: what data is required, who needs access, where work occurs, which party controls the environment, what evidence is available and which obligations must be contractual.

  • Procurement teams receive clearer scope and responsibility information.
  • Security reviewers can identify project-specific follow-up questions.
  • Technology and data leaders can align controls with the actual architecture.
  • Delivery teams can avoid assumptions about ownership and access.

Security questionnaire and documentation support

We can review reasonable due-diligence requests and provide available, approved information that is relevant to the proposed service. Some material may require a confidentiality agreement, clarification of scope or internal approval.

  • Supplier and information-security questionnaires
  • Architecture and data-flow discussions
  • Access and responsibility summaries
  • Available policies or supporting documents, where approved
Shared-security model

Clear ownership reduces security gaps

This matrix is illustrative. Actual responsibilities should be confirmed for the selected service, hosting model, client environment and contract.

Illustrative responsibility matrix
AreaOur roleClient roleShared activity
Identity ownershipUse approved identities and assigned access for agreed work.Provision, approve and revoke access within client-controlled systems.Review access when scope, personnel or risk changes.
Cloud configurationWork within authorised environments and raise observed delivery risks.Own tenant, subscription, network, policy and privileged configuration decisions.Agree architecture boundaries and project-specific controls.
Data selectionUse the minimum data reasonably required for delivery.Confirm lawful authority, permitted use and data supplied for the engagement.Consider masking, sampling, synthetic data or restricted access where practical.
Backup and recoveryFollow the agreed delivery and handover process for project artefacts.Maintain backups for client-owned production systems unless otherwise contracted.Document recovery scope, retention, dependencies and testing expectations.
Incident coordinationEscalate suspected issues through the applicable internal and client channel.Lead response for client environments and required legal or regulatory decisions.Coordinate facts, containment actions, communications and lessons learned as agreed.

Scope and limitations

Controls can vary by project, client platform, location, service model, data classification, third-party dependency and contractual requirement. A control described as an approach should not be interpreted as universally deployed in every environment.

Client responsibilities

Clients should provide accurate requirements, appropriate authority, approved access, relevant data instructions and timely notification of changes. They remain responsible for decisions and configurations within systems they own or control unless expressly agreed otherwise.

Frequently asked questions

Information security questions from buyers and reviewers

These answers provide general context. Project-specific commitments should be confirmed through approved documentation and contract terms.

What does data consulting information security mean for an engagement?

It means considering access, data sensitivity, devices, environments, delivery methods, dependencies and shared responsibilities as part of project planning and execution. The exact controls depend on the service, client environment, data involved and contract.

Do you hold any information security certifications?

This page does not claim a certification, audit result or compliance status. Any certification or assurance document should be treated as confirmed only when it is explicitly supplied through an approved company source.

Is multi-factor authentication required for every system?

MFA is used where supported by the relevant platform, account type and engagement setup. Client-controlled systems remain subject to client configuration, and unsupported or exceptional cases should be discussed during security review.

How do you manage access to client data and systems?

Our approach is to request access that is proportionate to assigned work, use approved identities and revise access when the role or scope changes. Clients generally control provisioning and revocation within their own environments.

Do your team members receive unrestricted administrative access?

Administrative or broad access is not intended to be the default. Where elevated permissions are necessary, the requirement should be justified by the work, authorised through the relevant process and limited where the platform permits.

Can work be completed without production data?

Often, selected samples, masked records, synthetic data, read-only access or non-production environments can reduce exposure. Suitability depends on the analytical, engineering, AI, reporting or support task and should be agreed with the client.

How is security handled in cloud data projects?

Cloud security depends on architecture, provider services, identity design, network boundaries, logging, configuration ownership and the shared-responsibility model. Project-specific expectations should be documented before sensitive workloads are introduced.

What secure development practices do you follow?

Depending on scope, delivery may include peer review, testing, controlled changes, dependency consideration, secrets handling, environment separation and handover documentation. These practices are adapted to the technology, risk and client process.

Do you monitor all client environments?

No universal monitoring claim is made. Visibility depends on platform capabilities, permissions, contractual scope and operational ownership. Logging, alerting, retention and investigation duties should be agreed where they are material.

Who is responsible for backups and disaster recovery?

Responsibility follows the hosting and service model. Clients generally retain responsibility for client-owned production systems unless a contract states otherwise. Project documentation should identify backup, restore, retention and recovery dependencies.

How are security incidents reported?

Suspected issues should be escalated through the designated company and client channels. The response process, notification duties and decision authority depend on the facts, environment, contract and applicable legal requirements.

Can you complete a supplier security questionnaire?

We can review reasonable questionnaires and provide available, approved information relevant to the proposed engagement. Responses may require clarification, supporting documents, confidentiality controls or internal review before release.

Can clients request additional security controls?

Yes. Additional controls can be discussed during scoping and security review. Feasibility, ownership, cost, timing, technical dependencies and contractual treatment should be confirmed before they are presented as committed requirements.

Does this page form part of a contract or guarantee?

No. This page is general information and does not replace a signed agreement, statement of work, data-processing agreement, security schedule or project-specific architecture. Contractual terms take precedence where applicable.

Security review support

Request security information relevant to your engagement

Share the proposed service, environment, data context and review questions. We will assess what approved information is available and identify any project-specific clarification required.

Contact the Trust Team