HabiTrak Data Processing Agreement

This Data Processing Agreement ("DPA") forms part of the HabiTrak Terms between Habitrak Software Ltd ("HabiTrak", the Processor), which is registered with the Information Commissioner's Office as a data controller (registration number ZC266969), and the customer organisation that subscribes to HabiTrak (the Controller). Where it conflicts with the Terms in relation to personal data, this DPA prevails. It is made under Article 28 of the UK GDPR, and the Article 28(3) point each clause meets is shown beside its heading.

1. Roles. The Controller is the controller of the resident, staff and operational personal data it and its Users put into the Service, including special-category data. HabiTrak processes that data as the Controller's processor. HabiTrak is a controller in its own right for account, billing, prospect and website-visitor data, which this DPA does not cover — the Privacy Policy does. HabiTrak does not decide the purposes or means of processing the Controller's data.

2. Particulars of processing (Article 28(3), opening words).
Subject-matter: providing the HabiTrak supported-housing management service.
Duration: the subscription, plus the read-only and return-or-deletion steps in clause 11.
Nature and purpose: hosting, storing, organising, retrieving, displaying, exporting and deleting housing, compliance, support and safeguarding records so the Controller can run and evidence its supported-housing service.
Types of personal data: identity and contact details; tenancy and occupancy records; support plans and notes; risk and safeguarding information; health and care needs; property compliance records; staff account details and the record of which User made key changes — including special-category data.
Data subjects: residents and applicants; the Controller's staff and its managing agents' staff; support and maintenance workers; next of kin and professional contacts named in records.

3. Documented instructions [Article 28(3)(a)]. HabiTrak processes the personal data only on the Controller's documented instructions — this DPA, the Terms, the Controller's configuration and use of the Service, and any further written instruction agreed — including as regards transfers outside the UK. If UK law requires other processing, HabiTrak will tell the Controller before processing unless that law forbids it on important grounds of public interest. HabiTrak will immediately tell the Controller if, in its opinion, an instruction infringes data protection law.

4. Confidentiality [Article 28(3)(b)]. Everyone HabiTrak authorises to process the data is bound by a written duty of confidentiality or a statutory one, and access is limited to people who need it to provide or support the Service. Who that is today is set out in Annex 2.

5. Security [Article 28(3)(c), Article 32]. HabiTrak takes the measures described in Annex 2, which it may improve but will not reduce in overall protection.

6. Sub-processors [Article 28(3)(d), 28(2) and 28(4)]. The Controller gives general written authorisation for the sub-processors listed in Annex 3. HabiTrak will give at least 30 days' notice by email before it adds or replaces a sub-processor of the Controller's personal data, and will update Annex 3. The Controller may object on reasonable data-protection grounds within that period; if the objection cannot be resolved, the Controller may cancel without penalty and receive a pro-rata refund of any prepaid fees for the unused period. A sub-processor in Annex 3 may itself add or replace a processor of its own (an onward processor) on the notice its own terms give HabiTrak, which can be shorter than 30 days (for IDDQD Limited, 14 days). When that happens, HabiTrak passes the notice to the Controller promptly after receiving it, and the Controller may object to HabiTrak within whatever remains of that sub-processor's notice period; the same cancellation and refund right then applies. HabiTrak imposes the same data-protection obligations on each sub-processor by contract and remains fully liable to the Controller for their performance.

7. Data-subject requests [Article 28(3)(e)]. The Service lets the Controller find, correct, export (as PDF report packs and file downloads) and erase a data subject's records itself, subject to the safeguards in clause 11. If a request reaches HabiTrak directly, HabiTrak will not answer it but will pass it to the Controller without undue delay and within 5 working days. Where the Controller cannot meet a request through the Service, HabiTrak will help, taking into account the nature of the processing. "Working day" means Monday to Friday, excluding UK bank holidays.

8. Security incidents, breaches and impact assessments [Article 28(3)(f), Articles 32 to 36]. HabiTrak will notify the Controller of a personal data breach affecting the Controller's data without undue delay after becoming aware of it, and in any event within 48 hours, with the information the Controller needs to notify the Information Commissioner's Office (or the body that replaces it) and, where required, the people affected, and will keep the Controller updated as more is known. HabiTrak's address for breach notices in both directions is support@habitrak.co.uk. HabiTrak will give reasonable help with data protection impact assessments and prior consultation with the Information Commissioner's Office, taking into account the nature of processing and the information available to HabiTrak.

9. Information and audits [Article 28(3)(h)]. HabiTrak will make available the information necessary to demonstrate compliance with Article 28, and will allow for and contribute to audits, including inspections, by the Controller or an auditor it appoints. HabiTrak may first answer with Annex 2, the sub-processor list in Annex 3 and the history the Service keeps on each record (when it was created and last changed, and the User recorded on key actions); where that is not enough, an audit may take place once in any 12 months on at least 30 days' notice, at the Controller's cost, and additionally after a breach affecting the Controller's data or where a regulator requires it.

10. Where data is held. The Controller's personal data is stored in the United Kingdom, in the AWS London region (eu-west-2): the database, uploaded files, logs and the sign-in service. Uploaded files are delivered through Amazon CloudFront, which can hold a cached copy of a file at AWS edge locations in Europe, North America and Israel while serving it; a postcode or address typed into an address search goes to IDDQD Limited, and email sent to HabiTrak's support and billing mailboxes is held by Google Workspace, as Annex 3 describes. By accepting this DPA the Controller instructs these transfers, which take place under the safeguards in each supplier's published data processing terms. HabiTrak will not otherwise transfer the Controller's personal data outside the UK except on the Controller's documented instructions and with a transfer mechanism UK law recognises.

11. Retention, erasure and the end of the Service [Article 28(3)(g)]. While the subscription continues, the Controller's records stay in the Service until the Controller erases them. HabiTrak never deletes them on its own initiative, and the Service applies no automatic retention period or deletion to them. When a tenancy ends, the residence is kept as an ended, read-only record, and the former resident can still read their own documents and agreements in the Service for twelve months after the move-out date. The Service refuses to erase a residence while a safeguarding concern raised by someone other than that resident is still on record for it (UK GDPR Article 17(3)), and while support plans, support sessions, risk assessments or fire-safety inductions are still on record for it; the Controller decides whether and when those records are removed. Any longer retention the Controller must observe — for example keeping safeguarding records for 7 years — is the Controller's own instruction to apply: HabiTrak keeps no retention period of its own for the Controller's records, and the Controller must export, or ask HabiTrak to return, any records it must keep before the read-only period after its subscription ends (Terms clause 6.10) is over. When the Service ends, the Controller can use the Service's exports and file downloads (clause 7) during that read-only period and chooses whether HabiTrak deletes or returns the personal data; HabiTrak carries out that choice and deletes existing copies, unless UK law requires HabiTrak to keep them. If the Controller has made no choice by the end of the read-only period, the Terms clause 6.10 instruction applies and HabiTrak deletes the personal data. Database backups and earlier versions of uploaded files expire on their normal 30-day cycle and are not restored for any other purpose. HabiTrak's own billing records (Terms clause 6.8) are HabiTrak's controller data, covered by the Privacy Policy, not the Controller's records.

12. Liability. Each party's liability under or in connection with this DPA is subject to the limits and exclusions in the Terms. Nothing in this DPA or the Terms limits any liability a party has to a data subject under Article 82 of the UK GDPR, or any liability that cannot lawfully be limited.

Annex 1 — Particulars of processing

As clause 2.

Annex 2 — Technical and organisational measures

These are the measures in place in HabiTrak's production service, each read from the deployed production environment and the Service's code on 7 October 2026. Each line says what is in place and where it was verified.

1. Encryption in transit. Every connection from the internet uses HTTPS with TLS 1.2 as the minimum: the API's load balancer accepts only TLS 1.3 and 1.2 and answers plain HTTP only with a redirect to HTTPS; the website, the web app and uploaded files are served through Amazon CloudFront with TLS 1.2 as the minimum and HTTP Strict Transport Security (two years, including subdomains). The database refuses any connection that does not use TLS, and every storage bucket refuses requests that do not use TLS. Inside the private network, the hop from the load balancer to the application is plain HTTP; it runs only within private subnets, behind a firewall rule that admits the load balancer alone. Verified: production infrastructure code (load balancer, content delivery, database and storage modules) and the live database setting check.

2. Encryption at rest (database, file storage, backups). The database (MySQL 8.4 on Amazon RDS) is encrypted with a HabiTrak-managed AWS KMS key with automatic key rotation, and its automated backups and snapshots are encrypted with it. Uploaded files are held in a dedicated storage bucket, marked as special-category data, encrypted with their own HabiTrak-managed rotating key that only the application (and CloudFront, to serve a file) may use. The AWS audit trail and the application, database, firewall and network logs are each encrypted with their own rotating key; the other storage buckets use AES-256. Verified: production infrastructure code; live reads of the database instance (storage encrypted), its four automated snapshots (each encrypted) and the six HabiTrak KMS key aliases, 7 October 2026.

3. Access control and least privilege (who holds production access, MFA). Production access to the AWS account is held by HabiTrak's director alone. People sign in to AWS through AWS IAM Identity Center, through one administrators' group with one-hour sessions. The AWS root account has multi-factor authentication on and has no access keys. Deployment pipelines hold no stored AWS keys: they assume short-lived roles (one-hour sessions) through OpenID Connect, under a permissions boundary that also stops them switching off the audit trail, threat detection, alarms or the security alert topic. The running application's own role may only read its runtime secret, connect to the database as the application user (by IAM database authentication, so no database password is stored), store, list and delete objects in the uploads bucket, administer Users in the sign-in service and send email from HabiTrak's domain. The database and the application servers run in private subnets with no public IP address; network rules allow internet traffic to reach only the load balancer, the application only from the load balancer, and the database only from the application; remote shell access into the application containers is switched off; web application firewalls front the API and the websites. An alarm fires on any AWS console sign-in without MFA. The AWS account has no IAM users, so no long-lived user access keys exist. Verified: AWS account summary and IAM user list reads, 7 October 2026 (root MFA on, no root access keys, no IAM users); HabiTrak's record of production access, 5 October 2026; production infrastructure code (identity, deployment roles, permissions boundary, application role, network and alarm modules); infrastructure runbook.

4. Sign-in and sessions. Users sign in through Amazon Cognito in the London region with their email address and a password, using the Secure Remote Password protocol. Passwords must be at least 8 characters and contain upper-case and lower-case letters, a number and a symbol; a temporary invitation password lasts 7 days; account recovery goes to the verified email address only. Access and identity tokens expire after 60 minutes; refresh tokens last 90 days in the app and 5 days for the server's own client; tokens can be revoked; sign-in responses do not reveal whether an account exists. Nobody can create an account directly with the sign-in service: accounts are created by invitation or through HabiTrak's own sign-up, which is rate-limited. Every API request other than a short published list (health check, sign-up, current Terms and the payment-provider webhook) needs a valid signed token, checked against the sign-in service's issuer and keys and for expiry; the server keeps no session; a token for a person HabiTrak does not know is refused, never turned into a new account. Multi-factor sign-in is not offered to Users. Verified: production sign-in configuration (Cognito user pool and app clients) and the Service's security configuration code.

5. Per-organisation data separation. All organisations share one database and one uploads bucket, and separation between them is enforced by the application. Every request is resolved to the single role the User is acting in (a staff assignment, a provider membership or a residence), and access is decided under that role only. Opening a record passes one authorisation check against the record; lists are filtered inside the database query by the same rule, never fetched and filtered afterwards. Automated architecture tests require every endpoint that takes a record identifier to pass that check, and automated isolation tests check that one provider, operator or resident cannot reach another's records. An organisation whose trial or payment has lapsed becomes read-only: its records can be read and exported, but not changed. Uploaded files are stored under random identifiers and are served by links that are handed only to a User who passed the check on the record the file belongs to; the links are not signed and do not expire, so anyone holding a link can open that file. Verified: the Service's authorisation code, its architecture and isolation tests, and the file storage and delivery code; production infrastructure code (shared database and bucket, unsigned file delivery).

6. Audit trail and log retention. The Service records when each record was created and last changed, when each file was uploaded, and which User renewed each certificate and when; which User took other actions is recorded for some record types only, not for every action. It does not keep a log of who viewed which record. AWS account activity is recorded by a multi-region AWS CloudTrail trail with log-file integrity validation, including access to the uploads bucket, in a private, versioned, encrypted bucket. The audit trail, application logs, database error log, network flow logs, web application firewall logs, sign-in function logs and container performance logs are each kept for 400 days, and the trail cannot be set below 396 days; platform, access and security logs are therefore kept for at least 12 months. The database's slow-query and general logs are not exported, because they would copy resident data. Verified: live log-group and trail reads, 7 October 2026; the Service's record model code; production infrastructure code (audit trail and logging modules).

7. Backups and restore test date. The database takes automated daily backups with point-in-time restore, kept for 30 days and encrypted; deletion protection is on, a final snapshot is taken if the database is ever deleted, and automated backups are kept after a deletion. The database runs in a single availability zone, so recovery is by restore. Uploaded files are versioned, and earlier versions of a file are kept for 30 days, the same horizon as the database backups. Restore readiness verified 7 October 2026; a full restore rehearsal has not been run. Verified: live reads of the database instance and its automated backups, 7 October 2026 (30-day retention, point-in-time restore active, deletion protection on, storage encrypted, four encrypted automated snapshots available); production infrastructure code (database and uploads bucket).

8. Patching. The database runs MySQL 8.4 with automatic minor-version upgrades on, which AWS applies in a weekly maintenance window on Fridays, 02:17 to 02:47 UTC. The application runs on AWS Fargate on the current platform version, so there are no servers for HabiTrak to patch and each new task starts on the patched platform. Container images cannot be overwritten once published and are scanned for known vulnerabilities when pushed. The load balancer, content delivery, sign-in, storage and email services are managed and patched by AWS. Amazon GuardDuty, AWS Security Hub (CIS and AWS Foundational Security Best Practices standards), AWS Config and IAM Access Analyzer run continuously. Verified: live database instance read, 7 October 2026 (maintenance window, automatic minor-version upgrade on); production infrastructure code (database, container service, image registry and security-baseline modules).

9. Supplier assurance. The sub-processors in Annex 3 process the Controller's data under their own published data processing terms: Amazon Web Services under the AWS Data Processing Addendum, IDDQD Limited under its Data Processing Agreement (retrieved 5 October 2026), and Google under its published data processing terms for Google Workspace. The application, database, uploaded files, logs and the sign-in service run in the AWS London region (eu-west-2); CloudFront's certificates and the websites' firewall are set up in the AWS US East (N. Virginia) region, as AWS requires, and CloudFront serves files from edge locations in Europe, North America and Israel (clause 10). Stripe's position is stated below Annex 3. Verified: production infrastructure code (region, content delivery and edge modules; the domain's mail records); the suppliers' published terms.

10. Staff training owner. HabiTrak's director, the only person at HabiTrak with production access, owns and gives the data-protection and security training of anyone at HabiTrak who can see it. Verified: HabiTrak's record of roles and production access, 5 and 6 October 2026.

11. Incident-response contact and breach decision-maker. HabiTrak's director is the incident-response contact and decides on breach notification, including the notice to the Controller under clause 8. Security monitoring raises alerts on one channel: 15 CIS alarms (among them root-account use, unauthorised API calls, console sign-in without MFA, failed console sign-ins, and changes to permissions, the audit trail, encryption keys, bucket policies, firewall rules and the network), eight workload alarms, database events and GuardDuty findings all go to HabiTrak's security alert topic, which has a confirmed email subscription. Verified: live alert topic subscription read, 7 October 2026; HabiTrak's record of roles, 6 October 2026; production infrastructure code (security-baseline and workload alarm modules).

12. The customer mailbox. support@habitrak.co.uk (support, data-subject requests and breach notices) and billing@habitrak.co.uk (invoices and payment queries). Verified: HabiTrak's record of its mailboxes, 6 October 2026.

Annex 3 — Sub-processors of the Controller's personal data

Stripe processes HabiTrak's own billing data (the Customer's billing contact, invoices and payments) for HabiTrak, and as a controller for its own fraud-prevention and legal duties. HabiTrak sends Stripe only the price, the number of rooms billed and HabiTrak's own subscription reference — never resident records or addresses — so Stripe is not a sub-processor of the Controller's personal data; it is listed in the Privacy Policy.