Tag: eDiscovery Copilot

Copilot audit trails are the complete records of every interaction between users and Microsoft 365 Copilot — including the prompts users submit, the responses Copilot generates, the documents referenced during grounding, and the web queries used to supplement answers. These audit records are captured through Microsoft Purview and serve as the compliance backbone for Copilot governance, enabling incident investigation, regulatory reporting, legal discovery, and usage pattern analysis.

This guide covers the complete audit and monitoring stack for Microsoft 365 Copilot, from initial configuration through advanced investigation workflows.

What Copilot Logs: Understanding the Audit Record

Every Copilot interaction generates an audit event containing multiple data points. Understanding what is captured — and what is not — is essential for building effective monitoring and investigation capabilities.

Captured in the audit record:

• User prompt: The exact text the user typed or spoke to Copilot
• Copilot response: The complete text Copilot generated
• Referenced documents: File names, locations, and IDs of documents Copilot accessed for grounding
• Web queries: Search queries Copilot issued to retrieve supplementary information
• Application context: Which M365 application hosted the interaction (Teams, Word, Excel, Outlook, etc.)
• Timestamp and user identity: When the interaction occurred and which user account initiated it
• Sensitivity labels: Labels on any documents that were referenced during the interaction

Not captured:

• Internal model reasoning or intermediate processing steps
• Copilot’s confidence scores or alternative responses it considered
• Interactions that were blocked by DLP before Copilot processed them (these generate separate DLP events)

Configuring Purview Audit for Copilot

Enabling Audit Logging

Microsoft Purview Audit must be enabled at the tenant level for Copilot interaction events to be captured. Most enterprise tenants have audit logging enabled by default, but verification is essential before assuming Copilot interactions are being recorded.

Verification steps:

1. Navigate to the Microsoft Purview Compliance Portal
2. Select Audit from the left navigation
3. Confirm that “Auditing” status shows as enabled
4. Run a test search for “CopilotInteraction” activity type to verify events are flowing

Purview Audit Standard vs Premium: Standard audit retains Copilot events for 180 days. Purview Audit Premium extends retention to 365 days (configurable up to 10 years) and adds intelligent insights, higher API throughput for programmatic access, and priority processing for compliance investigations. Regulated industries should deploy Premium.

Configuring Retention Policies for Copilot Data

Audit log retention is separate from data retention. Even with audit logging enabled, the underlying Copilot interaction data (prompts, responses, referenced documents) must be preserved through dedicated retention policies.

1. Navigate to Purview → Data lifecycle management → Retention policies
2. Create a new policy scoped to Microsoft 365 Copilot interactions
3. Set the retention period based on regulatory requirements: 3 years minimum for most enterprises, 6-7 years for financial services (SEC/FINRA), indefinite for litigation-prone organizations
4. Configure the policy to retain and then delete (not retain only) to manage storage growth

Microsoft Purview Activity Explorer for Copilot

Activity Explorer is the primary interface for investigating individual Copilot interactions. It provides a searchable, filterable view of all audit events, including Copilot-specific activity types.

Key Copilot Activity Types

Filter Activity Explorer by these activity types to focus on Copilot events:

• CopilotInteraction: General Copilot usage events across all M365 applications
• CopilotDocumentAccess: Events where Copilot accessed specific documents for grounding
• CopilotDLPMatch: Interactions that triggered a DLP policy match
• CopilotComplianceAlert: Interactions flagged by Communication Compliance policies

Investigation Workflow Using Activity Explorer

When investigating a specific Copilot interaction:

1. Filter by user and date range to narrow the scope
2. Select the CopilotInteraction activity type
3. Review the prompt text — what did the user ask?
4. Review the response text — what did Copilot provide?
5. Examine referenced documents — which files were accessed for grounding?
6. Cross-reference with DLP events — did any policy matches occur?
7. Check document sensitivity labels — was any Confidential or Highly Confidential content accessed?

Data Security Posture Management for AI

Microsoft Purview Data Security Posture Management (DSPM) for AI provides a dashboard-level view of Copilot security and compliance posture across the organization. Rather than investigating individual interactions, DSPM for AI answers strategic questions:

• How much sensitive data is Copilot accessing across the tenant?
• Which departments generate the most DLP policy matches?
• What percentage of Copilot interactions reference labeled vs unlabeled content?
• Are there users whose Copilot usage patterns suggest overly broad permissions?

DSPM for AI should be reviewed monthly by the security team and quarterly by executive stakeholders as part of the Copilot governance review cycle.

eDiscovery Workflows for Copilot Data

Copilot interactions are discoverable under Microsoft Purview eDiscovery. This means Copilot prompts, responses, and referenced documents can be placed under legal hold, collected for review, and produced in litigation or regulatory proceedings.

Placing Copilot Data Under Legal Hold

1. Create a new eDiscovery case in Purview
2. Add custodians (the users whose Copilot interactions must be preserved)
3. Apply a hold that includes Microsoft 365 Copilot as a data source
4. The hold preserves all Copilot interactions for the custodian, preventing deletion even if retention policies would otherwise expire the data

Collecting and Reviewing Copilot Data

Copilot interactions appear in eDiscovery collections alongside emails, documents, and Teams messages. Reviewers can filter specifically for Copilot interaction types and review prompts and responses in context with the documents that were referenced.

Key considerations for legal teams:

• Copilot responses may contain synthesized content from privileged documents — review for privilege before production
• Prompts reveal user intent and knowledge state — these may be relevant to investigations
• Referenced document lists show what information the user had access to through Copilot, even if they did not directly open those files

Building Audit-Ready Documentation

For organizations subject to external audits (SOC 2, ISO 27001, regulatory examinations), Copilot governance must be documented to audit standards. The audit documentation package should include:

• Copilot governance policy: The organization’s official policy document covering all five governance domains
• Configuration evidence: Screenshots or exports of DLP policies, sensitivity labels, Restricted SharePoint Search settings, and Communication Compliance rules
• Audit log samples: Exported audit events demonstrating that logging is active and capturing expected data
• Incident response playbook: Documented procedures for Copilot-related security incidents
• Training records: Evidence that users received Copilot governance training
• Review cadence: Calendar and minutes from monthly/quarterly governance reviews

Incident Investigation Workflow

When a report indicates that Copilot surfaced sensitive data inappropriately, follow this investigation workflow:

1. Triage (0-1 hour): Determine severity. Did Copilot surface regulated data (PHI, PII, MNPI)? Was the recipient unauthorized? Is regulatory notification required?
2. Containment (0-2 hours): Disable Copilot for the affected user via the Microsoft 365 Admin Center. If the exposure is systemic (affects a group or department), disable Copilot at the group level
3. Investigation (1-5 days): Use Activity Explorer to review the specific interaction. Identify the source documents. Determine why those documents were accessible — was it a permission misconfiguration, a missing sensitivity label, or a gap in Restricted SharePoint Search?
4. Remediation (1-3 days): Fix the underlying access issue. Apply or correct sensitivity labels. Update DLP policies if the exposure pattern was not previously covered
5. Notification (as required): Assess regulatory notification obligations. HIPAA requires breach notification within 60 days. GDPR requires DPA notification within 72 hours. State breach notification laws vary
6. Documentation (ongoing): Record the incident, root cause, remediation steps, and preventive measures in the governance log. Update the incident response playbook if new patterns were identified

Frequently Asked Questions