# PLT-002: Disclose where decisions are enforced and how the control fails


- Area: Platform, Privacy & Assurance

- Verification: Documentation + Live test
- OWASP adoption tier: AT0–AT4
- Formerly: ARC-015
- URL: /r/PLT-002

**Acceptance criteria:** Enforce before submission, so a blocked payload is never sent and a denied tool call never runs. State where each decision is evaluated (device, browser or cloud), whether TLS interception, a forward proxy or a managed certificate is required, and whether each surface fails open or fails closed.

**Why it matters:** Where a decision runs and how it fails decide whether data is actually stopped.

**How to verify:** The vendor documents enforcement points and failure modes per surface, and the pilot confirms them.

**OWASP adoption context:** Enforcement points and failure behavior can differ by surface, so each listed context needs its own answer.

**Mappings:**
- NIST CSF 2.0: PR.IR-03, PR.DS-02; SOC 2: CC6.7, CC9.1; ISO 27001: A.8.27, A.8.20 — A documented enforcement point and failure mode support secure-architecture and resilience decisions, and show whether data in transit is actually stopped. Neither fail-open nor fail-closed is right in every case; the buyer must choose per surface and test the behavior.
SOC 2: CC6.7 supports restrictions on unauthorized data transfers. Tested fail-open/fail-closed behavior provides evidence for assessing disruption risks and selecting mitigation under CC9.1. The buyer must approve the trade-off and implement the response; documenting a failure mode alone does not establish a complete mitigation plan.
- NIST AI RMF: MAP 4.2; ISO 42001: A.6.2.5 — Knowing where decisions run and what happens when they cannot be made documents the control's deployment requirements and dependencies. It is readiness evidence, not proof of correct behavior under failure.