Admin Read Audit
Traceability and control of privileged read access
1. Control objective and scope
This page defines mandatory controls and evidence standards for privileged read access to sensitive data domains within the prokodo Marketplace platform.
This page serves transparency purposes and does not replace binding contract documents (in particular Terms (AGB), Seller Terms, Verification Policy, and Refund & Dispute Policy).
Scope includes: user profiles, compliance records (deletion requests, deletion policies), erasure jobs and their statuses, audit event collections, tombstone data, and security-relevant metadata.
Privileged access is defined as any read access that exceeds the permissions of a regular, non-administrative user — regardless of whether it occurs through the application UI, direct database queries, or Admin SDK operations.
As of February 16, 2026. Subject to change.
2. Minimum controls
Privileged read access is permitted only under the following cumulative conditions. These are minimum requirements; stricter rules may apply per team.
- RBAC (Role-Based Access Control): Access is based on assigned administrator role, determined by Firestore role field or Firebase custom claims. Firestore security rules and storage rules enforce default-deny
- Need-to-know and least privilege: Access is limited to the data domains required for the specific task
- Purpose binding: Mandatory statement of purpose before sensitive read operations. Implemented as required fields in admin audit events (fields: reasonCode and note)
- Four-eyes principle: Intended for high-sensitivity or high-volume read operations (e.g., bulk export, compliance reviews). Open validation item (Security): Implement technical enforcement of the four-eyes principle for defined high-risk operations.
- Sampling review: Regular manual or automated review of audit logs for anomalies and unjustified access. Open validation item (Security): Define review interval and sample size.
3. Audit evidence requirements (who/when/what/why)
Every privileged read access to sensitive data domains should be logged with the following minimum fields. The following description is based on the implemented audit event structure:
- Who: actorUid (user ID of the accessing administrator) and actorEmailHash (pseudonymized HMAC-SHA256 hash of the administrator's email address – no plaintext stored)
- When: createdAt (server timestamp of the access)
- What: actionType (type of action, e.g., CANCEL_RUN, FAIL_RUN, RETRY_RUN, VERSION_RELEASED, VERSION_REJECTED), listingId, semver, runId (contextual identifiers)
- Why: reasonCode (machine-readable) and note (free text, max 500 characters, automatically sanitized for secrets: GitHub tokens, AWS keys, Stripe keys, private keys)
- Deduplication: requestId as unique key per audit event
- Storage: Dedicated Firestore collection. Firestore security rules: read access for administrators only; no client write access (writes only via server-side Admin SDK)
- Integrity: Audit notes are automatically scanned for embedded credentials and sanitized. No client-side write access to the audit collection. Open validation item (Security): Confirm whether append-only write or write-only separation is implemented or planned for the audit collection.
4. Deletion status communication guardrails
Communication of deletion status to users and support staff is strictly bound to the actual processing state. Statements that anticipate an unachieved state are not permitted.
- erased_core: Core identifiers in the primary user profile and auth system are removed/anonymized. External connectors (Stripe, Mailchimp, Typesense, Storage) may still be pending. Permissible communication: "Account deactivated; final deletion in progress."
- erased_complete: All six configured erasure targets are terminal (succeeded or skipped/NOT_APPLICABLE). Evidence is documented in the erasure job record. Permissible communication: "Deletion completed per policy; only legally required residual records remain."
- The statement "deletion completed" is permissible only when erased_complete status is reached
- Under legal hold (LEGAL_HOLD, OPEN_DISPUTE, FRAUD_REVIEW): Only legally required minimum data may remain, with documented legal basis. Communication: "Deletion temporarily suspended due to legal obligation."
- Backups and log streams: Additional note that deletion from backup systems occurs through configured retention windows
5. Retention values and canonical matrix
The following values are based on the current infrastructure configuration (Firestore TTL resources, Terraform-defined) and the constants in the erasure worker code. The canonical retention matrix is the authoritative primary source.
- Erasure jobs (orchestration data): 90 days — TTL-enforced via Firestore expiresAt field
- Erasure audit events (compliance evidence): 180 days — TTL-enforced via Firestore expiresAt field
- Erasure dead letters (error/recovery evidence): 180 days — TTL-enforced via Firestore expiresAt field
- User tombstones (pseudonymous suppression records): 365 days — TTL-enforced via Firestore expiresAt field
- Firestore backups: 14 weeks (8,467,200 seconds; configured in Terraform). No single-record deletion; removal via backup rotation
- Cloud Logging: per log sink retention setting. No single-record deletion
- Error telemetry (Bugsnag): per provider retention setting. No direct per-user deletion guarantee
- Typesense snapshots: 14 days (configured). Artifact registry images: 7 days old / keep 10 most recent
- Temporary uploads (GCS uploads/*): 14 days (lifecycle rule)
6. Review and enforcement
The following control mechanisms are designed to ensure compliance with the requirements above:
- Monthly compliance review of access log anomalies (planned). Open validation item (Security): Formalize the review process and assign owner.
- Immediate escalation for unjustified access without documented purpose statement
- Documented corrective actions and preventive actions for identified deviations
- Management reporting on critical deviations and trend analysis
- Repeated violations are classified as governance risk requiring strengthened controls (e.g., extended logging, access restriction, disciplinary measures)
- Audit findings and corrective actions must be retained for at least the retention period of the underlying audit events
