# GRD-020: Scope exceptions to a single detection for a defined group


- Area: Runtime Guardrails

- Verification: Live test
- OWASP adoption tier: Tier-independent
- Formerly: POL-009
- URL: /r/GRD-020

**Acceptance criteria:** Grant an exception for one detection, data class or tool to one group, leaving every other protection in place for that group. For example, a deal team can discuss financial projections without losing credential or personal-data protection. Document a named owner, business rationale and review date for each exception.

**Why it matters:** A team that needs latitude on one data type should not lose every other protection.

**How to verify:** One detection is relaxed for a pilot group while all other detections still fire for that group. Show the documented exception owner, business rationale and review date.

**OWASP adoption context:** Exceptions apply wherever the group works, so a scoped exception should behave the same across every listed context.

**Mappings:**
- NIST CSF 2.0: ID.RA-07, PR.AA-05; SOC 2: CC6.3, CC5.3; ISO 27001: A.5.15, Cl. 6.1.3 — A narrowly scoped exception records a specific deviation and keeps least privilege in place for everything else. The exception still needs an owner, a rationale and a review date.
ISO/IEC 27001: The exception record supports Cl. 6.1.3 only when linked to risk assessment, the risk owner’s approval of the treatment plan and acceptance of residual risk. A named owner, business rationale and review date alone do not establish those decisions.
- NIST AI RMF: GOVERN 1.4 — Granular exceptions keep the risk-management process transparent about exactly which control is relaxed and for whom. The rationale for each exception must still be documented.