Skip to content

Roles and decision rights (RACI)

The app owner is accountable for a worker-built app once it's in use, and the builder is responsible for building it. Decision rights scale with risk tier: the table below says who approves employee-built apps in a citizen developer program, who signs what, and what to do when one person holds several roles. There are ten roles, plus the executive sponsor for Critical risk and legal or privacy counsel, who is consulted.

Who this is for

IT managers, security leads and app owners setting up or running a program for worker-built apps. You get role definitions, a RACI table for 18 decisions, the minimum staffing when one person holds several roles, separation-of-duties rules by tier and an escalation path. Reading time: about 12 minutes.

These are roles, not job titles. One person can hold several, except where separation of duties says otherwise. Record each in the app registry by role name plus a named successor.

The roles

Builder
The person who builds or changes the app, with or without AI help. Responsible for the build, the intake answers, the app's own test cases and the verification self-check. Can be a non-developer or a professional developer. A maintainer is anyone other than the original builder who later changes the app.
App owner
The business person accountable for the app once anyone besides the builder relies on it, usually the process owner or the builder's manager. See app ownership.
Manager
The builder's line manager. Agrees the building time, names a new app owner when one leaves, and is the first escalation point.
Enablement lead
Runs intake and triage, the registry, training and champions. Signs downgrades from Important (or the security reviewer does), and owns the counsel route. See enablement and training.
Business reviewer
Any colleague who knows the process. At Important and Critical, reviews the logic, the data used and whether the access matches the intent. Doesn't sign off data rules; that's the technical check.
Technical reviewer
A platform or IT engineer, or a champion who has been trained and listed as a technical reviewer on a published list. Does the Important-tier technical check (an exposure scan, the data-rule negative tests and a 30–45 minute fixed-list check). Until a published list exists, the IT/platform owner names technical reviewers. Signs standard downgrade 3 with the app owner after doing the check. See business review and technical check.
Security reviewer
Security staff, or an outside security provider under contract. Does the Critical-tier security review, signs downgrades (from Important, instead of the enablement lead; from Critical, with the IT/platform owner), and leads security incidents.
Data owner
The person accountable for a data set (HR, finance or customer data, for example). Signs off any app that uses Confidential or Restricted data.
IT/platform owner
Owns the approved-tools list (by data class, including tools' built-in AI features), the hosting patterns and identity. Approves new tools, co-owns Critical apps through graduation, and signs downgrades from Critical with the security reviewer.
Compliance owner
The person who manages the company's audits and attestations (for example SOC 2, ISO 27001 or SOX). Receives every app with the audit-scope flag set to yes and is accountable for its change-management and evidence requirements; an audit-scope app doesn't go live until those requirements are set. The flag doesn't change the tier, and the requirements apply at whatever tier the app is: there's no minimum tier for audit-scope apps. If you have no compliance function, the IT/platform owner holds this role, and the flag is answered "no" unless you give customers an attestation or have an external audit.
Executive sponsor
The senior leader named in the leadership charter. Accepts residual risk for Critical apps (or delegates it to the app owner's executive), settles escalations, and is the second signer when one person holds both Critical downgrade roles.
Legal or privacy counsel (consulted)
Answers the counsel gates: the jurisdiction flag, the consent gate (biometric identifiers, data about anyone under 18, consumers' health or other sensitive data), and the human-review design for apps that help decide things about people. Can be in-house or outside counsel; how requests reach them is the counsel route.

Who decides what

R = responsible (does it), A = accountable (one per decision; signs), C = consulted before, I = informed after. A blank cell means the role has no part in that decision. "Approver for the tier" follows the downgrade path.

Decision Builder App owner Manager Enablement lead Business reviewer Technical reviewer Security reviewer Data owner IT/platform owner Compliance owner Executive sponsor Counsel
Intake: Sandbox (workspace registration) A/R I I
Intake: Team or Important (tier and answer) R C I A C (Important) C C if audit-scope flag yes C if a counsel gate applies
Intake: Critical R C I R C C A C if audit-scope flag yes I C if a counsel gate applies
Use Confidential or Restricted data R C I C A C
Add an AI feature (M1) R A C C C C (service approved for the data class) C if Q5 isn't (a)
Grant an agent or automation its permissions (M3) R A I C C (Important and above) C R (issues scoped credentials)
Set evidence and change requirements for an audit-scope app C R I C C A
Go-live R A I I R (Important and above) R (Important and above) R (Critical) I C (Critical: R) C (requirements met, if audit-scope flag yes)
The technical check C I I A/R C I
Production access for a Critical app I C I C C A/R I
Accept residual risk C A (Team, Important) I C C C C C A (Critical; may delegate to the app owner's executive) C
Downgrade one tier R (prepares) A (requests and signs) I R (signs, from Important) R (signs standard downgrade 3) R (signs) C R (signs, from Critical) I R (second signer if one person holds both Critical roles)
Graduate to IT C R I C C I A I I
Retire an app R A I R (registry) I C R (Critical) C if audit-scope flag yes C (legal hold)
Reassign the app owner I R (outgoing) A R (registry) I I I
Approve a new tool or AI service I R C C A C C
Handle an incident R R I I A (security incidents) C R I I (Critical) C
Bounded exception: change a gate's timing or method (never a tier, an answer, a floor or a legal trigger) I R (requests and signs) I A (Team, Important) C C (Critical: R, signs) C C (Critical: A) C

Notes on the table:

  • Downgrades need two signatures (downgrade path, rule 2); the builder prepares the record but never signs it.
  • A bounded exception changes a gate's timing or method, never whether it applies. Its approver is the A in its row; the full rule is on bounded exceptions.
  • Accepting residual risk for a Critical app is a business decision, so the executive sponsor (or a delegate) is accountable; IT co-owns the app, so IT's objections go in the Decision Record.
  • The audit-scope row gives the compliance owner one A: setting what change history, approvals and evidence the app must keep. Go-live waits until those requirements are set.

Don't: make the builder the sole owner

A builder-only owner leaves an orphaned app the day they go: still live, unpatched and holding its access (AP19)1. From Team up, name a business app owner who isn't only the builder, with a successor (principle 4).

Don't: make everyone, or a committee, accountable

"IT and the business are jointly accountable" means nobody is: each decision has one A, as Australia's government AI policy does with named accountable officials2. And a central team that must approve everything becomes a queue builders stop waiting for: Thoughtworks describes noncoders building their own software "instead of waiting for the IT department"3. The enablement lead triages; the app owner and the named reviewers make most Team and Important decisions.

When one person holds several roles

Often one IT manager is the IT/platform owner, the technical reviewer and, in practice, the security reviewer. The model still works if you staff the minimum and keep a second signer.

Minimum staffing before intake opens:

  1. An enablement lead (can be part-time, and can be the IT manager).
  2. At least one technical reviewer who isn't the enablement lead's only backup: a second IT person, or a champion trained and listed as a technical reviewer.
  3. An IT/platform owner.
  4. A named security reviewer: an internal person or an outside security provider under contract. If you have no one for this role, no app can be approved at Critical; Critical candidates stay capped at their current scope until one is named.
  5. An executive sponsor, named in the leadership charter.
  6. A counsel route, set up by the enablement lead: who counsel is, what to send and the target turnaround (see the counsel route).

The same minimum people can tier the apps that already exist: run a tier workshop for existing apps.

Second-signer rules:

  • If one person holds both Critical signer roles (IT/platform owner and security reviewer), the executive sponsor is the second signer for downgrades from Critical, and the outside security provider, if you have one, is consulted.
  • If the enablement lead is also the only technical reviewer, they can't both check an app they triaged and sign its downgrade from Important; the security reviewer signs.
  • If the IT manager built the app, separation of duties below applies to them like any builder: someone else reviews and signs.
  • If an outside provider does your security, put the review turnaround in the contract and give it read access to the registry.

The likeliest failure is one person quietly signing both sides. Record every use of a fallback signer, and report the count to the executive sponsor quarterly.

The counsel route

The jurisdiction flag defaults to yes and the consent gate routes before any collection, so many apps that touch customer data will wait on counsel. The enablement lead owns the counsel route: they set it up before intake opens, send each request, and track waits.

  • Who counsel is: in-house counsel or a privacy officer if you have one. If you don't, outside counsel on an agreed scope is fine. Name counsel in the leadership charter.
  • What to send: Intake Parts 1 and 2, which gate fired and why, the people or regions if known, where the data is stored or sent (including any AI service), and the question.
  • How fast: agree a target turnaround with counsel, and report the median wait each month beside the intake answer time. While a counsel gate holds, the app stays at its current scope.
  • Don't ask the same question twice. Record each answer as a Decision Record that later intakes with the same facts can cite. We expect that to let counsel keep up with intake, but it's untested: measure the share of intakes routed to counsel and the median wait, and if the wait regularly exceeds five working days, add counsel capacity or narrow the questions.

Separation of duties by tier

Tier Rule
Sandbox None: the builder is the owner and only user.
Team The app owner isn't only the builder. The builder can't be the champion who backs them up.
Important The builder can't be the business reviewer or the technical reviewer of their own app. The named backup isn't the builder.
Critical As Important, plus independent tests by someone other than the builder; the security reviewer and IT/platform owner aren't part of the build. If they are, the executive sponsor names a substitute.
Any tier The builder never signs their own downgrade. A data owner doesn't sign off their own app's data use; their manager or deputy does. The same person never provides both signatures on one Decision Record.

Escalation path

  1. Builder to app owner, for anything about the app's purpose, users or data.
  2. App owner to enablement lead, for intake answers, tier disputes and late reviews (after five working days).
  3. Enablement lead to the security reviewer or IT/platform owner, for anything Critical, any floor at risk, and incidents.
  4. To the executive sponsor named in the leadership charter when two of the above disagree, when review capacity is the bottleneck, or when a Critical residual risk needs accepting.

Tier disputes follow the process on risk tiers: record the higher answer until it's settled.

Depends on your circumstances (C1)

If you process regulated or special-category data, name the data owner and privacy officer for each regulated data set before intake opens, and make counsel a standing reviewer for Q1(d) and Q5 apps. Health-care providers and plans also name the HIPAA security official, who approves standard downgrade 2's platform.

Depends on your circumstances (C6)

If you already run a platform team, its engineers are the default technical reviewers; keep the champion route open anyway, so review capacity grows with demand (A-042).

Depends on your circumstances (C7)

If several business units already build independently, keep one tier model, registry and approved-tools list; each unit names its own enablement lead and technical reviewers. Critical apps, new tools and downgrades from Critical stay with the central IT/platform owner and security reviewer.

Assumptions and evidence

  • A-034 (Low): we expect the app owner can be recorded as a role with a named successor, so ownership survives people leaving; test this by checking each quarter how many owner roles have no current holder.
  • A-042 (Low): we expect Important-tier review capacity (business review plus technical check) to keep up with demand, including where one IT person holds several roles; test this by measuring the median wait for a technical check against five working days, and counting fallback signers each quarter.

Evidence: government policy and practitioner guidance on named accountability, and a standards-body risk list; no controlled study of decision rights for worker-built apps. Facts on this page are as of October 2026.

  1. OWASP Citizen Development Top 10, CD-SEC-09 "Asset Management Failures" (2022; the orphan risk persists). https://owasp.github.io/www-project-citizen-development-top10-security-risks/content/2022/en/CD-SEC-09-Asset-Management-Failures [primary], accessed 2026-10-21. ↩

  2. Australian Digital Transformation Agency, policy for the responsible use of AI in government (v2.0 effective 15 Dec 2025). https://www.dta.gov.au/blogs/responsible-choices-new-policy-using-ai-australian-government [primary], accessed 2026-10-21. ↩

  3. Thoughtworks Technology Radar, "AI-accelerated shadow IT", Nov 2025 entry (Vol. 33, Hold): "AI is lowering the barriers for noncoders to build and integrate software themselves, instead of waiting for the IT department to get around to their requirements." https://www.thoughtworks.com/radar/techniques/ai-accelerated-shadow-it [primary], accessed 2026-10-21. ↩