Security principles and practices that frame how engagement risks are discussed and managed.
Trust Center · Information Security
Information Security for Responsible Data & AI Consulting
DataConsultant approaches information security as a connected set of governance, access, data-handling, technology, monitoring and response decisions. This page helps security, procurement, risk and technical reviewers understand how those decisions may apply across data, analytics, cloud and AI engagements.
Security requirements considered in the context of the engagement
Access intended to remain proportionate to assigned work
Client, consultant and provider responsibilities distinguished
Assurance requests handled through evidence-aware review
This page describes general practices and considerations. Project-specific controls, client-managed safeguards, technical configurations and contractual commitments can differ. It is not a certification statement, audit report or guarantee of absolute security.
Information Security Assurance MapReview ready
How to interpret this information security page
Safeguards that depend on data, platform capabilities, client policies, architecture and scope.
Clear ownership across DataConsultant, the client, technology providers and approved third parties.
Due-diligence information is provided according to relevance, approval and confidentiality constraints.
Why this matters
Data and AI delivery can create security dependencies across people, platforms and information
Analytics, engineering, BI, AI, database, automation and managed-service work can involve different access models and risk profiles. The security discussion therefore needs to begin with the real engagement context rather than a generic control checklist.
Security starts with defined scope
Before access or sensitive work begins, reviewers should be able to identify what information is needed, where work will occur, which systems are involved, who controls those systems and which requirements must be documented.
- Identify information sensitivity and intended use.
- Clarify users, roles, access paths and privileged activities.
- Define client-controlled and provider-controlled environments.
- Record relevant contractual, policy and operational requirements.
- Surface exceptions and unresolved dependencies before they become hidden assumptions.
Permissions can exceed the work required
Role clarity, named identities and proportionate permissions help reduce unnecessary exposure.
Sensitive information can enter unsuitable workflows
Purpose, minimisation, classification, approved channels and environment decisions should be explicit.
Cloud and platform controls depend on configuration
Provider capability does not automatically establish that an engagement is securely configured.
Monitoring and response require clear ownership
Logs, alerts, incidents, backups and recovery responsibilities need a defined operating model.
Security assurance framework
Five connected domains organise the information security conversation
This framework is a practical way to structure due diligence for consulting delivery. It does not assert that every listed control is implemented in every environment; specific safeguards must be confirmed for the engagement.
Govern
Set direction and accountability before technical controls are selected.
- Security responsibilities
- Policies and client requirements
- Risk and exception decisions
- Awareness and escalation
Protect
Reduce unnecessary exposure through appropriate safeguards.
- Identity and authentication
- Least-necessary access
- Data and endpoint safeguards
- Configuration and secrets
Detect
Create appropriate visibility for review and investigation.
- Logging where available
- Security-relevant monitoring
- Vulnerability identification
- Technical review
Respond
Coordinate facts, ownership and proportionate action when concerns arise.
- Issue escalation
- Incident coordination
- Containment decisions
- Communication routes
Recover
Restore appropriate operating capability and learn from disruption.
- Continuity dependencies
- Recovery ownership
- Handover and closure
- Corrective improvement
The framework is intentionally evidence-aware: a principle becomes decision-useful only when scope, ownership, implementation and review evidence are understood.
From scope to review
Security requirements should move from context to documented decisions
A consulting engagement can change as data, platforms, users and delivery responsibilities evolve. The security process should make those changes visible and reviewable.
Understand context
Service, data, systems, users, locations, dependencies and intended delivery model.
Assess risk
Sensitivity, access, architecture, operational impact, client policy and third parties.
Define safeguards
Appropriate identity, data, endpoint, platform, delivery and monitoring requirements.
Allocate ownership
Clarify DataConsultant, client, platform-provider and other third-party responsibilities.
Record evidence
Document decisions, configuration assumptions, approvals, exceptions and review material.
Review change
Reassess material changes, incidents, scope expansion, handover and closure conditions.
Turn security questions into engagement-specific review items
Share the proposed service, environment, data context, questionnaire and decision being supported.
Protection layers
How key security areas may be addressed in consulting delivery
The controls below combine practices described in DataConsultant’s current Trust Center with engagement-dependent safeguards. Wording is intentionally qualified where platform capability or client configuration affects implementation.
Identity
Named identities and approved access
Access decisions should connect a known user to an approved delivery purpose.
- Named user access is preferred where supported.
- Access needs are considered during onboarding and role changes.
- Client-managed identities remain subject to client policy and configuration.
Privilege
Least-necessary permissions
Project roles should inform requested access and privileged activities.
- Administrative access is avoided unless the task requires it.
- Temporary or scoped access may be used where platforms support it.
- Access should be revisited when scope, role or risk changes.
Authentication
Multi-factor authentication
Additional authentication factors can reduce reliance on passwords alone.
- MFA is used where supported by the account and platform model.
- Client systems follow client authentication configuration.
- Unsupported or exceptional cases should be reviewed explicitly.
Information
Data minimisation and handling
Exposure can be reduced by limiting information to what is reasonably needed.
- Masking, sampling or synthetic data may be considered where practical.
- Local copies should be limited and governed by engagement need.
- Confidential information follows agreed workflows and client instructions.
Environment
Cloud, network and endpoint context
Safeguards depend on architecture, account ownership and provider capability.
- Environment boundaries and access routes are considered during setup.
- Device access controls, screen locking and software updates are expected to be managed.
- Project-specific restrictions may be defined for sensitive workloads.
Delivery
Secure development and change
Technical safeguards can follow the development and delivery lifecycle.
- Peer review, testing and controlled changes may be used according to scope.
- Secrets handling and environment separation should be considered where relevant.
- Handover should clarify ownership, access and unresolved limitations.
Conceptual assurance architecture
Security controls sit across layers of the delivery environment
This is a conceptual assurance model for review conversations, not a representation of DataConsultant’s production architecture. Actual systems, providers, configurations and responsibilities must be verified for the specific engagement.
Users & identityApproved users, authentication, roles, privilege and access lifecycle.
Delivery environmentRepositories, applications, collaboration tools, project workspaces and approved workflows.
Compute & platformCloud services, analytics environments, data platforms and provider-operated capabilities.
Network & connectivityAccess routes, boundaries, remote connectivity and client or provider network controls.
Storage & dataDatasets, project artefacts, backups, retention, transfer and handling expectations.
GovernanceConfigurationMonitoringBackupIncident responseResilience
Detect, respond, improve
Visibility and incident readiness depend on the operating model
Information security is not complete at the protection layer. Reviewers also need to understand how relevant events can be identified, escalated and connected to corrective action.
Monitoring and security review
Logging and monitoring are environment-specific. The appropriate level of visibility depends on platform capability, permissions, client ownership and whether ongoing operations are included in scope.
01
Identify available telemetryConfirm relevant audit records, platform logs and security events rather than assuming universal visibility.
02
Allocate review responsibilityClarify who monitors, investigates and retains security-relevant records where those duties are material.
03
Address vulnerabilities proportionatelyObserved weaknesses or risky configurations should be triaged against context, ownership and practical remediation paths.
Incident linkage and escalation
A suspected incident can require coordination across DataConsultant, the client, platform providers, legal or privacy stakeholders and other authorised parties.
01
Escalate the concernShare the minimum facts needed through the applicable route without exposing credentials or unnecessary sensitive data.
02
Establish facts and ownershipAssess affected systems, information, roles, dependencies and immediate containment needs.
03
Recover and learnCorrective actions, recovery steps and lessons should reflect confirmed facts and agreed responsibilities.
Risk, exceptions and change
Security exceptions should be explicit decisions, not invisible workarounds
When a standard path is not feasible, the decision should be considered in context, assigned to an appropriate owner and documented at a level proportionate to the risk.
01IdentifyControl gap, exception, change or dependency.
02AssessContext, likelihood, impact and alternatives.
03AssignResponsible decision owner and contributors.
04DecideMitigate, restrict, accept, defer or redesign.
05RecordRationale, conditions, evidence and dependencies.
06ReviewRevisit when scope, systems or risk changes.
Third-party security is part of the decision
Cloud platforms, software services, repositories, specialist tools and other providers can become part of the control environment. Provider capabilities should be assessed rather than treated as DataConsultant controls.
- Identify the provider’s delivery role and information access.
- Clarify client approval or contractual restrictions where relevant.
- Separate provider-operated controls from client and consultant responsibilities.
Material change can trigger fresh review
A new dataset, integration, privileged role, hosting location, model service or operational responsibility can materially change security assumptions.
- Record changes that affect access or data sensitivity.
- Revisit safeguards and ownership when architecture changes.
- Carry unresolved limitations into acceptance, handover or contract discussions.
Assurance access & due diligence
Security confidence should be built through the right level of evidence
Not every security artefact is appropriate for unrestricted publication. Evidence should be relevant to the decision, accurate, approved for disclosure and handled in a way that does not create unnecessary security exposure.
Public information
General Trust Center content suitable for open review.
Trust Center detail
Expanded explanation of governance, practices, responsibilities and limitations.
Control / process evidence
Supporting material that may require relevance and disclosure review.
Restricted assurance material
Security-sensitive information that may require controlled access or confidentiality conditions.
Client-specific due diligence
Questionnaires, contract-specific evidence and deeper review tied to the proposed engagement.
Client security review
Questions to resolve before sensitive access begins
These review prompts help security, architecture, procurement and project stakeholders convert general assurance into specific engagement decisions.
What data and systems are in scope?
Identify information categories, system owners, environments, integrations and restricted workloads.
Who needs access, and why?
Confirm named users, account ownership, privilege, authentication and access lifecycle.
Where will the work occur?
Confirm client-hosted, provider-hosted or DataConsultant-controlled components and configuration ownership.
Can exposure be reduced?
Consider masking, samples, synthetic data, read-only access or non-production environments where suitable.
Who monitors and responds?
Define logs, alerts, incident routes, backups, recovery and ongoing support responsibilities where relevant.
What must be demonstrated?
Identify questionnaires, contractual clauses, approvals, review records or other evidence required for the decision.
What this means for clients
A clearer basis for security review, delivery and acceptance
The objective is not to replace client security governance. It is to make scope, safeguards, responsibilities and evidence easier to evaluate before and during the engagement.
More focused due diligence
Security reviewers can connect questions to the proposed service, data and environment rather than generic claims.
Fewer ownership gaps
Client, consultant, platform-provider and shared responsibilities can be surfaced before technical work begins.
Traceable security decisions
Requirements, exceptions, dependencies and approvals can be linked to project or contractual records where appropriate.
Safer evidence exchange
Public, controlled and security-sensitive information can be distinguished instead of exposing material unnecessarily.
Frequently asked questions
Information security questions from buyers and reviewers
These answers provide general context for procurement, security, risk and technical review. Project-specific commitments should be confirmed through approved documentation and the applicable agreement.
What does information security mean for a DataConsultant engagement?
It means considering the people, access, data, devices, delivery environments, platforms, dependencies and operating responsibilities relevant to the work. The exact safeguards depend on the service, client environment, information involved, technical design and agreed contract terms.
Does this page confirm that every listed security control applies to every engagement?
No. This page describes general practices, decision principles and areas that may need to be addressed. Platform capabilities, client configuration, delivery model, data classification, risk and contractual scope determine which controls apply and who is responsible for them.
Do you claim an information security certification on this page?
No. This page does not claim a certification, audit result or independent assurance status. A certification or assurance document should be treated as confirmed only when it is supplied through an approved DataConsultant source and is current for the decision being made.
How is access to client systems and data approached?
Our approach is to use approved identities and access that is proportionate to assigned work. Named user access is preferred where supported, project roles inform requested permissions, and administrative access is avoided unless the task requires it. Clients generally control provisioning and revocation inside client-owned environments.
Is multi-factor authentication used for every system?
MFA is used where supported by the relevant platform and account model. Client-controlled systems remain subject to client authentication configuration, and unsupported or exceptional cases should be discussed during the security review for the engagement.
Can an engagement reduce the need to use production data?
Often, exposure can be reduced through selected samples, masking, synthetic data, read-only access or non-production environments where those approaches are suitable for the work. The right method depends on the analytical, engineering, AI, reporting or support task and must be agreed with the client.
How are logging and monitoring handled?
Visibility depends on the platform, permissions, client environment and operational scope. Logging, alerting, retention, review and investigation responsibilities should be defined where they are material. This page does not claim that DataConsultant monitors every client environment.
Who is responsible for cloud security and platform configuration?
Responsibility is shared. Technology providers operate their underlying services, clients retain responsibilities for their accounts, data, users, policies and configurations, and DataConsultant is responsible for activities expressly assigned to us within the approved environment and engagement scope.
What happens if a suspected security issue is identified?
The issue should be escalated through the applicable route so facts, scope, ownership and appropriate actions can be assessed. Response may involve DataConsultant, the client, technology providers or other authorised parties. See the Incident Response page for the dedicated lifecycle and guidance.
Can procurement or a security team submit a questionnaire?
Yes. Use the Contact Trust Team route to provide the proposed service, review stage, required evidence, questionnaire context and decision deadline. Available information is provided according to relevance, approval, confidentiality restrictions and the engagement being evaluated.
What security evidence can be requested?
Requests may cover available policies, process descriptions, architecture or data-flow discussions, access and responsibility summaries, or other approved information relevant to the proposed service. Availability should not be assumed, and security-sensitive material may require controlled disclosure or additional review.
Does information security remove all risk from a data or AI engagement?
No. Security controls help reduce and manage risk but cannot establish absolute security. Residual risk can remain because of people, data quality, configuration, dependencies, changing threats, client-controlled systems, third-party services and future operating conditions.
Build the Security Review Around Evidence, Scope and Responsibility
If your security, procurement or risk team needs deeper information, share the service being evaluated, the environment and data context, the questionnaire or evidence required and the decision deadline. We can route the request to the appropriate Trust Team review.
Evidence-aware reviewEngagement-specific controlsClear responsibility boundariesNo unsupported certification claims