Website enquiries often contain personal data, even when the form looks simple. A name, email address, phone number, company name, message content, uploaded files, IP address, and timestamp can all qualify as personal data under GDPR. For a hosting company, managed hosting provider, or website owner using a control panel such as Plesk, the key question is not only what you collect, but also what you really need to keep, where it is stored, who can access it, and how long it should remain available.
As a general rule, you should store only the enquiry data that is necessary to respond to the request, provide the service, or meet a legal obligation. Anything else should be minimised, restricted, or deleted on a clear retention schedule. This helps reduce compliance risk, improves security, and makes data handling easier to manage across forms, mailboxes, ticket systems, and backups.
What counts as website enquiry data
Website enquiries can arrive through contact forms, quote requests, support forms, callback forms, booking forms, or email links. In a hosting environment, the data may be stored in multiple places: form plugins, CMS databases, web application logs, mailbox archives, helpdesk systems, CRM tools, and server backups.
Common types of data collected through enquiries include:
- Full name
- Email address
- Phone number
- Company or organisation name
- Job title or department
- Message text and attachments
- IP address and browser metadata
- Date and time of submission
- Preferred contact method
- Any special category data the user chooses to include, such as health or payment-related information
Even if you do not ask for sensitive data, it may still appear in free-text fields. For that reason, enquiry forms should be designed to request only the minimum necessary information.
What should you store from website enquiries
The safest approach is data minimisation. Store only the fields that are needed to answer the enquiry, keep evidence of consent where relevant, and retain records only for as long as there is a clear purpose.
Usually safe and necessary to store
- Contact details needed to reply, such as name and email address
- The enquiry itself, if it is required to resolve the request
- Date and time of submission
- The source page or form used, if needed for troubleshooting or auditing
- Consent records or privacy notice version, if the form relies on consent
- Internal reference numbers for support or sales tracking
Only store if you have a specific reason
- Phone number, if a callback is genuinely required
- Company size, budget, or technical details, if relevant to the service
- Attachments, if they are necessary for quotation, support, or contract processing
- IP address, if needed for security, abuse prevention, or fraud handling
Usually best not to store
- Unnecessary identifiers such as full postal address for a simple contact request
- Notes about preferences unrelated to the enquiry
- Sensitive personal data entered accidentally into free-text fields
- Duplicate copies of the same enquiry in multiple systems without purpose
- Old form submissions kept indefinitely “just in case”
If you use a managed hosting platform, check whether the form data is stored in the CMS, sent by email only, or also saved in the hosting control panel, database backups, or application logs. The more locations you store it in, the harder retention and deletion become.
How long should you keep enquiry data
There is no single retention period that fits every business. Under GDPR, data should be kept no longer than necessary for the purpose for which it was collected. In practice, retention depends on the type of enquiry, whether a contract follows, whether the message is needed for customer service, and whether legal or accounting rules apply.
A useful way to think about retention is by enquiry type.
General contact enquiries
For simple “contact us” messages, keep the data only as long as needed to respond and close the conversation. If there is no further business need, delete or anonymise the record within a short period, such as a few weeks or a few months, depending on your workflow.
Sales or quote requests
If the enquiry may lead to a contract, you may need to retain the data longer for follow-up, negotiation, and proof of what was requested. If the lead does not convert, set a shorter retention period and delete the data once the sales process ends and no further legitimate interest exists.
Customer support requests
Support cases often need longer retention because the same issue may recur, a customer may refer back to the conversation, or the record may be needed for accountability. Keep the enquiry data for the duration of the support case and for a limited period afterwards, based on your internal policy and any legal requirements.
Contract and billing related enquiries
If the enquiry becomes part of a contract, invoice, or service record, retention may be governed by commercial, tax, or accounting rules rather than by the original form submission purpose. In this case, separate the enquiry record from the financial or contractual record where possible, and apply the appropriate retention rule to each.
Enquiries containing complaints or disputes
Where the message may relate to a complaint, dispute, or legal claim, keep the record until the matter is resolved and any limitation period has expired. This is one of the few situations where longer retention may be justified.
Recommended retention approach for hosting and website forms
For a hosting company, a practical retention model should cover the entire data flow: form submission, mailbox delivery, ticketing, control panel storage, database records, logs, and backups.
1. Define the purpose of each form
Every form should have one clear purpose. For example:
- Contact form for general enquiries
- Support form for technical issues
- Quote form for sales requests
- Callback form for urgent follow-up
When the purpose is clear, retention rules become easier to justify and document.
2. Map where the data is stored
In a typical hosting environment, form data may be copied into:
- The website CMS database
- Form plugin storage
- Mailbox inboxes and archives
- Helpdesk or CRM systems
- Web server logs or application logs
- Backup snapshots
Make sure each storage location has a retention rule. Deleting the record in one system does not automatically remove copies from every other system.
3. Set a retention period by category
Use a simple internal schedule, for example:
- General enquiries: delete after the case is closed and no later than a short defined period
- Sales leads: delete after a defined follow-up window if no contract is created
- Support cases: retain for the period needed for service history and dispute handling
- Contract-related records: retain according to legal and accounting obligations
Keep the schedule documented so staff can apply it consistently.
4. Separate active records from archives
Do not leave old enquiries in active inboxes or open tickets forever. Move records into an archive with restricted access or remove them entirely when retention ends. Archiving is not a substitute for deletion unless there is still a valid business reason to keep the data.
5. Delete data from backups where feasible
Backups are often overlooked. In many hosting setups, deleted form data may still exist in backup files until those backups expire. That is acceptable if backups are secured and not used for routine access, but the backup retention period should be limited. Document how long backups are kept and how restoration is handled if deleted data reappears temporarily during recovery.
How to reduce data collection on contact forms
The best way to manage enquiry data safely is to collect less in the first place. This is especially relevant for websites hosted on WordPress, Joomla, Drupal, or similar platforms where form plugins can easily be overconfigured.
Use only essential fields
For many enquiries, a name, email address, and message are enough. Add extra fields only if they are needed to process the request.
Avoid open-ended free-text questions unless required
Free-text fields can lead users to share more data than necessary. Use structured fields, dropdowns, or checkboxes where possible.
Do not ask for sensitive personal data unless strictly necessary
If a form might collect sensitive data, redesign it. Sensitive data requires a stronger legal basis, tighter security, and stricter handling.
Explain why data is requested
Short help text under each field can reduce unnecessary submissions. For example, “We need your phone number only if you want us to call you back.”
Security measures for stored enquiry data
Retention is only one part of the obligation. Data stored from website enquiries must also be protected properly. For hosting environments, good security controls should cover both the application and the server layer.
- Use TLS/HTTPS for all form submissions
- Restrict access to mailboxes, databases, and helpdesk queues
- Apply strong passwords and multi-factor authentication in the control panel
- Keep CMS, plugins, and server software updated
- Limit admin access to staff who need the data for their role
- Encrypt backups where possible
- Log administrative access to stored enquiry records
- Remove test forms and staging copies that contain real data
If you use Plesk or a similar hosting control panel, review permissions for website directories, database users, email accounts, and backup storage. A form may be secure in the browser but still exposed through a misconfigured mailbox, database dump, or shared admin account.
Special points for form plugins, mailboxes, and control panels
Website enquiries are often handled through a combination of web forms and email. This creates several storage points that should be reviewed together.
Form plugins and CMS databases
Some plugins store all submissions in the database by default. If you do not need that feature, disable it or limit storage to a short period. If you do need it, create a cleanup routine and confirm how records are removed.
Mailbox storage
If enquiry messages are sent by email, they may remain in inboxes, sent folders, archives, and backups long after the business purpose has ended. Apply mailbox retention policies and delete old threads that are no longer needed.
Helpdesk or CRM systems
When enquiries become support tickets or sales leads, define when the case is closed and when the data should be deleted. Closed tickets are often kept too long because they are useful, but usefulness is not the same as necessity.
Server logs
Web server logs may contain IP addresses, request paths, and submission data if the form is not configured correctly. Logs are important for security and troubleshooting, but they should be rotated and retained for a short, documented period.
Legal basis and accountability
For EU websites, every enquiry form should have a clear legal basis. In many cases, processing is based on legitimate interest or pre-contractual steps, rather than consent. Consent may still be appropriate for optional marketing follow-up, but it should not be mixed with the main purpose of answering the enquiry.
To stay accountable, keep internal documentation showing:
- What each form is for
- What data fields it collects
- Why each field is necessary
- Where the data is stored
- How long it is retained
- Who can access it
- How it is deleted
This documentation is useful not only for GDPR compliance, but also for support teams, hosting administrators, and anyone maintaining the website over time.
Practical retention examples
Here are a few examples of how this can work in practice.
Example 1: basic contact form
A visitor sends a message asking for information about managed hosting plans. The website stores their name, email address, message, and timestamp. Once the enquiry is answered and no follow-up is needed, the record is deleted after a short retention period.
Example 2: support form for a hosting customer
A customer submits a technical issue through the helpdesk form. The ticket includes website access details, logs, and communication history. The record is kept until the case is resolved and then retained for a limited period in line with support and dispute-handling needs.
Example 3: quote request with business details
A company asks for a migration quote and provides site size, CMS type, and expected traffic. The data is kept while the quote is active. If no contract follows, the lead is deleted after the follow-up period ends.
How to build a simple deletion process
Retention rules only work if they are applied consistently. Set up a repeatable process so old enquiry data does not remain in the system by accident.
- Identify all systems that store enquiry data
- Set a retention period for each form type
- Assign responsibility to a team or administrator
- Schedule regular reviews, such as monthly or quarterly
- Delete or anonymise records that are no longer needed
- Check that deletions also apply to exports, archives, and local copies
- Review backup expiry so deleted data does not persist too long
For larger hosting platforms, automation can help. For example, ticket systems can close and purge records automatically after the retention window, and database cleanup tasks can remove old form submissions.
FAQ
Do I need to keep every website enquiry forever?
No. Under GDPR, you should keep enquiry data only for as long as it is needed for the purpose for which it was collected, unless a legal obligation requires longer retention.
Is an email inbox a safe place to store enquiry data?
Not by itself. An inbox may be suitable for receiving enquiries, but it still counts as stored personal data. Apply access controls, mailbox retention rules, and deletion procedures.
Should I store enquiry forms in the website database?
Only if you need to. If the form data is stored in the database, make sure there is a clear retention schedule and a way to delete old submissions securely.
What if a user includes sensitive data in the message field?
If sensitive data is not needed, delete it as soon as possible and update the form design to discourage such submissions. You should also review whether your privacy notice and security controls are adequate.
Do backups have to be deleted immediately when a form submission is deleted?
Usually not immediately, but backup retention should be limited and documented. Deleted data should not remain in active systems, and backups should expire according to policy.
How does this apply to a hosting control panel like Plesk?
In Plesk or similar panels, enquiry data may be stored across mailboxes, databases, website files, and backups. Review retention for each layer, not just the form plugin itself.
Conclusion
For website enquiries, the right approach is to store the minimum data needed, for the shortest time needed, in as few places as possible. In a hosting or managed hosting environment, that means checking forms, mailboxes, databases, control panel accounts, logs, and backups together. A clear retention policy, combined with access control and regular cleanup, reduces risk and makes GDPR compliance much easier to maintain.
If you manage websites for EU users, treat every enquiry form as a data-handling process, not just a contact feature. That mindset helps you decide what to store, how to protect it, and when to delete it.