What do organisations get wrong about responding to access and correction requests under New Zealand’s Privacy Act?

The most common failure is treating access and correction requests as informal service tasks instead of timed legal obligations. Organisations must decide access requests as soon as reasonably practicable and no later than 20 working days, and correction requests within 20 working days. They also need transfer procedures, escalation paths, and clear responsibility for privacy commissioner complaints.

What organisations get wrong about access and correction requests

The core mistake is procedural, not technical: many teams treat privacy requests like customer service tickets and forget they are statutory deadlines with defined decision points. That leads to vague ownership, poor triage, and missed transfers. The practical test is whether the organisation can trace the request from intake to decision, escalation, and complaint handling without improvising.

That traceability matters because access and correction requests often involve sensitive records, mixed systems, and multiple business owners. A request can be valid even when the information is scattered across email, case systems, file shares, and third-party platforms. The real failure is assuming the data owner can “work it out later” instead of having a controlled process that preserves timing, accuracy, and accountability.

Why timing, transfer, and ownership matter more than a polite reply

The statutory clock starts when the request is received, not when the right person happens to see it. Organisations get into trouble when privacy requests sit in generic inboxes, are reassigned without tracking, or wait on a manager’s convenience. A legally adequate process needs an intake rule, a transfer rule, and a clear line for who can decide whether access is granted, limited, or refused.

Transfer procedures are especially important where the request lands in the wrong function but the information is still held elsewhere in the organisation. If the first recipient cannot satisfy the request, they still need to move it to the right owner quickly and preserve the original receipt date. The same discipline applies to corrections: the organisation must assess whether the record should be amended, annotated, or left unchanged with an explanation.

How to make requests defensible when complaints follow

Good handling is not just about issuing a response, it is about being able to explain the response later. That means recording what was requested, what searches were run, who decided, what was disclosed or corrected, and why any limits were applied. If the person escalates to the Privacy Commissioner, the organisation should be able to show a complete decision trail rather than a chain of ad hoc emails.

For privacy requests, identity and access governance basics are relevant because the same discipline that tracks entitlements and ownership also helps locate records, confirm who can act, and prove the process was controlled. Where organisations handle personal data carefully, identity data privacy and consent practices can also sharpen how teams think about lawful handling, retention, and data subject rights.

Risk and Threat Considerations

Poor request handling creates both compliance risk and disclosure risk. If access is delayed, incomplete, or never formally decided, the organisation can compound the original complaint with a process failure. If correction requests are handled informally, inaccurate records may continue to drive downstream decisions, communications, or restrictions on the individual.

Failure mechanism: Requests are routed through informal service channels, ownership is unclear, and the legal clock is not tracked from receipt through decision and transfer.

Impact: The organisation can miss statutory deadlines, fail to correct inaccurate records, and lose the ability to defend its decision if the matter reaches a complaint or investigation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AU-2 — Event Logging	Request handling needs a traceable decision trail for complaints and audits.
	IR-4 — Incident Handling	Missed or mishandled privacy requests require formal escalation and containment.
Recommendation — Log receipt, transfers, decisions, and exceptions for every privacy request. Escalate overdue or disputed privacy requests through a defined response process.
ISO/IEC 27001:2022	A.5.34 — Privacy and protection of PII	Access and correction requests are a PII handling obligation requiring governed procedures.
Recommendation — Document and operate a repeatable process for handling PII access and correction requests.
GDPR	Art. 15 — Right of access by the data subject	The subject is about operational handling of access requests, a core data subject right.
	Art. 16 — Right to rectification	Correction requests map directly to the right to rectification and its handling.
Recommendation — Set a controlled workflow to respond to access requests within the legal deadline. Verify and action correction requests promptly, including annotation where a change is disputed.

Practitioner Guidance

What to verify: Confirm that every request has a timestamped intake point, an assigned owner, and a decision log that shows whether the request was answered, transferred, extended, or refused. If any of those elements depends on memory or email chasing, the process is not yet defensible.

Common mistake: Treating “we acknowledged it” as success. An acknowledgement does not satisfy the obligation unless the organisation can show the request was actively managed to a lawful outcome within the required timeframe.

Practitioner takeaway: The safest model is a governed workflow with clear ownership and evidence, not a goodwill response handled by whichever team sees the request first.