Not every citizen-built app needs the same level of oversight. The organizations getting governance right use a tiered model that matches controls to actual risk, not a one-size-fits-all review process.
A three-tier risk classification system is the single most important structural decision in citizen development governance design. It determines how much oversight each solution receives, what application lifecycle management requirements apply, and where the boundary sits between citizen development and professional IT.
This guide provides the complete framework: the tier definitions, the classification criteria, the ALM requirements for each tier, and the data classification matrix that makes tier assignment consistent and defensible.
Why Tiers Matter
Without risk tiers, organizations face an impossible choice. Apply enterprise-grade governance to every citizen-built solution and the program dies from overhead. Apply no governance and the program dies from an incident.
The tiered model eliminates this false choice. A personal task tracker and a department-wide financial reporting dashboard are fundamentally different in risk profile. They should receive fundamentally different levels of governance. Tiers make that distinction systematic rather than ad hoc.
Programs that implement risk tiers consistently report faster time-to-deployment for low-risk solutions (because Tier 1 has minimal overhead), better compliance for high-risk solutions (because Tier 3 gets appropriate scrutiny), and clearer handoff criteria between citizen development and professional IT (because the tier boundary defines when work exceeds citizen development scope).
The Three Tiers
Tier 1: Personal and Team (Green Zone)
Scope: Solutions used by individuals or small teams, typically fewer than 25 users, with non-sensitive data.
Typical examples: Personal task management apps, team meeting schedulers, simple data capture forms, individual productivity automations, dashboards built from non-confidential data sources, and proof-of-concept prototypes.
Governance requirements: Minimal. Lightweight versioning through the platform's built-in version history. Simple backups where supported. No formal change records required. Direct publish from the maker's personal or team workspace. No CoE review before deployment.
ALM pattern: Informal. The citizen developer builds and publishes in a single environment. No environment separation required. No solution packaging. The platform's native undo and version history provides sufficient rollback capability.
Key principle: Tier 1 must feel frictionless. The majority of citizen development value is created here. If your governance model adds any meaningful overhead to Tier 1 work, builders will route around it.
Tier 2: Departmental (Amber Zone)
Scope: Solutions serving a department or business function, potentially handling confidential data or supporting operationally important processes. Typically 25 to 500 users or solutions with departmental business impact.
Typical examples: Departmental approval and routing workflows, solutions processing internal financial or HR data, cross-team reporting dashboards pulling from multiple data sources, automations connecting restricted connectors, and solutions that would cause meaningful disruption if they failed.
Governance requirements: Structured. CoE review before production deployment, focused on data access patterns, connector usage, user access model, and support plan. Peer review or design review with a CoE member or Champion. Basic user acceptance testing before go-live.
ALM pattern: Department-specific sandbox environment for development and testing. Basic solution packaging for deployment. Manual export from sandbox, import to production. Source control recommended but not required. Documentation stored in a standard repository with owner name, creation date, and purpose statement.
Key principle: Tier 2 governance should feel proportionate, not punitive. The review focuses on risk-relevant factors, not architectural elegance. A Tier 2 review should take hours, not weeks.
Tier 3: Enterprise and Regulated (Red Zone)
Scope: Solutions with broad organizational impact, regulated data, or high business criticality. More than 500 users, cross-departmental data dependencies, regulatory compliance requirements, or integration with core business systems.
Typical examples: Anything handling protected health information (PHI), personally identifiable information subject to GDPR or similar regulation, or data governed by industry-specific compliance frameworks. Solutions integrated with ERP, core financial, or customer-facing systems. Enterprise-wide automations or solutions requiring custom code components. Any solution where failure would have significant financial, legal, or reputational impact.
Governance requirements: Formal. Solution Architecture Board review before development begins. Formal user acceptance testing and integration testing. Security review covering data flows, access patterns, and connector permissions. Documented rollback plan. Incident response plan.
ALM pattern: Separate development, test, and production environments. Managed solutions only in production (no unmanaged or direct edits). Automated CI/CD pipelines via Azure DevOps, GitHub Actions, or equivalent. Required Git-based version control. Formal release management with documented change records.
Key principle: Most Tier 3 work should transition to professional development teams. The CoE's role is identifying when a solution has grown beyond citizen development scope and managing that handoff. Citizen developers may remain involved as subject matter experts, but the technical ownership shifts to IT.
The Classification Matrix
Tier assignment is based on three dimensions assessed independently. The highest-risk dimension determines the tier.
Data Sensitivity
Public or non-sensitive data (meeting schedules, team directories, project status): Tier 1 eligible.
Internal confidential data (financial reports, HR metrics, internal KPIs, strategic plans): Tier 2 minimum.
Regulated or protected data (PHI, PII subject to GDPR/CCPA, data governed by SOX, HIPAA, PCI-DSS, or industry-specific frameworks): Tier 3 required.
User Scope
Individual or small team (fewer than 25 users, single team): Tier 1 eligible.
Department or business function (25 to 500 users, single department or cross-team within a function): Tier 2 minimum.
Enterprise or cross-departmental (more than 500 users, multiple departments, or organization-wide): Tier 3 required.
Business Criticality
Convenience (nice-to-have, no impact if unavailable for days): Tier 1 eligible.
Operational (supports daily work, moderate disruption if unavailable): Tier 2 minimum.
Critical or regulated (failure has financial, legal, or reputational consequences; supports regulated processes): Tier 3 required.
The escalation rule: Any single dimension at a higher tier pulls the entire solution to that tier. A personal app (Tier 1 on scope) that connects to regulated data (Tier 3 on sensitivity) becomes a Tier 3 solution.
Tiered ALM: Scaling Lifecycle Management Down
The fundamental ALM challenge for citizen development is whether lifecycle management can scale down, not up: making it accessible to citizen developers without requiring them to step outside their maker experience.
Tier 1 ALM Practices
Version history through the platform's native capabilities. Manual backups before significant changes if the platform supports export. No formal documentation requirements. No environment separation. The citizen developer is the builder, tester, and deployer.
Tier 2 ALM Practices
Development in a sandbox environment separate from production. Basic solution packaging for deployment (solution export/import or equivalent). Peer review before promotion to production, focused on the App Review Checklist: business case documented, risk tier confirmed, data sources reviewed, access model defined, testing completed, support plan in place, monitoring configured, documentation stored, decommission trigger defined. Manual promotion process with a brief change record.
Tier 3 ALM Practices
Full environment separation: development, test, and production. Only managed solutions deployed to production. Automated deployment pipeline. Required source control with branching strategy. Formal testing including integration tests and user acceptance testing. Change Advisory Board or Solution Architecture Board approval. Documented rollback procedures. Post-deployment monitoring and validation.
Implementing Tier Assignment in Practice
During Intake
When a solution request comes through the intake process, the CoE performs a quick triage using the classification matrix. The intake form should capture enough information to make an initial tier assignment: data sensitivity, estimated user count, department, and business impact description.
Initial tier assignment should happen within one to two business days. Delays at this stage are the most visible sign that governance is becoming a gate.
Tier Escalation
Solutions can move up in tier as they evolve. A Tier 1 personal tool that gains departmental adoption becomes Tier 2. A Tier 2 departmental solution that starts handling regulated data becomes Tier 3.
Build tier reassessment into your regular governance cadence. Quarterly portfolio reviews should include a scan for solutions that have outgrown their current tier. Automated discovery tooling that monitors user counts, connector usage, and data access patterns makes this reassessment data-driven rather than relying on self-reporting.
Tier Boundary Disputes
When stakeholders disagree on tier assignment, the decision defaults to the higher tier. It is always safer to over-govern initially and downgrade after review than to under-govern and discover the gap after an incident. Document the rationale for any tier assignment that is disputed, and include it in the governance review record.
Common Mistakes
Applying Tier 2 governance to Tier 1 work. This is the most common and most damaging mistake. If every citizen developer must submit a review request before deploying a personal task tracker, the program has failed the seventh principle: the governed path is no longer the easiest path.
Letting Tier 3 solutions remain in citizen development scope. When a solution clearly requires enterprise-grade ALM, professional security review, and formal project management, it should transition to IT. Keeping it in citizen development scope stretches the CoE beyond its mandate and exposes the organization to risk.
Assigning tiers based on the builder's seniority rather than the solution's risk profile. An experienced Champion building a personal productivity tool should still be Tier 1. A new Explorer building an app that connects to the CRM should still be Tier 2. The tier follows the solution, not the person.
Not revisiting tier assignments. Solutions evolve. A quarterly portfolio review that checks for tier drift catches solutions that have silently escalated in risk without corresponding governance adjustments.