Ownership Rules
Ownership rules ensure that every application in your Microsoft Entra ID tenant has clearly defined accountability. These rules require a minimum number of owners and are the foundation of effective application governance.
Rule types
EasyLife 365 Identity supports three types of ownership rules, each serving a different governance purpose:
Minimum application owner
What it does: Requires applications to have a minimum number of Entra ID owners (native Azure owners).
Why use it: Entra ID owners have direct permissions to manage the application in Azure. At least one Entra ID owner is typically required to ensure someone can make technical changes to the app configuration.
Common configurations:
- 1 owner: Standard requirement for most applications
- 2+ owners: Critical applications requiring redundancy
Use cases:
- Ensure applications can be modified when needed
- Prevent orphaned applications that no one can manage
- Maintain continuity when individuals leave the organization
How it's evaluated:
- Checks the application's owners in Entra ID
- Counts only direct owners (not group members)
- Triggers non-compliance if the count falls below the minimum
Minimum technical owner
What it does: Requires applications to have a minimum number of technical owners from EasyLife 365 Identity.
Why use it: Technical owners are responsible for the technical aspects of the application—configuration, permissions, certificates, secrets, and troubleshooting. They may or may not have Entra ID ownership, but they're designated as the technical point of contact in EasyLife 365 Identity.
Common configurations:
- 1 technical owner: Standard for most applications
- 2+ technical owners: Complex or critical applications
Use cases:
- Designate who handles technical issues and configuration
- Separate technical responsibility from business ownership
- Ensure someone can answer questions about how the app works
- Support scenarios where Entra ID owners are centralized (e.g., cloud team), but app-specific technical contacts are needed
How it's evaluated:
- Checks the application's technical owners in EasyLife 365 Identity
- Independent of Entra ID ownership
- Triggers non-compliance if the count falls below the minimum
Example: A centralized cloud team may be the Entra ID owner of all applications, but each application has designated technical owners from the development teams who built them.
Minimum business owner
What it does: Requires applications to have a minimum number of business owners from EasyLife 365 Identity.
Why use it: Business owners represent the business purpose of the application—why it exists, what it's used for, who uses it, and whether it's still needed. They provide non-technical accountability.
Common configurations:
- 1 business owner: Standard for most applications
- 2+ business owners: High-value or cross-departmental applications
Use cases:
- Identify who requested or sponsors the application
- Ensure someone can answer "Why do we have this?"
- Support license optimization and cost allocation
- Enable informed decisions during application reviews
- Provide business context for security and compliance assessments
How it's evaluated:
- Checks the application's business owners in EasyLife 365 Identity
- Independent of Entra ID ownership and technical ownership
- Triggers non-compliance if the count falls below the minimum
Example: An HR system has a technical owner (the developer who integrated it), an Entra ID owner (the cloud team), and a business owner (the HR director who requested it).
Owner types compared
| Aspect | Application Owner (Entra ID) | Technical Owner | Business Owner |
|---|---|---|---|
| Defined in | Microsoft Entra ID | EasyLife 365 Identity | EasyLife 365 Identity |
| Permissions | Can modify app in Azure | No automatic permissions | No automatic permissions |
| Responsibility | Technical management in Azure | Technical implementation and support | Business justification and sponsorship |
| Typical role | Cloud admin, app developer | Developer, DevOps engineer, IT specialist | Business sponsor, department head, product owner |
| Answers questions like | How do I change app settings? | How does this app work? | Why do we have this app? |
Configuration examples
Basic governance policy
Ensure every application has at least one responsible owner:
Rules:
- Minimum application owner: 1
- Minimum technical owner: 1
Result: Every app must have someone who can manage it technically (Entra ID owner) and someone designated as the technical contact (technical owner).
Business accountability policy
Require business ownership for all applications:
Rules:
- Minimum application owner: 1
- Minimum technical owner: 1
- Minimum business owner: 1
Result: Every app must have technical accountability AND business accountability. Ideal for organizations that want to track business sponsorship and cost allocation.
High-criticality policy
Require redundancy for mission-critical applications:
Rules:
- Minimum application owner: 2
- Minimum technical owner: 2
- Minimum business owner: 1
Result: Critical apps have redundant technical ownership (two Entra ID owners, two technical owners) to ensure continuity. Useful for applications that must never become orphaned.
SaaS integration policy
Require business ownership for third-party integrations:
Rules:
- Minimum application owner: 1
- Minimum business owner: 1
Result: Every SaaS integration must have a business owner who can justify the integration and make decisions about its continued use. Technical owner is not required because the vendor manages the technical implementation.
Developer application policy
Focus on technical ownership for apps created by developers:
Rules:
- Minimum application owner: 1
- Minimum technical owner: 1
Result: Developer-created apps must have an Entra ID owner and a designated technical owner (the developer). Business owner is not required because these are often internal tools without dedicated business sponsors.
Best practices
Align ownership with organizational structure
Match ownership requirements to how your organization works:
- Centralized IT: May use application owners (Entra ID) for all apps, with technical and business owners for accountability
- Federated IT: May require business owners to represent different departments
- DevOps culture: May emphasize technical owners to designate responsible development teams
Use different requirements for different app types
Create multiple policies tailored to specific scenarios:
- Production applications: Require all three owner types
- Development/test apps: Require only application and technical owners
- SaaS integrations: Require application and business owners
- Service principals: Require application and technical owners
Plan for ownership transitions
Ownership changes when people change roles or leave:
- Automatic notifications: Use My Tasks to notify owners when they're assigned
- Regular reviews: Monitor compliance to identify apps losing owners
- Documented processes: Maintain procedures for transferring ownership
- Grace periods: Allow time to assign new owners before escalation
Combine with expiration policies
Ownership and expiration work together:
- Expiration identifies apps that should be reviewed
- Ownership ensures someone is responsible for responding to the review
Configure policies to require ownership for apps that expire, ensuring reviews are completed by responsible parties.
Separate technical and business ownership
Don't assume one person should be both:
- Technical owners need technical skills to support the application
- Business owners need business context to justify the application
- Separation of concerns prevents conflicts of interest and improves accountability
Use minimum values strategically
Higher minimum values provide redundancy but require more effort:
- Minimum 1: Standard for most applications, ensures basic accountability
- Minimum 2: Critical applications, provides backup coverage
- Minimum 3+: Rarely needed, only for the most critical systems
Compliance and non-compliance
When applications become non-compliant
Applications become non-compliant when:
- An owner is removed from the application
- An owner's account is disabled or deleted
- The policy minimum is increased
How compliance is restored
Compliance is restored when:
- Additional owners are assigned to meet the minimum
- The policy minimum is reduced
- The policy is removed or deactivated
Owner assignment methods
Owners can be assigned in several ways:
By the application owner (self-service):
- Owners can assign additional owners from the application detail page
- Supports delegation of ownership management
By administrators (centralized management):
- Admins can assign owners in bulk from the Manage section
- Useful for inherited applications or organizational changes
During provisioning:
- Owners are assigned automatically when apps are created through EasyLife 365 Identity
- Ensures new apps start in compliance
Escalation and remediation
When applications remain non-compliant after notifications:
Standard escalation
Configure escalation actions to alert broader teams:
- Email: Send to IT leadership or governance teams
- Webhook: Create tickets in ServiceNow, Jira, or other ITSM systems
- Logic Apps: Trigger automated remediation workflows
Automated remediation
Use webhooks and automation to respond to non-compliance:
- Auto-assignment: Assign default owners based on app metadata
- Disable apps: Automatically disable apps that remain non-compliant
- Archive apps: Move non-compliant apps to a quarantine group
Manual review processes
For sensitive scenarios, use manual workflows:
- Weekly reviews: Governance team reviews non-compliant apps
- Approval workflows: Require manager approval to assign new owners
- Audit trails: Document ownership changes for compliance
Related concepts
- Ownership - Learn about the three types of owners
- Policies - Understand policy evaluation and escalation
- App Registration Policies - See ownership rules in action for app registrations
- Enterprise Application Policies - See ownership rules in action for enterprise applications