Data processing framework

This framework helps prospective customers understand the subjects covered by a Nexus data processing agreement. It does not appoint Nexus as a processor, authorise processing, or amend another contract by itself.

Where a deployment requires Nexus Soft Ltd to process personal data on behalf of a customer, an Article 28 GDPR agreement and its deployment schedules must be completed before that processing begins. This page is not evidence that such an agreement, subprocessor approval or international-transfer assessment already exists. Statutory obligations still apply according to the actual processing roles.

The DPA identifies the controller, processor and any independent-controller activities. It records the subject matter, duration, nature and purpose of processing, data types, data-subject categories and the customer’s documented instructions.

Nexus processes customer personal data only on documented instructions unless Union or Member State law requires otherwise. Product configuration or support requests that change processing scope should be captured through an authorised change process.

White-label branding does not determine the legal role. A customer may control its publisher, advertiser or end-user data; Nexus may process it through managed hosting or support, while acting as controller for its own business accounts and correspondence. Customer-hosted software without Nexus access needs a different assessment from a managed service. Neither deployment model automatically removes privacy obligations.

For Search Syndication and XML / JSON, identify the query and feed parameters, publisher or sub-ID fields, network metadata, click records and partner reporting actually used. For OpenRTB, DSP, campaign and VAST workflows, identify request and device identifiers, inventory, creative, bid, impression and event data passed to each partner.

For CPA and tracking workflows, identify click IDs, conversion and postback parameters, offer and payout records. For a Web Push integration, identify subscription endpoints, keys, consent records and delivery metadata. These are scoping examples, not a declaration that every deployment collects every field or supports every protocol.

The schedule must name the participating parties, data-subject groups, purposes, countries, access paths and retention for the enabled modules. Traffic and demand providers are not automatically Nexus subprocessors; assess whether each is an independent controller, joint controller or processor for the actual flow. White-label use must not hide the responsible operator from its users.

The customer is responsible for the lawfulness, fairness and transparency of its advertising and data strategy, including its legal basis, consent signals where required, notices, partner permissions, data accuracy and instructions to Nexus.

The customer should avoid sending data that is unnecessary for the agreed purpose and must not introduce special-category, children’s, precise-location or other high-risk data unless expressly assessed and authorised in writing.

People authorised to process customer personal data are bound by confidentiality and receive access according to their responsibilities. Production credentials remain server-side; privileged operations require authenticated and authorised context and should generate appropriate audit evidence.

Deployment schedules specify tenant boundaries, administrator roles, support access and any customer-controlled identities or allowlists.

The security schedule is tailored to the deployment and risk. It may cover encryption in transit, federated identity, credential management, platform-level authorization, network and service boundaries, role-based access, input validation, rate limiting, logging, vulnerability management, backups, recovery and incident response.

Security measures are reviewed as technology and risk change. A public architecture statement does not replace the detailed schedule or create a certification that has not been expressly documented.

The signed DPA identifies or links to the subprocessors authorised for the deployment, their function and processing location. It requires prior specific or general written authorisation, notice of intended changes under general authorisation and a meaningful opportunity to object. Flow-down terms must protect the data to the required standard; delegation does not remove Nexus responsibilities for its subprocessors.

Transfers outside the EEA require a lawful mechanism such as an adequacy decision or Standard Contractual Clauses, with supplementary measures where the transfer assessment requires them.

Taking into account the nature of processing, Nexus provides reasonable assistance for data-subject requests, DPIAs, regulator consultations and evidence needed to demonstrate the processor obligations covered by the signed DPA.

Requests received directly from a data subject about customer-controlled data are normally referred to the customer unless law requires another response. The parties agree secure request and identity-verification channels.

The executed DPA records the incident notification channel, information to be provided, cooperation duties and any agreed operational target. It must use the statutory personal-data-breach definition, not narrow it by contract. Where acting as processor, Nexus must notify the customer without undue delay after becoming aware of a personal data breach; information may be supplied in phases as facts become available.

Customers remain responsible for regulatory and data-subject notifications where they act as controller, with Nexus providing relevant information within its control.

Deployment schedules must define operational retention, backup cycles, exit export and deletion behaviour before processing. At the end of services, the customer chooses return or deletion of personal data and deletion of copies, unless applicable law requires storage. The schedule must account for remaining backup copies and prevent their return to ordinary processing. This page does not promise an unverified backup or deletion deadline.

Retention should be based on purpose and operational need rather than indefinite availability. Aggregated or irreversibly anonymised information falls outside personal-data return obligations when it can no longer identify a person.

The signed DPA describes reasonable audit information, certifications where actually held, inspection conditions, confidentiality and cost allocation. Audit mechanisms should provide meaningful assurance without weakening other customers’ security or exposing unrelated systems.

Liability, governing law and order of precedence are defined in the commercial agreement and executed DPA, subject to mandatory law. Contractual caps cannot remove statutory rights of data subjects or regulator powers. The processor must make the required compliance information available, allow the required audits and alert the controller if an instruction infringes applicable data protection law.

To discuss a DPA, use our contact form or select Show email in the Legal contact panel. Include the expected products, roles, data categories, traffic regions, hosting requirements and target deployment model. Nexus can then identify the schedules and technical information needed for a useful review.