Frequently asked questions

That is exactly the stage it is for. Every pilot that works becomes something the business is responsible for but never designed properly. The Readiness Assessment finds what is already running, sanctioned and shadow, and tells you whether you have a governance gap before an auditor or an incident does. If the answer is "not much, and it is under control", the assessment says so and you are done.

Possibly. The Act has extraterritorial reach, so UK firms serving EU clients can be in scope, and transparency obligations apply from August 2026, with high-risk obligations following in December 2027. Whether it applies to your specific business is a legal question for your compliance team. What we do is map each AI system against the risk categories so that conversation happens with evidence rather than guesswork.

Not a separate one. The Governed AI Landing Zone extends the same policy-as-code discipline to agents: identity per agent, data-loss prevention on prompts and responses, model and region allow-lists, and audit trails. If your existing foundation is sound, we build on it. If you have never had one, the AI build establishes it properly.

If you already have a validated view of your AI estate and its gaps, yes, we can start from that evidence. If not, we run a compressed discovery first, because building a governed foundation on assumptions is how the wrong controls get enforced. The assessment exists so the build fixes what is actually broken.

For the assessment: read-only access (Reader, Security Reader, and Purview) granted under NDA, a list of the AI tools you already know about, and a couple of hours each from an engineering contact and a compliance contact. We share a full pre-kickoff checklist once an engagement is agreed; access being granted promptly is what keeps the timeline to two to three weeks.

Two to three weeks, counted from the day read-only access is granted. We share a full pre-kickoff checklist once an engagement is agreed and chase access hard in week zero, because access is the only thing that ever slips the timeline. The work ends with a written report and a readout session with your technical and compliance leads, not a six-month consulting cycle.

A written inventory of every AI system and agent we find across Microsoft 365 and Azure, sanctioned and shadow; each one classified against the EU AI Act high-risk categories and your sector's obligations; a map of what data reaches which models; a posture snapshot across Microsoft Entra, Purview and Defender for Cloud; and a prioritised 90-day roadmap with owners and effort estimates, walked through in a readout session.

A fixed price, agreed before we start: £12,500 for the standard scope, which covers a typical mid-market estate of 50-300 users and up to 5 subscriptions; from £9,500 for a narrow, single-entity scope; and from £15,000 for regulated depth, with full EU AI Act mapping across several entities. It costs less when bundled with the Governed AI Landing Zone, and there is no day-rate drift.

The roadmap points at the build. The Governed AI Landing Zone puts in the foundation the assessment found missing, and it is discounted when it follows an assessment. If the assessment finds that your AI estate is small and under control, it says so and you are done. Either way you leave with a defensible written compliance position for your board and examiners.

Yes. The governance layer, identity, data controls, policy and audit, applies regardless of where agents are built: Microsoft Foundry, Copilot Studio, Power Platform, or a third-party framework. Agents get a traceable identity, their data access is controlled through Purview, and their activity is logged for evidence, whatever produced them.

Three things: Microsoft Entra ID P1 or P2 (required for the agent identity and Conditional Access model), Microsoft Purview for data governance, and Microsoft Defender for Cloud paid plans for security posture. If any of these are not licensed yet, tell us early. It is a prerequisite and affects what the foundation can enforce.

No. We design and build the foundation, then hand it over: the infrastructure-as-code repository becomes yours, along with the policy set, a governance playbook, operational runbooks, and a knowledge-transfer session. Thirty days of post-handover support are included so your team is never left holding something they were not shown how to run.

Minimal by design. The build follows a strict design-first sequence: nothing is deployed until the high-level and low-level designs are signed off in writing by your named approver. Guardrails are deployed as policy-as-code with a defined scope, so existing workloads are not swept up unintentionally, and networking changes are surfaced early because they carry the most elapsed-time risk.

A fixed price agreed at design sign-off, tiered by the size of your estate: from £35,000 for Foundation (1-2 subscriptions, 1-2 agent teams), from £45,000 for Standard (3-5 subscriptions, multiple workloads), from £55,000 for Extended (6+ subscriptions, multi-region). Every tier includes hands-on delivery and 30 days of post-handover support. Additional agent deployments are quoted per scope, and the build is discounted when it follows a Readiness Assessment.

A monthly refresh of the agent registry, so nothing runs that nobody owns; compliance monitoring and evidence collection against your current obligations; posture reviews covering Defender for Cloud alerts, Purview DLP effectiveness and policy drift; pre-flight reviews of any new agent or model before it reaches production; a monthly executive dashboard and a quarterly steering review; and an annual tabletop exercise on agent incident response.

Yes. The retainer keeps a governed agent estate governed, so it needs a foundation to watch: either our Governed AI Landing Zone, or an existing landing zone that we review and validate first. Without one there is no consistent agent identity, data control or audit trail for the monthly reviews to check, and building that foundation would be the first job.

A fixed monthly retainer, tiered by the number of agents under governance: from £3,500 a month for Starter (up to 5 agents), from £5,500 a month for Standard (5-15 agents), from £8,000 a month for Extended (15-25 agents), with additional agents quoted. The term is 12 months, with a discount for annual commitment, and service levels, response times and a monthly advisory-hours budget are agreed up front.

Organisations running agents in production, roughly three or more, or heading there fast, that need continuous oversight without building an in-house AI governance function. It also suits regulated firms that need current, monthly audit evidence on hand rather than reconstructed when an examiner writes. The usual first step is a free, one-hour governance health check of where your estate stands today.

An Azure Landing Zone is the foundational platform that sits beneath your workloads - management groups, subscriptions, policy, network topology, identity, and logging, all configured to Microsoft's Cloud Adoption Framework. If you plan to run more than a handful of workloads in Azure, building a landing zone early prevents the sprawl, inconsistency, and control gaps that are significantly harder to fix later.

The Cloud Adoption Framework (CAF) is the methodology - the full set of guidance for adopting Azure responsibly. A landing zone is one of its outputs: the concrete platform that encodes CAF principles into management groups, policies, networking, and identity. We design and deploy landing zones as the tangible implementation of CAF, not as a theoretical reference.

Yes, though the approach differs from a greenfield build. We start by mapping what is already in place - subscriptions, policies, network layout, identity - then design a target landing zone and a migration path that brings existing workloads into it in phases. It is slower than starting fresh, but avoids the disruption of rebuilding production workloads from scratch.

We use Infrastructure-as-Code for every deployment, typically Terraform or Bicep depending on client preference and existing tooling. The landing zone, policies, and baseline resources live in a Git repository with proper change control. This means the platform is reproducible, auditable, and evolvable - no click-ops configuration sitting in the portal.

A standard enterprise-scale landing zone takes four to eight weeks to design and deploy, depending on complexity and decision-making pace. Smaller or single-region environments can complete in two to four weeks. Timelines are dominated by architectural decisions - network topology, identity strategy, policy posture - rather than the deployment itself, which is largely automated once decisions are made.

Yes - that is much of the point. Management groups, Azure Policy, and RBAC are configured at the group level so new subscriptions inherit the same guardrails by default. Adding a subscription becomes a declarative action rather than a manual checklist. Policies enforce allowed regions, resource types, tagging, encryption, and logging before any workload team touches the environment.

DevSecOps means security controls are built into the delivery pipeline itself, not layered on afterwards. In Azure, that typically covers automated policy enforcement, secret management through Key Vault, vulnerability scanning of code and container images, infrastructure-as-code validation, and compliance checks before anything reaches production. Security becomes a property of the pipeline rather than a separate review step.

DevOps focuses on delivery speed and automation; DevSecOps keeps those goals but embeds security as a first-class concern at every stage. Practically, that means security tooling runs automatically alongside build and deployment - shifting detection left so issues are caught by developers at commit time rather than by security teams weeks later. Same speed, higher confidence.

We work with Azure DevOps and GitHub Actions as primary platforms, which covers most Azure-centric teams. The patterns we implement - pipeline-as-code, policy gates, artifact scanning - are portable, so the same approach translates to other platforms if you change toolchains later. We do not mandate a specific stack; we adapt to what your team already uses.

Secrets live in Azure Key Vault and are injected at runtime using workload identity federation or managed identities - never stored in pipeline variables, repository files, or config. Pipelines authenticate to Azure without long-lived credentials, access is scoped to the minimum required, and every secret access is logged. This removes the category of leaked-credentials incidents almost entirely.

Standard coverage includes static code analysis, dependency scanning for known CVEs in open-source libraries, container image scanning, infrastructure-as-code validation against Azure Policy, and secret scanning to catch credentials committed by mistake. Results are gated - a pipeline with critical findings cannot promote to production without an explicit, logged override.

We integrate with what you have wherever possible. Most engagements start by reviewing existing pipelines and adding security stages incrementally - a scan here, a policy gate there - so teams keep shipping while the controls mature. Full rebuilds are only necessary when the existing pipelines are fundamentally unsuitable, which is rare.

It covers ongoing operations of your Azure environment: round-the-clock automated monitoring and alerting, incident response in UK business hours, patching, backup and recovery, security posture management, cost oversight, and regular platform improvements. The goal is a stable, continuously-improving platform without your team having to carry the operational weight in-house. Scope is defined per client so you pay for what you actually need.

Traditional MSPs often operate a ticket-and-fix model - incident happens, someone reacts. Our approach is engineering-led: we improve the platform continuously so incidents happen less often, automate remediation where it is safe, and treat each incident as a signal to make the environment more resilient. You get operations support plus platform evolution, not just break-fix.

Response times are tiered by severity and run in UK business hours: critical production incidents within one hour, major within four hours, and routine within one business day. Out-of-hours cover for critical incidents can be added, agreed in the contract. Resolution targets depend on the nature of the issue and the client's environment, so we set them explicitly per engagement rather than making generic promises. SLAs are reported monthly and tied to service credits where appropriate.

Either model works. Some clients use us to run the whole platform; others keep an internal team and use us for out-of-hours cover, specialist input, or capacity during busy periods. The engagement model is set up explicitly at the start so ownership, escalation paths, and decision rights are clear - there is no ambiguity about who does what.

Yes - most managed engagements start with an environment that already exists. We begin with a discovery and onboarding phase to map the platform, identify risks, document runbooks, and align monitoring to our standards. Where we find significant issues, they are surfaced transparently with a remediation plan rather than absorbed silently into the service.

Automated monitoring and alerting run around the clock, and our engineers respond in UK business hours. If you need critical incidents handled out of hours, that cover can be added to your contract, with the escalation path agreed up front. Incidents are logged, investigated, and remediated with a written post-incident review for anything above routine severity. We do not use a generic service desk as the frontline; incidents go to engineers who know your environment from the start.