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
| Risk | Likelihood | Severity |
|---|---|---|
| Database breach exposing NI / UTR / bank details | Low | High |
| Storage misconfiguration leaks ID document photos | Low | High |
| Tenant-isolation failure exposing another firm's data | Low | High |
| Account takeover of a firm owner | Low | High |
| Encryption key compromise | Very low | High |
| Excessive retention of archived workers | Medium | Low |
| Onboarding link interception (worker shares it on WhatsApp) | Medium | Medium |
| DSAR fulfilled with another firm's data accidentally included | Low | Medium |
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.