Secure your analytics & reporting

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure DevOps analytics and reporting provide powerful insights into your development processes, but with that power comes the responsibility to protect sensitive data and control access to organizational metrics. This article outlines the security concepts, access controls, and best practices for securing your analytics and reporting implementation.

Security model overview

Analytics and reporting security operates on a multi-layered approach that includes:

• Control data visibility: Manage who can view analytics data and which projects they can access.
• Implement dashboard permissions: Control access to dashboards and their underlying data. For more information, see Set dashboard permissions
• Configure project-level access: Restrict analytics access based on project membership. For more information, see Default permissions and access for reporting
• Manage Power BI integration: Secure connections between Azure DevOps and Power BI. For more information, see Connect to Power BI Data Connector
• Enable audit and compliance: Track data access and maintain compliance requirements. For more information, see Access, export, and filter audit logs

Identity and access management

Access levels for reporting

Analytics and reporting capabilities vary by access level. For comprehensive information about default permissions for each access level, see Default permissions and access for reporting.

For more information, see About access levels.

Authentication for external tools

When you connect external reporting tools to Azure DevOps, secure authentication is essential:

Analytics security

Data access permissions

Analytics security is built on the principle of data visibility inheritance from source projects:

• Project-based access: Users can only see analytics data for projects they have access to. For more information, see Change project-level permissions
• Work item visibility: Analytics respects work item area path permissions. For more information, see Set work tracking permissions
• Repository access: Code metrics are filtered based on repository permissions. For more information, see Set Git repository permissions
• Pipeline visibility: Build and release analytics follow pipeline security settings. For more information, see Set pipeline permissions

Analytics views

Control access to specific data sets through Analytics views. For more information about creating and managing Analytics views, see Create an Analytics view.

Data filtering and privacy

Implement data filtering to protect sensitive information:

• Configure area path restrictions: Limit analytics data to specific work item areas. For more information, see Set work tracking permissions
• Apply field-level security: Hide sensitive work item fields from analytics. For more information, see Add and modify a field
• Manage cross-project access: Control visibility across multiple projects.

Dashboard security

Dashboard permissions

Control who can view, edit, and manage dashboards. For step-by-step instructions on configuring dashboard permissions, see Set dashboard permissions.

Widget security considerations

Different widgets have varying security implications:

• Query-based widgets: Inherit security from underlying work item queries. For more information, see Set permissions on queries
• Analytics widgets: Follow analytics view permissions and project access.
• External widgets: Might require other authentication and data sharing considerations. For more information, see Security best practices
• Custom widgets: Security depends on implementation and data sources. For more information, see Add, rename, and delete dashboards

Team and project dashboards

Manage dashboard access at different organizational levels:

• Team dashboards: Accessible to team members and project stakeholders. For more information, see Add a team, move from one default team to several teams
• Project dashboards: Available to all project contributors. For more information, see Change project-level permissions
• Personal dashboards: Private to individual users
• Organization dashboards: Visible across the entire organization. For more information, see Change permissions at the organization or collection-level

For more information about dashboard types and access, see Add, rename, and delete dashboards.

Power BI integration security

Data connector security

When you use Power BI with Azure DevOps, implement these security measures. For detailed setup instructions, see Connect to Power BI Data Connector.

• Use service principals with Microsoft Entra ID: Implement application-based authentication for automated refresh with centralized identity management. For more information, see Use Microsoft Entra tokens
• Configure row-level security: Filter Power BI data based on user identity
• Manage refresh credentials: Securely store and rotate data source credentials using Microsoft Entra ID authentication
• Apply workspace permissions: Control access to Power BI workspaces containing Azure DevOps data

Data privacy in Power BI

Protect sensitive data when sharing Power BI reports:

• Configure data sensitivity labels: Apply appropriate classification to reports and datasets
• Implement sharing restrictions: Control who can access and share Power BI content
• Monitor data usage: Track access patterns and identify potential security issues
• Apply export restrictions: Limit data export capabilities based on organizational policies

For more information about Power BI security best practices, see Power BI security baseline.

Compliance and auditing

Audit logging

Data retention and compliance

Implement appropriate data retention policies:

• Configure analytics data retention: Set appropriate retention periods for historical data
• Manage dashboard lifecycle: Establish processes for dashboard archival and deletion
• Document data lineage: Maintain records of data sources and transformations
• Implement compliance reporting: Generate reports for regulatory requirements

For more information about data protection, see Data protection overview.

Best practices for Analytics & Reporting security

Access management

• Apply least privilege principle: Grant minimum required access for analytics and reporting needs
• Conduct regular access reviews: Periodically audit dashboard and analytics permissions
• Use group-based management: Manage permissions through security groups rather than individual assignments
• Implement role-based access: Define standard roles for different reporting needs

Data protection

• Classify data sensitivity: Identify and protect sensitive metrics and reports. For more information, see Data protection overview
• Implement data masking: Hide or obfuscate sensitive information in shared reports. For more information, see Add and modify a field
• Control data export: Restrict bulk data export capabilities based on user roles. For more information, see Change access levels
• Monitor anomalous access: Watch for unusual patterns in data access and reporting. For more information, see Access, export, and filter audit logs

Integration security

• Secure external connections: Use encrypted connections for all external reporting tools. For more information, see Use Microsoft Entra tokens
• Validate third-party tools: Ensure external analytics tools meet security requirements. For more information, see Security best practices
• Manage Microsoft Entra authentication: Use organizational identity management for external integrations instead of individual tokens. For more information, see Use Microsoft Entra tokens
• Monitor integration usage: Track data access through APIs and external connections. For more information, see Access, export, and filter audit logs

Organizational governance

• Establish reporting standards: Define approved tools and practices for organizational reporting. For more information, see Security best practices
• Create data governance policies: Implement policies for data accuracy, privacy, and usage. For more information, see Data protection overview
• Train users on security: Educate teams on secure reporting practices and potential risks. For more information, see Security best practices
• Document security procedures: Maintain up-to-date documentation of security configurations and processes. For more information, see About permissions and security groups

Common security scenarios

Multi-project analytics

When implementing analytics across multiple projects, establish clear security boundaries:

Example scenario: An organization with multiple product teams needs consolidated reporting while maintaining project isolation:

Organization: TechCorp
├── Project: ProductA (Team A access only)
├── Project: ProductB (Team B access only)
├── Project: Shared Services (All teams access)
└── Project: Executive Dashboard (Managers only)

In this configuration:

• Team members can access analytics only for their assigned projects. For more information, see Change project-level permissions
• Shared Services metrics are visible to all teams for dependency tracking.
• Executive dashboard provides high-level metrics without exposing sensitive project details. For more information, see Set dashboard permissions
• Cross-project queries are restricted based on user permissions. For more information, see Create an Analytics view

External stakeholder reporting

Manage security when sharing reports with external stakeholders:

• Create stakeholder-specific dashboards: Design views that show relevant metrics without sensitive details
• Use read-only access: Provide view-only permissions for external users
• Implement time-limited access: Set expiration dates for external user access
• Apply data filtering: Ensure external users see only approved information

For guidance on managing external users, see Add external users to your organization.

Regulatory compliance reporting

For organizations with compliance requirements:

• Implement audit trails: Maintain detailed logs of all data access and modifications. For more information, see Access, export, and filter audit logs
• Apply data retention policies: Ensure analytics data meets regulatory retention requirements. For more information, see Data protection overview
• Control data location: For cloud instances, understand where analytics data is stored. For more information, see Data locations for Azure DevOps
• Generate compliance reports: Create standardized reports for regulatory submissions. For more information, see Export user list with access levels

Security configuration checklist

Initial setup

• [ ] Configure appropriate access levels for analytics users
• [ ] Set up security groups aligned with reporting needs
• [ ] Configure project permissions for analytics access
• [ ] Set dashboard permissions for team and project dashboards
• [ ] Configure Analytics views with appropriate access controls
• [ ] Set work tracking permissions to control data visibility

External integrations

• [ ] Configure Microsoft Entra authentication for external reporting tools
• [ ] Configure Power BI connections with Microsoft Entra ID authentication
• [ ] Set up row-level security in Power BI for multitenant scenarios
• [ ] Document and approve all external tool connections

Ongoing management

• [ ] Conduct regular permission audits for analytics and dashboard access
• [ ] Monitor audit logs for unusual analytics activity
• [ ] Review and update dashboard permissions as teams change
• [ ] Manage Microsoft Entra authentication and rotate credentials for external integrations
• [ ] Validate that analytics data filtering is working correctly