Data minimisation is a design choice: collect the smallest useful amount of information, hold it only for a stated purpose, and dispose of it through a process that can actually finish. It cannot eliminate cyber risk, legal duties or operational needs. It can reduce the amount of information available to be exposed, misused, over-retained or carried into the next incident.
This article separates documented facts from questions each organisation should answer, and from EOV6's own product-design intentions.
The practical case for less
Fact: a smaller, well-defined data set gives an organisation fewer records to protect, fewer systems to synchronise and fewer copies to account for during an incident. Retention limits and deletion controls help only when they cover the real lifecycle: primary databases, uploads, logs, backups, exports, queues, error stores and supplier systems.
Opinion: “collect it now in case it is useful” is usually an expensive default. A better starting point is purpose first: what exact information is required for this interaction, who needs it, where will it go, and what event ends that need?
The value is not only privacy. Smaller data sets can simplify access reviews, investigation scope, retention administration and customer explanations. But minimisation is not a substitute for access control, resilient operations, staff training or incident response.
Retention is a decision, not an expiry label
A retention period should connect to a purpose, a recordkeeping obligation or a defensible operational need. An automatic expiry field that is never executed, a cleanup job without monitoring, or a deletion request that excludes downloads and backups is not the same as reliable disposal.
In Queensland, the Office of the Information Commissioner explains that Queensland Privacy Principle 11 requires agencies to destroy or de-identify personal information that is no longer needed for any purpose, subject to exceptions such as a legal requirement to retain it. The same guidance says de-identification must be permanent: the agency must not be able to re-identify the person by matching it with other records. Read the OIC's QPP guidance.
That is not a general “delete everything” instruction. The Public Records Act 2023 (Qld), section 23 makes disposal of a public record unlawful unless it is under a disposal authorisation or other legal authority, subject to the Act's terms. Legal holds, audit needs, fraud and security investigation, financial and employment obligations, safety records, and evidence needed to resolve a dispute can all change the answer.
Questions to ask:
- What is the documented purpose for each data element, rather than each database table?
- Which records must be kept by law, public-records rules, contract or a current legal hold?
- Is the retention period proportionate to that purpose, and when was it last reviewed?
- Can the organisation prove deletion across operational copies, retries, error paths, vendor systems and restores from backup?
- Who receives an exception report when deletion fails or a scheduled job does not run?
These are governance questions, not an allegation that a particular organisation has breached a duty or retained information for an improper reason.
A useful Queensland example: deletion can be conditional
The current Queensland Digital Identity (QDI) Privacy Collection Notice is a useful reminder that “delete my account” and “erase every related record now” are different requests. It says a person may request deletion or deactivation, but that deactivation stops further use and does not necessarily delete all QDI information immediately. It also says requests are assessed subject to recordkeeping, legal, operational and disposal requirements.
The same notice distinguishes among kinds of information:
- It says QDI may use an image for face matching with specific consent; that is different from a statement that every biometric input is retained indefinitely.
- It says QDI retains identity-verification outcomes, consent records and audit/security logs in the circumstances described in the notice; those retained results are not the same thing as retaining a copy of an identity document.
- After a Document Verification Service check, it says it does not store copies of identity documents, while it may store document type and number for as long as needed to prevent the document being used to create another QDI.
The notice describes general retention of QDI account information for at least seven years after the last transaction, with longer retention where required or authorised by law, and disposal under approved authorities after the applicable period. That example does not establish whether the period is proportionate in every context. It illustrates why a retention discussion needs to name the record, purpose and applicable authority instead of treating every piece of information alike.
What the October Genesys disclosure does — and does not — show
Fact: in its 19 October 2026 security update, Genesys said an unauthorised third party accessed certain internal business systems, including its learning management system and CRM. Genesys also said that its Genesys Cloud, Genesys Engage and Genesys Engage Cloud platforms were not compromised, and that there was no unauthorised access to the customer and partner environments or data stored or processed in those platforms.
The narrow lesson is not that a particular technology caused the incident, or that a particular category of data would have changed the outcome. The more grounded lesson is that internal business systems can contain valuable relationship and account information. Keeping collection and retention deliberate helps limit the set of information present in any system, while leaving room for records an organisation must keep.
What EOV6's current source code intends to do
Documented source behaviour: the current EOV6 repository has a server-side session-ending function that marks a session as closing, recursively removes its Firestore subcollections, deletes objects under the session's uploads/ and sessions/ storage prefixes, then removes the session document. It retains a small closed-code reservation so a six-digit code is not reused for a later session. There is also a protected cleanup endpoint intended to find stale sessions and optionally sweep orphaned storage prefixes.
That is an intended application design, not a verified end-to-end deletion guarantee for the deployed service. A session-ending operation can fail partway through; cleanup depends on protected invocation and operational monitoring; and a retained code reservation is not the same as retaining session content.
What has not been verified for this article: production log configuration and retention, backup and restore behaviour, every subprocessor's retention, cleanup scheduling and retries, failed-session handling in the live environment, and deployment parity between the repository and production. A source review alone cannot establish those matters. It would be inaccurate to say that EOV6 chat or uploads are verified as deleted at session end across all of those layers.
A measured standard
Data minimisation works best as an operating discipline:
- collect only what a named step needs;
- classify the record and its lawful or operational reason for retention;
- set a proportionate review date or disposal authority;
- make deletion observable, including exceptions and retries; and
- test the boundary cases — exports, logs, backups, uploads, failed sessions and suppliers.
The aim is neither alarm nor a simplistic promise of “no data retained.” It is a system in which people can see what is collected, why it remains, what is removed, and where the limits are.