Privacy access request (DSAR) workflow¶
| ID | MOD-148 |
| System | SD08 |
| Repo | bank-app |
| Build status | Not started |
| Deployed | No |
Purpose¶
Provide an end-to-end governed workflow for handling customer privacy access requests (data subject access requests, DSARs) under the NZ Privacy Act 2020 (Information Privacy Principle 6) and AU Privacy Act 1988 (APP 12). The workflow covers intake, identity verification, data assembly across platform systems, decision and disclosure, correction requests, and escalation to the Privacy Commissioner where a request is refused or the statutory SLA is at risk of breach.
What it does¶
Intake channels¶
Customers may submit a DSAR through the in-app support interface using the MOD-053 case management form, or a staff member may create a case on the customer's behalf following a phone or branch contact. Each submission creates a privacy_access_request case type in MOD-053 and triggers the DSAR workflow. Duplicate detection runs on submission to identify whether the same customer has an open request of the same type.
Identity verification¶
Before data assembly begins, the customer's identity must be confirmed. Requests submitted through the authenticated app session satisfy this requirement automatically — the existing MOD-068 session token is recorded as the verification event. For requests submitted via other channels (email, branch, phone), the handling agent must document the verification method used and record the outcome before the workflow advances to assembly. Data assembly is blocked until a verified identity event is present on the case.
SLA timer¶
The module applies a jurisdiction-appropriate statutory timer from the moment of receipt. For NZ customers, the NZ Privacy Act 2020 requires a response within 20 working days. For AU customers, APP 12 requires a response within 30 calendar days. The correct timer is applied automatically based on the customer's jurisdiction field in their CDD profile (MOD-010). An amber warning notification is generated when 50% of the available SLA time remains. A red escalation alert is sent to the Privacy Officer when 20% of the available time remains. If the deadline is reached without a disclosed or refused outcome, the case is escalated automatically and a Privacy Commissioner notification is prepared for review.
Data assembly¶
On reaching the assembly stage, the module generates a structured extract of all personal information held about the customer across platform systems. The extract draws from the CDD profile (MOD-010), account and transaction data (MOD-001), loan records, communication logs, marketing preferences, and consent records. Assembly is automated; the resulting package is presented to the privacy team in a structured review interface before any disclosure occurs. The assembling agent may annotate individual data categories and flag items for legal review.
Third-party data redaction¶
Where the assembled data contains personal information about third parties — for example, joint account holders, authorised signatories, or named payees — the reviewing agent must redact that information before disclosure. The module provides an in-browser redaction tool that allows the agent to black out fields or sections. Redaction actions are logged with the agent identifier, timestamp, and the category of information removed. The redacted package is generated as a separate artefact; the unredacted source is retained internally for audit.
Correction requests¶
Customers may request correction of personal information they believe to be inaccurate or incomplete. Correction cases follow the same intake and verification steps, with an additional review stage in which the proposed correction is assessed by the data owner for the relevant data category. If the correction is upheld, it is applied and the customer is notified of the change. If declined, the customer is advised of the outcome and their right to complain. The outcome and rationale are recorded on the case.
Refused requests¶
Where a request is refused — on grounds such as legal professional privilege, harm to a third party, or a statutory exception — the refusing officer must document the specific ground for refusal on the case. A formal refusal letter is generated from a template, incorporating the stated ground and the customer's right to complain to the Privacy Commissioner (NZ: Office of the Privacy Commissioner; AU: Office of the Australian Information Commissioner). Refused cases are flagged for Privacy Officer review before the letter is dispatched.
Data table¶
The app.privacy_access_requests table holds: request_id, customer_id, request_type (access / correction / erasure_query), received_at, identity_verified_at, jurisdiction (NZ / AU), sla_due_at, status (received / assembling / under_review / disclosed / refused / escalated), disclosed_at, refusal_reason, commissioner_notified.
Compliance reason¶
NZ Privacy Act 2020 IPP 6 and AU Privacy Act 1988 APP 12 both confer a right on individuals to access personal information held about them by an organisation, and a right to request correction of that information. Failure to respond within the statutory timeframe is a breach of the Act and grounds for a formal complaint to the Privacy Commissioner. Without a governed workflow, DSAR responses are managed ad hoc, with no SLA enforcement, no consistent identity verification gate, and no audit trail of what was disclosed and to whom. The module eliminates all three deficiencies and creates the documentation required for regulator examination.
Commercial reason¶
Privacy access request volumes are increasing across financial services as customers become more aware of their rights. A manual DSAR process is labour-intensive — assembling data across multiple systems for a single request can take hours. Automated assembly alone eliminates the bulk of that effort. SLA enforcement prevents the escalations to the Privacy Commissioner that are disproportionately damaging to the institution's reputation relative to the cost of responding on time. The governed workflow also protects the institution from inadvertent over-disclosure of third-party data, which creates its own privacy liability.
Module dependencies¶
Depends on¶
| Module | Title | Required? | Contract | Reason |
|---|---|---|---|---|
| MOD-053 | Case & complaint management module | Required | — | DSAR cases are created as a specialised case type within the case management system — SLA tracking, agent assignment, and escalation use the same case management infrastructure. |
| MOD-068 | Authentication & session management | Required | — | Customer identity must be verified before any personal information is assembled or disclosed — authentication session is required. |
| MOD-047 | Agent action logger | Required | — | All agent actions taken on DSAR cases are logged via the agent action logger for privacy audit purposes. |
| MOD-010 | CDD tier assignment engine | Required | — | CDD profile provides the authoritative list of personal data held about the customer across platform systems. |
| MOD-103 | Neon database platform bootstrap | Required | — | Neon database and schema provisioned by MOD-103 must exist before this module can read or write Postgres. |
| MOD-104 | AWS shared infrastructure bootstrap | Required | — | AWS shared infrastructure provisioned by MOD-104 (EventBridge buses, S3, KMS, Kinesis, Cognito) is required before this module can be deployed. |
Required by¶
(No modules in this wiki currently declare a dependency on this module.)
Policies satisfied¶
| Policy | Title | Mode | How |
|---|---|---|---|
| PRI-001 | Privacy Policy | AUTO |
Customer access requests are received, triaged, and fulfilled within the statutory timeframe — the workflow enforces the SLA and escalates automatically if it is at risk. |
| PRI-003 | Personal Information Retention & Destruction Policy | LOG |
Every access request, data assembly action, disclosure decision, and regulator escalation is logged as an immutable privacy record. |
| PRI-006 | Customer Data Access & Correction Policy | AUTO |
DSAR workflow assembles the complete data inventory held about a customer across all platform systems — subject access fulfilment is automated, not manual. |
Capabilities satisfied¶
(No capabilities mapped)
Part of SD08 — Customer App & Back Office Platform
Compiled 2026-05-22 from source/entities/modules/MOD-148.yaml