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, the parties execute a DPA meeting Article 28 GDPR requirements before that processing begins. The signed agreement and its schedules control over this public explanation.

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.

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 defines notice and objection mechanics for changes and requires subprocessors to accept materially equivalent data protection obligations.

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 defines what constitutes a personal data breach for the service, the notification channel, information to be provided, cooperation duties and any agreed operational target. Nexus notifies the customer without undue delay after becoming aware of a qualifying breach affecting customer personal data.

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

Deployment schedules define operational retention, backup cycles and deletion behaviour. At the end of services, Nexus returns or deletes customer personal data as instructed, unless applicable law requires retention, and addresses remaining backup copies through the agreed lifecycle.

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, caps, governing law and order of precedence are defined in the commercial agreement and executed DPA. This public framework does not create service commitments or override negotiated terms.

To discuss a DPA, contact contacts@nexus-soft.org with 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.