The Privacy Act 2020 replaced legislation written before most New Zealand businesses had websites. The update introduced mandatory breach notification, strengthened individual rights, and applied the same obligations to sole practitioners as to listed companies. For financial services firms, where websites routinely collect personal and sometimes sensitive financial information, the Act creates specific obligations that most sites do not currently meet.
The Privacy Act 2020 contains thirteen Information Privacy Principles (IPPs), but only a handful directly govern what happens on your website. IPP 1 requires you to collect personal information lawfully and not by unfair means. IPP 2 says you must collect it directly from the individual concerned, which is exactly what a contact form does. IPP 3 -- the one most websites get wrong -- requires that you tell people why you are collecting their information, who will hold it, and what happens next.
For a financial services website, this means every form that collects a name, email, phone number, or financial detail needs to be covered by a clear collection statement. Not buried in a privacy policy footer link. Present at the point of collection.
IPP 5 covers storage and security -- your obligation to protect information against loss, unauthorised access, and misuse. If your contact form submissions sit in an unencrypted WordPress database on shared hosting, that is an IPP 5 conversation. IPP 6 gives individuals the right to access their information, and IPP 7 lets them request correction. Both create obligations your website processes need to support, even if the request comes by phone rather than through the site.
The Office of the Privacy Commissioner publishes the full principles on their guidance pages, and they are worth reading in full rather than relying on summaries.
Most financial services websites treat their privacy policy as a catch-all compliance document. It is not. A privacy policy is a general statement about how the organisation handles personal information. A collection statement is specific to the moment of collection -- it tells the person filling in your form exactly what will happen to the information they are about to provide.
The Privacy Act requires both, but they serve different functions. Your privacy policy can live on a dedicated page. Your collection statement needs to appear at or near the form itself. "We take your privacy seriously" is neither.
A practical collection statement for a financial advisor's contact form might read: "We collect your name and contact details to respond to your enquiry. This information is held by [firm name] and you can request access to or correction of it at any time by contacting us at [email]. We will not share your details with third parties without your consent."
That is not legal advice -- it is a structural example. The point is that it is specific, present at the point of collection, and covers the IPP 3 requirements. Most accounting firm websites have a privacy policy page that nobody reads and no collection statements at all. The Act does not treat one as a substitute for the other.
Every business, sole trader, partnership, and incorporated practice in New Zealand is an "agency" under the Privacy Act 2020. There is no small-business exemption. A sole-practitioner financial advisor with a WordPress site collecting enquiry form submissions has the same obligations as a Big Four firm.
This catches some smaller practices off guard. The assumption that privacy compliance is a large-organisation concern does not survive a reading of the Act. If you collect personal information -- and every contact form, newsletter signup, and online calculator that asks for an email address does exactly that -- the Information Privacy Principles apply to you.
The Privacy Act 2020 defines "agency" broadly in section 7. The only exemptions are for individuals acting in a personal capacity, courts, and a handful of specific entities listed in Schedule 1. Your accounting practice is not on that list.
A compliant privacy policy for a financial services website needs to address each category of personal information you collect, the purpose of collection, who has access, how long you retain it, and how individuals can exercise their rights under the Act.
For most advisory and accounting firm websites, the categories are predictable: contact details from enquiry forms, email addresses from newsletter signups, usage data from analytics, and possibly financial information from online tools or onboarding forms. Each category needs its own treatment because the purpose, retention period, and access controls differ.
The policy should also name the privacy officer or contact person -- the Act requires agencies to have someone who handles privacy requests. For a small practice, that is usually a partner. For larger firms, it may be a dedicated role.
Template privacy policies downloaded from American legal sites are worse than useless. They reference legislation that does not apply here, omit the IPPs entirely, and often include GDPR-specific language that creates confusion about which regime governs. If you are going to use a template, start with one written for the New Zealand Privacy Act 2020. The Privacy Commissioner's office has resources for businesses that are a reasonable starting point.
Google Analytics 4 collects personal information. That is not a controversial interpretation -- IP addresses are personal information under the Privacy Act, and GA4 processes them even if it does not store the full address. Every third-party script on your website that sets cookies or collects behavioural data is a potential privacy consideration.
The Privacy Act does not have a cookie-specific consent regime like the EU's GDPR. You do not need a cookie consent banner as a matter of New Zealand law. But you do need to disclose in your privacy policy that you use analytics tools, what data they collect, and who the third-party provider is. If you are using Google Analytics, Meta Pixel, Hotjar, or any similar tool, your privacy policy needs to say so.
The practical exposure for financial services sites is not the analytics itself -- it is the accumulation of undisclosed third-party scripts. A typical accounting firm website might load Google Analytics, Google Tag Manager, a chatbot widget, a scheduling tool, and a CRM integration. Each one collects data. If your privacy policy only mentions "cookies to improve your experience," you have a disclosure gap.
Audit your scripts before you write your policy. View source, check the network tab, and list every third-party domain your site calls. Then disclose them.
The Privacy Act 2020 introduced mandatory breach notification -- a significant change from the 1993 Act. A privacy breach becomes notifiable when it causes serious harm or is likely to do so. The threshold is not "any breach" but "serious harm," and the Act lists factors for assessing that: the sensitivity of the information, whether it is secured by a password or encryption, the nature of the harm that could result, and who obtained or could obtain the information.
For a financial services website, the scenarios that cross the threshold are concrete. A database breach exposing client contact details paired with information about their financial situation -- notifiable. An email list export that ends up public -- likely notifiable. A contact form submission accidentally emailed to the wrong address -- possibly notifiable depending on content.
A form plugin vulnerability that exposes submissions to unauthenticated access is the most common website-specific scenario. WordPress form plugins have had multiple CVEs over the years. If your contact form stores submissions in the WordPress database -- and most do by default -- a plugin vulnerability that exposes that data is a breach. Whether it crosses the "serious harm" threshold depends on what information the forms collect, which is why financial services forms that ask for account numbers or IRD details create more exposure than a simple name-and-email enquiry.
When you determine a breach is notifiable, you must notify both the Privacy Commissioner and the affected individuals "as soon as practicable." The Act does not specify a fixed timeframe in hours or days, but "as soon as practicable" means once you have confirmed the breach and have enough information to provide a meaningful notification -- not after your lawyer has spent three weeks drafting a response.
The notification to the Commissioner must include the nature of the breach, the information involved, what you have done in response, and your recommendation to affected individuals about what they should do. The notification to individuals must cover the same ground in plain language.
The Privacy Commissioner's NotifyUs tool walks you through the process. For a small practice, the realistic scenario is: your web developer tells you the site was compromised, you determine what data was accessible, you assess whether it meets the serious harm threshold, and if it does, you notify. Having a basic incident response plan -- even a one-page document that names who makes the call and who does the notifying -- saves time when a breach actually happens.
Financial services firms regulated by the FMA have additional disclosure considerations under their own licensing conditions, which may run in parallel with Privacy Act obligations.
The simplest way to reduce breach risk on a financial services website is to collect less data and store it for less time. Every field on your contact form that you do not actually need to respond to the enquiry is unnecessary exposure. If you do not need a phone number to reply, do not ask for it.
Form submissions stored in your WordPress database are a liability. Most form plugins offer the option to email submissions to you without storing them on the server. If you do not need a searchable archive of form submissions -- and most small practices do not -- turn off database storage. The submission reaches your inbox, you respond, and there is nothing on the server to breach.
For firms that do need to retain form data, basic measures apply: keep WordPress and all plugins updated, use a security plugin that monitors for known vulnerabilities, ensure your hosting provider applies server-level patches, and use HTTPS with a valid certificate. These are not Privacy Act requirements specifically, but they support your IPP 5 obligation to protect information against loss and unauthorised access.
If your website collects financial information through onboarding forms or calculators, the exposure calculation changes significantly. That data should never sit in a standard WordPress database. It belongs behind a dedicated secure system with access controls, encryption at rest, and audit logging.
The Privacy Act sets a floor, not a ceiling. Compliance means meeting the Information Privacy Principles. But client expectations for how financial professionals handle their data have moved well past the statutory minimum, driven partly by awareness of overseas regimes like GDPR and partly by high-profile breaches in the news.
A financial services website that technically complies with the Act -- has a privacy policy, includes collection statements, has a breach response plan -- can still feel careless to a visitor. If your privacy policy is a wall of legal text last updated in 2019, if your site loads tracking scripts from five different vendors, if your forms ask for unnecessary personal details -- the visitor notices, even if the Privacy Commissioner would not.
Best practice for financial services websites goes beyond the Act: minimal data collection, clear and plain-language privacy communication, cookie consent even though NZ law does not require it, and regular audits of third-party scripts. These are not legal requirements. They are trust signals for an audience that is about to hand you their financial information.
The firms that treat privacy as a trust-building exercise rather than a compliance checkbox tend to have better conversion rates on their contact forms. That is not a coincidence.
Accessibility and privacy are treated as separate compliance streams, but they overlap on financial services websites in ways that matter. A contact form that does not work with a screen reader is both an accessibility failure and, arguably, an unfair means of collection under IPP 1 -- you are effectively preventing some users from providing information directly while allowing others to do so.
The New Zealand Government Web Standards recommend WCAG 2.1 AA compliance. While these standards are mandatory only for government agencies, the Human Rights Act 1993 prohibits discrimination in the provision of services, and the Human Rights Commission has been clear that this extends to digital services. For a financial services firm, an inaccessible website is both a legal risk and a reputational one.
Where this intersects with privacy: alternative data collection methods for users who cannot use your website forms (phone, email, in-person) need the same privacy protections as the digital channel. If your privacy policy only covers website collection, you have a gap. And if your forms use CAPTCHA that prevents screen reader users from submitting, you are creating an accessibility barrier that has privacy implications.
Run through this list against your current website. It takes about thirty minutes and will tell you where your gaps are.
Forms: List every form on your site. For each one, note what fields it collects, where submissions are stored (email only, WordPress database, CRM), and whether a collection statement is visible at the point of submission. If any form collects financial information, flag it separately.
Privacy policy: Does it exist? Does it reference the Privacy Act 2020 (not the 1993 Act)? Does it name the types of information you collect, the purposes, and the contact person for privacy requests? Does it cover analytics and third-party tools?
Third-party scripts: Open your site in Chrome, open Developer Tools, go to the Network tab, and reload. Count the third-party domains. Are all of them disclosed in your privacy policy? Common ones you may not have thought about: Google Fonts (sends visitor IP to Google), embedded YouTube videos (sets cookies), social media share buttons (track visitors).
Storage and retention: How long do form submissions sit in your database? Is there a process for deleting them? Can you respond to an access or correction request -- do you know where all copies of a person's data are?
Breach readiness: Do you know who to call if your web developer tells you the site has been compromised? Is there a documented process, even a basic one?
You can write your own privacy policy using the Privacy Commissioner's templates. You can add collection statements to your forms. You can audit your third-party scripts and reduce your data collection footprint. None of that requires a lawyer.
You should get legal advice when your website collects sensitive financial information through onboarding forms, calculators, or client portals. The intersection of Privacy Act obligations, FMA licensing conditions, and the Anti-Money Laundering and Countering Financing of Terrorism Act 2009 creates complexity that a template cannot address. If your website is part of your client onboarding workflow -- not just a marketing brochure -- legal review of your data handling is a reasonable investment.
You should also get legal advice if you experience a breach that may be notifiable. The "serious harm" assessment has legal dimensions, and the notification process creates a record that may be relevant if a complaint follows.
For the majority of financial services websites -- those that collect names, emails, and phone numbers through contact forms and nothing more -- the Privacy Commissioner's guidance and a careful reading of the Act are sufficient. The firms that need lawyers are the ones whose websites do more than market.
Privacy compliance for a financial services website is not a one-time exercise. The Act sets ongoing obligations -- to collect fairly, disclose clearly, store securely, and respond when things go wrong. Most of this is straightforward. The firms that struggle are the ones that treated their privacy page as a set-and-forget exercise in 2018 and have not revisited it since. Start with the audit checklist, close the obvious gaps, and get legal advice for the parts that intersect with your regulatory obligations. The Privacy Commissioner's office is genuinely helpful when you approach them with specific questions -- use them.
