The new website has a contact form, a marketing connection and visitor tracking. The developer demonstrates the administration screen. Enquiries appear in a tidy list, ready to be exported whenever someone needs them.
Six months later, the same enquiries are still there. They have also arrived in a shared mailbox and been copied into the customer management system. Nobody asked for three permanent archives. The website project quietly created them.
This is an illustrative scenario, not an incident documented by the regulator. But it describes a decision easily missed when commissioning a website: which information should this business become responsible for holding?
The OAIC's 26 October release on large-scale breaches puts that question in perspective. It received 667 notifications for January–June 2026, against 662 in the previous six months. Breaches affecting 100,000–250,000 people increased from three to six; those affecting 500,000–1 million rose from zero to three.
Malicious or criminal activity remained the leading cause. Health service providers recorded 149 notifications, followed by education with 85, business and professional associations with 79, and financial and personal services with 51 each. Identification and notification speeds improved.
These are notifications under the Notifiable Data Breaches scheme, not every Australian breach. They do not identify websites as the cause or establish that one publishing platform is safer than another. The connection to website design is a practical risk question, not an OAIC finding about architecture.
Commissioner Carly Kind expressed the underlying principle plainly: “Organisations can’t lose personal information they don’t hold.”
The enquiry list is a business asset with a carrying cost
An enquiry archive can be useful. It lets an office manager find a missed message, identify repeat requests or follow up unfinished work. The problem begins when nobody distinguishes that purpose from keeping everything indefinitely.
Ask where one submission goes. A form plugin may save it in the website database, email it to several staff and send it to a customer relationship management service. A marketing connection may create another profile. Analytics or tracking scripts may collect identifiers and behaviour separately. Storage depends on the plugins, services and configuration; WordPress does not universally retain every contact submission by default.
The visible website and the services connected to it are different places to look. Removing a form from a page does not empty the mailbox receiving its messages or remove records from a marketing platform. An account once created for a customer may survive long after its purpose ends.
Each additional copy needs access controls, a retention decision and an explanation if something goes wrong. The cost is rarely visible in the website quotation. It appears later, when the business has to establish which records were exposed and whose information they contained.
A form field should earn its place
Consider an initial consultation request. A name, preferred contact method and short description may be enough to arrange a conversation. A date of birth, residential address or identity-document upload needs a separate explanation at that stage. The fact that the form builder offers those fields is not one.
Different work justifies different collection. A health provider may need information that a landscape designer does not. A professional engagement may require records that an informal enquiry does not. Timing matters: collecting something during onboarding can be justified even when asking every prospective customer for it is excessive.
For businesses covered by the Australian Privacy Principles, APP 3 generally limits collection of ordinary personal information to what is reasonably necessary for their functions or activities. Merely convenient is not enough. Sensitive information generally also requires consent unless an exception applies.
The OAIC's small-business guidance matters here. The Privacy Act generally covers businesses with annual turnover above $3 million, with exceptions that bring some smaller operators within it, including health service providers holding health information. Turnover alone therefore does not settle coverage. The APPs and NDB scheme do not automatically cover every small business. Other statutory, contractual and professional responsibilities can still apply. These are general business observations, not legal advice.
A useful design conversation therefore starts with the task. What does someone need to tell us to receive this service? Where should that information go? Who will use it? Those answers should shape the form before its appearance is approved.
The architecture decides what needs protecting
A conventional database-driven content management system runs an application on the server, retrieves stored content and assembles pages for visitors. It normally brings a database, administrator authentication, application updates, plugins and dependencies. Those components can be entirely appropriate when the business needs their functions.
A statically generated website builds pages ahead of time and serves the resulting HTML, CSS and JavaScript. It can publish service information without a public-facing CMS application or content database. MDN's explanation of static and dynamic sites describes this distinction. Removing the live publishing application can remove opportunities to exploit its login, plugins or database connection.
The benefit depends on what is actually removed. Keeping a CMS online as a publishing backend still leaves that system to protect. Connecting a static page to an external form service can place every enquiry in somebody else's database. Email delivery creates records in mailboxes. Hosting logs may contain visitor information even without analytics.
Static delivery also needs secure hosting, protected deployment credentials and maintenance of build tools and dependencies. JavaScript and third-party integrations can introduce vulnerabilities or collect information. A static website is not a promise that no personal information is held.
There are two separate benefits here. Removing unnecessary software and accounts can close off potential routes into a system. Holding less personal information can reduce what an intruder could expose even if another route remains. Fewer records do not prevent every incident, but can limit its consequences.
For a brochure site, however, visitor accounts and a permanent enquiry database may do little useful work. Leaving them out reduces systems and credentials to administer. For a membership association or online shop, removing necessary accounts could simply push staff into less controlled workarounds. A well-maintained dynamic site can be the appropriate choice.
Consider a professional-services firm moving from WordPress to a static site. Its form plugin holds years of enquiries that the business decides it no longer needs, after considering its recordkeeping obligations. Publishing the replacement site does not dispose of the old database, hosting backups or exported spreadsheets. A secure migration should include an inventory of information being left behind, with an agreed destination or disposal arrangement for each copy. Otherwise, the public website becomes simpler while the historical records remain in old systems that still need protecting.
Solway Web Consulting's website migration service includes assessing whether to retain WordPress or rebuild a suitable site for static delivery. The useful question is which functions the business needs to operate, including the information handling behind them.
Put an end to the enquiry's journey
Return to that first submission. Once the enquiry has been answered, which record remains useful? Perhaps the customer system should hold the ongoing relationship while temporary website copies expire. That needs an agreed purpose and retention arrangement, rather than an assumption that every copy is equally valuable. A completed enquiry may still have a legitimate business purpose; it need not be deleted immediately. Retention should be intentional, justified and consistent with applicable obligations, rather than continuing because nobody decided when it should end.
APP 11 guidance distinguishes reasonable protection of information held from reasonable steps to destroy or de-identify it when no longer needed for a permitted purpose. Exceptions include Commonwealth records and retention required by Australian law or a court or tribunal order. There is no universal deletion period for every enquiry or customer record.
Review historical submissions alongside customer accounts, CRM records, shared mailboxes, cloud exports and marketing platforms. Former staff access deserves attention too. Backups need deliberate expiry and access arrangements: deleting a live record may leave recoverable copies, and restoring an old backup may reintroduce it. Required records must remain protected and usable for as long as the obligation applies.
Solway Web Consulting's small-business cyber security review covers website, email, administrator and backup risks. It can support technical decisions about those systems; legal retention questions require appropriate advice. Collecting less does not remove applicable breach-notification obligations.
At the next redesign, ask the developer to demonstrate where an enquiry goes and how its copies eventually leave. A polished administration screen is easy to approve. The harder decision is which records should still be sitting behind it years later if the business has to explain a breach.