diff --git a/docs/security/SUPPORT_ACCESS_PROPOSAL.md b/docs/security/SUPPORT_ACCESS_PROPOSAL.md
new file mode 100644
index 00000000..d0cf4349
--- /dev/null
+++ b/docs/security/SUPPORT_ACCESS_PROPOSAL.md
@@ -0,0 +1,17 @@
+# Scoped support access proposal
+
+10 November 2026. Review draft on `codex/security-offline-preflight` after `ecadc29b`. Begin with the existing role-gated operational metadata and the [audit minimisation fix](ADMIN_INFORMATION_ISOLATION.md). The current audit and processing views already provide record identifiers, event/processing state and outcomes. Prefer those views, or a synthetic reproduction supplied by the user, for ordinary support.
+
+## Proposed first scope
+
+If a documented support case still requires a private record, allow a separately authorised support agent to request read access to one specific record and an enumerated set of fields. Show the verified owner the purpose, actor, exact scope, expiry and revocation control. The initial scope excludes mailbox bodies, raw CVs, documents, exports and download links. General Admin membership supplies no additional access.
+
+After explicit owner approval, the server can grant one support actor read-only access for up to one hour. Each read rechecks current role, active session, target owner, fields, grant purpose and expiry. Owner revocation, logout/revocation of the support session, or deletion of the owner or record invalidates access. A new actor, scope or time period needs a new approval. User-controlled grants provide a product access control. The controller must separately approve lawful basis and applicable notice and retention.
+
+Do not cache or persist private response bodies in the support view, logs or audit record. Log the actor, owner, approved record/field identifiers, purpose, timestamps and result. Define a bounded retention and deletion schedule for request and access metadata before enabling it. A security incident or legally required investigation uses separate approved incident procedures. [GDPR Articles 5 and 25](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng/), [EDPB guidance on data protection by design and default](https://www.edpb.europa.eu/documents/guideline/guidelines-42019-on-article-25-data-protection-by-design-and-by-default_en)
+
+## Approval and qualification
+
+Approval must specify the exact role, first record type and fields, user notice, lawful basis, retention, and any incident-policy relationship. Synthetic A/B tests must prove denial before approval, after expiry/revocation, for another actor/owner, on guessed or replayed identifiers, and on writes/export requests. Verify the persisted grant and audit trail, role/session changes, deletion, and absence of response content in logs. Positive tests should show only the approved field set.
+
+No access policy, route, storage or permission is implemented by this proposal.