Retention and minimization principles
NEXEFII seeks to retain personal data only for as long as necessary for the purposes for which it was collected, the operational requirements of the platform, and applicable legal obligations.
We follow the principle of minimization: collect the least necessary, limit access by role (RBAC), and reduce the exposure of sensitive data wherever possible.
Retention periods by category
The specific retention periods by data category — for example, account data, operational records, audit logs, and acceptance evidence — are the periods defined in the Data Retention and Deletion Policy, still pending legal and DPO review.
We do not publish definitive periods until they are confirmed, so as not to assert unverified commitments.
Deletion on request or termination
Upon a legitimate request from the data subject or the customer, and at the end of the contractual relationship, NEXEFII carries out deletion or anonymization of the applicable personal data, subject to legal exceptions that require retention.
Some information may need to be kept for an additional period to comply with legal obligations, defend rights, or serve audit and accountability purposes, as detailed in the Privacy Policy.
Retention of acceptance and audit evidence
Evidence of acceptance of legal documents and audit trails are preserved for accountability purposes and to demonstrate consent and acceptance over time.
The platform's audit trails are immutable by design, which supports the integrity of that evidence.
Minimization of IP addresses in acceptance evidence
In legal-acceptance evidence, IP addresses are minimized: they are truncated or hashed before being recorded, and are not stored in raw (full) form.
This handling reduces the exposure of potentially identifiable data while preserving sufficient technical evidence that acceptance occurred.
Backups
Backups may retain data for a period beyond deletion in the active systems, due to technical backup and restore cycles.
Data present in backups is overwritten or expires according to rotation cycles; in the meantime, it remains subject to the applicable access and security controls.
Contact
Deletion requests or questions about data retention may be sent to contact@nexefii.com.
Tenant lifecycle and retention
The tenant lifecycle policy defines the following states: ACTIVE, SUSPENDED, EXPORT_WINDOW, ARCHIVED, RESTORABLE, DELETION_SCHEDULED, DELETED, and LEGAL_HOLD. These states describe the policy target, and not all of them correspond to already-implemented automated mechanisms.
On cancellation, we cease new operational processing. An export window is offered per the configured policy, so that data can be retrieved during that period. Once the window closes, data is removed from the operational environment and the tenant is archived in a segregated and protected manner (this segregated archive is a policy target, not a claim that an isolated cold archive already exists).
The "up to five years" figure is a MAXIMUM Master Control policy limit, not a uniform mandatory retention for every category; effective retention is applied through a per-category matrix, identified as the periods defined in the Data Retention and Deletion Policy. Credentials, sessions, tokens, and secrets are not restored. A legal hold suspends deletion only with justification.
Valid deletion requests are evaluated per contract and applicable law. Backups have their own purge cycle, distinct from deletion in the active systems. Where applicable, a notice is issued before final deletion. Reactivation, where possible, requires the same organization, validated authority, a new subscription, the same or compatible modules, compatibility verification, and an audited restore.
We do not promise restoration of integrations, tokens, sessions, or transient data, nor eternal availability. Restoration, when it occurs, is an audited process subject to verification, not an unconditional technical guarantee.
Current implementation status (honest)
To be honest: today Master Control implements a logical tenant status (active, inactive, suspended, and archived) in the SAME operational database, with an audited archive transition (event TENANT_ARCHIVED). We do not claim the existence of a segregated cold archive.
Hard delete/purge, a segregated cold archive, an automated export window, an automated retention timer, and an automated restore flow are NOT yet implemented; they are future phases. The policy states above describe the intended target, not capabilities already available.
It is important to distinguish four concepts: (i) logical retention — the data remains in the operational database under a status such as archived; (ii) segregated archive — storage isolated from the operational environment, not yet implemented; (iii) backup — backup copies with their own purge cycle; and (iv) restore — returning a tenant to operation, today carried out manually and in an audited manner, with no automated flow.