diff --git a/docs/compliance/EXTERNAL_SECURITY_REVIEW_SCOPE.md b/docs/compliance/EXTERNAL_SECURITY_REVIEW_SCOPE.md
new file mode 100644
index 0000000..9b2a622
--- /dev/null
+++ b/docs/compliance/EXTERNAL_SECURITY_REVIEW_SCOPE.md
@@ -0,0 +1,82 @@
+# CASAN — External Security Review / Penetration-Test Scope
+
+This is the procurement and evidence baseline for an **independent** security
+review before an enterprise pilot. It is not a penetration-test report and must
+not be used as a claim that CASAN has passed an external assessment.
+
+## 1. Engagement boundary
+
+| In scope | Required test focus |
+|---|---|
+| Control Panel API, UI, reverse proxy and deployment manifests | authentication boundary, RBAC/SoD, tenant/project isolation, input/output validation, HTTP/TLS configuration |
+| Harness CLIs and CI workflows | command/path injection, policy bypass, unsafe fallback, artifact/evidence tampering, secret handling and supply-chain controls |
+| Governed Chat and approval paths | unauthorized tool execution, approval replay/bypass, audit-chain integrity, cross-tenant replay and data exfiltration |
+| Evidence Pack and publication flow | manifest signature/verification, retention/immutability assumptions, artifact access control and chain of custody |
+| Production-like deployment | OIDC claim mapping, Vault/KMS access, Object Lock, rootless runner/sandbox, network egress and observability |
+
+Out of scope tests require a written change order. Production data, destructive
+load tests, phishing and social engineering are forbidden unless the customer
+explicitly authorizes them in writing.
+
+## 2. Prerequisites supplied by CASAN/customer
+
+- A dedicated, non-production test tenant with synthetic code, prompts and
+  secrets; no customer production source code or personal data.
+- DNS name, CA-issued test certificate, enterprise OIDC test application and
+  least-privilege assessor accounts for viewer, operator, project-admin and
+  org-admin roles.
+- A deployment inventory: image digests, SBOM, workflow commit, configuration
+  version, data-flow diagram, network/egress policy and known limitations.
+- A change window, emergency contact, on-call escalation path and explicit
+  stop-test authority.
+- A current Evidence Pack and commands for `verify-pack`, audit-chain
+  verification, backup restore drill and release-provenance verification.
+
+## 3. Required attack scenarios
+
+The assessor must cover at least these scenario classes and record the exact
+target version/configuration for every finding:
+
+1. Authentication/session handling, OIDC issuer/audience/JWKS failures and
+   browser-supplied identity-header spoofing.
+2. RBAC scope escalation, separation-of-duties bypass and cross-project or
+   cross-tenant reads/writes/replays.
+3. Prompt/tool-output injection, unregistered tool execution, CODEGEN write
+   attempts and approval-token replay.
+4. Secret/PII exfiltration via logs, Evidence Pack, model routing, artifacts,
+   API responses, error paths and egress configuration.
+5. Evidence/audit/trace tampering, clock/retention assumptions and failure of
+   manifest/provenance verification.
+6. Container/sandbox privilege, rootful daemon usage, writable host mounts,
+   network escape, resource exhaustion and queue starvation.
+7. Dependency, image and CI supply-chain validation against the live scanner,
+   SBOM and digest/provenance assertions.
+
+## 4. Rules of engagement
+
+- Assessors must use named accounts and an agreed source-IP range; all activity
+  is captured in the H5 audit trail and preserved in a review Evidence Pack.
+- Do not alter production state, delete artifacts, rotate real keys, or bypass
+  legal/contractual third-party rate limits.
+- Critical findings trigger immediate notification to the security contact;
+  CASAN may engage the kill switch while preserving evidence.
+- Retesting is required for every Critical/High finding and for any control
+  used as an enterprise procurement claim.
+
+## 5. Acceptance evidence
+
+The independent assessor must deliver a dated, signed report with scope,
+methodology, target versions, findings/CVSS or agreed severity, reproduction
+evidence, limitations and retest results. CASAN must retain:
+
+| Evidence | Owner |
+|---|---|
+| Signed statement of work and rules of engagement | Security owner |
+| Report plus finding/remediation register | Security + engineering owners |
+| Retest attestation for remediated findings | Assessor |
+| Evidence Pack and audit export for the assessment window | Release/security owner |
+| Risk acceptance signed by accountable business owner for any deferred finding | Customer/security owner |
+
+Enterprise-pilot readiness requires no unresolved Critical findings. Any
+unresolved High finding needs a time-bounded, documented risk acceptance; this
+does not make the platform "pentest certified".
diff --git a/docs/plans/CASAN_BACKLOG_STATUS.md b/docs/plans/CASAN_BACKLOG_STATUS.md
index 4007a07..b9b1c23 100644
--- a/docs/plans/CASAN_BACKLOG_STATUS.md
+++ b/docs/plans/CASAN_BACKLOG_STATUS.md
@@ -45,6 +45,7 @@
 | T2.7 | Backup/restore + restore drill | 🟡 automated + test | `state-backup.sh` creates manifest/hash-bound state snapshots, requires encryption key in prod, restores only to an empty explicit directory; `phase-state-backup` is in CI. Remaining: customer object-store replication, retention/RPO/RTO, and a retained production restore-drill record. |
 | T2.8 | Upgrade/rollback compatibility | 🟡 automated + test | `upgrade-compatibility.sh` is fail-closed and permits only explicit matrix rules; the 1.0.x patch/rollback rule requires provenance, backup, artifact smoke and post-deploy Evidence Pack verification. Remaining: a reviewed migration rule for every future minor/major release and a retained live rollout/rollback record. |
 | T2.9 | Gitea Evidence Pack publishing | 🟡 workflow implemented | `harness-ci.yml` creates, verifies, and uploads `casan-evidence-pack-<run>` on every PR/push workflow. Remaining: first hosted run must be retained and checked in the Gitea UI; API token/PR creation is still needed from this environment to initiate that evidence. |
+| T2.10 | External security review / pentest | 🟡 scope ready, assessment not started | `docs/compliance/EXTERNAL_SECURITY_REVIEW_SCOPE.md` defines the independent engagement boundary, attack scenarios, rules of engagement and required signed/retest evidence. Remaining: procure an assessor, execute against a dedicated environment, remediate findings and retain the signed report. |
 
 ## TIER 3 — Platform plans (INDEX 01–12, việc lớn nhiều phiên) 📋