Tier low-code apps by what they touch and what they can do: personal (own data only), team (shared data, internal audience) and sensitive (customer, financial or regulated data, or external actions). Each tier gets a proportionate review, so security effort goes where the risk is.
Why tiering
OWASP's prevention advice for Asset Management Failures (CD-SEC-09) includes implementing tiered risk classification alongside ownership, lifecycle, a central governance function and a full inventory. Without tiers, either everything is reviewed and the process stalls, or nothing is reviewed and the inventory becomes decoration.
Three questions that place an app
- What data does it read or write? Own files, shared internal data, or customer, financial or employee data.
- What can it do? Read only, change records, send messages, move money, call external services.
- Who uses it? Only the builder, a team, or the whole company or the public.
If any answer is at the high end, the app goes in the higher tier. The rule is highest wins.
The tiers
| Tier | Typical profile | Review | Controls |
|---|---|---|---|
| Personal | Builder's own data, no sharing | Register only | Approved connectors, no personal secrets shared |
| Team | Shared internal data, team audience | Light check by a trained reviewer | Service identity, named owner, review date |
| Sensitive | Customer or regulated data, external actions, broad audience | Full security review before launch | Narrow scopes, data flow map, logging, tested rollback, quarterly review |
Move apps between tiers deliberately
Apps drift upward. A personal flow gets shared, a team app gains a customer data source, and the tier changes without anyone noticing. Set triggers that force re-tiering:
- A new connector or new data source is added.
- The audience grows beyond the original group.
- The app begins to send email or messages outside the company.
- The app starts writing to a system of record.
What the review covers at the sensitive tier
- Identity: service identity, scope and owner.
- Data: map of hops and destinations.
- Configuration: sharing, endpoints, anonymous access, secrets.
- Input handling: validation and platform syntax tests.
- Logging: who did what, without secrets in logs.
- Recovery: how to switch it off quickly.
Keep it light
Limit yourself to three tiers and a one-page checklist per tier. If people cannot place an app in under two minutes, the model is too complicated.
A quick example
A recruiter builds a flow that reminds them of interview follow ups from their own calendar. That is personal. They share it with the hiring team, and it now reads candidate details from a shared tracker: team. Later it emails candidates directly and writes offers to the HR system: sensitive. The flow did not change much in each step, but the risk did, which is why triggers for re-tiering matter more than the first label.
Where Safeguard fits
Safeguard's policies, gates and guardrails let engineering teams apply different rules to different change risk levels in code. Tiering low-code apps themselves is a governance practice you run in your registry. Free scan: https://gold.safeguard.sh/scan.
Quick check
Who decides the tier?
The builder proposes it with the three questions, and a reviewer confirms for team and sensitive apps.
What if an app fits two tiers?
Use the higher one.
Sources
Last reviewed: 19 October 2026.
