5. From Tiers to Enforcement

5.1 Combining the two tiers

The Application Tier and Permission Tier are evaluated together to determine how a consent request is handled.

In multi-permission requests, the highest-risk permission determines the overall permission tier, ensuring that a single high-risk scope cannot be diluted by lower-risk scopes in the same request.

Organizations should map tier combinations to enforcement outcomes that reflect their own risk appetite and review capacity. For example: auto-approving only low-risk permissions from well-governed apps, requiring analyst review for mid-tier requests, and escalating any high-tier application or permission to a formal exception process.

The guiding principle is that the two tiers are combined on a highest-risk-wins basis: neither strong app governance nor a benign permission alone should bypass scrutiny of the other layer.

5.2 Reference enforcement matrix

Note

This matrix is a reference example, not a normative requirement. Organizations are expected to tune outcomes to their own risk appetite and review capacity. The normative requirement is the highest-risk-wins principle in §5.1.

App Tier ↓ / Permission Tier →	Low	Medium	High	Critical
Low	Auto-approve	Analyst review	Analyst review	Exception review
Medium	Analyst review	Analyst review	Exception review	Exception review
High	Analyst review	Exception review	Exception review	Exception review
Critical	Exception review	Exception review	Exception review	Exception review

Outcome definitions:

• Auto-approve — The request is granted without human intervention; the decision and its inputs are logged for audit.
• Analyst review — A security analyst reviews the scored request and approves or denies it against documented criteria.
• Exception review — A formal exception process with named accountable ownership, a documented business justification, a compensating-control assessment, and a review expiry date.

5.3 Periodic re-evaluation

Risk drifts even when an application’s configuration does not change. Certificates expire, owners leave, apps fall dormant, publisher verification lapses, and permissions granted long ago go unused. Because every OARS input is programmatically retrievable, scoring should be re-run on a schedule rather than only at consent time, so that governance reflects current conditions rather than conditions at the moment of approval.

---

OARS §5 is derived from the Graph Consent Risk Framework by Khurram Chaudhary. Licensed CC BY 4.0.