Security, privacy and quality built into the delivery lifecycle.
Our secure data consulting delivery process brings requirements, access, data handling, testing, approval, handover and closure into one structured engagement approach—so stakeholders can make informed decisions at every stage.
Secure delivery is not a single review at the end of a project. It begins with clear requirements and continues through environment setup, controlled access, data use, change management, testing, acceptance, deployment, support and closure.
Security and privacy questions are considered alongside business and technical requirements.
Approvals, exceptions, dependencies and client decisions are made visible at appropriate gates.
Controls are proportionate to the data, service, environment, risk and agreed delivery model.
Closure addresses access, retention, deletion instructions, handover and outstanding responsibilities.
Risk-informed
Requirements and controls should reflect actual data, systems, users, dependencies and intended outcomes.
Purpose-limited
Data and access should be used for the agreed engagement purpose and reduced where practical.
Evidence-led
Testing, documentation, review and approval provide decision-useful evidence rather than unsupported assurance.
Shared responsibility
Our team and the client each retain responsibilities that must be understood and actively managed.
End-to-end lifecycle
Ten stages in our secure delivery process
Each stage combines delivery activity with a security and privacy checkpoint. The sequence may be adapted for iterative, agile, advisory, managed-service or client-controlled environments.
01
Discovery
Understand the business outcome, systems, stakeholders, data context, constraints, and expected deliverables.
Security and privacy checkpointIdentify likely data sensitivity, access needs, third parties, locations, and material dependencies before detailed scoping.
02
Risk and Requirement Review
Translate business, technical, privacy, security, legal, and procurement needs into engagement requirements.
Security and privacy checkpointRecord agreed requirements, unresolved questions, client-mandated controls, and risks requiring approval or treatment.
03
Planning
Define scope, responsibilities, milestones, environments, review gates, acceptance criteria, and communication routes.
Security and privacy checkpointConfirm intended data use, authorised users, delivery channels, change controls, retention expectations, and escalation paths.
04
Secure Environment Setup
Prepare engagement-specific workspaces, repositories, tools, permissions, and collaboration arrangements.
Security and privacy checkpointProvision access according to role and need; verify approved systems and record environment-specific limitations.
05
Development or Analysis
Perform data engineering, analytics, BI, AI, automation, database, cloud, or advisory work within the agreed scope.
Security and privacy checkpointUse approved data, maintain traceability where practical, limit unnecessary copies, and separate experimental work from approved outputs.
06
Testing
Evaluate logic, functionality, data transformations, model behaviour, reports, integrations, and operational readiness.
Security and privacy checkpointUse suitable test data and document defects, exceptions, assumptions, and unresolved limitations before release review.
07
Quality and Security Review
Review deliverables against scope, acceptance criteria, quality expectations, and applicable security or privacy requirements.
Security and privacy checkpointCheck access, configuration, documentation, known issues, data exposure risks, and readiness for client review.
08
Client Acceptance
Present deliverables, evidence, known limitations, and required decisions for client validation and approval.
Security and privacy checkpointCapture approval, requested changes, accepted exceptions, outstanding dependencies, and authorised deployment or handover instructions.
09
Deployment or Handover
Move approved outputs into the agreed destination or transfer them to authorised client representatives.
Security and privacy checkpointVerify recipients, delivery channel, deployment authority, documentation, rollback or recovery considerations, and access ownership.
10
Support and Closure
Complete agreed support, knowledge transfer, closure checks, access removal, retention actions, and final records.
Security and privacy checkpointConfirm closure responsibilities, remaining copies, retained records, deletion requests, support boundaries, and open risks.
Delivery controls
How key control areas are addressed
These practices support a controlled engagement, but their exact implementation depends on client requirements, delivery scope, system ownership and verified company procedures.
Access provisioning and removal
Access is considered by role, business need, environment, duration, and client instruction. Joiner, mover, and leaver actions should be reflected in the engagement plan, with removal or transfer of access at closure or role change.
Why this matters: Reduces unnecessary access and makes ownership clearer throughout the engagement.
Data intake and transfer controls
Before data is received, we aim to confirm the purpose, expected content, sensitivity, approved transfer route, required recipients, and whether reduced, masked, synthetic, or sample data can meet the need.
Why this matters: Helps prevent avoidable collection, uncontrolled sharing, and ambiguity about permitted use.
Version control and change management
Repositories, file versions, change requests, review comments, and approvals are managed according to engagement scope and tooling. Material changes should be traceable and assessed for delivery, security, privacy, and timeline impact.
Why this matters: Supports reproducibility, reviewability, and controlled movement from draft to approved output.
Testing and validation
Testing is tailored to the service: data reconciliation, transformation checks, report validation, code review, functional testing, model evaluation, integration checks, or user acceptance support may be used where relevant.
Why this matters: Provides evidence that outputs meet agreed requirements and makes known limitations visible.
Documentation and client approval
Documentation may include assumptions, design decisions, data definitions, configuration notes, test results, operating guidance, known issues, approval records, and agreed exceptions, subject to engagement requirements.
Why this matters: Enables informed acceptance and supports future maintenance or audit activity.
Deployment, handover and knowledge transfer
Deployment or handover follows the agreed authority, destination, recipients, format, and support model. Knowledge transfer is scoped to the people, systems, documentation, and operational context required for responsible ownership.
Why this matters: Reduces dependency and clarifies who owns the delivered solution after acceptance.
Project closure, retention and deletion
Closure should address access removal, return or deletion instructions, retained business records, legal or contractual dependencies, backup limitations, ongoing support, unresolved risks, and evidence required by the client.
Why this matters: Limits indefinite access and makes post-engagement responsibilities explicit.
Client perspective
What this means for clients
The process is designed to give business, procurement, legal, privacy, security and technical stakeholders clearer information and more deliberate decision points.
Clearer due diligence
Procurement, legal, privacy, security, and technical stakeholders can see where decisions, approvals, dependencies, and evidence fit into delivery.
Fewer hidden assumptions
Requirements and limitations are surfaced early so that scope, data use, access, acceptance, and operational responsibilities can be agreed.
Controlled handover
Approved outputs, documentation, knowledge transfer, access ownership, and post-delivery support are addressed before project closure.
Shared accountability
The process distinguishes our responsibilities, client responsibilities, and decisions that require active coordination.
Shared responsibility
Responsibilities matrix
Secure delivery depends on coordinated action. This matrix provides a general allocation; contracts, statements of work, client policies and system ownership remain authoritative for each engagement.
General responsibilities for our team, the client and shared decisions.
Area
Our team
Client
Shared
Requirements and data classification
Ask relevant questions, document known requirements, identify unclear or conflicting instructions, and design delivery around the agreed scope.
Provide accurate requirements, identify sensitive or regulated data, disclose mandatory controls, and confirm authorised uses and stakeholders.
Resolve assumptions, approve scope boundaries, and update requirements when circumstances change.
Access and environments
Use approved access for assigned work, follow engagement permissions, and report access issues or unexpected exposure.
Authorise systems and users, maintain client-controlled environments, and revoke or adjust access when roles or needs change.
Review access during delivery and confirm ownership at handover or closure.
Data transfer and minimisation
Use agreed channels, limit use to the stated purpose, and request reduced or representative data where practical.
Confirm authority to share data, provide only required information, and use approved transfer methods.
Agree permitted datasets, recipients, locations, and handling conditions.
Testing and acceptance
Perform agreed validation, document material findings, and present known limitations or unresolved issues.
Provide representative requirements, test scenarios, timely feedback, and authorised acceptance decisions.
Agree acceptance criteria, defect priorities, exceptions, and release readiness.
Deployment and operations
Follow approved deployment or handover instructions and provide agreed documentation and knowledge transfer.
Control production authority, operating decisions, downstream access, monitoring, and business use after handover unless contracted otherwise.
Coordinate release timing, dependencies, fallback arrangements, and operational ownership.
Retention, deletion and closure
Complete agreed closure actions and document material exceptions or dependencies that prevent immediate completion.
Provide retention or deletion instructions, identify legal holds, and confirm authorised recipients for final materials.
Confirm access removal, retained records, support boundaries, and closure evidence.
Important considerations and limitations
This page is intended to explain an approach, not to create a contractual commitment or replace engagement-specific due diligence.
Controls vary by service, data, jurisdiction, technology, delivery model and client requirements.
Client-controlled systems, identities, networks, backups and production operations remain client responsibilities unless expressly agreed otherwise.
No process can eliminate all security, privacy, operational or delivery risk.
Certifications, audit reports, technical standards, retention periods and response commitments must be separately verified before publication or reliance.
Legal, regulatory and compliance applicability must be assessed by qualified stakeholders for the specific engagement.
Third-party platforms and subprocessors may introduce separate terms, controls, locations and dependencies.
Related resources
Continue your Trust Center review
Use these pages to explore related topics or request engagement-specific information for procurement, legal, privacy, security and technical assessment.
Secure delivery questions from buyers and reviewers
These answers support early assessment. Engagement-specific requirements, controls, evidence and commitments should be confirmed through the appropriate review and contracting process.
What is a secure data consulting delivery process?
It is a structured way to integrate security, privacy, quality, governance, access, testing, approval, handover, and closure considerations into a data or technology engagement. The exact controls and evidence depend on the service, systems, data, contract, client requirements, and delivery model.
Does the same delivery process apply to every project?
No. The lifecycle provides a consistent structure, but the depth of review and the controls used should reflect the engagement. A BI dashboard, data migration, managed data team, AI proof of concept, cloud platform implementation, and advisory project may require different environments, tests, approvals, and evidence.
How are security and privacy requirements identified?
We aim to identify them during discovery and risk review through client requirements, data context, intended use, system architecture, user roles, transfer needs, contractual terms, and stakeholder questions. Requirements that are unclear or unsupported should be resolved before relying on them.
How do you control access to client systems and data?
Access is intended to be limited to authorised people, approved systems, and the work they need to perform. Provisioning, changes, periodic review, and removal are handled according to the engagement model and the systems controlled by us or the client. Exact identity, authentication, and logging controls must be confirmed for the relevant environment.
Can you work without receiving production data?
Where practical, projects may use synthetic, masked, sampled, aggregated, or otherwise reduced data. Whether this is suitable depends on the purpose, required accuracy, edge cases, integration needs, and the client’s ability to prepare representative information.
How is client data transferred?
The approved method should be agreed before transfer and may depend on client systems, file size, sensitivity, geography, contractual conditions, and available secure channels. Email or consumer file-sharing should not be assumed to be appropriate for sensitive information.
How are changes to scope, data, or design managed?
Material changes should be documented, reviewed for delivery and risk impact, and approved by authorised stakeholders. The change process may cover revised requirements, new data sources, permissions, architecture changes, deadlines, costs, tests, and acceptance criteria.
What testing is performed before delivery?
Testing is based on the service and agreed acceptance criteria. It may include data reconciliation, transformation validation, functional testing, report checks, code review, integration testing, model evaluation, security-focused checks, user acceptance support, or documentation review. No single test set is appropriate for every engagement.
Who approves deployment or handover?
Deployment or handover should be authorised by the people identified in the engagement plan. Client acceptance does not remove the need for production authority, operational readiness, access decisions, and change-management approval where those responsibilities sit with the client.
What documentation is provided?
Documentation is scoped to the engagement and may include requirements, assumptions, data definitions, architecture, configuration, code or repository guidance, test evidence, operating instructions, known limitations, support information, approval records, and closure notes.
What happens to access and data when a project ends?
Closure should confirm access removal or transfer, final delivery, support boundaries, retained records, client deletion or return instructions, legal or contractual dependencies, and any technical limitations such as backups or client-controlled copies. Exact timelines must be agreed and verified for the engagement.
Do you guarantee that a project is completely secure or compliant?
No. Security and compliance depend on people, systems, configurations, client responsibilities, third parties, changing threats, law, and operational decisions. This page describes an approach to responsible delivery; it is not a certification, audit opinion, legal advice, or guarantee.
Engagement-specific review
Discuss a Secure Delivery Plan
Share your service scope, data context, system environment, stakeholder requirements and due-diligence questions. We can identify the information and decisions needed for a responsible delivery plan.
