MonetizeNow supports the GDPR right to erasure (Article 17) through a formal, auditable process. As a processor, we act on deletion requests submitted by the customer (controller). This document explains what information we require, how we verify and process requests, timelines/SLAs, and what evidence we provide.

Submitting a Request

1. Who can submit: Authorized customer admin, Legal/Privacy, or Security.
2. Where to submit: Send email to: [email protected]
3. What to include (minimum):
   1. Controller company name
   2. Authorized requester (name, title, work email, phone)
   3. Data subject identifiers: primary email used in MonetizeNow, all known aliases, user id (if available), account/tenant ID
   4. Scope: CPQ, Billing, Metering, Self-Serve, Support artifacts (as applicable)
   5. Acknowledgments: legal-retention, backups rotation, and suppression (see below)

Processing Workflow

1. Authorize & Verify
   We verify controller authorization and confirm subject identifiers (email(s), user/seat ID, tenant).
2. Locate & Scope
   We enumerate the subject’s records across:
   1. CPQ: users/contacts, quotes, drafts, order forms
   2. Billing: billing contacts, subscription records, invoices/credit memos (subject to legal retention), payment tokens we control
   3. Metering: usage records linked to the identity
   4. Ancillary: logs/analytics (where feasible), attachments, support artifacts
3. Delete / Pseudonymize
   1. Hard delete where possible.
   2. Irreversible pseudonymization where references are required for data integrity or legal retention (e.g., keep invoice number and amounts; remove personal fields not legally required).
   3. Documents: delete drafts if permissible; executed commercial records are retained as required by law with PII minimized and access restricted.
4. Sub-Processor Propagation
   We notify/invoke deletion with approved sub-processors (e.g., e-signature, email delivery, observability) and track confirmations.
5. Backups & DR
   We do not modify historical backups. Deletions are enforced by backup rotation (typ. 7–35 days, service-dependent). If a restore occurs, automated jobs re-apply the erasure.
6. Suppression
   We add a non-reversible token/hash to a suppression register to prevent accidental re-creation of the identity via future imports/integrations.
7. Attestation & Closure
   We deliver a completion report listing systems affected and sub-processor confirmations. All actions are logged (timestamp, actor, systems) and are reviewed under SOC 2 Type II.

Timelines & SLAs

• Standard completion: 7–10 business days
• Regulatory maximum: ≤ 30 days from verified request (GDPR Article 12)
• Complex, multi-system requests are communicated proactively with interim updates.