A retention policy becomes software work when records need schedules, exceptions, deletion jobs, backup behavior, legal holds, reporting, and tenant-specific rules. The estimate should include what happens when data cannot be deleted on time.

Classify the records

List users, transactions, messages, files, audit events, exports, logs, backups, and derived data. Identify owner, purpose, sensitivity, tenant, and dependency for each class.

Define retention behavior

Record start event, duration, timezone, archive state, deletion action, exception, and review. The software permission audit cost guide illustrates why data scope and access scope should be priced separately.

Include deletion and holds

Budget for scheduled jobs, dry run, preview, approval, deletion verification, legal or operational hold, failed cleanup, and safe retry. Do not let a failed job silently reset the retention clock.

Cover backups and providers

Review snapshots, replicas, exports, caches, queues, analytics, storage providers, and support copies. Document what deletion means for each layer and who can verify it.

Audit and tenant isolation

Include policy version, actor, reason, scope, result, exception, access control, and reporting. Ensure one tenant's retention job cannot delete or expose another tenant's data.

Plan maintenance

Allow for new record classes, policy changes, provider updates, storage growth, exception review, restore testing, support, and monitoring. Ask for evidence of successful cleanup in the estimate.

Retention rules defined in policy but not in the product? Ask Vertinus to scope schedules, deletion, holds, and verification together.