Assigning Permissions in Azure for Nonprofits: Subscription, Resource Group, or Service

At the heart of this post is Kairos IMS, an innovative Impact Management System designed to empower human-serving nonprofits and social impact organizations. Co-developed by the Urban League of Broward County and our trusted technology partner, Impactful, Kairos IMS reduces administrative burdens, enhances holistic care, and enables organizations to leverage data for increased agility and seamless service delivery. In this blog series, we’ll take a closer look at the powerful technologies that fuel Kairos IMS, from Azure services to security frameworks, offering insight into how modern infrastructure supports mission-driven impact. Click here  to learn more. 

Managing access in Azure can feel overwhelming—especially for nonprofits juggling limited IT resources and a growing need for secure, cloud-based solutions. Whether you're building a donor portal, managing volunteer data, or hosting a public website, assigning the right permissions to the right people is critical.

This guide breaks down when and how to assign permissions at different levels in Azure: Subscription, Resource Group, and Service (Resource)—so your team can stay secure and productive.

Understanding Azure Role-Based Access Control (RBAC)

Azure uses Role-Based Access Control (RBAC) to manage who can do what. You assign roles to users, groups, or service principals at different scopes:

• Subscription: The entire Azure environment
• Resource Group: A container for related resources
• Resource: A specific service (e.g., a single web app or storage account)

 Assigning Permissions at the Subscription Level

When to Use:

• Small nonprofit teams with a single environment
• Admins or IT leads who need full visibility and control
• Billing and cost management roles
•  Example Roles:

• Owner: Full access, including user management
• Contributor: Can manage resources but not access control
• Reader: View-only access

 Caution:

Avoid giving too many people access at this level—it’s like giving keys to the entire building.

 2. Assigning Permissions at the Resource Group Level

When to Use:

• Organizing by project (e.g., “Volunteer Portal” or “Fundraising App”)
• Delegating access to specific teams or vendors
• Isolating environments (e.g., dev, test, prod)

 Example Roles:

• Web App Contributor: Manage web apps only
• Storage Blob Data Contributor: Manage blob storage
• Monitoring Reader: View logs and metrics

Tip:

Use naming conventions for resource groups to keep things organized (e.g., rg-volunteer-portal-prod).

3. Assigning Permissions at the Resource (Service) Level

When to Use:

• Fine-grained control for sensitive services (e.g., databases)
• External consultants or volunteers working on a single app
• Automation accounts or service principals

Example Roles:

• SQL DB Contributor: Manage SQL databases
• Function App Contributor: Manage Azure Functions
• Key Vault Reader: View secrets (but not modify)

Best Practice:

Use least privilege—only give access to what’s absolutely necessary.

Combining Scopes for Flexibility

You can mix and match scopes to fit your nonprofit’s structure:

Security Tips for Nonprofits

• ✅ Use Azure AD Groups to manage access at scale
• ✅ Enable Multi-Factor Authentication (MFA)
• ✅ Audit access regularly using Azure Activity Logs
• ✅ Use Privileged Identity Management (PIM) for just-in-time access

Final Thoughts

Assigning permissions in Azure doesn’t have to be complicated. By understanding the scope hierarchy and applying least privilege principles, your nonprofit can stay secure, organized, and efficient—freeing up more time and resources to focus on your mission.