Securing Customer Data When You've Outgrown Your Website

Your website was built to show your services and collect inquiries. A contact form, maybe a quote request, perhaps a simple booking widget. Somewhere along the way, it started collecting things it was never designed to protect — customer applications with dates of birth, uploaded documents containing financial information, form submissions with data that would be catastrophic in a breach. The website still works. But it’s now holding data it has no business holding.

This happens gradually. First you add a form to collect a bit more detail from prospects. Then someone suggests putting the application form online to save time. Then clients start uploading documents — ID, payslips, contracts — because it’s more convenient than emailing them. Each addition makes perfect sense in isolation. But in aggregate, your $3,000 WordPress site is now a repository for personally identifiable information that could destroy your business if it leaked.

A property management company we spoke with put it bluntly: “We’ve been hacked before. Probably every property management company gets targeted regularly.” They were collecting tenant applications through their WordPress backend — birth dates, tax file numbers, employment history, credit authorisations. Their solution? Manually deleting applications from the database every day, because they didn’t want to be holding that data on a hackable website. They knew the risk. They just didn’t have a better system yet.

How Websites Become Data Liabilities

Nobody sets out to build a security risk. It happens through scope creep — small, reasonable expansions that gradually push a website beyond its design.

Stage 1: Contact form. Collects name, email, phone number. Low-risk data. The website handles this fine.

Stage 2: Detailed inquiry form. Now you’re collecting address, business details, maybe a description of what they need. Still relatively low risk, but you’re starting to build a database of personal information.

Stage 3: Application or intake form. This is the tipping point. You add fields for date of birth, identification numbers, financial details, employment history. You add file upload so people can attach supporting documents. Suddenly you’re collecting sensitive PII through the same system that runs your blog.

Stage 4: Ongoing data storage. Those submissions don’t get deleted. They sit in the WordPress database indefinitely, alongside every other piece of content on your site. Anyone who gains access to the site — through a plugin vulnerability, a compromised password, or a hosting breach — has access to everything.

The jump from Stage 2 to Stage 3 is where the risk profile changes fundamentally. A contact form breach is embarrassing. An application form breach — with birth dates, tax file numbers, and financial documents — is a legal and reputational catastrophe.

What You’re Actually Storing

Most business owners haven’t done a thorough audit of what data their website holds. Here’s an exercise worth doing this week:

1. List every form on your website. Contact forms, application forms, quote request forms, file upload forms — everything.
2. For each form, list every field. Write down exactly what data each field collects.
3. Categorise the sensitivity. Name and email is low sensitivity. Date of birth and tax file number is high sensitivity. Financial documents are critical.
4. Check your database. How far back do submissions go? Are submissions from two years ago still sitting in the database? Most likely, yes — because nobody set up automatic deletion.
5. Check uploaded files. Where are file uploads stored? On the web server? In a publicly accessible directory? Can you access them by guessing the URL?

This audit usually produces an uncomfortable moment. Business owners realise they’re sitting on hundreds or thousands of records containing sensitive personal information, stored in a system with minimal security controls, accessible to anyone with admin credentials — which often includes the web developer, the marketing person, and a former employee whose access was never revoked.

Why WordPress and Basic Websites Are Risky for Sensitive Data

WordPress powers roughly 40% of the web. It’s a brilliant content management system. It is not, and was never designed to be, a secure data management platform. The same applies to Squarespace, Wix, and other website builders.

Plugin vulnerabilities. The average WordPress site runs 20-30 plugins. Each plugin is a potential attack surface. Security vulnerabilities in popular plugins are discovered weekly — and many sites don’t apply updates promptly. A single vulnerable plugin can give an attacker access to the entire database, including every form submission you’ve ever received.

Shared hosting environments. Many small business websites run on shared hosting, where dozens of websites share the same server. A breach on any site on that server can potentially compromise yours. It’s the digital equivalent of storing confidential documents in a filing cabinet in a shared office building where you don’t control the front door.

No encryption at rest. Standard WordPress databases store data in plain text. If someone gains access to the database — through a backup that wasn’t secured, a hosting vulnerability, or a compromised admin account — they can read everything. Names, dates of birth, tax file numbers — all in plain text, ready to export.

No access controls. WordPress has basic user roles, but they weren’t designed for data security. An “editor” can typically access form submissions. There’s no concept of “this person can see inquiry forms but not application forms” or “this person can view applications but not download attached documents.” It’s all or nothing.

No audit trail. Who accessed what data, when? In a standard WordPress setup, you have no idea. If a breach occurs, you can’t determine what was accessed or by whom. Regulators and affected customers will want answers you can’t provide.

No automatic purging. Data that should have been deleted months or years ago is still sitting in the database. Every old submission increases your exposure. A breach doesn’t just expose current data — it exposes everything you’ve ever collected.

What Secure Data Handling Looks Like

If your business needs to collect sensitive data — and many legitimately do — it needs to happen in a system designed for it. That doesn’t necessarily mean expensive enterprise software. It means a purpose-built portal with the right security controls.

Encrypted storage. Data is encrypted at rest (in the database) and in transit (between the user’s browser and the server). Even if someone gains access to the raw database, they can’t read the data without the encryption keys.

Role-based access control. Different staff members see different data based on their role. The receptionist who schedules viewings can see tenant names and contact details but not their financial information. The property manager processing applications can see financial details but only for their assigned properties. Access is granted on a need-to-know basis.

Audit trails. Every access is logged. When someone views a tenant application, it’s recorded — who, what, when. If a breach occurs, you know exactly what was accessed. This isn’t just good security practice; it’s increasingly a regulatory expectation.

Automatic data purging. Data retention policies are built into the system. Applications that weren’t approved are purged after 30 days. Completed tenant records are archived and sensitive fields are redacted after the tenancy ends. You’re not holding data you no longer need, because the system removes it on schedule.

Separation from the public website. The portal where sensitive data is collected and stored is a separate system from the public website. Compromising the website doesn’t give access to the data portal. Different systems, different credentials, different attack surfaces.

The Cost of Getting It Wrong

Data breaches aren’t abstract risks. They carry concrete, quantifiable costs.

Direct costs. The Australian Notifiable Data Breaches scheme requires you to notify affected individuals and the OAIC if a breach involves personal information that’s likely to cause serious harm. The administrative cost of notification alone — identifying affected records, drafting notifications, handling inquiries — typically runs $50,000-$150,000 for a small business. That’s before any regulatory fines.

Legal exposure. Individuals affected by a breach can pursue compensation. A property management company that leaks tenant birth dates, tax file numbers, and financial documents is looking at potential claims from every affected tenant. The legal costs of defending those claims — even if you win — are substantial.

Reputational damage. How do you tell a property owner that their tenant’s personal data was leaked from your website? How do you tell prospective tenants that you take data security seriously when your last breach is searchable on Google? The trust that took years to build evaporates in a news cycle.

Operational disruption. A breach doesn’t just cost money — it consumes time. Staff spend weeks responding to the incident instead of doing their jobs. Systems get taken offline for investigation. Normal operations grind to a halt while you deal with the fallout.

For a property management company holding 500 tenant records with sensitive PII, a breach isn’t a bad day. It’s potentially a business-ending event. The maths is brutal: $100,000 in direct costs plus legal fees plus lost clients plus the months of operational disruption to recover. All because an application form was bolted onto a website that was built to show property listings.

This Isn’t Just Property Management

Any business collecting sensitive personal information through web forms faces the same risk profile.

Healthcare clinics collecting patient intake forms with medical histories, Medicare numbers, and health fund details through a WordPress plugin. The data sits in the same database as the blog posts about flu season tips.

Financial advisors receiving client statements of position through website upload forms. Tax returns, superannuation balances, bank account details — uploaded to a web server that the marketing agency also has access to.

Legal firms using website forms for initial client intake, collecting details about legal matters, personal circumstances, and financial positions. Information that’s not just sensitive but legally privileged, stored alongside the firm’s newsletter signup list.

Recruitment agencies collecting candidate applications with work history, salary expectations, references, and uploaded CVs containing home addresses and phone numbers. Thousands of records accumulated over years, never purged.

The common thread: the website was never designed for this. It was designed to attract visitors and generate inquiries. The sensitive data collection was added later, incrementally, without anyone stopping to ask whether the platform could protect what it was being asked to store.

Start Here This Week

1. Audit your forms. List every form on your website and what data each one collects. Flag anything that qualifies as sensitive PII.
2. Check your database. How many historical submissions are sitting in your website’s database? How far back do they go?
3. Review access. Who has admin access to your website? Does that list include former employees or contractors who no longer need access? Revoke what shouldn’t be there.
4. Assess your hosting. Are you on shared hosting? When were your plugins last updated? Do you have automatic backups — and are those backups encrypted?
5. Plan the migration. For your highest-risk forms, start scoping a move to a secure portal. The website keeps doing what it was built for. The sensitive data goes somewhere built to protect it.

Your website is a shopfront, not a vault. If it’s holding data that belongs in a vault, the question isn’t whether something will go wrong — it’s when. The fix isn’t complicated, but it does need to happen before the breach does.