Data Protection Impact Assessment — Summary

A public summary of the Article 35 DPIA Altix maintains. Processes biometric data and financial identifiers, so a DPIA is required.

Effective 30 April 2026

1. Why a DPIA is required

Under UK GDPR Article 35, a Data Protection Impact Assessment is required where processing is "likely to result in a high risk" to data subjects. Altix processes:

  • Biometric data — worker profile photos used as identity evidence (special category, Article 9).
  • Identity documents — passports / driving licences uploaded to evidence right to work.
  • Financial identifiers — bank sort code, account number, name on card, used for payroll.
  • Tax identifiers — National Insurance number, UTR, used for HMRC CIS reporting.

Combined, this is a high-sensitivity data set. The DPIA is therefore mandatory rather than discretionary.

2. Description of the processing

Subcontractor firms collect onboarding data from their workers via an Altix-hosted form, accessed through a one-time link shared by the firm. The data is used by the firm for payroll, right-to-work checks, certification expiry tracking, and construction-site compliance. Altix is the processor; the firm is the controller.

Volume: tens of workers per firm; firms range from sole traders to ~50-person subcontractors. Processing is continuous: data sits in the platform until a worker is archived or the controller requests erasure.

3. Necessity and proportionality

Each data category has a specific lawful basis (see privacy notice §5). Construction industry compliance — CDM 2015, CIS, right-to-work checks — requires this data; collecting less would not enable the controller to meet its statutory obligations. No category is collected speculatively.

4. Risks identified

RiskLikelihoodSeverity
Database breach exposing NI / UTR / bank detailsLowHigh
Storage misconfiguration leaks ID document photosLowHigh
Tenant-isolation failure exposing another firm's dataLowHigh
Account takeover of a firm ownerLowHigh
Encryption key compromiseVery lowHigh
Excessive retention of archived workersMediumLow
Onboarding link interception (worker shares it on WhatsApp)MediumMedium
DSAR fulfilled with another firm's data accidentally includedLowMedium

5. Mitigations in place

  • Application-layer encryption (AES-256-GCM) of NI number, UTR, sort code, account number, share code — even with full database read access, an attacker cannot recover plaintext without the separately-held encryption key.
  • Tenant isolation enforced at the database layer on every table holding personal data, scoped by company membership. Site-scoped managers see only their site's workers.
  • Storage bucket private; documents accessed only via short-lived signed URLs (15 min for upload, 30 min for DSAR).
  • Strict CSP, HSTS preload, X-Frame-Options DENY to neutralise XSS and clickjacking vectors.
  • Onboarding tokens are 30-day TTL, single-use after stage 3; the public token URL never echoes sensitive data back even if the link leaks.
  • Append-only audit log retained 24 months — every consequential write is recorded with actor, IP, user-agent.
  • MFA available for all owners (TOTP).
  • Retention cron hard-purges accounts past their 30-day grace and trims old logs.
  • Breach runbook with 72-hour ICO notification, see /legal/breach-runbook.
  • No third-party trackers; only auth and preference cookies (PECR-exempt).

6. Residual risk

After mitigations, the highest residual risk is encryption-key compromise via the Vercel project access list. A future improvement is to migrate the key to a managed KMS (AWS KMS or GCP KMS) with envelope encryption — this is on the roadmap but adds a sub-processor and operational cost, so it's deferred until the customer base justifies it.

The second-highest residual risk is DSAR misuse: an owner could request the full export (which includes every worker) on behalf of a single requester. The export endpoint is owner-only and audit-logged, but Altix relies on the controller to filter the export down before forwarding to the data subject.

7. Sign-off and review

The DPIA is reviewed when processing materially changes (new data categories, new sub-processors, significant scope changes) and at least annually. Material findings from each review are summarised in the changelog of this document.

Operator: Viktor (sole trader). Contact: daster1708@gmail.com.