Back to Playbook

    Pokee Playbook

    DSAR & Subject Rights

    Map a data subject access request to your systems, track the deadlines, and draft the response letter.

    Know what you hold, where it lives, what you owe

    A DSAR that looks simple on its face is really a question about every system that holds the data. The skill answers that question before the deadline is missed.

    The mapping, from your inventory

    Every data category in the request is mapped to the systems that hold it, with access method and scope. Every mapping cites the inventory source.

    The deadline, cited or marked

    The response deadline is calculated from the request date and the applicable regime. Where a deadline is stated in the record, it is cited. Where the skill supplies a general reference, it is marked to verify.

    The gaps, before they are missed

    Legacy systems, incomplete archives, and unverified scopes are surfaced and marked open. The letter does not promise what the record cannot deliver.

    What the skill does for you

    Four stages, one run. From request to response letter.

    1. 1

      Parse the request

      The scope, as understood

      • Requester identity, the data categories requested, the stated purpose, the request date
      • Anything ambiguous is noted as an open item
      • The scope as understood is stated in the letter, so it can be corrected early

      The outcome: A clean read of what was requested, before the work starts.

    2. 2

      Map data to systems

      What you hold, where it lives

      • Each data category mapped to the systems in your inventory that hold it
      • System name, data elements, retention, access method, and scope
      • Every mapping cites the inventory source

      The outcome: A work plan for the collection, built from the table, not from a reread of the inventory.

    3. 3

      Build the deadline and verification plan

      The clock, visible

      • The response deadline, from the request date and the applicable regime
      • The identity verification steps required, each with owner and status
      • Any exemptions that may apply, marked to verify where the skill supplies the general reference

      The outcome: A deadline and a verification plan that are visible, not assumed.

    4. 4

      Build the tracker and letter

      The letter, from the same facts

      • Request fields, data mapping, verification, deadlines, exemptions, and exceptions in one cited XLSX workbook
      • The draft response letter is generated from the same fact base
      • When the request develops, re run and the tracker and letter stay in sync

      The outcome: A draft for attorney review where the letter and the tracker never disagree.

    A sample request, run end to end

    Meridian Health Systems, DSAR of Robert Alan Chen (fictional). A patient access request for clinical and billing records. Three documents in; the output below is real.

    data to system mappings, each cited to the inventory
    13data to system mappings, each cited to the inventory
    deadlines: one cited from the record, one marked to verify
    2deadlines: one cited from the record, one marked to verify
    exemptions to verify, each with reason and source
    3exemptions to verify, each with reason and source
    exceptions: legacy systems and an incomplete archive, marked open
    4exceptions: legacy systems and an incomplete archive, marked open

    From the tracker (real output, abbreviated)

    Meridian DSAR · Chen · Patient ID MHS-4482917

    IDItemDetailStatus
    S-001Clinical notesEPIC EHR (primary system): clinical notes, problem lists, medicationsIN SCOPE
    EX-1Legacy lab results 2019 to 2020Pre migration records remain in the legacy system; access method to be confirmedOPEN
    EX-2Fax and scanned archive, 2019Records from 2019 may be incomplete in the scanned archiveOPEN

    The response letter is drafted from the same fact base as the tracker, so the letter and the tracker never disagree.

    Built to be defensible

    Runs on your infrastructure

    The skill operates on your own Pokee deployment, including fully offline or air gapped environments. Request data does not leave your control.

    Every mapping is cited

    Every tracker row and every letter statement points to a source document or inventory item. If a mapping cannot be cited, it is not in the output.

    No legal conclusions

    The skill does not decide whether an exemption applies, and it does not produce the data. Exemptions are to verify, not applied.

    See the tracker before the deadline

    Run the skill on one real request of your choosing, with your own documents, on your own infrastructure.

    Book a walkthrough

    Go deeper

    Related

    Data Breach Response

    The same citation discipline for incidents.

    Suite

    All nine use cases

    The full Pokee.ai legal suite.

    Meet Pokee-Isaac 28B — the world’s first real 10M-token context model.Try it→
    Pokee AI
    • FinanceCompliance, onboarding, document review
    • Health CareClinical workflows, EHR, care coordination
    • E-commerceCatalog, support, post-purchase ops
    • LegalContract review, eDiscovery, legal operations
    • EducationAdmissions, grading, student support
    • ManufacturingPredictive maintenance, supply chain
    Finance
    Health Care
    E-commerce
    Legal
    Education
    Manufacturing
    Request a Demo
    • Security
    • Agent Security ResearchNew
    • Deployment
    • Agent Infrastructure
    • Playbook
    • Integrations
    • Skills Marketplace
    • Developer Program
    • Pricing
    • Careers
    • Contact
    APIInsights
    Book Demo
    • Finance
    • Health Care
    • E-commerce
    • Legal
    • Education
    • Manufacturing
    • Security
    • Agent Security ResearchNew
    • Deployment
    • Agent Infrastructure
    • Playbook
    • Integrations
    • Skills Marketplace
    • Developer Program
    • Pricing
    • Careers
    • Contact
    APIInsights
    Book Demo