Data Subject Access Request (DSAR) Form Template twelve sections that turn blank-page drafting into a privacy-counsel-defensible right-of-access response
A free, copy-ready DSAR form template for GRC and compliance teams, privacy officers, data protection officers, privacy programme leads, in-house counsel, CISOs, internal security teams, AppSec teams, vulnerability management teams, security engineering teams, data security teams, security operations leaders, and engineering and customer-success leads who receive named right-of-access requests on the inbound side of the privacy programme. Twelve structured sections covering header and version control and controller identity, request intake and statutory clock anchor across named regimes, request classification and statutory regime mapping with named right classes, identity verification with proportional tiering across authenticated session, known-requester one-time-token, unknown-requester reasonable-information, and high-risk processing tiers, scope-and-search plan across the named system list with a named search ledger per system, response content under GDPR Article 15(1) confirmation and 15(3) copy, third-party data redaction and exception assessment under Article 15(4) and Recital 63, automated decision-making and profiling and source-of-data disclosure under Article 15(1)(g) and (h), international transfer disclosure under Article 15(2) and Schrems II supplementary measures, secure delivery method and recipient acknowledgement, refusal pathway with named statutory basis and named supervisory authority complaint pathway under Article 77 and named judicial remedy under Article 79, and closure with named retention period and named disposition schedule. Aligned with GDPR Article 12, 15, 16, 17, 18, 20, 21, 22, 23, 77, 79, UK GDPR equivalents, California CCPA section 1798.130 and CPRA right-to-know and right-to-correct, Colorado CPA, Connecticut CTDPA, Virginia VCDPA, Utah UCPA, Texas TDPSA, Brazil LGPD Article 18 and 19, Singapore PDPA section 21, Canada PIPEDA Principle 9, Australia Privacy Act APP 12, China PIPL Article 45, Korea PIPA Article 35, Japan APPI Article 33, EDPB Guidelines 01/2022 on the right of access, ICO Right of Access guidance, ISO/IEC 27701:2019 Clause 6.10, NIST Privacy Framework v1.0, SOC 2 P1.0 to P8.0 Privacy Criteria, ISO/IEC 27001:2022 Annex A 5.34, and DORA Article 28.
Run DSAR responses on the live engagement record, not on ad-hoc downloads
SecPortal opens a DSAR engagement on receipt so the named clock anchor, the named verification tier, the named search ledger across the workspace finding records, the named redaction-and-exception register, the named secure-delivery chain-of-custody record, the named closure record, and the named retention period all live on one workspace with a named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn a DSAR response from a blank-page draft into a privacy-counsel-defensible artefact
A data subject access request (DSAR) is the operational form a controller uses to receive, identify, scope, fulfil, and document a request from a natural person who is exercising a statutory right of access. The most common access right is GDPR Article 15 in the European Economic Area and UK GDPR Article 15 in the United Kingdom, but a defensible template also handles California CCPA and CPRA right-to-know and right-to-correct, Colorado CPA, Connecticut CTDPA, Virginia VCDPA, Utah UCPA, Texas TDPSA, Brazil LGPD Article 18, Singapore PDPA, Canada PIPEDA, Australia Privacy Act APP 12, China PIPL Article 45, Korea PIPA Article 35, and Japan APPI access provisions. The form is not legal advice and does not replace privacy counsel; it is the durable operating record the controller, the data protection officer, the privacy programme, the legal team, the security team, the engineering team, and the customer-facing function read against so the response is identity-verified, scoped, complete, redacted where required, delivered through a named secure channel, logged for audit, and closed inside the statutory clock with an evidentiary record the supervisory authority and the requester can both read.
The DSAR form template is the inbound right-of-access companion to the data protection impact assessment template (the GDPR Article 35 risk record for the underlying processing operation), to the data classification policy template (the standing inventory that names which data classes the response covers), to the audit evidence retention policy template (the standing programme policy that names the response evidence retention floor), to the legal hold notice template (the matter-scoped retention override where a hold is in force), and to the data breach notification letter template (the outbound regulator and individual notification where a DSAR surfaces a notifiable breach), and to the customer security questionnaire response pack template (the inbound customer-security-review response artefact that sits at the same intake surface as a DSAR, with its own canonical control catalogue, evidence library, and SLA per deal stage). Copy each section, replace the variable placeholders from the live request record, and run the response under named privacy programme authority.
Copy the full DSAR form template (all twelve sections) as one block.
1. Header, version control, and controller identity
Open the DSAR form with the named controller, the form version, the named privacy programme owner, the named data protection officer where one is designated, and the named request identifier. A reviewer reading the first lines should see who is responding, which version of the form is current, where the request sits inside the request register, and which framework expectations the artefact evidences. GDPR Article 12 read together with Article 15, UK GDPR equivalents, ISO/IEC 27701 Clause 6.10 data subject rights, NIST Privacy Framework, and the named state privacy laws (CCPA, CPRA, CPA, CTDPA, VCDPA, UCPA, TDPSA, named-other) all expect a documented response artefact.
DSAR matter identifier (cross-referenced from the privacy request register or the workspace engagement record): {{DSAR_IDENTIFIER}}
Form version: v{{DSAR_FORM_VERSION}}
Form effective date: {{DSAR_FORM_EFFECTIVE_DATE}}
Request received timestamp (the named clock anchor): {{DSAR_REQUEST_RECEIVED_TIMESTAMP}}
Request channel (one of: privacy portal submission, named privacy mailbox, named in-product privacy request flow, named customer-success ticket, named DPO contact, named workforce channel, named regulator-forwarded request, named other): {{DSAR_REQUEST_CHANNEL}}
Controller identity:
- Controller legal name: {{CONTROLLER_LEGAL_NAME}}
- Controller registered address: {{CONTROLLER_REGISTERED_ADDRESS}}
- Controller representative under GDPR Article 27 where the controller is not established in the EEA: {{ARTICLE_27_REPRESENTATIVE}}
- Lead supervisory authority where the one-stop-shop applies: {{LEAD_SUPERVISORY_AUTHORITY}}
Joint controllers under GDPR Article 26 (where two or more controllers jointly determine the purposes and means of processing in scope of this request):
- Joint controller 1: {{JOINT_CONTROLLER_1_NAME_AND_ROLE}}
- Joint controller 2: {{JOINT_CONTROLLER_2_NAME_AND_ROLE}}
- Reference to the Article 26 arrangement: {{ARTICLE_26_ARRANGEMENT_REFERENCE}}
Data Protection Officer (where one is designated under Article 37):
- DPO name: {{DPO_NAME}}
- DPO contact (privacy@): {{DPO_CONTACT}}
- DPO supervisory-authority registration reference: {{DPO_REGISTRATION_REFERENCE}}
Privacy programme owner (the named role accountable for closing the DSAR inside the statutory clock):
- Role: {{PRIVACY_PROGRAMME_OWNER_ROLE}} (typically Privacy Programme Lead, Data Protection Officer, Chief Privacy Officer, named GRC Lead)
- Named person at time of receipt: {{PRIVACY_PROGRAMME_OWNER_NAME}}
- Workspace owner role (where the DSAR engagement runs on a security and compliance workspace): {{WORKSPACE_OWNER_ROLE}}
Revision history (each entry: form version, effective date, named change, named author, named reviewer, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, change {{PRIOR_CHANGE_1}}, author {{PRIOR_AUTHOR_1}}, reviewer {{PRIOR_REVIEWER_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, change {{PRIOR_CHANGE_2}}, author {{PRIOR_AUTHOR_2}}, reviewer {{PRIOR_REVIEWER_2}}, signed {{PRIOR_SIGNATORY_2}}
2. Request intake and statutory clock anchor
Capture the requester contact information, the named request channel, the named received-by user, the named received timestamp, and the named statutory clock the request runs against. The clock anchor is the durable record that the supervisory authority, the audit committee, and the requester all read against; reconstructing it weeks later from email threads is the recurring spoliation point.
Requester contact information (captured as supplied; treat as personal data and minimise collection to what is necessary to process the request):
- Requester display name as supplied: {{REQUESTER_DISPLAY_NAME}}
- Requester preferred contact channel: {{REQUESTER_CONTACT_CHANNEL}}
- Requester primary contact value (the registered account email where the relationship is authenticated, or the supplied contact value where the relationship is unauthenticated): {{REQUESTER_PRIMARY_CONTACT}}
- Alternate contact channel for delivery (where the primary channel is unsuitable for the response delivery method named in Section 10): {{REQUESTER_ALTERNATE_CONTACT}}
- Requester preferred response language: {{REQUESTER_PREFERRED_LANGUAGE}}
- Requester preferred response format (named one of: structured machine-readable export, structured human-readable PDF, named portal download, named hard-copy mail): {{REQUESTER_PREFERRED_FORMAT}}
Authorised agent (where the request is submitted on behalf of the data subject by a named third party such as a legal representative, named privacy advocacy organisation, named parent or guardian under named-jurisdiction child-protection rules, named-other):
- Agent named representative: {{AGENT_REPRESENTATIVE_NAME}}
- Agent authorisation document reference (a power of attorney, named legal-representative authorisation, named parent-or-guardian authorisation, named-other): {{AGENT_AUTHORISATION_REFERENCE}}
- Agent relationship class: {{AGENT_RELATIONSHIP_CLASS}}
Received-by record:
- Received-by named user (the named programme operator who recorded the request): {{RECEIVED_BY_NAMED_USER}}
- Received timestamp (start of the statutory clock): {{RECEIVED_TIMESTAMP_CLOCK_START}}
- Received channel reference (named portal submission identifier, named privacy mailbox message identifier, named ticket identifier, named regulator-forwarded letter reference, named other): {{RECEIVED_CHANNEL_REFERENCE}}
Statutory clock anchor:
- Named applicable regime (one of: GDPR Article 12 and 15, UK GDPR Article 12 and 15, CCPA section 1798.130, CPRA right-to-know, CPA, CTDPA, VCDPA, UCPA, TDPSA, LGPD Article 19, PDPA, PIPEDA, Australia Privacy Act APP 12, PIPL Article 45, PIPA Article 35, APPI, named-other): {{APPLICABLE_REGIME}}
- Named baseline response window (one of: one month under GDPR Article 12(3), forty-five days under CCPA section 1798.130, fifteen days under LGPD Article 19, thirty days under PDPA, thirty days under PIPEDA, ten days under PIPA, named-other): {{BASELINE_RESPONSE_WINDOW}}
- Named baseline response due date: {{BASELINE_RESPONSE_DUE_DATE}}
- Named extension permitted (yes-or-no with named regime reference): {{EXTENSION_PERMITTED}}
- Named extension trigger evaluated (named complexity, named volume, named identity-verification difficulty, named search-scope size, named third-party-data exception assessment): {{EXTENSION_TRIGGER_EVALUATED}}
- Named extension communication record (the named outbound communication to the requester within the baseline window naming the extension reasons and the named extended due date, where extension is applied): {{EXTENSION_COMMUNICATION_RECORD}}
- Named extended response due date (where extension is applied): {{EXTENDED_RESPONSE_DUE_DATE}}
- Named clock-pause regime (where the regime tolls the clock pending identity verification or pending requester response to a clarifying question): {{CLOCK_PAUSE_RULES}}
3. Request classification and statutory regime mapping
Capture the named request class against the named statutory regime so the response runs against the correct legal basis, the correct scope, and the correct downstream workflow. A workforce DSAR runs against a different data source set than a customer DSAR; an Article 17 erasure request triggers a different exception assessment than an Article 15 access request. The classification block is the routing record that prevents the wrong workflow from picking up the request.
Named request class (each request can carry one or more classes; the operator selects the named-applicable classes from the named list below):
- Right of access (GDPR Article 15, UK GDPR Article 15, CCPA right-to-know, CPRA right-to-know, CPA, CTDPA, VCDPA, UCPA, TDPSA, LGPD Article 18(II) and (V), PDPA section 21, PIPEDA Principle 9, Australia Privacy Act APP 12, PIPL Article 45, PIPA Article 35, APPI Article 33): {{REQUEST_CLASS_ACCESS}}
- Right of rectification or correction (GDPR Article 16, UK GDPR Article 16, CPRA right-to-correct, LGPD Article 18(III), PIPEDA Principle 9, PIPL Article 46): {{REQUEST_CLASS_RECTIFICATION}}
- Right of erasure or deletion (GDPR Article 17, UK GDPR Article 17, CCPA right-to-delete, CPRA right-to-delete, CPA, CTDPA, VCDPA, UCPA, TDPSA, LGPD Article 18(VI) and (IX), PDPA, PIPL Article 47): {{REQUEST_CLASS_ERASURE}}
- Right to restrict processing (GDPR Article 18, UK GDPR Article 18, LGPD Article 18(IV) named anonymisation or blocking): {{REQUEST_CLASS_RESTRICT}}
- Right to data portability (GDPR Article 20, UK GDPR Article 20, CCPA portability of right-to-know data, CPRA, CPA, CTDPA, VCDPA, UCPA, TDPSA, LGPD Article 18(V), PIPL Article 45): {{REQUEST_CLASS_PORTABILITY}}
- Right to object (GDPR Article 21, UK GDPR Article 21, CCPA right-to-opt-out of sale and sharing, CPRA opt-out of cross-context behavioural advertising and sensitive personal information use, LGPD Article 18(VIII), Australia APP 7): {{REQUEST_CLASS_OBJECT}}
- Right not to be subject to automated decision-making (GDPR Article 22, UK GDPR Article 22, CPRA automated decision-making rules, LGPD Article 20): {{REQUEST_CLASS_ADM}}
- Right to know automated decision-making logic and consequences (GDPR Article 15(1)(h) read in conjunction with Article 22, CPRA explainability rules): {{REQUEST_CLASS_ADM_LOGIC}}
- Right to withdraw consent (GDPR Article 7(3), LGPD Article 18(IX), PIPL Article 15): {{REQUEST_CLASS_CONSENT_WITHDRAWAL}}
- Right to file a complaint with the supervisory authority (GDPR Article 77, UK GDPR Article 77, LGPD Article 18(VII), PIPL Article 50): {{REQUEST_CLASS_COMPLAINT_PATH}}
Data subject relationship class (one of: customer, prospective customer, former customer, workforce member, former workforce member, contractor, prospective workforce member, named third-party data subject named in another controller record, named website visitor, named API consumer end-user, named-other):
- {{DATA_SUBJECT_RELATIONSHIP_CLASS}}
Named applicable jurisdictions (each entry: jurisdiction, named lead supervisory authority where applicable, named local-counsel relationship, named local DSAR specifics):
- {{JURISDICTION_1_NAME}} | Supervisory authority {{JURISDICTION_1_SA}} | Local counsel {{JURISDICTION_1_LOCAL_COUNSEL}} | DSAR specifics {{JURISDICTION_1_DSAR_SPECIFICS}}
- {{JURISDICTION_2_NAME}} | Supervisory authority {{JURISDICTION_2_SA}} | Local counsel {{JURISDICTION_2_LOCAL_COUNSEL}} | DSAR specifics {{JURISDICTION_2_DSAR_SPECIFICS}}
Sector overlay (each applicable sector overlay extends the baseline DSAR with sector-specific rules):
- Healthcare (HIPAA Privacy Rule 164.524 access, named state health privacy rules): {{SECTOR_HEALTHCARE_OVERLAY}}
- Financial services (GLBA, named state financial privacy rules, named regulator handling rules): {{SECTOR_FINANCIAL_OVERLAY}}
- Education (FERPA access, named state education privacy rules): {{SECTOR_EDUCATION_OVERLAY}}
- Children data (GDPR Article 8, COPPA, named state child-protection rules): {{SECTOR_CHILDREN_OVERLAY}}
- Telecommunications (named sector-specific telecoms metadata access rules): {{SECTOR_TELECOM_OVERLAY}}
- Named other sector-specific overlay: {{SECTOR_OTHER_OVERLAY}}
Request scope as supplied by the requester:
- Named requested data categories (each named category as supplied, with the named regime reference where the requester invokes a specific right): {{REQUESTED_DATA_CATEGORIES}}
- Named date range supplied by the requester (where applicable): {{REQUESTED_DATE_RANGE}}
- Named system or service references supplied by the requester (where applicable): {{REQUESTED_SYSTEM_REFERENCES}}
- Named clarifying questions to the requester (where the operator needs targeted clarification before scope freeze, sent under the named clock-pause regime where applicable): {{CLARIFYING_QUESTIONS_TO_REQUESTER}}
4. Identity verification with proportional tiering
Verify the requester identity at the tier appropriate to the relationship class and the sensitivity of the data set. Under-verification risks disclosing personal data to an impersonator; over-verification breaches the GDPR Article 5(1)(c) data-minimisation principle and creates a fresh privacy harm. The proportional tiering model in this section is anchored on the EDPB Guidelines 01/2022 and the ICO Right of Access guidance.
Verification tier selection (the operator selects the named tier appropriate to the relationship class and the data set sensitivity):
Tier A: Authenticated session verification
- Applicable where the requester is an active customer, an active workforce member, or an active platform user with a recorded authenticated session.
- Verification record: named authenticated session reference, named multi-factor authentication enforcement record, named primary identifier (account email or workforce identifier).
- No additional document collection required.
- Named verification timestamp: {{TIER_A_VERIFICATION_TIMESTAMP}}
- Named verifier: {{TIER_A_VERIFIER_NAME}}
- Named session reference: {{TIER_A_SESSION_REFERENCE}}
Tier B: Known requester one-time-token verification
- Applicable where the requester is an unauthenticated known customer or former customer for whom a contact channel of record exists.
- Verification record: a named one-time verification token delivered to the named contact channel of record, paired with a named historic transaction reference the requester supplies and the operator confirms against the workspace record.
- Named verification timestamp: {{TIER_B_VERIFICATION_TIMESTAMP}}
- Named verifier: {{TIER_B_VERIFIER_NAME}}
- Named historic transaction reference: {{TIER_B_HISTORIC_REFERENCE}}
- Named one-time-token issuance reference: {{TIER_B_TOKEN_REFERENCE}}
Tier C: Unknown requester reasonable-information verification
- Applicable where the requester has no recorded relationship with the controller and the controller cannot locate the data subject without additional information.
- Verification record: the named minimum identifying information necessary to locate the data, collected with the named data-minimisation justification and the named retention and disposal schedule for that additional information; explicit refusal to expand scope to government identity documents unless the request reaches a high-risk processing class.
- Named verification timestamp: {{TIER_C_VERIFICATION_TIMESTAMP}}
- Named verifier: {{TIER_C_VERIFIER_NAME}}
- Named additional information collected: {{TIER_C_ADDITIONAL_INFO_COLLECTED}}
- Named retention and disposal schedule for the additional information: {{TIER_C_ADDITIONAL_INFO_RETENTION}}
Tier D: High-risk processing verification
- Applicable where the data set in scope of the request includes special-category data, financial data, health data, biometric data, named other high-risk processing classes, or where the request reaches a workforce member subject to named heightened verification rules.
- Verification record: the Tier B or Tier C record plus a named additional identity verification step proportionate to the data sensitivity (named identity document review under the named retention and disposal schedule, named in-person verification at a named location, named recorded video verification, named-other), with named DPO approval.
- Named verification timestamp: {{TIER_D_VERIFICATION_TIMESTAMP}}
- Named verifier: {{TIER_D_VERIFIER_NAME}}
- Named additional verification method: {{TIER_D_ADDITIONAL_METHOD}}
- Named DPO approval reference: {{TIER_D_DPO_APPROVAL_REFERENCE}}
Authorised agent verification (where the request is submitted by a named authorised agent on behalf of the data subject):
- Named agent authorisation document review record: {{AGENT_AUTH_DOC_REVIEW_RECORD}}
- Named data-subject independent confirmation pathway where required by named state law (CCPA section 1798.130 named authorised-agent rules): {{AGENT_DATA_SUBJECT_CONFIRMATION_RECORD}}
Verification refusal pathway under GDPR Article 12(6):
- Named refusal trigger (the controller has reasonable doubts concerning the identity of the natural person making the request after a reasonable verification attempt): {{VERIFICATION_REFUSAL_TRIGGER}}
- Named refusal communication reference (the named outbound communication to the requester naming the basis for the refusal and the named additional information needed for verification): {{VERIFICATION_REFUSAL_COMMUNICATION}}
- Named refusal escalation pathway: {{VERIFICATION_REFUSAL_ESCALATION}}
5. Scope and search plan across data sources
Walk the named search across every system where personal data of the named data subject may live, with the named query, the named operator, the named timestamp, and the named result-set reference. The search ledger is the durable record that paired with the response copy proves the controller did what the access right required. Skipping a named system at intake is the recurring failure mode.
Search ledger (each named system carries a named search record; the named result counts and named result-set references roll up into the response under Section 6):
Customer-facing application database:
- Named application database (named primary, named read replica, named warehouse export): {{APP_DB_REFERENCE}}
- Named query identifier and named query strategy: {{APP_DB_QUERY}}
- Named search timestamp: {{APP_DB_SEARCH_TIMESTAMP}}
- Named operator: {{APP_DB_OPERATOR}}
- Named result-set reference: {{APP_DB_RESULT_SET}}
Data warehouse and analytics replica:
- Named warehouse system and named replica reference: {{WAREHOUSE_REFERENCE}}
- Named query identifier and named query strategy: {{WAREHOUSE_QUERY}}
- Named search timestamp: {{WAREHOUSE_SEARCH_TIMESTAMP}}
- Named result-set reference: {{WAREHOUSE_RESULT_SET}}
CRM and customer-success platform:
- Named CRM platform: {{CRM_REFERENCE}}
- Named query identifier and named result-set reference: {{CRM_QUERY_AND_RESULT_SET}}
- Named operator and timestamp: {{CRM_OPERATOR_AND_TIMESTAMP}}
Marketing automation and consent records:
- Named marketing platform: {{MARKETING_REFERENCE}}
- Named consent management platform: {{CONSENT_MANAGEMENT_REFERENCE}}
- Named query identifier and named result-set reference: {{MARKETING_QUERY_AND_RESULT_SET}}
Support ticketing platform:
- Named ticketing platform: {{TICKETING_REFERENCE}}
- Named query identifier and named result-set reference: {{TICKETING_QUERY_AND_RESULT_SET}}
Email gateway and shared mailbox archive:
- Named email platform: {{EMAIL_REFERENCE}}
- Named shared mailbox set in scope: {{EMAIL_SHARED_MAILBOX_SET}}
- Named query identifier and named result-set reference: {{EMAIL_QUERY_AND_RESULT_SET}}
Chat platform and meeting recording archive:
- Named chat platforms in scope: {{CHAT_REFERENCE}}
- Named meeting recording archive: {{MEETING_RECORDING_REFERENCE}}
- Named query identifier and named result-set reference: {{CHAT_QUERY_AND_RESULT_SET}}
Document repository (SharePoint, Google Drive, OneDrive, Box, named other):
- Named repositories: {{DOC_REPO_REFERENCE}}
- Named query identifier and named result-set reference: {{DOC_REPO_QUERY_AND_RESULT_SET}}
Engineering record (Jira, GitHub, GitLab, observability tooling, named other):
- Named platforms: {{ENGINEERING_RECORD_REFERENCE}}
- Named query identifier and named result-set reference: {{ENGINEERING_QUERY_AND_RESULT_SET}}
Security record (SIEM, EDR, scanner outputs, finding records, named exception-register entries that reference the named individual):
- Named SIEM platform: {{SIEM_REFERENCE}}
- Named EDR platform: {{EDR_REFERENCE}}
- Named workspace finding records query (where the data subject is referenced in finding records, finding comments, exception register entries, scanner outputs): {{WORKSPACE_FINDING_QUERY_AND_RESULT_SET}}
- Named operator and timestamp: {{SECURITY_RECORD_OPERATOR_AND_TIMESTAMP}}
Identity provider audit log (named: Okta, Entra ID, Google Workspace, named other):
- Named identity provider: {{IDP_REFERENCE}}
- Named query identifier and named result-set reference: {{IDP_QUERY_AND_RESULT_SET}}
Cloud provider audit log (named: AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs, named other):
- Named cloud provider audit log references: {{CLOUD_AUDIT_LOG_REFERENCE}}
- Named query identifier and named result-set reference: {{CLOUD_AUDIT_QUERY_AND_RESULT_SET}}
HR system (where the request is workforce-related):
- Named HR system: {{HR_SYSTEM_REFERENCE}}
- Named query identifier and named result-set reference: {{HR_QUERY_AND_RESULT_SET}}
Payment processor (where billing identifiers reference the named individual):
- Named payment processor: {{PAYMENT_PROCESSOR_REFERENCE}}
- Named query identifier and named result-set reference: {{PAYMENT_QUERY_AND_RESULT_SET}}
Data processor list (per the Article 30 records of processing activity register):
- Named processor 1 with named DPA reference and named cooperation request reference: {{PROCESSOR_1_RECORD}}
- Named processor 2 with named DPA reference and named cooperation request reference: {{PROCESSOR_2_RECORD}}
- Named processor 3 with named DPA reference and named cooperation request reference: {{PROCESSOR_3_RECORD}}
Unstructured-data search (shared drives, named personal devices in scope, named recording archives where retention permits):
- Named unstructured-data scope: {{UNSTRUCTURED_DATA_SCOPE}}
- Named query strategy and named limitations (named search-tool capability and named data-minimisation rationale where a full sweep is disproportionate): {{UNSTRUCTURED_DATA_STRATEGY}}
Search ledger completeness sign-off:
- Named privacy programme reviewer: {{LEDGER_REVIEWER_NAME}}
- Named completeness statement and timestamp: {{LEDGER_COMPLETENESS_STATEMENT}}
Compose the response copy with the named statutory content blocks the requester is entitled to receive: the confirmation of processing, the categories and purposes, the recipients, the retention period, the rights of the data subject, the source of data, the automated decision-making disclosure, and the international transfer disclosure, plus the named copy of personal data under Article 15(3). The block names each disclosure separately so the response is auditable against the statute rather than reading as a free-form letter.
Confirmation of processing (Article 15(1) opening): The controller named in Section 1 confirms that it processes personal data concerning the named data subject as described below. Where confirmation is negative for a named scope (the controller does not process personal data concerning the named data subject in the named system or for the named purpose), state the negative confirmation explicitly with the named system or purpose reference.
Purposes of processing (Article 15(1)(a)):
- Named purpose 1 with the named lawful basis (Article 6 reference; Article 9 condition where special-category data is involved): {{PURPOSE_1_AND_BASIS}}
- Named purpose 2 with the named lawful basis: {{PURPOSE_2_AND_BASIS}}
- Named purpose 3 with the named lawful basis: {{PURPOSE_3_AND_BASIS}}
Categories of personal data concerned (Article 15(1)(b)):
- Named category 1 (named example: identifiers, contact details, account credentials hash, billing identifiers, named usage events, named device identifiers, named location data, named named behavioural attributes): {{CATEGORY_1}}
- Named category 2: {{CATEGORY_2}}
- Named category 3: {{CATEGORY_3}}
- Named special-category data per Article 9, where applicable (named health data, biometric data, racial or ethnic origin data, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, sexual orientation): {{SPECIAL_CATEGORY_DATA}}
Recipients and categories of recipients (Article 15(1)(c)):
- Named processor 1 with named contractual basis: {{RECIPIENT_PROCESSOR_1}}
- Named sub-processor 1 (where disclosed): {{RECIPIENT_SUB_PROCESSOR_1}}
- Named recipient outside the processor chain (named law enforcement disclosure under named legal compulsion, named regulator disclosure, named-other): {{RECIPIENT_OTHER}}
Retention period or criteria (Article 15(1)(d)):
- Named retention period per data category with named retention basis: {{RETENTION_PERIOD_CRITERIA}}
Rights of the data subject (Article 15(1)(e)) including the right to lodge a complaint with the supervisory authority (Article 15(1)(f)):
- Named right of rectification: {{RIGHT_RECTIFICATION_REFERENCE}}
- Named right of erasure: {{RIGHT_ERASURE_REFERENCE}}
- Named right to restrict processing: {{RIGHT_RESTRICT_REFERENCE}}
- Named right to data portability: {{RIGHT_PORTABILITY_REFERENCE}}
- Named right to object: {{RIGHT_OBJECT_REFERENCE}}
- Named right to lodge a complaint with the supervisory authority named in Section 1: {{RIGHT_COMPLAINT_REFERENCE}}
Article 15(3) copy of the personal data:
- Named structured export reference (the named result-set roll-up from Section 5 in the named requester-preferred format from Section 2): {{ARTICLE_15_3_COPY_REFERENCE}}
- Named human-readable plain-language summary that pairs to the structured export so the requester can read both the data and the interpretation: {{HUMAN_READABLE_SUMMARY_REFERENCE}}
- Named redaction-and-exception markup reference cross-referenced to Section 7: {{REDACTION_MARKUP_REFERENCE}}
Where the request invokes other rights named in Section 3:
- Rectification or correction response: named correction made, named record updated, named acknowledgement issued: {{RECTIFICATION_RESPONSE_RECORD}}
- Erasure or deletion response: named scope deleted, named retention exception applied where legal basis prevails, named acknowledgement issued, named downstream processor cooperation record where data was transferred: {{ERASURE_RESPONSE_RECORD}}
- Restriction-of-processing response: named scope flagged restricted, named restriction record applied across the named data sources, named acknowledgement issued: {{RESTRICTION_RESPONSE_RECORD}}
- Portability response: named portable scope exported in named machine-readable format (named JSON, named CSV, named XML, named other), named direct-to-controller transmission where applicable and technically feasible: {{PORTABILITY_RESPONSE_RECORD}}
- Objection response: named scope ceased processing where the controller cannot demonstrate compelling legitimate grounds under Article 21(1), or named cessation of direct marketing under Article 21(2): {{OBJECTION_RESPONSE_RECORD}}
- Automated decision-making response: named automated decision review record under Article 22(3), named human-review pathway: {{ADM_RESPONSE_RECORD}}
Response review and approval before delivery:
- Named privacy programme approver: {{RESPONSE_APPROVER_NAME}}
- Named DPO advice reference where applicable: {{RESPONSE_DPO_ADVICE_REFERENCE}}
- Named legal counsel approval reference where the response engages legally privileged communications, named regulator-pending matters, or named litigation matters under hold: {{RESPONSE_LEGAL_APPROVAL_REFERENCE}}
7. Third-party data redaction and exception assessment
Where the response copy would contain personal data of another natural person or named protected information, decide whether the named element is severable and redact, or whether the named right of others prevails and decline that portion with a named written explanation. The block forces a structured decision per named exception rather than letting the response operator make ad-hoc redaction calls that the supervisory authority cannot read against.
Exception assessment register (each named identified exception carries a named decision record):
Third-party personal data (Article 15(4) read with Recital 63):
- Named element 1 reference and named third-party data reference: {{TP_ELEMENT_1_AND_REFERENCE}}
- Named severability assessment (severable with named redaction, or non-severable with named rights-of-others prevailing): {{TP_ELEMENT_1_SEVERABILITY}}
- Named decision (named redaction applied, or named refusal of partial scope with named written explanation): {{TP_ELEMENT_1_DECISION}}
- Named approver and timestamp: {{TP_ELEMENT_1_APPROVER_AND_TIMESTAMP}}
Legally privileged communications (where applicable under jurisdictional privilege rules):
- Named privileged element reference: {{PRIV_ELEMENT_REFERENCE}}
- Named privilege class (attorney-client, work-product, named other jurisdictional privilege): {{PRIV_CLASS}}
- Named decision (named withholding with named statutory or common-law basis): {{PRIV_DECISION}}
- Named counsel approver: {{PRIV_COUNSEL_APPROVER}}
Trade secrets and confidential commercial information (Recital 63 limits on the right of access where disclosure would adversely affect trade secrets or intellectual property):
- Named element reference: {{TRADE_SECRET_REFERENCE}}
- Named decision (named partial response with named redacted summary, or named refusal of named element with named written explanation): {{TRADE_SECRET_DECISION}}
- Named approver and timestamp: {{TRADE_SECRET_APPROVER_AND_TIMESTAMP}}
Security evidence that would compromise security of other data subjects or systems (Article 23 restriction or named Article 15(4) rights-of-others where disclosure would enable an account-takeover, undermine ongoing fraud investigation, or expose named other data subjects to harm):
- Named security element reference: {{SEC_ELEMENT_REFERENCE}}
- Named decision (named withholding with named security rationale): {{SEC_DECISION}}
- Named CISO or security programme approver and timestamp: {{SEC_APPROVER_AND_TIMESTAMP}}
Law enforcement hold or named ongoing-investigation block (named Article 23 restriction under named member-state law, named CCPA carve-out, named regulator-cooperation hold):
- Named hold reference: {{LE_HOLD_REFERENCE}}
- Named decision (named withholding under named statutory basis): {{LE_HOLD_DECISION}}
- Named legal-counsel approver: {{LE_HOLD_LEGAL_APPROVER}}
Confidential workforce records (named state-specific workforce privacy rules, named named-jurisdiction workforce data limits):
- Named workforce-record element reference: {{WF_ELEMENT_REFERENCE}}
- Named decision (named partial response with named redaction, or named refusal of named element with named workforce-privacy basis): {{WF_DECISION}}
- Named HR or counsel approver: {{WF_APPROVER}}
Redaction-and-exception summary delivered to the requester:
- Named summary reference (the requester is informed of the existence of redacted elements and the named basis without disclosing the redacted content): {{REDACTION_EXCEPTION_SUMMARY_REFERENCE}}
- Named complaint pathway (the requester can challenge the redaction-and-exception decision through the supervisory authority complaint pathway under Section 11): {{COMPLAINT_PATHWAY_REFERENCE}}
Reviewer sign-off on the redaction-and-exception register:
- Named privacy programme reviewer: {{REDACTION_REVIEWER_NAME}}
- Named completeness statement and timestamp: {{REDACTION_REVIEWER_STATEMENT}}
8. Automated decision-making, profiling, and source-of-data disclosure
Disclose the existence of automated decision-making and profiling, the meaningful information about the logic involved, the significance and the envisaged consequences for the data subject under Article 15(1)(h), and any available information about the source of the data under Article 15(1)(g). The block is the recurring under-served disclosure in DSAR responses and the most-cited audit finding when the supervisory authority reviews the response.
Automated decision-making register entries applicable to the named data subject (Article 15(1)(h)):
- Named automated decision-making system 1 reference (named model name, named version, named decision class): {{ADM_SYSTEM_1_REFERENCE}}
- Named input feature set summary (plain-language, named non-sensitive feature classes): {{ADM_SYSTEM_1_INPUTS}}
- Named output decision class and named consequence for the data subject: {{ADM_SYSTEM_1_OUTPUTS_AND_CONSEQUENCES}}
- Named significance and envisaged consequences (the operational, contractual, financial, or service-availability consequence as the data subject experiences it): {{ADM_SYSTEM_1_SIGNIFICANCE}}
- Named human-review pathway under Article 22(3) where the decision produces legal or similarly significant effects: {{ADM_SYSTEM_1_HUMAN_REVIEW}}
- Named explainability artefact reference (the named technical and named plain-language explanation aligned with named AI Act Articles 13 and 86 where applicable): {{ADM_SYSTEM_1_EXPLAINABILITY_REFERENCE}}
Profiling register entries applicable to the named data subject (Article 4(4) read with Article 15(1)(h)):
- Named profile attribution reference (the named profile, segment, lookalike attribution, scoring engine, named other): {{PROFILE_1_ATTRIBUTION_REFERENCE}}
- Named profile inputs summary: {{PROFILE_1_INPUTS}}
- Named profile output and named consequence: {{PROFILE_1_OUTPUT_AND_CONSEQUENCE}}
Source-of-data disclosure (Article 15(1)(g)):
- Named data source 1 (named data broker, named credit bureau, named identity provider, named adverse-media feed, named public records source, named named-third-party API, named partner data sharing, named-other): {{DATA_SOURCE_1_REFERENCE}}
- Named data source 1 contract reference (named data-sharing agreement, named data-processing agreement, named named-other commercial agreement): {{DATA_SOURCE_1_CONTRACT_REFERENCE}}
- Named data classes obtained from source 1: {{DATA_SOURCE_1_CLASSES}}
AI Act overlay (where the controller operates an EU AI Act-relevant high-risk AI system):
- Named Article 27 fundamental rights impact assessment reference: {{AI_ACT_ARTICLE_27_REFERENCE}}
- Named AI Act Article 13 transparency artefact reference (the user-facing instructions for use and the named significance and consequence): {{AI_ACT_ARTICLE_13_REFERENCE}}
- Named AI Act Article 86 explainability artefact reference (the affected-person right to obtain a clear and meaningful explanation of named decisions): {{AI_ACT_ARTICLE_86_REFERENCE}}
State-law overlay (where named state automated decision-making transparency rules apply):
- Named CPRA automated decision-making rule reference: {{CPRA_ADM_REFERENCE}}
- Named Colorado CPA profiling rule reference: {{COLORADO_ADM_REFERENCE}}
- Named other state-law reference: {{OTHER_STATE_ADM_REFERENCE}}
9. International transfer disclosure
Where the personal data is transferred to a third country or an international organisation, inform the data subject of the appropriate safeguards under Article 46 (Article 15(2)). The block names the destination, the transfer mechanism, the transfer impact assessment, and the supplementary measures where applicable. The Schrems II era has made this disclosure operationally heavier than it used to be.
International transfer register entries applicable to the named data subject:
Transfer 1:
- Named third-country destination or named international organisation: {{TRANSFER_1_DESTINATION}}
- Named transfer mechanism (one of: adequacy decision under Article 45 with named adequacy reference, Standard Contractual Clauses under Article 46(2)(c) with named SCC version 2021/914 module and named optional clauses, Binding Corporate Rules under Article 47 with named BCR reference, Article 49 derogations for the named specific situation, EU-US Data Privacy Framework under the named adequacy decision and named participant reference, named-other safeguard): {{TRANSFER_1_MECHANISM}}
- Named data importer (the named processor, sub-processor, or named other recipient in the third country): {{TRANSFER_1_IMPORTER}}
- Named transfer impact assessment reference produced post-Schrems II: {{TRANSFER_1_TIA_REFERENCE}}
- Named supplementary measures (technical, contractual, organisational) where the transfer impact assessment identified residual risk: {{TRANSFER_1_SUPPLEMENTARY_MEASURES}}
- Named onward-transfer chain disclosure where applicable: {{TRANSFER_1_ONWARD_CHAIN}}
Transfer 2:
- Named third-country destination or named international organisation: {{TRANSFER_2_DESTINATION}}
- Named transfer mechanism: {{TRANSFER_2_MECHANISM}}
- Named data importer: {{TRANSFER_2_IMPORTER}}
- Named transfer impact assessment reference: {{TRANSFER_2_TIA_REFERENCE}}
- Named supplementary measures: {{TRANSFER_2_SUPPLEMENTARY_MEASURES}}
UK GDPR international transfer disclosure (where the UK is the named applicable regime):
- Named UK International Data Transfer Agreement or named UK Addendum to the EU SCCs reference: {{UK_IDTA_REFERENCE}}
- Named UK transfer risk assessment reference: {{UK_TRA_REFERENCE}}
LGPD international transfer disclosure (where Brazil is the named applicable regime):
- Named transfer-mechanism declaration reference under LGPD Article 33: {{LGPD_TRANSFER_REFERENCE}}
PIPL cross-border transfer disclosure (where China is the named applicable regime):
- Named cross-border-transfer security assessment reference under PIPL Articles 38-40 or named standard contract: {{PIPL_TRANSFER_REFERENCE}}
PIPA cross-border transfer disclosure (where Korea is the named applicable regime):
- Named PIPA Article 28-8 cross-border transfer disclosure reference: {{PIPA_TRANSFER_REFERENCE}}
APPI cross-border transfer disclosure (where Japan is the named applicable regime):
- Named APPI Article 24 cross-border transfer disclosure reference: {{APPI_TRANSFER_REFERENCE}}
Aggregate transfer summary in the requester-facing response:
- Named plain-language summary of the named transfers, the named safeguards, and the named requester pathways to obtain the named safeguards on request: {{TRANSFER_REQUESTER_FACING_SUMMARY}}
10. Secure delivery method and recipient acknowledgement
Deliver the response copy through a named secure channel that protects the named personal data the response is meant to disclose. Sending the response copy as an unencrypted email attachment or as a clear-text download is the recurring privacy incident that turns a DSAR response into a data breach. The block names the delivery method, the named authentication, the named time-limited access, and the named acknowledgement record.
Named delivery method (the operator selects the named-applicable method appropriate to the response copy sensitivity and the requester relationship class):
Method A: Authenticated portal download with workspace authentication
- Named portal location: {{DELIVERY_A_PORTAL_LOCATION}}
- Named authentication enforcement (named multi-factor authentication enforcement record): {{DELIVERY_A_AUTH_RECORD}}
- Named access-link expiry: {{DELIVERY_A_EXPIRY}}
- Named download access-log preservation reference: {{DELIVERY_A_ACCESS_LOG_REFERENCE}}
Method B: Time-limited secure file transfer with named single-use access link
- Named secure file transfer platform: {{DELIVERY_B_PLATFORM}}
- Named single-use access link reference: {{DELIVERY_B_LINK_REFERENCE}}
- Named link expiry: {{DELIVERY_B_EXPIRY}}
- Named verification before download (named one-time-token verification): {{DELIVERY_B_VERIFICATION}}
Method C: Password-protected encrypted archive with named out-of-band password delivery
- Named archive format (named password-protected ZIP with named AES encryption, named 7z, named-other): {{DELIVERY_C_ARCHIVE_FORMAT}}
- Named in-band archive delivery channel: {{DELIVERY_C_INBAND_CHANNEL}}
- Named out-of-band password delivery channel (named separate channel from the archive delivery channel; named voice call, named SMS to verified number, named-other): {{DELIVERY_C_OOB_CHANNEL}}
- Named archive access-log record: {{DELIVERY_C_ACCESS_LOG_RECORD}}
Method D: Physical hard-copy delivery with signed-receipt requirement
- Named delivery service (named tracked courier, named registered postal service, named-other): {{DELIVERY_D_SERVICE}}
- Named recipient address and named signed-receipt requirement: {{DELIVERY_D_ADDRESS_AND_RECEIPT}}
- Named tracking reference: {{DELIVERY_D_TRACKING_REFERENCE}}
Named requester acknowledgement record:
- Named acknowledgement channel: {{ACK_CHANNEL}}
- Named acknowledgement timestamp: {{ACK_TIMESTAMP}}
- Named acknowledgement reference on the matter record: {{ACK_RECORD_REFERENCE}}
- Named clarification record where the requester asks named follow-up questions inside the named regime-permitted follow-up window: {{ACK_CLARIFICATION_RECORD}}
Delivery exceptions:
- Named language-accessibility accommodation reference (where the requester invokes a named accessibility right under named regional law): {{DELIVERY_ACCESSIBILITY_REFERENCE}}
- Named alternate-format accommodation reference (named braille, named large-print, named audio, named-other): {{DELIVERY_ALT_FORMAT_REFERENCE}}
- Named delivery-failure recovery pathway (where the named delivery method fails, named re-issuance under named secondary method): {{DELIVERY_FAILURE_RECOVERY}}
Delivery chain-of-custody record:
- Named delivery operator: {{DELIVERY_OPERATOR_NAME}}
- Named delivery timestamp: {{DELIVERY_TIMESTAMP}}
- Named delivery verification record: {{DELIVERY_VERIFICATION_RECORD}}
11. Refusal pathway, complaint pathway, and supervisory authority referral
Name the refusal pathway where the controller declines to act on the request or refuses to action a named portion of the request, the requester complaint pathway, and the supervisory authority referral. The block is the audit-defensible exit pathway that maps to Article 12(4), Article 12(5), Article 23 restrictions, and the named supervisory authority complaint regime under Article 77. The bar for refusal is high and the burden of proof is on the controller.
Refusal pathway under GDPR Article 12(5) (manifestly unfounded or excessive) and named equivalent provisions across CCPA section 1798.130(a)(3), LGPD Article 18, PDPA section 21, named other regimes:
- Named refusal trigger (named manifestly unfounded under named pattern, named manifestly excessive under named pattern, named identity-not-verifiable under Article 12(6), named Article 23 restriction under named member-state law, named legal-privileged communication, named third-party rights prevailing under Article 15(4), named legal-claims defence under Article 17(3)(e)): {{REFUSAL_TRIGGER}}
- Named refusal class (full refusal of the named request, partial refusal of named scope, named fee assessment under named fee policy with named justification): {{REFUSAL_CLASS}}
- Named fee assessment basis (where applicable): {{FEE_ASSESSMENT_BASIS}}
- Named fee amount and named payment pathway: {{FEE_AMOUNT_AND_PATHWAY}}
Refusal communication to the requester:
- Named written refusal communication reference (issued no later than the named statutory window with named substantive basis, named appeal pathway, and named supervisory authority complaint pathway): {{REFUSAL_COMMUNICATION_REFERENCE}}
- Named refusal communication timestamp: {{REFUSAL_COMMUNICATION_TIMESTAMP}}
- Named refusal approver (named DPO, named privacy programme lead, named legal counsel): {{REFUSAL_APPROVER}}
Complaint pathway:
- Named internal complaint pathway (the requester can challenge the refusal or the partial response through the named internal escalation): {{INTERNAL_COMPLAINT_PATHWAY}}
- Named internal complaint owner: {{INTERNAL_COMPLAINT_OWNER}}
- Named internal complaint SLA: {{INTERNAL_COMPLAINT_SLA}}
Supervisory authority referral (Article 77 right to lodge a complaint):
- Named lead supervisory authority for the requester jurisdiction: {{SA_NAME}}
- Named supervisory authority contact pathway: {{SA_CONTACT_PATHWAY}}
- Named complaint procedure as published by the supervisory authority: {{SA_PROCEDURE_REFERENCE}}
Judicial remedy (Article 79):
- Named judicial remedy reference (the requester retains the right to an effective judicial remedy against the controller or processor): {{JUDICIAL_REMEDY_REFERENCE}}
Workspace audit record of the refusal decision:
- Named decision identifier on the workspace engagement record: {{REFUSAL_DECISION_WORKSPACE_REFERENCE}}
- Named activity-log entry timestamp: {{REFUSAL_DECISION_ACTIVITY_LOG_TIMESTAMP}}
- Named retention of the refusal decision record (named retention basis paired to the statutory limitation period for related claims): {{REFUSAL_RECORD_RETENTION}}
Programme-level escalation when refusal density rises:
- Named escalation trigger (named refusal-rate threshold across the rolling named period): {{REFUSAL_RATE_ESCALATION_TRIGGER}}
- Named escalation owner: {{REFUSAL_RATE_ESCALATION_OWNER}}
- Named escalation pathway (named board risk committee, named audit committee, named DPO summary report): {{REFUSAL_RATE_ESCALATION_PATHWAY}}
12. Closure, retention, and post-response evidence pack
Close the DSAR engagement with the named closure record, the named retention period for the response evidence pack, the named disposition schedule on expiry, and the named overlay where a legal hold under the named legal-hold-notice template overrides the standing retention. The block is the durable record that the supervisory authority, a subsequent regulator, a court, an auditor, and the requester themselves on a follow-up request can read against.
Closure record on the workspace engagement:
- Named DSAR request identifier (from Section 1): {{CLOSURE_DSAR_IDENTIFIER}}
- Named statutory clock end-state (named in-window closure or named overrun with reason): {{CLOSURE_CLOCK_STATE}}
- Named approver of the closure: {{CLOSURE_APPROVER_NAME}}
- Named closure timestamp: {{CLOSURE_TIMESTAMP}}
- Named summary statement of the named scope returned, named scope refused, and named scope outside the request: {{CLOSURE_SUMMARY_STATEMENT}}
Post-response evidence pack content:
- Identity-verification record (Section 4): {{EVIDENCE_VERIFICATION_REFERENCE}}
- Scope-and-search ledger (Section 5): {{EVIDENCE_SEARCH_LEDGER_REFERENCE}}
- Response copy (Section 6): {{EVIDENCE_RESPONSE_COPY_REFERENCE}}
- Redaction-and-exception register (Section 7): {{EVIDENCE_REDACTION_REGISTER_REFERENCE}}
- Automated decision-making and source-of-data disclosure record (Section 8): {{EVIDENCE_ADM_RECORD_REFERENCE}}
- International transfer disclosure record (Section 9): {{EVIDENCE_TRANSFER_RECORD_REFERENCE}}
- Secure-delivery chain-of-custody record (Section 10): {{EVIDENCE_DELIVERY_RECORD_REFERENCE}}
- Acknowledgement record (Section 10): {{EVIDENCE_ACK_RECORD_REFERENCE}}
- Refusal-decision record where applicable (Section 11): {{EVIDENCE_REFUSAL_RECORD_REFERENCE}}
- Internal-complaint pathway record where applicable (Section 11): {{EVIDENCE_COMPLAINT_RECORD_REFERENCE}}
Retention period and basis:
- Named retention period (commonly the statutory limitation period for related claims; named jurisdictional reference): {{RETENTION_PERIOD}}
- Named retention basis (legitimate interest in defence of legal claims under Article 6(1)(f) read together with Article 17(3)(e); named jurisdictional analogue): {{RETENTION_BASIS}}
- Named retention exception where a legal hold under the named legal-hold-notice template is in force: {{LEGAL_HOLD_OVERRIDE_REFERENCE}}
Named disposition schedule on expiry:
- Named disposition method (named workspace deletion, named secure erasure, named storage media destruction where applicable): {{DISPOSITION_METHOD}}
- Named disposition owner: {{DISPOSITION_OWNER}}
- Named disposition verification record: {{DISPOSITION_VERIFICATION_RECORD}}
Programme-level metrics roll-up:
- Named DSAR count for the named reporting period (named jurisdiction breakdown, named relationship-class breakdown): {{METRICS_COUNT}}
- Named in-window closure rate against the named statutory clock: {{METRICS_IN_WINDOW_RATE}}
- Named extension-applied rate with named extension justifications: {{METRICS_EXTENSION_RATE}}
- Named refusal rate with named refusal-class breakdown: {{METRICS_REFUSAL_RATE}}
- Named average response time and named median response time: {{METRICS_RESPONSE_TIME}}
- Named supervisory authority complaint count traceable to a named DSAR request: {{METRICS_SA_COMPLAINTS}}
Cross-references on the workspace engagement record:
- Named records of processing activity (ROPA) reference: {{CLOSURE_ROPA_REFERENCE}}
- Named data classification policy version applied: {{CLOSURE_DATA_CLASSIFICATION_REFERENCE}}
- Named audit evidence retention policy version applied: {{CLOSURE_AUDIT_RETENTION_REFERENCE}}
- Named breach notification letter reference where the DSAR was connected to a notifiable breach: {{CLOSURE_BREACH_NOTIFICATION_REFERENCE}}
- Named legal hold notice reference where the DSAR was operating under a hold: {{CLOSURE_LEGAL_HOLD_REFERENCE}}
- Named regulator-engagement protocol reference where the DSAR was regulator-noticed: {{CLOSURE_REGULATOR_ENGAGEMENT_REFERENCE}}
- Named data protection impact assessment reference for the underlying processing operation: {{CLOSURE_DPIA_REFERENCE}}
Named framework expectations evidenced by the closed DSAR operating on the workspace:
- GDPR Article 12, 15, 16, 17, 18, 20, 21, 22, 23, 77, 79 read on the right-class workflow, the verification record, the response copy, the redaction-and-exception record, the refusal pathway, and the supervisory authority referral.
- UK GDPR Article 12, 15, 16, 17, 18, 20, 21, 22 read on the equivalent rights workflow.
- CCPA section 1798.100, 1798.105, 1798.110, 1798.115, 1798.120, 1798.130, CPRA right-to-correct and automated decision-making rules read on the named state workflow.
- ISO/IEC 27701:2019 Clause 6.10 data subject rights, Annex A.7.3 and Annex B.8 read on the documented response artefact and the workforce-side analogue.
- NIST Privacy Framework v1.0 CT.PO-P, CT.PO-P3, CM.PO-P read on the data subject rights operationalisation.
- SOC 2 P1.0 to P8.0 Privacy Criteria read on the documented response artefact, the response evidence pack, and the closure record.
- ISO 27001 Annex A 5.34 (Privacy and Protection of Personally Identifiable Information) read on the operating workflow.
- DORA Article 28 (ICT third-party risk) read on the processor cooperation record.
- LGPD Article 18 and Article 19 read on the right-class workflow and the statutory clock.
- PDPA section 21, PIPEDA Principle 9, Australia Privacy Act APP 12, PIPL Article 45, PIPA Article 35, APPI Article 33 read on the equivalent right-class workflow.
Twelve failure modes the DSAR form has to design against
DSAR programmes fail under request pressure in recognisable patterns. Each failure has a structural counter that the template above is designed to enforce. Read this list before customising the form so the customisation does not weaken the discipline that makes the response defensible across supervisory authority inquiry, complaint review, contractual customer audit, regulator examination, and class-action discovery.
Clock-start ambiguity from inbound channel sprawl
The DSAR arrives through one of seven channels (privacy portal, privacy mailbox, in-product privacy request flow, customer-success ticket, DPO contact, workforce channel, regulator-forwarded letter) and the statutory clock-start is reconstructed days later from email threads. The supervisory authority reads the reconstruction as procedurally weak. The structural counter is the named received-by record at Section 2 with the named channel reference, the named received timestamp, and the named operator who recorded the request.
Over-verification breach of the data-minimisation principle
The intake operator asks every requester for a government identity document, regardless of relationship class or data sensitivity. The controller collects more personal data than necessary, breaches Article 5(1)(c), and creates an additional record the requester can make a separate access request against. The counter is the proportional-tiering verification model at Section 4 with Tier A authenticated-session verification as the default for relationship classes where a session exists.
Under-verification disclosure to an impersonator
The intake operator accepts a single supplied email address as identity verification and ships the response copy. The requester turns out to be an impersonator and the controller has disclosed personal data of a named third party. The counter is the Tier B and Tier C named historic-transaction-reference plus one-time-token confirmation at Section 4 paired with the named DPO approval at Tier D for high-risk processing classes.
Search-ledger gaps that omit the workspace finding record
The search covers the customer-facing application database, the CRM, and the support ticketing platform but omits the workspace finding records, the security exception register, the scanner outputs, the meeting recording archive, the unstructured document repository, and the processor cooperation chain. The response copy is incomplete and the supervisory authority reads the gap as procedural weakness. The counter is the named system-by-system search ledger at Section 5 with the named query, the named operator, the named timestamp, and the named result-set reference per system.
Free-form response letter that misses Article 15(1) disclosures
The response is written as a free-form letter naming the personal data the controller found, but it omits the Article 15(1)(a) purposes block, the (b) categories block, the (c) recipients block, the (d) retention block, the (e) rights block, the (g) source block, the (h) automated decision-making block, and the Article 15(2) international transfer block. The supervisory authority reads the response as procedurally incomplete. The counter is the structured Article 15(1) and 15(3) content blocks at Section 6 that force each disclosure to be present and named.
Ad-hoc third-party redaction without a written exception basis
The response operator redacts named-third-party data and named-confidential commercial information by feel, without naming the statutory basis for each redaction. The requester challenges the redaction, the supervisory authority asks for the redaction-and-exception decision record, and the controller cannot produce one. The counter is the named exception register at Section 7 with the named element reference, the named severability assessment, the named decision, the named approver, and the named timestamp per redaction.
Silence on automated decision-making and source-of-data disclosure
The response copy names the data the controller holds but does not address the Article 15(1)(g) source-of-data disclosure or the Article 15(1)(h) automated decision-making disclosure. The supervisory authority frequently cites this gap. The counter is the named ADM register and the named data-source register at Section 8 with the named system reference, the named inputs summary, the named output and consequence, the named human-review pathway, and the named explainability artefact reference.
Sending the response copy as an unencrypted email attachment
The response copy contains the named personal data the response is meant to disclose, and the operator ships it as an unencrypted email attachment to a contact value that was never re-verified. The named personal data flows in clear text across multiple mail-relay hops and the response itself becomes a data breach. The counter is the named secure-delivery method selection at Section 10 with named authenticated portal download, named time-limited secure file transfer, named password-protected encrypted archive with out-of-band password delivery, or named tracked physical hard-copy delivery.
Refusal without written basis and without supervisory authority complaint pathway
The controller refuses to act on a named portion of the request but does not communicate the named statutory basis, the named appeal pathway, or the named supervisory authority complaint pathway. The requester escalates to the supervisory authority and the regulator opens a procedural inquiry. The counter is the named refusal communication at Section 11 with the named statutory basis, the named appeal pathway, the named supervisory authority complaint pathway, and the named judicial remedy reference.
No retention basis for the DSAR response evidence pack
The response evidence pack is retained indefinitely on a shared drive without a named retention period or named disposition schedule. The retention itself becomes a processing activity the controller cannot justify. The counter is the named retention period and named retention basis at Section 12 paired to the named statutory limitation period for related claims plus the named legal-hold override where applicable.
Missing programme-level metrics for the audit committee read
Individual DSAR responses close on time but the programme cannot report the rolling in-window closure rate, the extension-applied rate, the refusal rate, the average response time, or the supervisory authority complaint count traceable to a named DSAR. The audit committee read of the privacy programme cannot be supported. The counter is the named programme metrics roll-up at Section 12 with named breakdown by jurisdiction and named breakdown by relationship class.
Workforce DSAR routed through the customer-facing intake without scope adjustment
A workforce member submits a DSAR and the intake operator routes it through the customer-facing search ledger, which omits the HR system, the workforce performance records, the named workforce monitoring telemetry, the named workforce-specific automated decision-making registers, and the named state-specific workforce-privacy overlay. The response is incomplete. The counter is the named relationship class capture at Section 3 that routes workforce requests through the HR-aware search ledger and the named workforce-privacy overlay.
Ten questions a quarterly DSAR programme review has to answer
Per-request closure keeps each DSAR response current. Programme-wide review answers the cumulative question: is the right-of-access capability durably audit-ready, is the programme on top of the named statutory clocks, the verification discipline, the search completeness, the redaction-and-exception register, the secure delivery chain, the refusal pathway, and the cross-reference chain to the broader privacy and security record. Run these ten questions at every quarterly programme review and capture the answers in the programme-level summary record.
1.How many DSARs did the programme receive during the period, broken out by named statutory regime (GDPR, UK GDPR, CCPA, CPA, CTDPA, VCDPA, UCPA, TDPSA, LGPD, PDPA, PIPEDA, Australia Privacy Act, PIPL, PIPA, APPI, named-other) and by named relationship class (customer, prospective customer, former customer, workforce member, former workforce member, contractor, named other)?
2.What was the in-window closure rate against the named baseline statutory clock per regime, what was the extension-applied rate, what were the named substantive reasons cited for each extension, and how many extensions were communicated to the requester inside the named baseline window?
3.How many DSARs invoked each named right under Section 3 (access, rectification, erasure, restriction, portability, objection, automated decision-making, ADM logic disclosure, consent withdrawal, complaint), and how did the right-class distribution evolve against the prior reporting period?
4.How many DSARs ran each verification tier under Section 4 (Tier A authenticated session, Tier B known-requester one-time token, Tier C unknown-requester reasonable information, Tier D high-risk processing), and how many were declined under Article 12(6) reasonable-doubts-as-to-identity after a reasonable verification attempt?
5.How many named systems were named in scope of the average DSAR search ledger under Section 5, how many search ledgers were marked complete without all named systems addressed, and how many named processors were invoked through the named cooperation request pathway?
6.How many DSARs invoked each named exception under Section 7 (third-party personal data, legally privileged communications, trade secrets, security evidence that would compromise others, law enforcement hold, confidential workforce records), and what was the redaction-versus-refusal ratio across the named exception classes?
7.How many DSARs surfaced an Article 15(1)(h) automated decision-making disclosure under Section 8, how many surfaced an Article 15(1)(g) source-of-data disclosure, and how many surfaced an Article 15(2) international transfer disclosure with named transfer impact assessment reference?
8.How many DSARs delivered the response copy through each named delivery method under Section 10 (authenticated portal download, time-limited secure file transfer, password-protected encrypted archive with out-of-band password, physical hard-copy delivery), and how many delivery failures triggered the named delivery-failure recovery pathway?
9.How many DSARs entered the refusal pathway under Section 11, how many of those refusals were challenged through the internal complaint pathway, how many escalated to the named supervisory authority, and how many resulted in a named regulator inquiry into the programme?
10.How many DSAR closures triggered a parallel matter under the named legal-hold-notice template, the named data-breach-notification-letter template, or the named regulator-engagement-protocol template, and how were the cross-references preserved on the workspace engagement record under Section 12?
How the DSAR form pairs with SecPortal
The template above is copy-ready as a standalone artefact and does not require any platform to operate. If the privacy, GRC, security, AppSec, vulnerability management, and engineering functions already run finding records, engagement records, evidence intake, exception management, retest records, and audit-evidence packaging on a workspace, the DSAR engagement becomes one of several engagements running alongside the standing security work rather than a separate document lifecycle. SecPortal opens a DSAR engagement on receipt of the request through engagement management so the named received timestamp, the named statutory clock anchor, the named privacy programme owner, the named verification tier, the named search ledger, the named response copy, and the named closure record all live on one workspace record from the first hour rather than being reconstructed weeks later when the supervisory authority asks for the chain.
The document management feature stores the executed DSAR form, the named identity-verification record, the named scope-and-search ledger, the named response copy, the named redaction-and-exception register, the named secure-delivery chain-of-custody record, the named acknowledgement record, and the named refusal-decision record where applicable as versioned artefacts on the engagement. The activity log captures named-actor status transitions on every entity by named user and timestamp with CSV export, so the audit chain of the response discipline is reconstructable from the workspace rather than from forwarded emails or chat archives the supervisory authority cannot read.
The findings management feature captures the named workspace finding records under the unified finding schema with CVSS 3.1 calibration, named owner, named scope capture, and named evidence pointer, so the named search ledger at Section 5 reads against a structured backlog where the named data subject is referenced inside finding records, finding comments, or scanner outputs. The finding overrides feature carries the eight-field exception decision chain (named scope, named approver, named rationale, named effective period, named review cadence, named framework reference, named acceptance method, named justification) so the named exception-register assessment at Section 7 stays on the live record rather than on a side spreadsheet.
The compliance tracking feature maps the framework expectations the DSAR engages (GDPR Article 12-22 and Article 77-79, UK GDPR equivalents, CCPA section 1798.130, ISO/IEC 27701 Clause 6.10, NIST Privacy Framework, SOC 2 P1-P8, ISO 27001 Annex A 5.34, DORA Article 28 processor cooperation, LGPD Article 18-19) so the parallel privacy posture is visible on one record. The team management feature carries the role-based access control with the named role grants (owner, admin, member, viewer, billing) so access to the DSAR engagement can be narrowed to privacy counsel, DPO, and named GRC operators rather than left wide-open. The multi-factor authentication enforcement gates workspace access so the access record reads as a documented control rather than as a hope. The encrypted credential storage feature carries the AES-256-GCM encrypted credential records scoped to verified domains for authenticated scanning, which are themselves frequent subjects of disclosure under DSARs that touch named workforce or named contractor accounts. The AI report generation workflow drafts the leadership read of the DSAR portfolio (count by jurisdiction, in-window closure rate, extension-applied rate, refusal rate, average response time, supervisory authority complaints traceable to a DSAR) from the same engagement data so the audit committee read of the privacy programme and the operational read are the same record rather than two independently edited summaries that diverge between cycles.
Honest scope: SecPortal does not provide privacy counsel, does not draft the response on the customer platform side, does not fulfil the access right against an external SaaS system, does not run a data discovery engine, does not auto-populate the records of processing activity register, does not orchestrate consent banners, does not maintain a cookie-tracker catalogue, does not run the supervisory authority filing workflow, does not deliver named-vendor privacy management platform integrations (OneTrust, TrustArc, DataGrail, Securiti, Privado, Ethyca, Osano, Termly, BigID, Collibra, Transcend, WireWheel, Wirewheel, named-other), does not ship native push connectors into Jira, ServiceNow, OneTrust, Vanta, Drata, SecureFrame, Whistic, LogicGate, Archer, MetricStream, RSA Archer, AuditBoard, Resolver, ServiceNow IRM, or any GRC platform, does not provide enterprise SSO or SCIM, does not automate approval routing, and does not automate request triage. The privacy team runs the privacy platform of record, the DPO advises the controller, privacy counsel signs the substantive response decision, and SecPortal carries the durable workspace engagement record those experts read into for the security-side evidence chain, the finding records, and the cross-functional audit trail.
Who reads the DSAR form artefact
GRC, compliance, and privacy teams
GRC and compliance teams, privacy officers, data protection officers, and privacy programme leads read the template as the operational form that turns an inbound right-of-access request into a verifiable response. The Section 4 verification tiering, the Section 7 redaction-and-exception register, and the Section 12 closure evidence pack directly inform the audit-evidence chain the GRC function operates. Pair the template with the GRC and compliance teams persona page and the audit fieldwork evidence request fulfillment workflow.
CISOs, security directors, and security programme owners
CISOs, security directors, security programme owners, and audit-committee chairs read the DSAR form as the operational artefact that lets the security organisation respond to inbound privacy requests with a structured search ledger across the named SIEM, the named EDR, the named scanner outputs, the named workspace finding records, and the named exception register rather than ad-hoc downloads from chat archives. Pair the template with the CISOs persona page and the security leadership reporting workflow.
Internal security, AppSec, and vulnerability management teams
Internal security teams, AppSec teams, vulnerability management teams, and security engineering teams read the template as the cross-functional request that lands on the team operating the named log sources, the named SIEM, the named workspace finding records, and the named exception register where the named data subject may be referenced. The Section 5 search ledger captures the named workspace finding query alongside the customer-facing application query. Pair the template with the internal security teams persona page, the AppSec teams persona page, the vulnerability management teams persona page, and the cross-engagement finding search workflow.
Engineering, data, and customer-facing functions
Engineering leads, data engineers, data security teams, customer success leads, and support managers read the template as the cross-functional intake that the privacy programme routes through their systems. The Section 5 search ledger names their system explicitly and the Section 6 response content names the recipients and processors their system handed data to. Pair the template with the data security teams persona page, the customer security evidence room workflow, and the GDPR framework page.