Processors · DPDP s.8(2), Rule 7

Processors that obey the withdrawal.

Register each processor with its agreement and review status. Connect the ones that hold personal data and every withdrawal and erasure is delivered to them, with a log of what was sent and whether it was accepted.

Request a demoSee what it does
s.8(2) Contract requireds.8(1) Fiduciary stays responsible20 connectors
The processor register: service, country, agreement status, security review and risk
The challenge

You remain responsible for what they do.

Section 8(1) is clear: the Data Fiduciary is responsible for compliance even when a processor does the processing. A withdrawal that reaches you but not your email tool is a breach waiting to be noticed.

s.8(2)
No contract, no processing
A processor may only act under a valid contract. Tracking which agreements exist, and when they expire, is a legal requirement, not a procurement nicety.
Withdrawal
The campaign that keeps sending
The person withdrew yesterday; the engagement platform sends today. Their consent was withdrawn as easily as it was given, as the Act requires; your systems did not notice.
Erasure
Twenty copies
A typical consumer business holds each customer in a CRM, an engagement tool, an email tool, a WhatsApp provider, a support desk, a payment gateway and two ad platforms.
What Nyvika does

A register that acts.

Most processor registers are spreadsheets. This one is wired to the systems it lists.

The register

Service, country, purposes served, data categories, agreement status and expiry, security review date, risk score.

  • Expiring agreements flagged
  • Appears in the data-flow map and access bundles
  • Processor register report

Twenty connectors

CRM, engagement, email marketing, WhatsApp, support desk, payments and advertising, plus a signed webhook for your own systems.

  • HubSpot, Salesforce, Zoho CRM, Freshsales
  • WebEngage, MoEngage, CleverTap, Mailchimp, Brevo, SendGrid
  • Gupshup, Interakt, WATI, Zendesk, Freshdesk, Razorpay, PayU, Google Ads, Meta

Delivery you can see

A transactional outbox queues each instruction; the sync log shows every attempt, response and retry.

  • Automatic retries with backoff
  • Manual retry from the console
  • Failures surface on the overview

Credentials sealed

Connector credentials are encrypted in the vault and write-only; saving tests the connection.

  • Never shown again after saving
  • Per-connector purpose mapping
  • Removed with the processor
One ledger

How it connects.

Every module writes to the same registers and the same hash-chained evidence, so nothing is re-keyed and nothing is lost between teams.

Notice & consent

A withdrawal in the ledger becomes an instruction to the processors on that purpose.

See notice & consent →
Retention & erasure

Erasure reaches a processor once every purpose it serves has expired.

See retention & erasure →
Data discovery

A connected CRM is also a discovery source for the inventory.

See data discovery →
Questions

Asked about processors.

What does a connector actually do at the processor?

On withdrawal it sets the processor's own opt-out or unsubscribe state for the person; on erasure it deletes or anonymises the contact where the processor's API allows, and sends a formal erasure request by email where it does not (payment processors, for example). We list what each one does during onboarding.

Our in-house system is not on the list.

Use the signed webhook. Nyvika posts each withdrawal and erasure to your endpoint with an HMAC signature you verify, and retries until you acknowledge.

Have the connectors been tested against the real services?

Against stand-ins that follow each vendor's published API, in our automated tests. Live-account verification is done during your onboarding with your own sandbox or trial accounts.

Still have a question? Write to us.

Connect the systems that hold your customers.

Bring API keys for your CRM and your engagement tool; a withdrawal will reach both before the demo ends.

Request a demoCheck your readiness