Copilot Business or Enterprise: Data Retention and IP Questions

Whatever the vendor's marketing says, your comparison should come down to a short list. For each item, find the answer for the exact plan, in the current terms:

• Prompt and suggestion retention: are prompts, the code context sent with them and the returned suggestions stored, and for how long? Is that different for the chat feature versus inline completion?
• Training use: is your content used to train models, and is that off by default for the plan?
• IP protection: does the plan include an indemnity for generated output, and what conditions attach to it? Conditions often include enabling a filter for suggestions that match public code.
• Admin controls: can an administrator enforce settings across every seat, including blocking public-code matches and excluding files or repositories?
• Audit: is there an audit log of who used the tool and which settings changed?
• Processing location: where is data processed, and does that match your customer commitments?

Anything not written down in a current document is not an answer.

Collect evidence in this order, and file it where your security team keeps vendor reviews:

1. Read the current product terms and data protection addendum for the plan, and save a dated PDF.
2. Read the vendor's trust center or security documentation for the retention and training statements.
3. Ask the vendor in writing about anything ambiguous, such as chat versus completion retention, and keep the reply.
4. Check the organization settings page after you enable a plan, because a setting that exists in documentation may still be off by default.
5. Record the date. Re-check when you renew or when the vendor announces a plan change.

This file becomes the source when a customer's security questionnaire asks how you handle code sent to AI tools.

Use your requirements to pick, not the plan names. A few scenarios:

Say you're a ten-person product team with no regulated customers. The business tier of an assistant with organization-managed seats and training off is often sufficient. The larger tier is worth a look only if you need a capability it adds, and you should name that capability before you pay for it.

Say you sell to banks or health systems whose contracts restrict where code and data flow. You need the retention and processing answers in writing, and probably an indemnity, before any developer touches a customer repository. That may point to the higher tier, or to no cloud assistant on certain repositories at all.

Say contractors work in your repos. Make sure they use seats under your organization, not personal accounts, because personal plans carry different terms and give you no controls.

Buying the plan doesn't finish the job. Confirm and document these settings:

• Seats are assigned through your organization, with single sign-on if you use it.
• The public-code match filter is on, if your IP protection depends on it.
• Repositories or paths that hold secrets or restricted code are excluded from assistant context.
• Chat and inline completion policies are set deliberately rather than left at defaults.
• Someone owns the review of settings each quarter.

Then link these settings to your assistant usage policy and to how you check AI-generated code.

Answer with facts you can back up. State which tool and plan you use, that seats are managed through your organization, what data the terms say is retained and whether it's used for training, and which technical exclusions you've set. If you can't yet answer one point, say you're confirming it rather than guess. A precise, dated answer builds more trust than a confident summary that turns out to be out of date. Review it whenever the vendor changes terms, and compare with other options in the assistant comparison.