Four stages, from scope to handover.

1. 01

   Assess

   Stage 1 of 4

   A defined scope, a named architecture and an agreed end state, before anything is built.

2. 02

   Prepare

   Stage 2 of 4

   Private networking, Key Vault and Unity Catalog governance in place before the first pipeline runs.

3. 03

   Execute

   Stage 3 of 4

   Every workspace, policy and catalog arrives as a reviewed pull request. Dev, test and production run the same code.

4. 04

   Hand over

   Stage 4 of 4

   Documented architectures and knowledge transfer, so your teams can own and evolve the platform.

• 01Assess

  • We classify the data before it is loaded and record the purpose and the owner of each dataset.
  • Personal data stays in the agreed region. For EU clients, that means EU regions only.
  • We do not send client data to external AI services unless you agree in writing.
• 02Prepare

  • One Entra ID group for each access level on each scope. Nobody is added directly.
  • Unity Catalog reader and contributor groups for each schema. Table or volume groups only for sensitive objects.
  • Secrets live in Azure Key Vault, one vault for each environment, or do not exist at all because managed identities replace them.
• 03Execute

  • Each pull request runs lint, unit tests, Terraform validate and plan, bundle validate, a security scan, static analysis, and dependency and secret scanning.
  • Terraform apply and bundle deploy run from pipelines, with workload identity federation and no stored secrets.
  • Acceptance and production need two reviewers, and nobody approves their own change.
• 04Hand over

  • Access is reviewed every quarter, and permissions that nobody uses are removed.
  • Every job has an owner group and failure notifications, and alerts cover failures, cost spikes and security events.
  • Each dataset has a retention period, and data is deleted or anonymised when it ends.

1. 01

   A short written status

   What was done, what is next and what is blocked, in a few lines you can forward.

2. 02

   A demo of working software

   Something that runs, not slides, so you can react while a change is still cheap.

3. 03

   Decisions that need you

   A short list of choices we need from you, each with our recommendation and the reason.

4. 04

   Risks and open points

   Security, privacy, cost and schedule risks, and what we do about each one.

5. 05

   The work in your repositories

   Every change is a pull request you can see, review and comment on, with tests and a linked work item.

At handover you receive the documentation, the run books and the repositories. Until then you can read the current state of the work at any time.

1. The change is code, in a pull request with a linked work item.
2. Build validation and code scanning pass.
3. Access uses Entra ID groups, with no direct user grants. Privileged roles use PIM.
4. Every service uses a private endpoint, and public access is disabled.
5. Secrets are in Key Vault, or are not needed because a managed identity is used.
6. Sensitive data is classified, tagged and protected.
7. Infrastructure uses our Terraform modules, with no copied module code.
8. Databricks resources deploy as a bundle through the pipeline.
9. New logic has tests, and no code is duplicated.
10. The documentation and the run book are up to date.
11. The change moved through dev, test, acc and main.

These are NexOps' own delivery standards, our point of view rather than a vendor requirement or a certification. If your standard is stricter, we follow yours. If it is weaker, we tell you and record the decision.

See all engagement models