Data retention policy

1. Purpose

This Data Retention Policy (“Policy”) establishes how REtelligent Pty Ltd and REtelligent EU SRL (collectively, “REtelligent”, “we”, “us”, or “our”) retain, archive, and dispose of personal data and business records across the REtelligent Platform (https://app.retelligent.co) and supporting systems.

The Policy implements the storage limitation principle (GDPR Art. 5(1)(e)), the Australian Privacy Principle 11.2 requirement to destroy or de-identify personal information once no longer needed, and the tax, employment, and evidentiary retention obligations applicable to both Group entities.

It sits alongside, and is cross-referenced by, the Privacy Policy, Cookie Policy, Privacy Request Form, Data Processing Agreement, Incident Response Plan, and Information Security Policy.

2. Scope

This Policy applies to:

•       All personal data processed by REtelligent as controller or processor in either jurisdiction, whether held in production systems, analytics platforms, backups, or archives;

•       All business records generated in the course of operating the Platform, including contracts, invoices, audit trails, and AI decision artefacts;

•       All employees, contractors, and sub-processors with access to REtelligent data (see Section 6 for roles).

It does not extend to data held by third parties (e.g., property operator systems) acting as independent controllers. Where REtelligent processes such data on the operator’s behalf, retention is governed primarily by the operator’s instructions and the applicable DPA, with this Policy acting as the minimum floor.

3. Controllers and Applicable Law

4. Guiding Principles

1.     Storage limitation (GDPR Art. 5(1)(e); APP 11.2): personal data is retained only for as long as necessary for the purposes for which it was collected, or for legal, regulatory, or evidentiary obligations.

2.     Data minimisation (GDPR Art. 5(1)(c); APP 3): the narrowest category of data necessary is retained; non-essential fields are purged before archival where possible.

3.     Purpose limitation (GDPR Art. 5(1)(b); APP 6): retained data is not re-purposed beyond the original lawful basis without separate authorisation.

4.     Integrity and confidentiality (GDPR Art. 5(1)(f); APP 11.1): retention media apply encryption at rest, least-privilege access, and tamper-evident logging consistent with the Information Security Policy.

5.     Accountability (GDPR Art. 5(2)): retention decisions, deletions, and holds are logged in a manner that allows REtelligent to demonstrate compliance.

6.     Harmonised floor-and-ceiling: where AU and EU rules diverge, REtelligent applies the stricter floor (e.g., longer tax retention) and the lower ceiling (e.g., shorter GDPR privacy-purpose retention) on a per-category basis, so that neither regime is breached.

5. Definitions

•       Retention Period — the total time personal data or a record is kept from the point the retention clock starts until authorised disposition.

•       Retention Clock Trigger — the event that starts the retention period (e.g., work-order closure, contract termination, last login).

•       Disposition — authorised action at end of retention: destruction, cryptographic shredding, de-identification, or archival transfer.

•       Legal Hold — a suspension of scheduled disposition where litigation, regulatory inquiry, or investigation makes preservation obligatory (see Section 10).

•       De-identification — processing under which the data no longer relates to an identified or reasonably identifiable individual (OAIC De-identification Decision-Making Framework; EDPB Guidelines 04/2024 on anonymisation). De-identification lifts data outside the retention clock but must be documented.

•       Cryptographic Shredding — destruction of encryption keys such that ciphertext is rendered unrecoverable; accepted destruction technique for object-store backed data (NIST SP 800-88 Rev. 1 “Purge” category).

6. Roles and Responsibilities

•       Data Protection Officer (REtelligent EU SRL) — owns this Policy in the EU, reviews material amendments, and is the escalation point for retention conflicts involving GDPR rights.

•       Privacy Officer (REtelligent Pty Ltd) — owns APP compliance, OAIC liaison, and routine policy updates in AU.

•       Head of Engineering — responsible for technical implementation: automated lifecycle rules (S3 lifecycle, DynamoDB TTL, Aurora partition pruning), deletion tooling, and audit evidence of disposition.

•       Head of Finance — owns retention of tax, invoice, and contract records under the Corporations Act, ITAA, and Romanian Accounting Law.

•       People & Culture — owns employee-record retention under the Fair Work Act and Romanian Labour Code.

•       All staff — must not create undocumented copies of personal data, must use Platform-sanctioned storage, and must raise any legal hold triggers to the Privacy Officer / DPO within 24 hours of awareness.

7. Retention Schedule

The Retention Schedule in Section 11 (landscape) sets out, for each data category:

•       Proposed retention period for REtelligent Pty Ltd (AU);

•       Proposed retention period for REtelligent EU SRL (EU);

•       Legal basis and citations supporting the period;

•       The event that starts the retention clock; and

•       The authorised disposition method.

Important: All periods in the Schedule are PROPOSED and subject to validation by qualified legal and tax counsel in both jurisdictions. Where the Schedule is silent on a category, the Privacy Officer / DPO must be consulted before any retention decision is made.

8. AI Triage and Automated Decision Artefacts

REtelligent operates AI triage and vendor-matching workflows that may, in isolation, meet the definition of “solely automated decision-making” under GDPR Art. 22 and may collect information relevant to an individual under APP 3.3. This category is treated under a tighter retention regime:

•       AI prompts and user-submitted free-text inputs: 12 months from submission, unless linked to an open maintenance record (in which case retained with the parent record).

•       AI triage decision logs (model version, input fingerprint, output recommendation, confidence, human-reviewer outcome): 24 months from decision, to support a reasonable Art. 22(3) contest window, bias monitoring, and SOC 2 CC3.2 change-management evidence.

•       Training and fine-tuning datasets: personal data is excluded by default and only included with documented lawful basis, a DPIA, and data-subject opt-in; retention aligns with the DPIA outputs.

•       Model artefacts (weights, embeddings): treated as potentially personal data per EDPB Opinion 28/2024 where they memorise identifiable inputs; retention reviewed annually against the minimisation principle.

Where a Data Subject requests human review of an automated decision (GDPR Art. 22(3); see Privacy Request Form Section C.1), the associated AI triage log must not be disposed of until the review is concluded and any appeal window elapsed, even if the 24-month period would otherwise lapse. This is implemented as an automatic “request hold” by the Privacy Request workflow.

Outputs of the AI triage that are actioned into a work order migrate to the maintenance-record retention rule (7 years) once the work order is created; the original prompt is independently subject to the 12-month rule.

9. Backups and Disaster Recovery

Operational backups retain residual copies of personal data beyond the primary retention period. The following rules balance resilience obligations (GDPR Art. 32(1)(c); SOC 2 A1.2; ISO 27001 A.8.13) with storage limitation:

•       Operational backups are retained on a rolling 35-day basis and are encrypted at rest with customer-managed keys.

•       Quarterly disaster-recovery snapshots are retained for 12 months before rotation.

•       Where a data subject exercises the right to erasure (GDPR Art. 17) or requests destruction under APP 11.2, primary deletion is executed immediately. Backups are not individually edited; instead, they age out on the rolling window, and a documented promise is made that any restore will re-apply the deletion before data re-enters production (Art. 29 WP Opinion 4/2007).

•       Backup destruction is by cryptographic shredding (NIST SP 800-88 Rev. 1 “Purge”).

•       Backups containing personal data subject to a legal hold are moved to a segregated, immutable hold-bucket on hold activation and are not rotated until release.

10. Legal Hold and Litigation Preservation

10.1 When a Legal Hold is triggered

A Legal Hold must be initiated as soon as reasonably practicable, and no later than 72 hours, after REtelligent becomes aware of any of the following triggers:

•       Commencement of, or credible threat of, litigation or arbitration involving REtelligent, an operator, a vendor, or a tenant;

•       Receipt of a subpoena, court order, search warrant, or preservation letter;

•       Notice of investigation or regulatory inquiry by OAIC, ANSPDCP, ATO, ANAF, ASIC, or any other competent authority;

•       A notifiable data breach that may give rise to civil claims (Privacy Act Part IIIC; GDPR Arts. 33-34);

•       Internal investigation into potential fraud, misconduct, or material policy breach;

•       Insurance claim that requires preservation of underlying evidence.

10.2 Who can issue a Legal Hold

A Legal Hold may be issued only by:

•       The Data Protection Officer (REtelligent EU SRL);

•       The Privacy Officer (REtelligent Pty Ltd);

•       The Head of Legal (or delegate); or

•       External counsel retained in the matter.

In urgent scenarios (e.g., active search warrant), any director may issue a provisional hold which must be ratified by one of the above within 24 hours.

10.3 Legal Hold Notice

The hold is effected through a formal Legal Hold Notice that records:

•       A unique reference (LH-[YYYY]-[####]);

•       The triggering event and date of awareness;

•       A defined scope of data (categories, custodians, date range, property or vendor identifiers);

•       Custodians placed on notice (named individuals and systems);

•       Override of retention: all scheduled dispositions within the hold scope are suspended, including automated lifecycle rules and backup rotation;

•       Acknowledgement requirement (each custodian acknowledges receipt within 5 business days);

•       Review cadence (hold re-affirmed at least every 6 months);

•       Expected release criteria.

10.4 Technical implementation

Engineering implements a Legal Hold by:

•       Tagging in-scope objects with a hold-metadata key (AWS S3 Object Lock in Governance or Compliance mode, as determined by the issuing officer);

•       Disabling lifecycle expiry and TTL-based purges on in-scope records in Aurora / DynamoDB;

•       Copying backups in scope to an immutable hold-bucket on hold activation;

•       Producing, on demand, an audit log proving no in-scope disposition occurred during the hold.

10.5 Interaction with data subject rights

A Legal Hold does NOT automatically override data subject rights. Instead:

•       Erasure requests (GDPR Art. 17; APP 11.2) during a hold are assessed against the Art. 17(3)(e) exemption (establishment, exercise, or defence of legal claims) and the corresponding APP 11.2 “required or authorised by law” carve-out. If the exemption applies, the requester is informed in writing, with reasons;

•       Access, correction, and portability requests continue to be processed normally, with any provided copy flagged as “subject to preservation; do not delete” in the Privacy Request workflow (see Privacy Request Form IU.5);

•       Where an erasure obligation ultimately prevails (e.g., successful appeal to ANSPDCP), Legal Hold scope is narrowed but other in-scope data remains preserved.

10.6 Release of a Legal Hold

A hold is released only in writing by the issuer (or successor). Release triggers:

•       A reconciliation pass: in-scope data is reviewed, documents not required are returned to normal retention (and disposed of where already past the scheduled date);

•       A final audit log entry is produced;

•       The LH reference is closed in the legal-hold register.

11. Retention Schedule

The Schedule is presented in landscape orientation on the following pages for readability.

RETENTION SCHEDULE

AU = REtelligent Pty Ltd  |  EU = REtelligent EU SRL

12. Disposition Methods

Where disposition is required, one of the following methods must be used and logged:

•       Secure deletion — record removed from primary datastore; storage pages overwritten per NIST SP 800-88 “Clear”; entry made in the Disposition Register.

•       Cryptographic shredding — per-object or per-bucket encryption keys destroyed; applicable to S3-resident objects and to backups per Section 9.

•       De-identification — identifiers removed or irreversibly transformed such that re-identification is no longer reasonably likely; methodology documented and reviewed by the DPO. De-identified data exits the scope of this Policy but remains in scope of the Information Security Policy.

•       Archival transfer — records transferred to cold storage with read-only access; retention clock continues to apply until final disposition.

13. Governance, Review, and Evidence

7.     This Policy is reviewed at least annually and on any material change to the product, applicable law, or sub-processor landscape.

8.     Retention periods in Section 11 are reviewed with external legal counsel in AU and RO at least every two years, or immediately upon legislative change.

9.     Quarterly: Engineering produces a Disposition Register extract confirming volumes of data disposed of per category.

10.  Semi-annually: the Privacy Officer / DPO reviews a sample of legal holds for continuing need.

11.  The Disposition Register, Legal Hold Register, and version history of this Policy constitute evidence for SOC 2 CC6.5/CC7.2, ISO 27001 A.5.34, and GDPR Art. 5(2) accountability.

14. Breaches of this Policy

Any breach of this Policy - including unauthorised retention, premature destruction, or failure to honour a Legal Hold - must be reported to the Privacy Officer / DPO within 24 hours. Confirmed breaches are treated as security incidents under the Incident Response Plan and, where they meet the thresholds in GDPR Art. 33 or Privacy Act Part IIIC, as notifiable events.

15. Cross-References

•       Privacy Policy (REtelligent - Privacy Policy V0.1 17Apr2026)

•       Cookie Policy (REtelligent - Cookie Policy V0.1 17Apr2026)

•       Privacy Request Form (REtelligent - Privacy Request Form V0.1 17Apr2026) - Section IU.5 (privacy request retention 3 years) aligns with Section 11 of this Policy.

•       Data Processing Agreement Template (Priority 1 item 3) - operator-held data retention must not undercut this Policy.

•       Information Security Policy (Priority 2 item 6) - controls for encryption, backups, and access governing retention media.

•       Incident Response Plan (Priority 2 item 7) - breach register retention (7 years) harmonised with Section 11.

•       Forthcoming DPIA (Priority 3 item 11) - governs AI-specific retention in conjunction with Section 8.

16. Contact

•       Email: privacy@retelligent.co

•       AU postal: The Privacy Officer, REtelligent Pty Ltd, Unit 2, 8A Judith Street, Carnegie VIC 3163, Australia

•       EU postal: Data Protection Officer, REtelligent EU SRL, [INSERT Romanian address]