Keep what remains necessary. Remove what no longer should.

This Data Retention Policy explains how KOMERRA Technologies Limited determines how long information is kept, when a retention period begins, what happens when the period ends, and why some limited records may remain after an Account, Workspace, file, or business record has been deleted.

The Policy applies to personal data, Business Content, Account records, Workspace records, files, documents, communications, AI-assisted processing, support information, security records, billing information, payment references, audit events, monitoring data, provider records, and protected backups within KOMERRA’s control.

Retention is based on the purpose, information category, lawful basis, contractual requirement, security risk, accounting requirement, dispute status, provider dependency, and applicable law rather than one indefinite period for every record.

This Policy should be read together with the Privacy Policy, Account Deletion Policy, Terms of Service, Data Processing Agreement, Cookie Policy, Subprocessors page, Security & Trust page, Refund and Cancellation Policy, and Responsible AI framework.

KOMERRA is operated by KOMERRA Technologies Limited, a company registered in the Federal Republic of Nigeria with registration number 9681120.

Questions about retention, deletion, restriction, legal holds, backups, or a particular data category may be sent to support@komerra.app.

Use “Data Retention Question” in the subject for a general enquiry.

Use “Privacy Request” where you are requesting access, correction, erasure, restriction, objection, portability, consent withdrawal, or another personal-data right.

“Retention period” means the time for which a category of information remains stored or otherwise available for a stated purpose.

“Retention trigger” means the event from which a retention period is calculated, such as Account creation, last activity, transaction completion, case closure, contract termination, Workspace deletion, credential revocation, or expiry of a legal hold.

“Active data” means information used in the ordinary operation of an Account, Workspace, feature, transaction, integration, or support relationship.

“Restricted data” means information retained for a narrow purpose but no longer available for ordinary product use.

“Deletion” means removal of information from active systems or another process that makes the information unavailable for ordinary use.

“Anonymization” means processing information so that it can no longer reasonably be linked to an identified or identifiable person.

“Pseudonymization” means replacing direct identifiers while retaining separately protected information that could allow re-identification under controlled circumstances.

“Legal hold” means a temporary instruction preserving information that may otherwise have been deleted because it is relevant to a legal claim, investigation, regulatory requirement, dispute, or similar obligation.

“Retention Schedule” means the controlled record identifying information categories, purposes, systems, triggers, periods, deletion methods, owners, exceptions, and review requirements.

KOMERRA keeps information only while it supports a specified and legitimate service, security, contractual, legal, accounting, fraud-prevention, dispute-resolution, or customer-instruction purpose.

Information is not retained indefinitely merely because storage is inexpensive or deletion requires additional engineering work.

Retention should be proportionate to the sensitivity of the information, the potential harm created by unnecessary storage, and the continuing reason for keeping it.

Where only part of a record remains necessary, unnecessary identifiers, attachments, content, or fields should be removed, anonymized, or restricted where reasonably possible.

KOMERRA determines a retention period by considering the purpose of processing, contractual relationship, sensitivity of the information, user expectations, legal requirements, accounting obligations, fraud and security risks, limitation periods, provider restrictions, dispute history, deletion capability, and whether the information can be minimized.

Where a specific period is imposed by applicable law, regulation, court order, contract, or provider requirement, that period may govern the relevant record.

Where an exact period cannot reasonably be stated, KOMERRA may describe the criteria used to determine it.

The period must be reviewed if the processing purpose changes materially.

A record should not be moved to a new system or category merely to avoid its applicable deletion requirement.

Where personal data is no longer required for its original purpose and no time-bound legal obligation or other documented lawful ground justifies continued retention, KOMERRA applies the storage-limitation rule required by the applicable Nigerian data-protection framework.

In those circumstances, the remaining personal data should be deleted, anonymized, or otherwise removed no later than six calendar months after the original processing purpose has been accomplished.

The six-month period is not a universal retention period for all KOMERRA information. It is a maximum post-purpose period where no different time-bound legal obligation or lawful exception applies.

A record may remain longer where it is still required for an active service, contractual obligation, legal duty, accounting requirement, security investigation, fraud prevention, legal claim, due diligence, dispute, or another lawful purpose.

Any exception must remain limited to information reasonably necessary for the documented purpose.

KOMERRA maintains or should maintain an internal Retention Schedule connecting each information category to the systems in which it appears, the retention trigger, applicable period, deletion method, owner, provider dependency, backup treatment, and permitted exceptions.

An exact public retention period should be published only after it has been verified against production databases, object storage, queues, caches, logs, monitoring services, AI providers, support systems, payment providers, and backup configuration.

A period written in a policy but not enforced in production is not a reliable retention control.

Where KOMERRA has not yet verified a precise period for a category, this Policy describes the applicable purpose and criteria rather than inventing a number.

Planned retention controls must not be represented as already operating until the corresponding jobs, lifecycle rules, access restrictions, provider instructions, and tests have been confirmed.

Account profile information generally remains available while the Account is active because it supports authentication, user preferences, notifications, support, security, Workspace access, and service continuity.

Account information may include the user’s name, email address, telephone number, avatar, locale, preferences, verification status, notification settings, and related profile fields.

Information that is no longer required for the Account should be corrected, removed, or minimized rather than retained merely because the Account remains active.

Inactive Accounts may be reviewed according to the last meaningful activity, remaining Workspace responsibilities, Credits, unresolved disputes, security risk, and applicable deletion rules.

Account closure begins the deletion or anonymization process described in the Account Deletion Policy.

Active session information is retained only while required to maintain, rotate, revoke, investigate, or secure the session.

Expired or revoked access tokens should not remain usable after their validity or revocation period.

Refresh-token records, session families, device associations, passkey credentials, multi-factor settings, recovery controls, and authentication events may be retained for the period necessary to operate and protect the Account.

A limited history of authentication events may remain after session expiry where needed to investigate unauthorized access, suspicious credential reuse, Account compromise, or security incidents.

Authentication secrets that are no longer valid should be securely deleted or rendered unusable rather than retained as ordinary historical content.

Password hashes remain only while the associated password credential is active or while a narrow security reason requires temporary restricted preservation.

Plain-text passwords must not be retained.

Passkey public-key credentials and associated metadata remain while the passkey is registered to the Account.

Raw fingerprint and facial-recognition templates used by a device’s ordinary biometric authentication are generally retained by the device or operating-system provider rather than KOMERRA.

Multi-factor secrets, backup codes, recovery codes, and similar credentials are revoked and deleted or rendered unusable when the method is removed or the Account is permanently deleted.

Security events showing that a credential was added, changed, revoked, or used may remain in minimized audit records.

Customers, products, orders, inventory records, business preferences, documents, reminders, activity, staff records, reports, and approved Business Memory generally remain while the Workspace is active because continuity and historical context form part of the service.

The Workspace owner may delete or correct eligible records through available controls, subject to permissions, legal duties, shared records, audit integrity, and other people’s rights.

A deleted operational record may leave a narrow audit or financial reference where necessary to preserve accountability, prevent fraud, maintain ledger integrity, or comply with law.

Workspace records should not remain active indefinitely after the Workspace has been deleted or transferred out of KOMERRA.

Workspace deletion follows the process described in the Account Deletion Policy.

Customer names, contact details, addresses, preferences, notes, order history, communications, balances, and related records remain while the business has a legitimate operational or legal reason to keep them.

A business is generally responsible for determining how long its customer information should remain in the Workspace.

KOMERRA processes customer information according to the business’s documented instructions, applicable law, and the Data Processing Agreement where KOMERRA acts as processor.

Customer records should be corrected, deleted, anonymized, or restricted when the business no longer has a lawful and necessary purpose for retaining them.

A customer’s request to a business may require the business to preserve transaction information while removing unrelated marketing, profile, or communication data.

Order records may remain while necessary for fulfilment, delivery, refunds, warranties, customer support, accounting, tax, dispute resolution, fraud prevention, legal claims, and business reporting.

A completed order should not be retained forever solely because it is historically interesting.

The relevant business is responsible for determining which transaction records it is legally required to retain.

Where a transaction record must remain, unnecessary personal details should be minimized where practical.

Deleting an order from ordinary product views does not necessarily erase associated financial, audit, dispute, or security evidence that remains subject to a separate lawful retention requirement.

Active product, service, price, stock, supplier, and inventory records remain while used by the business.

Historical inventory movements may be retained longer than current catalogue content where required to explain stock changes, orders, returns, adjustments, or suspected manipulation.

Deleted product images, descriptions, and inactive listings should be removed when they no longer support an active order, legal obligation, dispute, or other documented purpose.

Aggregated inventory trends may remain after underlying identifiers have been removed where they can no longer reasonably identify a customer or other individual.

Invoices, quotations, receipts, delivery notes, reports, exports, templates, and related metadata remain while the business requires them for active service, customer support, accounting, tax, legal, or contractual purposes.

Generated documents may contain customer and business information governed by different retention requirements.

A document previously downloaded, printed, emailed, or sent through a connected channel may remain with its recipient after the KOMERRA copy has been deleted.

Deletion of a document should address the database record, generated file, object-storage copy, search entry, cache, and applicable provider copy where those systems are within KOMERRA’s control.

Documents retained only for legal or accounting reasons should be restricted from unrelated product or marketing use.

Uploaded logos, avatars, product images, attachments, receipts, payment evidence, identity documents, and other files remain while required by the associated Account, Workspace, record, verification, dispute, or service purpose.

Deleting a database record should not leave an unnecessary private file indefinitely in object storage.

Object-storage lifecycle rules and deletion jobs should identify unreferenced, abandoned, expired, or deleted files.

Temporary upload objects should expire where the upload was never completed or attached to an authorized record.

Private signed links may expire before the underlying file retention period ends.

Files subject to a legal hold, fraud review, security incident, or payment dispute may be moved to restricted preservation rather than left in ordinary user access.

Screenshots, transfer receipts, debit alerts, teller images, and other payment evidence may be retained while required to investigate, reconcile, dispute, or document the claimed payment.

Uploaded payment evidence is not authoritative proof that funds settled.

Once the payment issue is resolved and no accounting, fraud, security, legal, or dispute purpose remains, unnecessary evidence should be deleted or minimized.

Sensitive unrelated transactions visible in an uploaded statement or screenshot should not be retained where a narrower record is sufficient.

Businesses should avoid requesting or retaining excessive financial information merely to confirm one transaction.

Mini Store products, business information, policies, payment instructions, customer-facing pages, cart information, and order records remain while the Mini Store and related Workspace are active.

Removed listings may remain temporarily in restricted records where needed for an active customer order, complaint, refund, fraud review, or legal claim.

Customer Account and order information should follow the retention purposes applicable to the seller’s transaction and privacy obligations.

Public Mini Store content is removed from active KOMERRA publication when the relevant Workspace is deleted.

Search engines, social networks, browser caches, and third-party copies may retain previously public information outside KOMERRA’s direct control.

Published business details, verification indicators, policies, activity signals, and Trust Passport information remain while the Trust Passport is active and the information remains accurate and authorized.

Outdated or revoked verification indicators should not remain publicly displayed merely because the original verification record still exists.

Verification evidence may have a shorter or more restricted retention period than the public verification result.

A limited record that a check occurred may remain where required for fraud prevention, regulatory accountability, disputes, legal claims, or prevention of repeated verification abuse.

Public Trust Passport pages are removed from active publication when the relevant Workspace is deleted or the page is disabled.

Identity documents, business-registration information, facial images, liveness results, verification references, NIN-related information, and provider results are retained only for the verified and documented purpose.

Full identity evidence should not be retained merely because a limited verification result is sufficient.

Where practical, KOMERRA should retain the minimum verification outcome, date, provider, reference, and status rather than the complete underlying document.

Verification information may remain longer where necessary to investigate fraud, prevent repeated abuse, defend a legal claim, satisfy a regulatory duty, or demonstrate that a required check occurred.

Sensitive verification data must remain access restricted and must not be used for ordinary marketing or public Trust Passport display.

Provider-side retention is governed by the applicable provider agreement, legal duties, and deletion instructions.

Approved Business Memory may remain while the Workspace is active because persistent business context is part of the service.

Business Memory should distinguish approved or authoritative facts from temporary model interpretation, unverified extraction, or speculative Output.

A user should be able to correct or remove eligible retained context where the product supports it.

Sensitive information should not be retained in Business Memory merely because it appeared in a conversation, prompt, file, or temporary processing result.

Business Memory associated solely with a deleted Workspace should be deleted or anonymized according to the Account Deletion Policy.

AI inputs, prompts, messages, images, documents, voice notes, retrieved context, Outputs, classifications, extractions, drafts, and recommendations are retained according to the purpose of the applicable workflow.

Temporary AI-processing content should not remain indefinitely after the processing, validation, support, safety, or troubleshooting purpose has ended.

An approved business record created through an AI workflow follows the retention rule for the resulting customer, order, document, payment record, message, or other business object.

Rejected or abandoned AI drafts should have a shorter retention purpose than approved operational records unless they remain necessary for security, quality investigation, billing, or a user-selected history.

AI-provider retention must be considered separately from KOMERRA’s own application retention.

Safety blocks, prompt-injection indicators, tool denials, validation failures, corrections, rejected Outputs, and recurring error patterns may be retained where necessary to evaluate and improve guarded AI workflows.

Evaluation records should contain the minimum information needed to reproduce or understand the issue.

Private Workspace content should not be retained indefinitely for general model evaluation merely because it was involved in a failure.

Where a representative example is necessary for investigation, identifiers should be removed or reduced where practical.

Records connected to a material AI incident may be retained under the security-incident or legal-hold rules.

Voice notes, audio, transcripts, translations, and extracted details remain according to the purpose for which they were submitted and the resulting business record.

A temporary transcript used only to extract an approved order should not automatically receive the same retention period as the final order unless the source remains necessary for review, correction, dispute, or evidence.

Original audio may be deleted earlier than an approved structured record where the business no longer requires it.

Provider copies should be handled according to the applicable AI, speech, or translation provider’s retention terms and KOMERRA’s instructions.

Authorized messages, message drafts, connected-channel content, email records, SMS records, and communication metadata remain while necessary for the business workflow, customer relationship, support, delivery evidence, security, or dispute handling.

KOMERRA does not control how long a recipient, messaging provider, email provider, social platform, or telephone provider retains a delivered message.

Message content imported from a connected provider should not remain after the connection, business purpose, and lawful retention need have ended.

A business is responsible for configuring and applying suitable retention rules to customer communications it controls.

Deleting a message from KOMERRA does not retract a message already delivered externally.

Delivery status, provider identifiers, timestamps, recipient references, rejection reasons, and error information may be retained after message content is deleted where needed to explain whether a communication was accepted, delivered, failed, blocked, or retried.

Delivery logs should contain no more message content than is necessary for troubleshooting and accountability.

Authentication secrets, full message bodies, and unrelated customer information should not be included in ordinary delivery logs.

Provider logs remain subject to the provider’s own retention practices and applicable agreements.

Support tickets, correspondence, attachments, diagnostic information, and case notes remain while a request is open and for a reasonable period after closure for follow-up, quality control, dispute handling, security, and accountability.

A routine resolved support request should not automatically receive the same retention period as a fraud investigation, privacy complaint, payment dispute, or security incident.

Unnecessary attachments, identity information, screenshots, and Business Content should be removed when they no longer support the case.

Support records connected with legal claims, regulatory enquiries, chargebacks, security incidents, or privacy requests may remain under the applicable exception.

Users should not submit passwords, one-time passwords, bank PINs, card security codes, recovery codes, private keys, or unrelated private information to support.

Records of access, correction, deletion, restriction, objection, portability, consent withdrawal, and other privacy requests may be retained to demonstrate how the request was received, verified, assessed, and completed.

The retained record should contain the minimum identity and evidence necessary for accountability and dispute handling.

A request to delete personal data does not necessarily require deletion of the evidence showing that KOMERRA fulfilled the deletion request.

Verification documents supplied solely for the request should be removed when the verification and any applicable challenge period have ended unless another lawful reason applies.

Login failures, Account lockouts, session activity, credential changes, passkey changes, multi-factor events, suspicious requests, malware detections, access denials, and related security events may be retained longer than ordinary content.

These records support detection of abuse, investigation of compromise, protection of Accounts, correlation of incidents, and defense of legal claims.

Security records should be protected from ordinary Workspace access and limited to authorized security, support, compliance, or engineering purposes.

A security event should not contain full passwords, authentication tokens, private keys, or unnecessary Business Content.

When the security purpose and any related dispute or legal need end, the record should be deleted, anonymized, or reduced.

Audit records may identify who performed a sensitive action, the affected Workspace or resource, the action, time, result, and relevant request or event reference.

Audit records may remain longer than the ordinary record they describe where necessary to preserve accountability, financial integrity, access history, security, or legal claims.

Deletion of an Account may replace the user’s direct identifiers in retained audit records with a neutral or pseudonymous reference.

Audit logs must not be retained indefinitely without a documented purpose and review.

Access to sensitive audit records should itself be attributable and restricted.

Records of privileged administrative, support, security, verification, billing, and enforcement actions may be retained to demonstrate who accessed or changed protected information and why.

The record may include the acting administrator, affected Account or Workspace, reason, action, scope, time, and result.

Administrative-access records should remain separate from ordinary marketing and product analytics.

Where an administrative action relates to a security incident, fraud review, legal matter, or payment dispute, the applicable longer retention purpose may apply.

Credit purchases, promotional allocations, deductions, restorations, refunds, adjustments, balances, action charges, and ledger references may be retained for accounting, reconciliation, fraud prevention, customer support, dispute handling, and financial integrity.

Credit-ledger records may remain after an Account or Workspace closes where deletion would undermine financial records, refund evidence, chargeback response, or transaction integrity.

Retained ledger records should minimize unnecessary profile and Business Content information.

Purchased Credits and Promotional Credits should remain distinguishable in the ledger so their different financial and retention treatment can be applied correctly.

Billing information is not used for unrelated marketing merely because it has a longer lawful retention period.

Provider references, transaction status, amount, currency, payment method category, timestamps, reconciliation results, refund status, chargeback information, and related payment records may remain for accounting, fraud prevention, dispute handling, and legal compliance.

These references help prevent the same provider event from creating duplicate Credits or paid entitlement.

KOMERRA should not retain full card numbers, card security codes, bank PINs, one-time passwords, or equivalent payment credentials in ordinary platform records.

Payment providers may retain independent records according to their own legal obligations and agreements.

Deletion of a KOMERRA Account does not require a bank or payment provider to delete information it independently controls.

Idempotency records may be retained after the immediate request has completed where necessary to prevent duplicate financial, messaging, document, order, or provider effects.

The record should contain only the identifiers, status, result reference, expiry, and other information necessary to recognize the duplicate operation.

Idempotency records should not become an indefinite copy of the full request or response payload.

Different idempotency periods may apply according to the provider’s retry behaviour and the consequence of duplicate processing.

Refund requests, payment reviews, chargebacks, provider reversals, unauthorized-payment reports, evidence, correspondence, and decisions remain while the matter is open and for the period needed to defend or enforce the outcome.

Dispute records may remain longer than ordinary support records because payment-provider or legal challenge periods may continue after the support case appears closed.

Unrelated payment credentials and private transactions should be removed from submitted evidence where they are not necessary.

A resolved dispute should not justify indefinite unrestricted retention of all Account and Workspace content.

Cookies, local storage, device identifiers, analytics identifiers, consent records, and similar technologies follow the purpose and period described in the Cookie Policy or consent interface.

Essential security and session technologies may have different periods from analytics, preference, or advertising technologies.

A cookie’s browser expiry does not necessarily describe the retention period of server-side information associated with the cookie identifier.

Consent and objection records may be retained in limited form to demonstrate and respect the user’s choice.

Product analytics may include feature usage, page events, device category, performance, navigation, and other information used to understand and improve the service.

Identifiable analytics information should be retained only for the period necessary for the stated measurement, troubleshooting, or product purpose.

Where possible, analytics should be aggregated, shortened, pseudonymized, or de-identified rather than retained indefinitely at the individual-event level.

Analytics information must not be retained for unrelated advertising or customer profiling merely because it was originally collected for product improvement.

Consent and Cookie Policy requirements apply where relevant.

Where enabled, session replay or interaction reconstruction follows a separately configured and limited monitoring period.

Passwords, authentication secrets, payment credentials, government identifiers, private keys, designated sensitive fields, and prohibited screens should be masked or excluded.

Replay information should be retained only as long as needed to diagnose errors, investigate reported barriers, connect failures with technical context, or improve the affected workflow.

Access should be limited to authorized personnel with a legitimate support, engineering, security, or accessibility purpose.

Replay information connected with a material security or legal incident may be preserved under a documented hold.

Session replay is not intended to become a permanent visual archive of a user’s business activity.

Error events, stack traces, request identifiers, deployment references, device information, performance data, and related diagnostics remain for a limited period necessary to investigate failures and regressions.

Diagnostic systems should avoid collecting full request bodies, private files, authentication secrets, payment credentials, government identifiers, or unnecessary Business Content.

An error attached to a long-running incident may be retained under the incident record while duplicate diagnostic events are aggregated or removed.

Resolved ordinary errors should not remain identifiable indefinitely.

Application, database, queue, storage, gateway, network, deployment, provider, and infrastructure logs may be retained for reliability, security, debugging, capacity management, and incident response.

Log retention should reflect the sensitivity of the log, usefulness for investigation, storage location, and risk created by keeping it.

Logs should not be used as an uncontrolled backup of complete Business Content.

Credentials, access tokens, private keys, full payment details, and unnecessary personal data should be excluded or masked.

Provider-controlled logs may follow different periods that KOMERRA should assess and document.

Notification content, delivery state, read status, preference information, and related references remain while necessary for the Account, Workspace, or notification purpose.

Old routine notifications may be deleted or summarized after they no longer provide useful operational history.

Notifications relating to payment, security, permissions, legal notices, deletion, or significant administrative actions may remain longer under the relevant record category.

Notification preferences may remain while the Account is active and a minimal suppression record may remain after closure where necessary to respect an opt-out or objection.

Marketing contact information is retained while KOMERRA has a valid lawful basis and the person has not objected, unsubscribed, or withdrawn applicable consent.

After an opt-out, KOMERRA may retain a minimal suppression record to ensure that the person is not accidentally added back to the same marketing activity.

A suppression record should contain only the information necessary to respect the preference.

Marketing information should not be retained merely because the person once registered for or used the service.

Objection to marketing does not necessarily require deletion of security, billing, contractual, or legal records retained for another lawful purpose.

Active staff membership, roles, permissions, invitations, and related profile information remain while the person has authorized Workspace access.

When access ends, credentials and memberships should be revoked promptly.

Historical attribution may remain in orders, documents, approvals, security events, audit records, and other business records where necessary for accountability.

Direct identifiers should be reduced or replaced where attribution can be preserved without retaining the complete former user profile.

Employment or contractor records controlled independently by the business remain the business’s responsibility.

Workspace invitations, signup attempts, verification tokens, password-reset tokens, onboarding drafts, and incomplete registrations should expire after a limited period appropriate to their purpose and security risk.

Expired tokens should not remain usable.

An unused invitation should not create indefinite retention of the invited person’s email address or telephone number.

A limited record may remain temporarily to prevent invitation abuse, repeated sending, or security attacks.

Uncompleted onboarding drafts should be removed after their usefulness and any applicable recovery period have ended.

Integration tokens, provider identifiers, configuration, webhook subscriptions, sync state, error history, and related data remain while the integration is active and necessary.

Disconnecting an integration should revoke or delete KOMERRA-controlled credentials and stop ordinary synchronization.

Limited records may remain to document the connection, consent, security events, billing, provider errors, or previous synchronized business actions.

Disconnecting a provider through KOMERRA does not automatically delete information held independently by that provider.

Provider-specific retention must be documented through the Subprocessors page, Data Processing Agreement, provider review, or internal Retention Schedule.

Webhook delivery references, signature-validation results, event identifiers, timestamps, processing state, and failure information may remain to prevent replay, support retries, reconcile provider activity, and investigate rejected events.

Webhook payloads should not be retained longer or more completely than required for the applicable operational, security, or financial purpose.

Invalid or malicious webhook attempts may be retained under security-event rules.

Successful provider events affecting payment or Credits may remain under the applicable financial-record period.

API-key metadata remains while the key is active and for a limited period after revocation where necessary to investigate activity performed with the key.

Secret key material should not remain retrievable after it has been revoked or replaced.

API request logs should follow the applicable security, operational, and diagnostic periods without becoming indefinite copies of request content.

Developer contact, application, webhook, and integration records remain while the developer relationship or connected service remains active.

Search indexes, vector stores, retrieval systems, and derived lookup data should follow the retention state of the authoritative source records.

Deleting a source record should trigger or schedule removal from applicable indexes so the information cannot continue appearing through search or AI retrieval.

Index replicas and caches may require a controlled propagation period.

An index must not become an ungoverned archive of records deleted from the primary database.

Tenant identifiers and access controls must remain enforceable throughout index retention and deletion.

Caches retain copies of information for short operational periods to improve performance and availability.

Cache lifetimes should be limited according to the sensitivity and expected update frequency of the information.

Deletion, permission change, security restriction, or logout may require immediate invalidation rather than waiting for ordinary expiry.

A cache must not be used as a permanent record store.

Where a cache cannot be invalidated individually, its maximum lifetime should remain short enough to prevent inappropriate continued access.

Queued jobs, scheduled actions, retry records, failure details, and dead-letter entries remain while needed to execute, retry, reconcile, cancel, or investigate the operation.

Completed job payloads should not remain indefinitely after the result and necessary audit evidence have been recorded.

Failed jobs may remain longer where operator review or safe retry is required.

Sensitive job payloads should be minimized and tenant scoped.

Deletion workflows must address pending jobs so deleted information is not later recreated or transmitted by an old queued task.

Generated exports, temporary reports, archive files, signed download links, and staging files should expire after a limited period appropriate to their purpose.

The person who downloads an export becomes responsible for securing and retaining the downloaded copy outside KOMERRA.

Temporary export files should not remain in public or shared storage after their download period ends.

Audit information showing that an export occurred may remain longer than the export file itself.

Development and test environments should use synthetic, masked, anonymized, or purpose-limited information wherever reasonably possible.

Production personal data should not be copied into development environments merely for convenience.

Where limited production information is necessary to reproduce a serious issue, access, scope, purpose, and deletion should be documented.

Test records and temporary debugging copies should be removed when the test or investigation ends.

Development backups, local downloads, screenshots, and developer devices must not become uncontrolled retention locations.

KOMERRA may retain information that has been irreversibly anonymized or aggregated so that it no longer reasonably identifies a person, business, customer, or Workspace.

Examples may include service-level performance, overall usage trends, capacity measures, generalized error rates, and non-identifying product statistics.

Pseudonymized information remains personal data where re-identification remains reasonably possible and must continue to follow appropriate retention controls.

Anonymized information must not be combined with other information for the purpose of reconstructing a deleted identity.

Simply removing a name does not necessarily make a detailed business or customer record anonymous.

Closing an Account or deleting a Workspace begins the deletion and anonymization process described in the Account Deletion Policy.

Active product information is deleted, anonymized, restricted, or transferred according to ownership, shared records, legal duties, financial records, disputes, providers, and applicable instructions.

Closure does not automatically erase records that KOMERRA or the business must retain for payment, tax, accounting, fraud, security, legal claims, or other lawful purposes.

Retained exceptions are separated from ordinary product use and should contain only information necessary for the documented reason.

Public Mini Store and Trust Passport pages associated solely with the deleted Workspace are removed from active publication.

Deletion may occur through a sequence of active-record removal, access revocation, anonymization, provider instructions, object deletion, index cleanup, cache expiry, queue cleanup, and backup expiry.

Different systems may complete their portion of deletion at different times.

A record hidden from the user interface has not necessarily completed the full deletion lifecycle.

KOMERRA should not describe deletion as complete until the applicable active-system actions have been completed or the remaining information is held only under an identified exception.

Protected backups may contain information that has already been deleted from active production systems.

Backups are not ordinarily edited record by record because doing so can undermine their integrity and recovery function.

Deleted information ages out when the relevant backup expires, is overwritten, or is securely destroyed through the documented backup rotation.

Backups are access restricted and are not intended to be used for ordinary product, analytics, marketing, or customer-support activity.

Where a backup is restored following a serious failure, deletion markers and completed deletion requests should be reapplied so deleted information is not returned to ordinary active use.

The backup period published by KOMERRA must match the actual configuration of its database, storage, infrastructure, and provider backups.

Temporary copies created during disaster recovery, migration, restoration, incident response, or infrastructure repair are retained only while required to complete and verify the operation.

Recovery copies should remain protected to the same or a higher standard than the original information.

Once recovery validation is complete, unnecessary temporary copies should be securely deleted.

A disaster-recovery exercise must not create permanent undocumented copies of production information.

A legal hold may temporarily suspend ordinary deletion for information reasonably relevant to a legal claim, regulatory request, investigation, subpoena, court order, payment dispute, fraud review, security incident, due diligence process, or defense of rights.

A hold must identify its purpose, scope, owner, start, affected categories, systems, and review status.

A legal hold does not authorize unrelated use of the preserved information.

Access should be restricted to authorized personnel and advisers with a legitimate need.

When the hold ends, the information returns to its ordinary retention or deletion process.

Legal holds should be reviewed periodically and must not continue indefinitely without an active reason.

Information relevant to a suspected or confirmed security incident may be preserved while the incident is detected, contained, investigated, remediated, communicated, and reviewed.

Incident evidence may include authentication events, audit logs, affected records, provider events, request identifiers, deployment history, configuration changes, and support communications.

The retained scope should be proportionate to the incident and should avoid preserving unrelated Workspace content.

After the investigation, information no longer needed should be deleted or anonymized while the incident report and necessary evidence remain restricted for the applicable period.

KOMERRA may retain information connected with suspected payment fraud, identity fraud, Account takeover, promotion abuse, chargeback manipulation, forged evidence, tenant abuse, or other serious misuse.

The information may remain while the investigation, provider review, enforcement action, appeal, or legal process remains active.

Fraud prevention does not justify keeping every record belonging to every Account indefinitely.

Where a fraud-prevention marker remains necessary after other information is deleted, it should contain the minimum information required to identify the relevant risk.

Records may be retained where necessary to establish, exercise, or defend a legal claim.

The applicable period depends on the nature of the claim, dispute, contract, limitation period, jurisdiction, evidence, and professional advice.

Retention for a possible claim must be based on a reasonable and documented need rather than a speculative belief that any information could someday be useful.

After the claim or relevant period ends, unnecessary information should be deleted, anonymized, or minimized.

Certain payment, invoice, Credit, refund, transaction, company, accounting, tax, or regulatory records may need to remain for periods required by applicable law.

The legal period should be recorded in the Retention Schedule and reviewed when the applicable law changes.

Retention of a financial record does not require unrestricted retention of every message, file, AI interaction, or customer note associated with the transaction.

Where possible, the retained financial record should be separated from information no longer required.

KOMERRA should obtain appropriate Nigerian accounting, tax, data-protection, and legal advice before publishing exact statutory periods.

KOMERRA’s retention obligations extend to relevant processors and subprocessors that store or process information on its behalf.

Provider contracts and configuration should define retention, deletion, return, backup, incident, and termination requirements appropriate to the service.

A provider should not retain KOMERRA data indefinitely merely because the service relationship has ended.

Where a provider has an independent legal obligation to retain a limited record, that provider may retain the information within its own legal role.

KOMERRA should record deletion instructions, provider completion status, unresolved exceptions, and applicable evidence.

Provider retention information should be reflected accurately in the Subprocessors page, Privacy Policy, Data Processing Agreement, or enterprise documentation.

Where information is processed outside Nigeria, the applicable retention and deletion rules continue to apply to KOMERRA-controlled processing.

Cross-border processing should not be used to avoid a deletion, restriction, or storage-limitation obligation.

Provider location, legal duties, backup practices, government-access requirements, and deletion capability should be considered before the provider is approved.

International providers may have independent legal obligations that affect a narrow category of information, which should be assessed and documented.

A person may request information about the period for which their personal data will be stored or, where an exact period cannot reasonably be provided, the criteria used to determine that period.

A response may distinguish different categories because Account data, customer records, security events, payment information, support cases, and backups do not share one universal period.

KOMERRA may withhold information that would expose security controls, another person’s data, legally privileged material, or confidential provider details, while still explaining the applicable retention basis where required.

Requests should be submitted using “Privacy Request” through support@komerra.app.

A person may request correction of inaccurate personal data and may request erasure or restriction where applicable.

KOMERRA will assess the request according to its role as controller or processor, the purpose, lawful basis, relevant Workspace, other people’s rights, legal duties, and applicable exceptions.

Where personal data is no longer necessary and no lawful basis remains, it should be erased without undue delay.

Where a dispute about accuracy, authority, or lawful retention remains unresolved, the information may be restricted while the matter is assessed.

A restriction prevents unrelated use but does not necessarily require immediate destruction of the record.

Information may be removed through database deletion, object-storage deletion, lifecycle expiration, token revocation, cryptographic destruction, anonymization, overwriting, provider deletion, index cleanup, cache expiry, queue cleanup, or another appropriate method.

The selected method should reflect the system, sensitivity, recovery model, technical capability, and applicable legal requirement.

Deleting a pointer without deleting the underlying object is not sufficient where the object remains accessible or reasonably recoverable for ordinary use.

Deletion jobs should be idempotent, tenant aware, observable, safe to retry, and protected against cross-Workspace deletion.

Failures should create operational records and should not be silently treated as completed deletion.

Where complete deletion is not required or would undermine a lawful record, KOMERRA may remove direct identifiers and retain a minimized or anonymized form.

An anonymized record must not reasonably permit the person or business to be re-identified using information likely to be available.

A pseudonymous identifier remains protected information where re-identification remains possible.

A minimal user tombstone may remain where necessary for referential integrity, auditability, or financial ledgers, but it should not contain the original profile, credentials, or unnecessary contact information.

Retention periods, legal bases, systems, providers, deletion jobs, lifecycle rules, legal holds, and policy language should be reviewed periodically.

A review should also occur when KOMERRA introduces a new data category, provider, country, AI feature, verification method, payment workflow, monitoring tool, public page, or mobile application.

Expired records, failed deletion jobs, stale legal holds, abandoned files, outdated provider copies, and discrepancies between policy and configuration should be identified and corrected.

Review evidence may include configuration exports, deletion-job results, storage inventories, provider confirmations, restore tests, audit samples, and privacy assessments.

Each material information category should have an accountable business, product, engineering, security, privacy, legal, finance, or operational owner.

The owner is responsible for defining the purpose, validating the period, confirming the production implementation, reviewing exceptions, and ensuring that deletion failures are resolved.

Data retention should not be treated solely as a database-administration issue because copies may exist across providers, files, logs, caches, queues, support systems, analytics, and backups.

Material exceptions should be documented and approved by an appropriate person.

KOMERRA does not claim that every category shares one retention period.

KOMERRA does not claim that deleting information from the user interface proves that every copy has already disappeared from every active system, provider, cache, and protected backup.

KOMERRA does not claim that anonymized information is anonymous merely because a name or email address was removed.

KOMERRA does not claim that a provider’s default retention automatically satisfies KOMERRA’s legal or contractual obligations.

KOMERRA does not publish exact retention periods until they have been verified against actual production configuration and legal requirements.

KOMERRA does not retain information indefinitely merely to avoid building reliable deletion controls.

KOMERRA may update this Policy when information categories, services, providers, legal requirements, retention periods, deletion methods, backups, monitoring systems, or business purposes change.

Material changes will be communicated through an appropriate website, application, Account, Workspace, or email channel where required.

A policy update will not create a lawful basis to retain information that should already have been deleted.

The production Retention Schedule, Privacy Policy, Account Deletion Policy, Data Processing Agreement, and Subprocessors page should remain consistent with this Policy.

Historical versions may be retained for accountability and to determine which published rules applied during an earlier period.

Send questions about retention periods, deletion triggers, backups, legal holds, provider copies, or a particular information category to support@komerra.app.

Use “Data Retention Question” for a general enquiry.

Use “Privacy Request” to request access, correction, erasure, restriction, objection, consent withdrawal, portability, or information about the period or criteria applying to your personal data.

Include the Account email, business name, affected Workspace, information category, relevant date range, and the outcome you are requesting.

Do not send passwords, one-time passwords, recovery codes, private keys, card security codes, bank PINs, or unnecessary identity documents through ordinary email.