---
title: "KYE™ DSAR Evidence Pack™ — signed, offline-verifiable subject access response"
description: "KYE™ DSAR Evidence Pack™ — signed bundle of every audit-chain entry involving a named data subject. GDPR Art. 15 / UK DPA Pt 3 Ch 3 / CCPA"
url: https://kyeprotocol.com/dsar/
lang: en
source: "KYE Protocol"
---

> KYE™ DSAR Evidence Pack™ — signed bundle of every audit-chain entry involving a named data subject. GDPR Art. 15 / UK DPA Pt 3 Ch 3 / CCPA

KYE™ DSAR Evidence Pack™

# A subject access response your regulator can re-verify offline.

A KYE™ DSAR Evidence Pack™ is a signed bundle of every audit-chain entry involving a named data subject across the configured window, with the dsar-handling rule pack's inclusion / confidence / exclusion / redaction decisions applied. The requesting subject (or their counsel, or the supervisory authority) verifies the pack offline using only the controller's published JWKS — no controller cooperation required.

[Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Read the docs](https://kyeprotocol.com/docs/)

## Why DSAR responses get challenged

In a typical SaaS posture, the controller hand-assembles a DSAR response from a SQL export, a CSV from a CRM, and a screenshot of a permissions screen. The subject (and increasingly, the supervisory authority) cannot independently verify:

- that every audit-chain row mentioning the subject was actually considered;
- that no row was silently omitted because it was inconvenient;
- that the redactions are principled (third-party rights under GDPR Art. 15(4)) rather than expedient;
- that the response would be identical if reassembled tomorrow from the same data.

A KYE™ DSAR Evidence Pack™ closes all four gaps in one bundle.

## What's in the pack

Schema: `kye.dsar_evidence_pack.v1`. Reference example: [github.com/KYE-Protocol/examples/dsar-evidence-pack.json ↗](https://github.com/KYE-Protocol/examples/blob/main/dsar-evidence-pack.json).

- **Pack header** — pack\_id, subject\_request\_id (your case-management ticket), subject\_ref\_hash (SHA-256 of the subject reference; the raw value never leaves your audit chain).
- **Window** — inclusive (from / to) search window. Default \`from\` is the tenant retention floor; default \`to\` is \`issued\_at\`.
- **Inclusion policy** — inclusion\_min\_confidence, third\_party\_redaction (\`full\` / \`field\_level\` / \`none\`), exclude\_classifications (e.g. security\_monitoring rows that would prejudice an investigation under GDPR Art. 23).
- **evidence\_rows** — one entry per included audit-chain row. Sorted ascending by occurred\_at for deterministic content\_hash. Each row carries the original decision\_id (joinable back to the Decision Map™), the asset\_id touched, action / classification / purpose, decision, the per-field redactions\_applied with reason codes, and the evidence\_pack\_id for the full Evidence Pack™.
- **excluded\_rows\_summary** — aggregate count + reason\_code\_distribution. The subject sees that N rows were considered and excluded, without seeing the row contents. Defence-in-depth against silent omission.
- **summary** — assets\_touched, actions\_taken, decision\_distribution.
- **content\_hash** — SHA-256 over the RFC-8785 JCS canonical form of the pack minus the signature field. Byte-stable.
- **signature** — Ed25519 detached signature by a KID resolvable in your published JWKS.

## The 5-rule assembly pipeline

Rule pack: `dsar-handling`. Constitution §31 §2 (#12). 5 rules, deterministic order.

1. **dsar\_include\_if\_subject\_ref\_matches** — first-pass selector. Any audit-chain row whose data\_subject\_ref.ref\_value\_hash equals the request's subject\_ref\_hash is a candidate.
2. **dsar\_exclude\_if\_below\_inclusion\_confidence** — drop candidates whose match\_confidence falls below inclusion\_policy.inclusion\_min\_confidence. Counted in excluded\_rows\_summary with reason `dsar_inclusion_threshold_not_met`.
3. **dsar\_exclude\_if\_classification\_excluded** — drop candidates whose classification is in inclusion\_policy.exclude\_classifications (GDPR Art. 23 restrictions). Counted in excluded\_rows\_summary.
4. **dsar\_redact\_third\_party\_fields** — apply per-field redaction\_strategy (drop / partial\_mask / tokenise / preserve\_only\_for\_subject) from the asset's pii\_inventory to any field whose subject differs from the requester. GDPR Art. 15(4). Recorded in row.redactions\_applied with reason `dsar_third_party_redacted`.
5. **dsar\_require\_signed\_pack** — assembly-completion gate. Refuse delivery if content\_hash + Ed25519 signature absent or malformed.

## How a subject verifies the pack offline

Same posture as the [regulator probe playbook](https://kyeprotocol.com/playbooks/regulator-probe/), scoped to a single subject's view.

```
# 1. Fetch the pack
curl -s https://controller.example/dsar/<pack_id>.json > pack.json

# 2. Fetch the controller's JWKS (always discoverable)
curl -s https://controller.example/.well-known/jwks.json > jwks.json

# 3. Verify the pack signature with the open SDK
npx @kye/sdk verify-dsar-pack \
  --pack pack.json \
  --jwks jwks.json

# 4. (Optional) for any row in evidence_rows, fetch its parent Evidence Pack
#    and walk the Decision Map for the full authority chain at the time
#    of the decision. Same verifier, no controller cooperation required.
```

## Determinism + replay

Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it.

- **Byte-stable content\_hash.** Re-issue the same pack tomorrow from the same audit-chain state and the bytes match. The DSAR pack is reproducible evidence, not a snapshot rendered fresh each time.
- **Deterministic row ordering.** evidence\_rows are sorted ascending by occurred\_at. Tie-break is by event\_id (ascending). No clock-skew, no ordering ambiguity.
- **Canonical JCS encoding.** RFC 8785. The same bytes regardless of whether the pack is rendered in TypeScript, Python, Go, or via the open SDK.
- **Replay receipt.** Each evidence row keeps its evidence\_pack\_id pointer; an investigator can re-verify any single decision in the bundle independently of the pack.

## Honest limits

Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it.

- **We don't discover subjects.** The pack is keyed off subject\_ref\_hash. You produce the hash by salting your identifier and SHA-256-ing; KYE Protocol™ never sees the raw subject identifier.
- **We don't interpret legal basis.** If a row should have been refused at decision-time (e.g. consent withdrawn), the Pack records the row + reason. Whether that constitutes a breach is for your DPO / counsel / regulator to decide.
- **We don't decide what to exclude under Art. 23.** exclude\_classifications is set by the controller, per request, with justification recorded in your case file. KYE™ applies the policy deterministically and reports the count.
- **We don't certify delivery.** Pack assembly is offline-verifiable; delivery channel + identity of the requester remain the controller's responsibility.

## File a Data Subject Access Request

Free of charge. Acknowledged within 48 hours. Reply via secure delivery within the statutory window for the regime you elect (30 days GDPR / 45 days CCPA / 90 days POPIA).

## Data subject request

Your request goes to the KYE Protocol™ team, and a receipt with a reference number is emailed to you.

Name Email Request type Details I agree to the [privacy policy](https://kyeprotocol.com/legal/privacy/). Send

Or email `dsar@kyeprotocol.com` directly. We log every request to the per-tenant audit chain and emit a §0.3 evidence event before forwarding to the controller.

## Next steps

Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it.

- [Read the full KYE™ Data Governance Pack™ page →](https://kyeprotocol.com/data-governance/)
- [Apply for a Data Governance Pack engagement →](https://kyeprotocol.com/pilot-apply/) — the £150k annual SKU includes a DSAR-rehearsal exercise as part of scoping.
- [Regulator probe playbook →](https://kyeprotocol.com/playbooks/regulator-probe/) — the offline-verification posture this page references.
- [Reference DSAR pack example on GitHub ↗](https://github.com/KYE-Protocol/examples/blob/main/dsar-evidence-pack.json)

Canonical KYE™ surfaces referenced on this page: [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE Protocol™](https://kyeprotocol.com/).