Governing a Microsoft Copilot Rollout

What Copilot governance actually means

Copilot governance is the set of controls, policies, and operating disciplines that let an organization adopt Microsoft Copilot productively without exposing data it should not, without over-spending on licenses or consumption, and without handing regulated work to a probabilistic model. It is an internal capability, not a one-off project: the controls are designed before the first license is assigned, applied during a phased rollout, and run continuously afterward as Microsoft ships new agents and as employees find new ways to use the tool.

The reason governance exists as a distinct concern is that Copilot reads across the Microsoft 365 tenant on the user's behalf. Microsoft is explicit that Copilot only summarizes or references content the user is authorized to access and that it honors Microsoft Purview sensitivity labels and encryption. That is the reassurance and the problem in one sentence: Copilot does not grant anyone new access, it surfaces — in plain language — every permission you already granted. Years of frictionless SharePoint sharing, broad groups, and broken permission inheritance become instantly searchable the moment Copilot is switched on. Governance is the work of making that underlying permission estate correct before Copilot amplifies it.

It is important to separate governance from two adjacent topics this site already covers. The per-app overview of Microsoft Copilot in Dynamics 365 explains what each app does and what it costs; that is the capability map. A Copilot consulting engagement is the commercial project — assessment, remediation, pilot, rollout — that a partner delivers. Governance is the model those engagements install and that your team then operates. This guide is deliberately the operating model: the controls, the risk tiers, the measurement loop, and the cost discipline that determine whether a rollout is safe and whether it pays back.

In 2026 the product surface has split, and governance fails when teams treat it as one SKU. Microsoft 365 Copilot is a per-user seat (enterprise list price US$30/user/month annual, with Business add-on tiers lower). Dynamics 365 and Business Central embed Copilot capabilities in the apps, often with different entitlements than the Microsoft 365 seat. Copilot Studio is where you build custom and autonomous agents — internal agents for Microsoft 365 Copilot licensed users are included for employee-facing use within fair-use rules, while external channels, unlicensed users, and many autonomous patterns burn Copilot Credits (capacity packs at US$200 per 25,000 credits/month, pay-as-you-go, or prepaid Commit Units). Microsoft Agent 365 (generally available May 2026) is the control plane to observe, govern, and secure agents across Microsoft and partner ecosystems — standalone list pricing is commonly cited at about US$15/user/month, and it is also bundled into Microsoft 365 E7. The table in the next section maps which product you are governing so owners and budgets do not get mixed.

The four domains of Copilot governance

A workable governance model collapses a sprawling Microsoft 365 estate into four domains that map cleanly to owners and tooling. Splitting it this way prevents the most common failure mode — treating 'Copilot governance' as a single IT task that nobody fully owns — because each domain has a different primary stakeholder, a different Microsoft product stack, and a different risk profile.

The four domains are data and permissions governance (who can see what, and is that access correct), security and compliance governance (how sensitive data is classified, protected, and audited), usage and adoption governance (which use cases are enabled, who owns them, and whether employees actually use them), and cost governance (what the licenses and the metered Copilot Credits consumption actually cost). Microsoft's own foundational deployment guidance organizes the work along the same axes: establish guardrails for SharePoint, OneDrive, and Exchange access; make informed choices about how Copilot interacts with sensitive data; and monitor Copilot activity to identify and remediate risk.

The table below is the governance map. Treat it as the RACI starting point: every control in your rollout should live in one of these four boxes, and every box should have a named owner before any license is assigned.

Which Copilot product you are governing (seats, agents, credits)

Most confused rollouts start by mixing four different economic and control models under one word — Copilot. Governance owners need a product map before they buy seats, enable agents, or promise ROI. Treat each row as a separate decision: who pays, who owns risk, and which admin center holds the controls.

Microsoft 365 Copilot is the productivity seat in Word, Excel, PowerPoint, Outlook, Teams, and Copilot Chat. List pricing for enterprise remains US$30 per user per month on an annual commitment on top of a qualifying Microsoft 365 base license; Microsoft 365 Copilot Business is the SMB add-on path (list often around US$18–$21/user/month with promotional windows). Dynamics 365 and Business Central embed Copilot features and autonomous agents inside the ERP/CRM stack — entitlements and consumption are not always the same as the Microsoft 365 seat, which is why SMEs on Business Central commonly over-buy Microsoft 365 Copilot when in-app Copilot already covers their first use cases.

Copilot Studio is the build plane for custom agents. Licensed Microsoft 365 Copilot users can build and use internal Microsoft 365 agents without a separate Studio seat for employee-facing scenarios under Microsoft's published inclusion rules; standalone Copilot Studio uses tenant-wide Copilot Credit capacity (packs of 25,000 credits at US$200/pack/month), Azure pay-as-you-go, or prepaid Commit Units (often up to ~20% savings versus pay-as-you-go). Agent 365 is not another chatbot — it is the control plane for agent inventory, identity, policy, and security across Copilot Studio, Microsoft 365 agents, and an expanding partner ecosystem. For SMEs, the honest limit is capacity: you may not need E7 or full Agent 365 on day one, but you do need a named owner for agent inventory and credit spend the moment the first autonomous agent leaves a pilot.

The oversharing problem: your access model just became a search engine

Oversharing is the single highest-severity governance issue for a Copilot rollout, and it is the reason governance has to start before licensing. For years, broad sharing in SharePoint and OneDrive was a quiet risk: the data was technically exposed but practically buried, because finding an over-shared file still meant knowing where to look. Copilot removes that friction. Ask the right question and it will summarize the salary spreadsheet, the acquisition memo, or the board deck that happens to contain the answer — content the user was always permitted to open but never knew existed. The exposure was always there; Copilot just makes it easy to find in plain English.

Two patterns dominate real oversharing incidents. The first is the broad group, especially 'Everyone Except External Users,' which grants access to every internal account and gets attached to sites far more often than anyone intends. When that group sits on a site with sensitive content, the site is effectively published to the whole company, and Copilot treats that as fair game. The second is unlabeled sensitive data: Copilot respects sensitivity labels and the encryption they enforce, but that protection only works where labels exist, and the data that actually hurts you is usually the spreadsheet no one ever classified. A common field story sums it up — a leadership pilot that, within a week, summarized an internal HR document from a site nobody remembered existed: no breach, no policy violation, but the wrong people now knew about a confidential plan.

The fix is not to slow Copilot down. The fix is to use the SharePoint and Purview controls in the right order so Copilot lands on a tidy library rather than a chaotic one. That means mapping the oversharing first (the survey), then fencing the risky sites (the fences), then labeling the data that travels. The next section covers the toolchain that does exactly that.

The SharePoint and Purview toolchain: the survey and the fences

Microsoft gives organizations an engine to map oversharing and three fences to contain it once you know where the risk is. The engine is SharePoint Advanced Management (SAM); the fences are Restricted Content Discovery, Restricted Access Control, and sensitivity labels enforced through Microsoft Purview. Used in the right sequence, they let a rollout proceed on the clean parts of the tenant while the risky parts are reviewed — instead of blocking Copilot entirely while a multi-year cleanup runs.

SharePoint Advanced Management is the administrative governance layer for SharePoint and OneDrive, explicitly positioned as the way to prepare for Copilot and agents. Its Content Management Assessment hub runs a suite of reports that identify potentially overshared content, surface inactive or ownerless sites, define Copilot readiness, and produce actionable remediation recommendations; Microsoft recommends rerunning the assessment every 30 days to track progress. SAM also provides site ownership policies, inactive-site policies, site attestations, site lifecycle management, and Data Access Governance reports that show where broad access and oversharing patterns exist. For an SME on Dynamics 365 Business Central rather than the enterprise M365 tier, the equivalent discipline is data hygiene inside the ERP and Dataverse, covered in our data governance guide.

The three fences each do a different job, and confusing them is a common rollout error. Restricted Content Discovery (RCD) is a per-site flag that removes a specific SharePoint site from organization-wide search and Copilot without changing who can access it — it is the right temporary control for a high-risk site while permissions are reviewed. Restricted SharePoint Search (RSS), the older tenant-wide allow-list, is being retired: starting July 31, 2026, new RSS enablement is blocked, and Microsoft directs organizations to RCD and comprehensive data controls instead. Restricted Access Control tightens the membership of a site or content to a specific group. None of these is a substitute for sensitivity labels: Purview labels (Public, Internal, Confidential, Highly Confidential) encrypt content, enforce usage rights, and — critically for Copilot — are honored during grounding and content generation, with new content inheriting the highest-priority label from its sources. Note the practical caveat: RCD controls discovery, not access, and Microsoft warns that over-using it reduces the completeness and relevance of Copilot responses.

Two 2026 operational updates matter for the fences. First, Restricted Content Discovery can be delegated so site owners — not only tenant admins — toggle RCD with justification, which is how high-risk sites get fenced without waiting on a central ticket queue. Second, RCD now blocks discovery for both classic Copilot search and agentic experiences: if an agent you do not recognize is reasoning over a sensitive library, RCD is the temporary lock while you investigate. Neither update replaces least-privilege permissions; both buy time for remediation.

Use-case triage: which Copilot scenarios to enable, and at what risk

Once the data estate is under control, the next governance decision is which Copilot scenarios to switch on — because not every use case carries the same risk, and treating them identically either over-governs the safe ones (killing adoption) or under-governs the dangerous ones (creating incidents). A risk-tiered triage is the governance artifact that makes this explicit: every candidate use case is scored, assigned a tier, and given an approval rule before it is enabled in production.

The triage framework rests on a simple distinction Microsoft itself makes: Copilot is at its best on drafting, summarization, natural-language questions over records, and triage — the work that accelerates a human who reviews and signs off. It is weakest, and Microsoft warns it can give incorrect responses, on anything requiring accuracy or reproducibility. That maps cleanly to three tiers. Tier 1 (low-risk, enable freely) is human-reviewed assistance: draft an email, summarize a case, generate meeting notes, analyze a reconciliation in Business Central's Bank Reconciliation Assist. Tier 2 (medium-risk, enable with a human approval step) is semi-autonomous automation: the Sales Order Agent processing inbound orders, the Payables Agent handling invoices, the Case Management Agent updating cases — anything that takes an action a human must confirm. Tier 3 (high-risk, keep manual or lock down) is regulated and audit-critical work: period-close journals, regulated calculations, entries that must be reproducible to the cent, anything supporting an audit or a statutory filing.

The governance rule that follows is non-negotiable: every Tier 2 autonomous action carries a human approval step before it posts, resolves, or commits money, and every Tier 3 workflow stays out of scope of autonomous agents entirely. The point of the triage is not to ban AI from important work; it is to make the approval boundary explicit and documented, so that when an agent is later expanded or a new one is added, the team knows which tier it falls into and what review it requires. The same triage feeds the cost model in the cost-governance section, because Tier 2 autonomous actions are also where metered Copilot Credits are consumed.

The policy layer: acceptable use, human-in-the-loop, and responsible AI

Controls are only as durable as the policy behind them. A Copilot rollout needs a short, enforceable acceptable-use policy that employees actually read, anchored in three rules: Copilot output is a starting point, not a final source of truth; a human is accountable for anything that posts, resolves, or is sent externally; and sensitive or regulated data is governed by classification, not by trust in the model. Microsoft's own guidance is candid that Copilot can give incorrect responses, and the disclaimer attached to AI features — not for tasks requiring accuracy or reproducibility — should be reflected directly in the internal policy.

Microsoft provides the raw material for this policy. Microsoft 365 Copilot is compliant with the company's existing privacy, security, and compliance commitments to commercial customers, including GDPR and the EU Data Boundary, and prompts, responses, and data accessed through Microsoft Graph are not used to train the foundation models. It also ships with protective controls: blocking harmful content, detecting protected material, and blocking prompt-injection (jailbreak) attacks. On top of that, Microsoft's responsible AI principles — fairness, reliability and safety, privacy and security, transparency, accountability, and inclusiveness — and its published code of conduct for generative AI give a ready-made framework an organization can adopt or adapt rather than write from scratch. Organizations operating in the EU should also track the EU AI Act, which Microsoft is actively building compliance tooling around.

Two operational policies make the acceptable-use rules stick. The first is a human-in-the-loop approval rule wired into every Tier 2 agent: no autonomous action commits without a named approver, and the approval is logged. The second is Copilot interaction auditing. Microsoft 365 Copilot interaction data is stored for auditing and compliance scenarios, so the rollout policy should define what is audited, who can review it, and how long it is retained — which matters both for incident investigation and for demonstrating responsible use to a regulator or auditor. For Dynamics 365 workloads, the Dataverse security and governance model carries the equivalent controls for the data that lives outside the Microsoft 365 tenant.

Agent-building needs its own policy surface. In Copilot Studio, admins use Power Platform data policies to constrain knowledge sources, connectors, HTTP requests, channels, triggers, and autonomous agent capabilities — including blocking agent publication with generative AI features when the organization is not ready. Maker audit logs flow into Microsoft Purview; environment routing and maker welcome messages give builders a governed sandbox instead of the default environment free-for-all. Microsoft's Administering and Governing Agents guidance describes zone-based maturity (Environment Groups with escalating controls as agent risk rises) — a practical alternative to one flat lock-down that kills experimentation. When agents leave the pilot, Agent 365 becomes the inventory and security plane: real agent identities, policy aligned to existing Purview DLP and Insider Risk patterns, and discovery of shadow agents on devices via Defender and Intune. For an SME, adopt the zone model even if you never buy E7: pilot environment, production environment with DLP, and a rule that no Tier 2 agent publishes without a named business owner and credit budget.

Measuring adoption and value: baseline, pilot, before-and-after

A Copilot rollout that cannot prove its value loses executive sponsorship within two quarters. The measurement discipline that prevents that is simple to state and rarely done well: pick the specific workflows the rollout targets, measure a baseline before Copilot touches them, run a defined pilot group, and measure the same metric after on the same workflow. The discipline that separates a credible business case from a slide is measuring the same thing before and after — not quoting industry averages as if they were guarantees.

Microsoft provides the telemetry to do this inside the tenant. The Microsoft 365 admin center exposes adoption analytics showing active Copilot users and app-level usage, and the Microsoft 365 Copilot readiness report shows license status, update channels, and usage data to help plan and track deployment. For the autonomous agents in Business Central, consumption is trackable inside the product itself: opening an agent and choosing View consumption data shows execution by month and credits used by task, with a detailed task log of every step the agent took. Those numbers are the bridge between adoption (are people using it?) and cost (what is it consuming?), and they are the raw material for a defensible ROI calculation.

Independent benchmarks give the model a sane starting point, used as a framework rather than a promise. The Forrester Total Economic Impact study Microsoft commissioned for SMBs modeled a three-year ROI of 132% to 353%, a 6% revenue lift, a 20% reduction in operating costs, and 25% faster new-hire onboarding; Forrester's enterprise TEI found general users saved about 8 hours per month and highly sophisticated users up to 20 hours per month. These are modeled averages for composite organizations. The honest use of them is to size the opportunity and to sanity-check your own before-and-after numbers — not to present them as the return your rollout will deliver. The full ROI methodology, including how to avoid double-counting when a business runs Copilot alongside an ERP, is covered in our Copilot ROI guide.

Practitioner and market commentary through 2025–2026 is blunt about seat economics: paid attach rates lag Microsoft's commercial base, and US$30/user seats without redesigned workflows look like expensive wrappers. That skepticism is a governance input, not a reason to skip measurement. If active-user rates stay low after champions and prompt libraries ship, reallocate seats before expanding agents. If agents consume credits without moving the before/after KPI, turn the agent off. Governance that cannot decommission underused seats and agents is not cost governance.

Change management: champions, prompt libraries, and phased rollout gates

Buying Copilot licenses and announcing them does not produce adoption — and Copilot with no active users generates zero benefit while still costing the per-user fee. Microsoft learned this deploying Copilot to its own 300,000-plus employees and documented the experience in five chapters, the first of which is governance and the third of which is driving adoption to capture value. The internal capability those chapters describe is change management: the champion network, the role-specific enablement, and the phased rollout gates that turn a license into measurable behavior change.

A champion network is the single highest-leverage adoption control. Identify one advocate per team or department, equip them with a role-specific prompt library built from Microsoft's Copilot Scenario Library (which organizes use cases by role — Sales, Customer Service, Finance, Operations, HR, Field Service), and make them the local point of escalation for prompts that do not work. Champions are how adoption spreads peer-to-peer, which is what actually moves the active-user metric; a top-down 'use Copilot' mandate without local advocates reliably stalls. The prompt library is the reusable artifact — each entry maps a real workflow (summarize this opportunity, draft this follow-up, analyze this variance) to a tested prompt and an expected outcome.

The phased rollout is governed by gates, not by a calendar. Each phase — pilot group, then departmental waves, then company-wide — has explicit go/no-go criteria: the data estate for that scope is remediated, the use-case triage is complete, the credit budget is modeled, the champions are trained, and the before-baseline is captured. A wave only proceeds when its gate criteria are met, which is what prevents the failure mode of enabling Copilot tenant-wide before the permissions, labels, and approvals are in place. This is the same change-management discipline that governs any enterprise system rollout, and it is covered in depth in our ERP change management guide.

Cost governance: budgeting Copilot Credits before agents go live

Cost governance is the fourth domain, and it is where most rollouts get an avoidable surprise. The per-user license is the easy number; the metered Copilot Credits underneath autonomous agents and many Studio agents are the silent one. Enterprise Microsoft 365 Copilot still lists around US$30/user/month annual on top of the base suite — so all-in cost is seats plus base E3/E5 (or Business plans), not the add-on alone. Copilot Credits are Microsoft's common currency for usage-based billing across eligible services (renamed from messages in 2025), complementing fixed subscription licensing with pay-as-you-go tied to actual consumption. In Dynamics 365 — and especially in Business Central — the autonomous agents (Sales Order Agent, Payables Agent, Expense Agent, and agent design tooling) bill consumption per action, and a license with no credit budget modeled is a budget leak waiting to happen at month-end.

The governance rule is to model the credit budget before any Tier 2 agent is switched on, using the published per-action rates. In Business Central, a Generative answer typically consumes 2 credits and an Agent action 5 credits; the Sales Order Agent averages roughly 16.5 credits per request across its steps, the Payables Agent costs 50 credits per invoice plus 5 credits per line, and the Expense Agent is 50 credits per receipt. Each credit is worth roughly US$0.01, so a Payables invoice runs about US$0.50 plus US$0.05 per line. The discipline is to estimate monthly volume (invoices, orders, receipts), multiply by the rates, add a contingency, and treat that as a recurring line item alongside the license — reviewed monthly, not annually. Microsoft offers two billing models to bound this: prepaid Copilot Credit Commit Units (which can save up to 20% versus pay-as-you-go and are consumed first) and Azure pay-as-you-go that covers overage automatically. For new workloads, the Customer Cowork Estimator helps model credit usage before commitment.

Visibility is the other half of cost governance. In Business Central, consumption is visible on the agent itself (Actions, then View consumption data), broken down by month and by task with a step-level task log — but only to users with the SUPER or AGENT-DIAGNOSTICS permission set, since the AGENT-ADMIN set is deliberately not enough to see billing detail. The governance practice is to grant that visibility to the cost owner (Finance or the IT lead), set a monthly spend threshold that triggers a review, and link the Dynamics 365 or Business Central environment to a Power Platform environment so consumption is correctly allocated rather than falling silently against the tenant default. Done right, cost governance turns Copilot Credits from a surprise invoice into a managed, forecastable line item.

Studio-side metering has its own hard edge. Published rates include classic answers at 1 credit, generative answers at 2, agent actions at 5, and tenant graph grounding at 10 credits per event — with higher rates for premium generative tools and voice. Employee-facing agents used by authenticated Microsoft 365 Copilot licensed users can run many of those features at no additional credit charge under Microsoft's inclusion rules, but external channels, unlicensed users, certain agent-flow triggers, and Computer-Using Agents still consume credits. Prepaid capacity is not infinite: when a tenant hits 125% of prepaid Copilot Credit capacity, custom agents can be disabled until capacity is reallocated, purchased, or covered by pay-as-you-go. Cost governance therefore means environment-level allocation, alerts before the 125% cliff, and a rule that production agents always have a PAYG backstop or an approved capacity increase path — not a silent outage mid-quarter.

Agent 365 and agent sprawl: govern what you can inventory

By mid-2026 the governance problem shifted from 'should we buy Copilot seats?' to 'which agents are already running, on whose identity, with access to which data?' Microsoft Agent 365, generally available from May 2026, is Microsoft's answer: a control plane to observe, govern, and secure agents — including agents that act with delegated user access and agents that run with their own credentials — across Microsoft 365, Copilot Studio, Microsoft Foundry, and an expanding set of partner agents.

Why this belongs in a Copilot governance model: seats without agent inventory still fail. An employee can spin up a Studio agent, connect a broad SharePoint knowledge source, publish to a channel, or run a local coding agent that never appears in your Copilot license report. Microsoft's own framing is blunt — you cannot govern what you cannot see. Agent 365 registry, Entra agent identities, and integrations with Defender and Intune for shadow-AI discovery on devices exist to close that gap. Purview patterns familiar from user data protection (DLP on agent-drafted mail, blocking labeled-file access at runtime, Insider Risk and audit for agent actions) extend to agents so policy is not reinvented per builder tool.

Practitioners on the ground still report the same root cause security teams have seen for years: Copilot and agents do not invent access — they accelerate recon over permission debt. Red-team and MSP write-ups describe overshared SharePoint estates becoming conversationally searchable; X-side commentary echoes that tenant hygiene becomes a recurring invoice the moment AI is on. The governance response is sequential, not panic: inventory agents (Agent 365 or at minimum Power Platform environments and the Agent Store), apply the same risk tiers you use for use cases, fence high-risk sites with RCD while permissions are fixed, and refuse production autonomy without a named owner, credit budget, and human approval path. SMEs should not treat Agent 365 or E7 as mandatory day-one SKUs — but they should treat agent inventory and shadow-AI discovery as mandatory operating practices the moment the first agent leaves a sandbox.

Common governance failures and the gate model that prevents them

Most Copilot rollouts that go wrong fail for predictable, preventable reasons — which is the entire case for running governance as a continuous discipline rather than a launch checklist. The failures cluster into the same four domains the governance model is built around, and each maps to a control that, if it had been in place, would have caught the problem before it became an incident or an invoice.

On the data side, the dominant failure is enabling Copilot without an oversharing audit, so broad groups and unlabeled sensitive files get surfaced in plain language to anyone who asks. On the agent side, it is uncontrolled builder sprawl — agents published from the default environment with broad connectors and no owner, or local agents on laptops outside any inventory. On the usage side, it is no change management — licenses bought but unused because no champion network or prompt library existed, which silently zeroes out the ROI model. On the measurement side, it is no baseline, so there is no way to prove the investment paid off and sponsorship fades. On the cost side, it is unmodeled agent consumption: autonomous agents switched on without a credit budget, or prepaid capacity exhausted to the 125% enforcement cliff, producing either a surprise invoice or a mid-quarter outage. Every one of these is preventable inside the governance model above.

The structural fix is a gate model applied to each rollout phase. A phase proceeds only when its gate criteria are met: data remediated and labeled, use cases triaged, credit budget modeled, champions trained, baseline captured, and an owner signed off. The table below pairs the common failures with the gate that prevents them. Treat any failure in production as evidence that a gate was skipped, not as a reason to add a new ad-hoc control — because the four domains already cover the surface, and the discipline is in enforcing the gates, not inventing new ones.

How Flectic helps you govern a Microsoft Copilot rollout

Flectic is an AI-driven ERP and CRM implementation partner for SMEs on Microsoft Dynamics 365 and Odoo, delivering remote-first across Canada, the UK, and the US. We are dual-platform and platform-neutral — we implement Business Central, the F&O-tier Dynamics 365 apps, and Odoo — so we have no incentive to push you toward a Copilot license you do not need or a governance stack heavier than your tenant requires. For an SME, that neutrality matters because the most common governance mistake is buying the Microsoft 365 Copilot add-on when Copilot is already included in the Business Central license, and then layering enterprise controls an SME cannot operate.

For Copilot governance specifically, we help SMEs install the four-domain model without enterprise overhead. We run the oversharing assessment using SharePoint Advanced Management and Purview where you have the licensing, model the Copilot Credits budget before any autonomous agent is switched on, build the use-case triage with explicit human-approval rules on Tier 2 agents, and stand up a lightweight champion network with role-specific prompt libraries. Our AI-Accelerated Delivery Framework is designed to deliver up to 3x faster than a conventional rollout — qualified by our delivery methodology, not a blanket guarantee — and we scope every gate to your real user count rather than a generic enterprise template.

If you are governing a Copilot rollout, the most useful thing we can do is run a scoping conversation that maps your highest-risk data first, gives you a realistic governance and cost model, and tells you honestly where Copilot is ready for your workflows and where it is not — including a clear answer on whether your AI data is even ready. We will also give you the gate criteria to run the rollout yourself, even if the delivery partner is not us.

Frequently asked questions