Data Processing Agreement

Last updated · 18 August 2026

This Data Processing Agreement ("DPA") forms part of the agreement between Pointnode Limited, trading as Pointnode ("Processor"), and the Customer ("Controller") for the supply of the Pointnode platform under our Terms of Service.

It implements the Controller's and Processor's respective obligations under UK GDPR and the Data Protection Act 2018 in respect of personal data processed by Pointnode on the Controller's behalf.

1. Definitions

Capitalised terms not defined in this DPA have the meanings given in UK GDPR (Article 4) or in the Terms of Service. In particular:

• Customer Personal Data means personal data uploaded to, generated by, or otherwise processed through the platform on the Controller's behalf.
• Sub-processor means any third party engaged by Pointnode to process Customer Personal Data — see /legal/sub-processors.

2. Subject matter and duration

• Subject matter: provision of the Pointnode Cloud dashboard and supporting services as described in the Terms.
• Duration: for the term of the Customer's subscription, plus the 30-day post-termination return / deletion window.
• Nature and purpose: hosting and processing the Controller's personal data to enable condition monitoring (from on-asset controllers and optional wireless sensors), the asset register and technical file, inspections, documents, defects, work orders and engineer visits, service-provider access, pre-use and lock-out workflows, optional interlocks, optional AI-assisted Asset Intelligence, notifications, support and audit functions.

3. Categories of data subjects and personal data

See Annex 1 (Description of Processing) below.

4. Pointnode's obligations

Pointnode shall:

• Process Customer Personal Data only on documented instructions from the Controller, including with regard to international transfers, unless required by law to do otherwise.
• Ensure that personnel authorised to process Customer Personal Data are bound by confidentiality obligations.
• Implement and maintain the technical and organisational measures described in Annex 3 (Security Measures).
• Engage Sub-processors only on terms equivalent to this DPA, and remain responsible for their performance. The current list is at /legal/sub-processors.
• Assist the Controller, taking into account the nature of the processing, in fulfilling its obligation to respond to data subject requests under UK GDPR Articles 12 to 23.
• Assist the Controller in ensuring compliance with Articles 32 to 36 (security, breach notification, DPIA, prior consultation), taking into account the information available to Pointnode.
• On termination, at the Controller's choice, return or delete all Customer Personal Data within 30 days, unless retention is required by law. On deletion of an individual user account (by the Controller's admin or by the user themselves under our self-serve delete flow), any programmatic-access tokens (API tokens) that user created are revoked in the same database transaction as the account deletion, so an outstanding token cannot survive the user it belonged to. Outgoing webhook configurations created by the deleted user remain enabled at the Controller's discretion, on the basis that the configuration belongs to the Controller's organisation rather than to the individual.
• Make available to the Controller all information necessary to demonstrate compliance with this DPA, and allow for and contribute to audits — see Section 9.

5. Sub-processors

The Controller authorises Pointnode to engage the Sub-processors listed at /legal/sub-processors. Pointnode will give at least 30 days notice by email before engaging a new Sub-processor or replacing an existing one. The Controller may object on reasonable data-protection grounds; if the parties cannot agree a workable alternative, the Controller may terminate the affected services without penalty.

6. International transfers

Where Customer Personal Data is transferred outside the UK or EEA, Pointnode will ensure an appropriate transfer mechanism is in place — the UK International Data Transfer Agreement (IDTA), the EU Standard Contractual Clauses (SCCs), or any successor mechanism approved by the UK ICO or European Commission. The current Sub-processor list identifies which providers require which mechanism.

7. Personal data breaches

Pointnode shall notify the Controller without undue delay, and in any event within 48 hours of becoming aware of a personal data breach affecting the Controller's data. The notification will include the information required by UK GDPR Article 33(3) to the extent then known, and follow-up information will be provided as soon as it is established.

The Controller is responsible for any onward notification to data subjects and to the ICO.

8. Data subject rights

Where Pointnode receives a data subject request directly from an individual whose personal data is held on the Controller's behalf, Pointnode will, without undue delay:

• Acknowledge receipt and inform the data subject that the request should be directed to the Controller, providing the Controller's contact details.
• Notify the Controller and assist them as reasonably required to respond.

9. Audit rights

The Controller may, on at least 30 days written notice and not more than once per year, audit Pointnode's compliance with this DPA. The annual-frequency limit does not apply: (a) following a personal data breach affecting the Controller; (b) where an audit is required by a regulator with jurisdiction over the Controller (for example a financial-services or health-and-safety regulator); or (c) where the Controller has reasonable grounds to suspect material non-compliance. In practice the audit obligation is satisfied by:

• Pointnode providing relevant excerpts of its security policies on request, and
• Where applicable in future, sharing third-party audit reports (e.g. SOC 2 Type II) under NDA.

Audits must be conducted during business hours, with reasonable cooperation, and at the Controller's cost unless they reveal a material breach by Pointnode.

10. Liability

Each party's liability under or in connection with this DPA is subject to the liability cap and exclusions set out in the Terms of Service.

11. Term and termination

This DPA takes effect on the start date of the Customer's subscription and remains in force for as long as Pointnode processes Customer Personal Data. Sections that by nature should survive termination (in particular Sections 4(g) and 9) survive.

Annex 1 — Description of Processing

Categories of data subjects

• Operators (employees of the Customer who use the monitored assets).
• Site managers and supervisors employed by the Customer.
• Organisation admins, engineers, contractors and competent persons.
• Users of connected service-provider or inspection organisations.
• Pointnode staff users (Pointnode is the Controller for these).

Categories of personal data

• Identifiers: display name, email address.
• Profile contact details where supplied by the user: phone number, job title.
• Authentication: hashed password, TOTP MFA factor enrolment record, hashed single-use MFA recovery codes, session tokens.
• Role assignments inside the Customer organisation.
• Activity records: audit log, login history, configuration changes.
• Asset records: inspections, services, pre-use checks, certificates, technical documents and ad-hoc reports filed against an asset, together with signatures, photographs and attached evidence. Retention follows the Controller's instructions, contract and applicable record-specific law.
• Defects, work orders and visits: descriptions, risk and status, quotation or approval references, schedules, assignments, engineer notes, labour, parts and components, evidence, acknowledgement, review and acceptance decisions.
• Organisation connections and access grants: connected organisations, selected sites and assets, permitted capabilities, approving user and grant/revocation dates.
• Operator activity records: LOTO issue / release records, asset session start / end timestamps.
• Wireless device metadata (connected-lite sensors and interlock relays): radio identifier (LoRaWAN DevEUI / Bluetooth MAC), last-seen time, battery level, signal strength. Equipment data, not personal data.
• Interlock command / actuation records (where the optional start-inhibit interlock is enabled): the command issued (enable / inhibit), timestamp, the identity of the operator or automated rule that triggered it, the relay's reported contact state, and any use of the physical operator override.
• Notification preferences and recipient details, including app-specific APNs device tokens where iOS push is enabled.
• Photos and PDF evidence files uploaded as part of asset record submissions (pre-use safety checks, statutory inspection reports, services) — may incidentally include faces or other identifiers.
• Support tickets and conversation history: ticket subject, message bodies, attachments uploaded as part of the request, ticket number, category, priority, status, and the threaded follow-up messages.
• Help-content feedback: was-this-helpful votes and any optional free-text feedback the user supplies against a help article slug, recorded against their user identity for staff follow-up.
• Integration configuration: outgoing webhook destination URLs and per-webhook HMAC signing secrets; long-lived API tokens used for programmatic access (stored as one-way hash, never cleartext).
• Webhook delivery records: frozen snapshots of the event payloads delivered to the Customer's configured webhook endpoints, including operator identity (issued_by) where the event is a LOTO action.

Special categories of personal data

Pointnode is not designed to process special-category data (Article 9). Customers must not upload health data, biometric identifiers, or other Article 9 data through the platform.

Processing operations

• Storage in an EU-region encrypted database (eu-west-1).
• Display in Pointnode web and mobile clients licensed to the Controller, including the craneIQ iOS client for relevant lifting-equipment workflows.
• Ingestion of asset telemetry over MQTT (on-asset PLCs) and, for optional connected-lite assets, via a LoRaWAN Network Server (uplink sensor readings).
• Where the optional start-inhibit interlock is enabled: transmission of outbound relay commands (enable / inhibit) to a wireless device via a LoRaWAN Network Server, and processing of the resulting confirmation and audit records. The interlock is an administrative / procedural control that is always physically operator-overridable and is not a functional-safety device.
• Where the optional Asset Intelligence features are enabled: transmission of a bounded asset context (telemetry summaries, condition signals, compliance status, user questions, and uploaded document text) to the AI sub-processors listed in Annex 2 to generate advisory, human-in-the-loop analysis.
• Transmission to recipients via the email provider listed in our sub-processor list.
• Backup and retention per Privacy Policy Section 6.

Annex 2 — Sub-processors

Per the live list at /legal/sub-processors. That list includes Anthropic PBC and Voyage AI (MongoDB, Inc.), engaged for the optional Asset Intelligence features (AI briefings, the AI Engineer, and document search). Per-asset processing is limited to assets with Asset Intelligence enabled; organisation-level processing runs only where the organisation-wide feature is enabled. The providers are covered by the transfer safeguards described in Section 6, and Anthropic does not train models on commercial API Customer Content by default.

Apple Inc. provides Apple Push Notification service delivery where a user enables iOS push. Apple receives an app-specific device token and the notification payload required for delivery.

The list also includes a LoRaWAN Network Server (The Things Industries B.V.) engaged for the optional connected-lite wireless-sensor telemetry path and, where enabled, the wireless start-inhibit interlock. It is engaged only where Pointnode provides the managed network server, and processes device identifiers, sensor uplink payloads (machine data), and — for the interlock — outbound relay command bytes. Where the Customer operates its own network server, that server is the Customer's own infrastructure and is not a Pointnode sub-processor.

Annex 3 — Security Measures

This annex is written for your security team. A plain-English overview of the same controls is published at /security.

• Network security. Modern encryption (TLS 1.2 or higher) on every external connection. On the Cloud dashboard: HSTS with preload-ready policy, Content-Security-Policy with allow-listed connection origins (the Pointnode database project and the Sentry ingest host only), X-Frame-Options DENY, Cross-Origin Opener Policy same-origin, Cross-Origin Resource Policy same-origin, and upgrade-insecure-requests in production.
• Database security. Customer data is isolated per-organisation at the database level — cross-tenant access is checked one layer below the application as well as in application permissions. Technically: Postgres Row-Level Security policies enforce isolation at the row level, an ensure_rls event trigger blocks any new table from being created without an RLS policy attached, and SECURITY DEFINER functions have their search_path pinned and their EXECUTE privilege revoked from PUBLIC with explicit per-role grants.
• Audit log integrity. The audit log is append-only during normal operation and cannot be edited through the application. Technically: the public.logs table has BEFORE UPDATE / DELETE triggers (logs_block_mutation, SECURITY DEFINER with locked search_path) that reject ordinary mutation attempts, including from the service-role connection used by Edge Functions. Retention pruning runs under a tightly scoped session-local marker recognised by the trigger, so the configured retention process remains the controlled deletion path.
• Per-asset device authentication. Each directly connected MQTT asset uses credentials scoped to that asset. In the default certificate mode, it authenticates with a unique X.509 client certificate cryptographically bound to its mqtt_id, so a compromised credential cannot authenticate as a different asset. Revocation is published for the broker to refresh within 5 minutes. Customer leaf certificates have a 3-year validity (in line with NIST SP 800-89 for industrial control systems with strong revocation infrastructure); Pointnode service certificates have a 90-day validity and auto-renew. Revocation propagates via a published Certificate Revocation List (CRL) that the message broker re-checks every 5 minutes. New MQTT assets are provisioned with certificate-based authentication by default; a legacy username/password mode remains available as a fallback. Records-only assets and managed wireless sensors do not use this MQTT certificate path.
• Rate limiting. Per-asset caps on how much data an asset can send (rate and number of distinct readings), enforced via token bucket per mqtt_id with per-asset overrides on the assets row. Per-actor rate limiting on mutating actions (e.g. 30/min for alarm thresholds, 5/hour for test email sends). Per-organisation daily caps on outbound transactional emails.
• Secrets management. Internal admin credentials are never exposed to browsers or to on-asset controllers. Third-party provider API keys (message broker admin API, email provider, payment-webhook signing secret) are stored as encrypted server-side secrets, not in the dashboard's environment. Customer-facing API tokens are stored as one-way SHA-256 hashes; the cleartext value is shown once on creation and never persisted.
• Encryption at rest. Industry-standard AES-256 managed by our hosting providers (covering the database, file storage, and the ingest service’s persistent volume). Authenticator-app shared secrets are held inside the authentication provider (provider-managed); recovery codes are stored as one-way hashes and verified by hash comparison only.
• Authentication. Email and password with optional authenticator-app multi-factor authentication. Self-serve MFA enrolment is available in the dashboard. Session cookies are httpOnly, secure, and sameSite=lax.
• Logging and monitoring. Structured logs across hosting providers. The ingest service exposes Prometheus metrics on its internal interface. An independent external monitor (UptimeRobot) polls public health endpoints (/api/health/cron, /api/health/stripe-webhook-errors, and the ingest's /health). Application errors are captured by Sentry where a project DSN is configured; email addresses appearing in event payloads are replaced with a deterministic SHA-256 hash before transmission, and a defence-in- depth string scrubber in the SDK's beforeSend hook redacts email-shaped strings that bypass the helper.
• Personnel. Pointnode staff with access to production systems are bound by confidentiality obligations and use unique named accounts. Access is reviewed periodically. Pointnode's engineering use of AI-assisted tooling does not touch production Customer data — see the sub-processor list for the relevant carve-out.
• Incident response. Documented runbook (PRODUCTION-RUNBOOK.md), with five symptom → diagnose → fix → escalation entries covering the most likely production incident shapes. 48-hour Customer notification per Section 7 above. Coordinated-disclosure policy published at /.well-known/security.txt per RFC 9116.
• Software supply chain. A complete inventory of every library shipped in production (a CycloneDX 1.6 Software Bill of Materials) is regenerated on every deployment and published at /sbom.json for Customer compliance teams to fetch.

Annex 4 — International Transfer Provisions

Transfers from the EEA to Pointnode in the UK can currently rely on the European Commission's UK adequacy decision. Where a transfer to Pointnode or an onward transfer to a Sub-processor is a restricted transfer and no adequacy route applies, the relevant parties will put an approved transfer instrument in place:

• For transfers governed by UK GDPR: the UK International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, as appropriate, plus the required data protection test / transfer risk assessment.
• For transfers governed by EU GDPR: the European Commission's Standard Contractual Clauses under Decision 2021/914, using the module that reflects the parties' actual roles, plus any required transfer impact assessment and supplementary measures.

Roles are determined for each transfer. For an onward transfer by Pointnode to a non-adequate Sub-processor, Pointnode is normally the data exporter and the Sub-processor is the data importer under the provider's DPA. Pointnode is not described as the importer for an onward transfer it makes itself.

Where execution of the SCCs / IDTA is required for a specific Customer, the populated annexes (Annex 1 — Description of Processing, Annex 2 — Security Measures, Annex 3 — Sub-processors) are physically attached to the executed instrument rather than incorporated by reference only. The web copy of this DPA is informational; the signed PDF version constitutes the contractual record.

Sign and return

To execute this DPA, email legal@pointnode.io with the Customer's legal entity name and the signing representative. We'll return a PDF version with both parties' details ready for signature.