This is the full text published in the Phase 7 package. Effective dates, responsible contacts and contract-specific parameters are maintained in the corresponding release and deployment records.
Category-specific retention schedule
Before deployment, the project owner and legal function approve a schedule identifying categories, purposes, start/end triggers, periods, responsibilities and basis. Raw images, templates, bindings, consent, logs and evidence must not share an arbitrary default period.
Raw images, memory and temporary data
The confirmed model processes capture images within a session without default retention. Operators inspect caches, diagnostic logs, crash dumps, queues and support exports. Retaining images for investigation or evaluation requires a basis, time limit, separated location and explicit access controls.
Disposition triggers
Triggers include purpose completion, contract termination, validated requests, abandoned capture, device replacement and scheduled expiry. Each disposition job has a tracking reference and an affected-system inventory. Binding revocation and deletion may occur at different times, but revoked references must not remain eligible for ordinary matching.
Verify requests and retention obligations
The responsible entity verifies requester and scope. Legal review determines retention obligations, disputes or preservation orders; an "audit" label alone is insufficient. Retained items are restricted to the preservation purpose, access-separated and reconsidered when the conditions end.
Deletion across active systems and replicas
The deletion plan covers vaults, bindings, search indexes, replicas, caches, temporary files and device-resident data. Jobs verify each target, retry under the same tracking reference and escalate unresolved failures. Cryptographic erasure is used only when supported by the actual architecture and evidence.
Backup and restoration
Backups have their own schedules, access rules and expiry procedures. If individual records cannot be immediately removed from an archive, document the limitation, isolate use and apply the approved disposal schedule. Before restored data re-enters service, reapply deletion and revocation records to prevent reactivation.
Completion evidence
Closure evidence records scope, method, systems, results, unresolved failures, retained categories and reasons. Do not keep the deleted image or reference merely to prove deletion. The response must disclose backup limitations and exceptions and must not claim completion before target systems confirm it.
Review and periodic exercises
Assigned staff review overdue jobs, access to exception-retained data and post-deletion restoration. Firmware, engine or storage changes require an updated inventory and renewed procedure tests. Review frequency, timelines and named accountability remain approval items in the annex.
Responsibility & deployment annex
Detailed responsibilities are determined by activity and deployment records; this public document does not replace customer-specific contractual annexes.
- The relying organization defines business purposes, populations and operational authority within the deployment.
- Mobile-ID supplies and operates components within the agreed scope, including integration, control configuration and related evidence.
- Device suppliers support models, firmware, SDKs and maintenance within authorization; data access is never implicit.
- Legal, security and service ownership assignments are maintained in each organization’s operating records.
Execution and evidence cycle
- Record purpose, organization, data/device scope and the business reference.
- Verify authority, applicable conditions, configuration and relevant obligations.
- Execute with data minimization, authorization and necessary evidence.
- Close with confirmations from relevant systems, response handling and remaining exceptions.
Legal and reference sources
Detailed obligations, periods and exceptions apply according to law, contract and the actual service configuration.