⚠ Draft — Pending Lawyer Review — Not Yet Effective
LuxGov

Data Processing Agreement

Version 1.0· Effective Date: 5 June 2026· Luxemss Resources (202603121194)

Contents
  1. Parties
  2. Definitions
  3. Scope and Duration
  4. Subject Matter and Purpose of Processing
  5. Categories of Data Subjects
  6. Categories of Personal Data
  7. Obligations of the Processor
  8. Obligations of the Controller
  9. Security Measures
  10. Sub-processors
  11. Audit Rights
  12. Data Breach Notification
  13. Data Deletion and Return
  14. International Data Transfers
  15. Liability
  16. Governing Law
  17. Annex A — Description of Processing
  18. Annex B — Technical and Organisational Measures
  19. Annex C — List of Sub-processors

1. Parties

This Data Processing Agreement (“DPA”) is entered into between:

Data Controller: The entity subscribing to the LuxGov Platform (“Controller”, “Client”, or “Tenant”)

Data Processor: Luxemss Resources, SSM Registration No. 202603121194 (PG0587419-T), with its principal office at No 46, Jalan Bidara 3, Saujana Utama 3, 47000 Sungai Buloh, Selangor, Malaysia (admin@luxgov.net) (“Processor” or “LuxGov”)

This DPA supplements and forms part of the LuxGov Terms of Service (“Agreement”) and is effective from the date the Controller first accesses the Platform.

2. Definitions

“Applicable Data Protection Law” means all laws and regulations relating to the processing and protection of Personal Data that apply to the processing of Personal Data under this DPA, including PDPA 2010 (Malaysia), PDPA 2012 (Singapore), Privacy Act 1988 (Australia), UK GDPR and DPA 2018 (United Kingdom), and CCPA/CPRA (United States — California).

“Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data transmitted, stored, or otherwise processed by the Processor.

“Data Subject” means an identified or identifiable natural person whose Personal Data is processed under this DPA.

“Personal Data” means any information relating to a Data Subject that is processed by the Processor on behalf of the Controller in connection with the Platform.

“Processing” means any operation or set of operations performed on Personal Data, including collection, recording, organisation, structuring, storage, adaptation, alteration, retrieval, consultation, use, disclosure by transmission, dissemination, alignment, combination, restriction, erasure, or destruction.

“Sub-processor” means any third party engaged by the Processor to process Personal Data on behalf of the Controller.

“Standard Contractual Clauses” or “SCCs” means the standard contractual clauses for the transfer of personal data to processors established in third countries, as adopted by the relevant supervisory authority.

3. Scope and Duration

3.1. Scope. This DPA applies to the processing of Personal Data by the Processor on behalf of the Controller in connection with the provision of the LuxGov Platform services.

3.2. Duration. This DPA shall remain in effect for as long as the Processor processes Personal Data on behalf of the Controller, and shall automatically terminate upon the later of: (a) termination of the Agreement; or (b) the Processor ceasing all processing of the Controller’s Personal Data, including deletion in accordance with Section 13.

4. Subject Matter and Purpose of Processing

4.1. Subject Matter. The processing of building compliance documents, engineering drawings, professional certificates, project data, and associated personal data for the purpose of providing automated compliance auditing services.

4.2. Nature of Processing. The Processor performs the following processing activities:

  1. Ingestion: Receiving and securely storing building compliance documents uploaded by the Controller;
  2. Classification: Automated and AI-assisted classification of documents against jurisdiction-specific building code requirements;
  3. Analysis: Seven-stage compliance analysis pipeline, including Automated natural language processing via secure AI service provider;
  4. Scoring: Generation of compliance scores, deficiency lists, and non-conformance findings;
  5. Reporting: Generation of audit reports, evidence summaries, and compliance certificates;
  6. Storage: Secure storage of all data in tenant-isolated, jurisdiction-specific sovereign storage;
  7. Retention: Maintaining data in accordance with the retention schedule set out in the Privacy Policy;
  8. Deletion: Permanent deletion of data upon termination in accordance with Section 13.

4.3. Purpose. The Processor processes Personal Data solely for the purpose of providing the Platform services as described in the Agreement. The Processor shall not process Personal Data for any other purpose unless instructed in writing by the Controller.

5. Categories of Data Subjects

Personal Data processed under this DPA may relate to the following categories of Data Subjects:

6. Categories of Personal Data

The following categories of Personal Data may be processed:

7. Obligations of the Processor

7.1. Processing Instructions. The Processor shall process Personal Data only on documented instructions from the Controller, unless required to do so by applicable law. The Agreement and this DPA constitute the Controller’s complete initial instructions. Any additional instructions must be agreed in writing.

7.2. Confidentiality. The Processor shall ensure that all personnel authorised to process Personal Data have committed themselves to confidentiality obligations or are under an appropriate statutory obligation of confidentiality.

7.3. Security Measures. The Processor shall implement and maintain the technical and organisational security measures described in Annex B to protect Personal Data against Data Breaches. The Processor shall regularly test, assess, and evaluate the effectiveness of these measures.

7.4. Sub-processing. The Processor shall not engage another processor (Sub-processor) without prior written authorisation from the Controller, subject to Section 10.

7.5. Assistance with Data Subject Rights. The Processor shall assist the Controller, by appropriate technical and organisational measures, in fulfilling the Controller’s obligation to respond to requests from Data Subjects exercising their rights under Applicable Data Protection Law.

7.6. Assistance with Compliance. The Processor shall assist the Controller in ensuring compliance with the obligations regarding security of processing, notification of Data Breaches, data protection impact assessments, and prior consultation with supervisory authorities.

7.7. Demonstrating Compliance. The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in this DPA, and shall allow for and contribute to audits and inspections conducted by the Controller or a mandated auditor, subject to Section 11.

8. Obligations of the Controller

8.1. The Controller warrants that it has a lawful basis to provide Personal Data to the Processor for processing in accordance with this DPA.

8.2. The Controller is responsible for ensuring that appropriate consents or authorisations have been obtained from Data Subjects whose personal data is uploaded to the Platform, particularly where documents contain the personal data of third parties (e.g., professional engineers, certifiers).

8.3. The Controller shall provide processing instructions that comply with Applicable Data Protection Law.

8.4. The Controller shall notify the Processor promptly of any Data Subject rights requests that require the Processor’s assistance.

9. Security Measures

9.1. The Processor implements and maintains the technical and organisational measures detailed in Annex B, including but not limited to:

CategoryMeasure
Tenant IsolationPostgreSQL Row Level Security (RLS) enforcing per-tenant data boundaries at the database layer
Encryption at RestAES-256-GCM encryption for tenant state files; Azure Storage Service Encryption for all blob storage
Encryption in TransitTLS 1.2+ for all data transmissions between clients, the Platform, and third-party services
Secret ManagementAzure Key Vault for all credentials, API keys, encryption keys, and connection strings — zero hardcoded secrets
Access ControlRole-based access control (RBAC) across defined tenant and platform roles, fail-closed enforcement at startup
AuthenticationMicrosoft Entra ID (Azure AD) with JWT token validation, JWKS key verification, and session management
Audit LoggingSHA-256 hash-chained tamper-evident audit trail; WORM immutability on published audit outputs
ImmutabilitySOFT WORM for UK/SG/MY (allows deletion after retention); HARD LOCK for AU/US (deletion prohibited before expiry)
Rate LimitingPer-tenant, per-plan rate limits preventing abuse and denial-of-service
Network SecurityAzure App Service with managed identity; no public database endpoint; firewall rules for administrative access

9.2. The Processor shall not materially reduce the overall level of security without prior written notice to the Controller.

10. Sub-processors

10.1. The Controller provides general written authorisation for the Processor to engage the Sub-processors listed in Annex C.

10.2. The Processor shall:

  1. Enter into a written agreement with each Sub-processor imposing data protection obligations no less onerous than those set out in this DPA;
  2. Remain fully liable to the Controller for the performance of each Sub-processor’s obligations;
  3. Notify the Controller at least thirty (30) days before engaging any new Sub-processor or replacing an existing Sub-processor, providing the name, processing activities, and location of the proposed Sub-processor.

10.3. The Controller may object to a new Sub-processor on reasonable grounds within fifteen (15) days of receiving notice. If the objection is not resolved, the Controller may terminate the affected services without penalty.

11. Audit Rights

11.1. The Processor shall make available to the Controller all information reasonably necessary to demonstrate compliance with this DPA.

11.2. The Controller (or its mandated independent auditor) may conduct an audit of the Processor’s data processing activities and security measures:

  1. Routine audits: Once per calendar year, with at least thirty (30) days’ prior written notice;
  2. Incident-triggered audits: Immediately upon reasonable suspicion of a Data Breach or material non-compliance.

11.3. Audits shall be conducted during normal business hours, shall not unreasonably interfere with the Processor’s operations, and shall be subject to reasonable confidentiality obligations.

11.4. The Processor may satisfy audit requests by providing written responses to the Controller's specific audit questions, security architecture documentation, and evidence of implemented technical and organisational measures as described in Annex B.

11.5. The Controller shall bear its own costs for audits, except where an audit reveals material non-compliance by the Processor.

12. Data Breach Notification

72-Hour Notification Commitment

The Processor shall notify the Controller of a Data Breach without undue delay and in no event later than seventy-two (72) hours after becoming aware of the breach.

12.2. The notification shall include, to the extent available:

  1. A description of the nature of the Data Breach, including the categories and approximate number of Data Subjects and Personal Data records affected;
  2. The name and contact details of the Processor’s Data Protection Officer or other contact point (admin@luxgov.net);
  3. A description of the likely consequences of the Data Breach;
  4. A description of the measures taken or proposed to address the breach, including measures to mitigate its adverse effects.

12.3. Where it is not possible to provide all information simultaneously, the Processor shall provide information in phases without undue further delay.

12.4. The Processor shall cooperate with the Controller and take reasonable steps to assist in the investigation, mitigation, and remediation of the Data Breach.

12.5. Notification of a Data Breach shall not be construed as an acknowledgement of fault or liability.

13. Data Deletion and Return

13.1. Upon termination of the Agreement, or upon the Controller’s written request, the Processor shall, at the Controller’s election:

  1. Return all Personal Data to the Controller in a structured, commonly used, and machine-readable format (JSON, CSV, DOCX, PDF); or
  2. Delete all Personal Data from the Processor’s systems, including from active storage, backups, and archives (subject to regulatory retention requirements).

13.2. The Controller shall make its election within thirty (30) days of termination. If no election is made, the Processor shall delete all Personal Data.

Regulatory Retention Exception

Where Applicable Data Protection Law or regulatory requirements mandate retention of certain data (e.g., WORM-protected audit logs in AU/US jurisdictions with retention periods up to 7 years), the Processor shall: isolate such data from active processing; apply appropriate security measures for the duration of retention; delete such data promptly upon expiry of the applicable retention period; and provide the Controller with written confirmation of the specific data retained and the applicable retention period.

13.4. The Processor shall provide written confirmation of data deletion within thirty (30) days of completing the deletion process.

14. International Data Transfers

14.1. The Processor stores Personal Data in the Azure region corresponding to the Controller’s Jurisdiction, as specified in the Privacy Policy.

14.2. Where Personal Data is transferred to a country outside the Controller’s Jurisdiction, the Processor shall ensure that appropriate safeguards are in place:

TransferSafeguard
AI processing via US-based AI service providerSub-processor DPA + Standard Contractual Clauses (where required)
Payment processing via Stripe (US-based)Stripe DPA + Standard Contractual Clauses
Azure infrastructure management (cross-region telemetry)Microsoft DPA + Standard Contractual Clauses

14.3. For UK Tenants: The International Data Transfer Agreement (IDTA) or UK Addendum to the EU SCCs is incorporated by reference where Personal Data is transferred outside the UK.

14.4. For Australian Tenants: The Processor ensures that overseas recipients of Personal Data are bound by obligations substantially similar to the Australian Privacy Principles, in compliance with APP 8.

14.5. For Malaysian Tenants: Cross-border transfers comply with Section 129 of the PDPA 2010, ensuring that Personal Data is transferred only to jurisdictions with adequate levels of protection or with the Data Subject’s consent.

14.6. For Singaporean Tenants: Cross-border transfers comply with the PDPA 2012 Transfer Limitation Obligation (Section 26), ensuring that recipients provide a standard of protection comparable to the PDPA.

15. Liability

15.1. The liability of each party under this DPA is subject to the limitations and exclusions of liability set out in the Agreement (Terms of Service, Section 12).

15.2. Nothing in this DPA limits or excludes liability for: (a) Data Breaches caused by wilful default or gross negligence; (b) any liability that cannot be limited by Applicable Data Protection Law.

16. Governing Law

16.1. This DPA shall be governed by and construed in accordance with the governing law of the Agreement (Malaysia, subject to jurisdiction-specific provisions as set out in the Terms of Service, Section 19).

16.2. Any dispute arising out of this DPA shall be resolved in accordance with the dispute resolution provisions of the Agreement (mediation, then AIAC arbitration).

Annex A — Description of Processing

FieldDescription
Subject matterProcessing of building compliance data and associated personal data for the purpose of providing automated compliance auditing services
DurationFor the term of the subscription Agreement plus any post-termination retention period
Nature of processingCollection, storage, classification, AI-assisted analysis, scoring, report generation, archival, and deletion
PurposeProviding the LuxGov compliance intelligence platform services: automated audit of building documents against jurisdiction-specific building codes
Categories of Data SubjectsTenant employees, professional engineers, architects, building certifiers, inspectors, project stakeholders
Categories of Personal DataNames, professional titles, registration numbers, email addresses, organisational roles, professional opinions, authentication tokens, session data, IP addresses, usage timestamps
ControllerThe subscribing Tenant organisation
ProcessorLuxemss Resources (LuxGov)
Sensitive dataNot ordinarily processed. If compliance documents contain health and safety incident data or similar sensitive categories, the Controller must notify the Processor

Annex B — Technical and Organisational Measures

B.1. Access Control

MeasureDetail
AuthenticationMicrosoft Entra ID (Azure AD) with OAuth 2.0 / OpenID Connect; JWT token validation with JWKS key verification
Role-based accessDefined roles across platform and tenant scopes
Permission granularityDot-notation permissions enforced at middleware layer
Fail-closed enforcementPlatform refuses to start if role configuration is missing, malformed, or empty
Session managementToken expiry timers with 5-minute warning; automatic logout on expiry
Multi-tenant isolationTenant identity derived exclusively from cryptographic JWT claims, never from request parameters

B.2. Encryption

MeasureDetail
In transitTLS 1.2+ mandatory for all client-server and server-to-server communications
At rest (state files)AES-256-GCM with keys managed in Azure Key Vault
At rest (blob storage)Azure Storage Service Encryption (SSE) with Microsoft-managed keys
Secret managementAll credentials, API keys, and encryption keys stored in Azure Key Vault (kv-luxgov-core); zero hardcoded secrets in codebase
Key rotationSupported via Key Vault secret versioning

B.3. Data Isolation

MeasureDetail
Database isolationPostgreSQL Row Level Security (RLS) policies enforce tenant-scoped queries; application sets SET LOCAL app.current_tenant per connection
Storage isolationPer-tenant namespaced containers within jurisdiction-specific Azure Blob Storage accounts
Network isolationAzure App Service with managed identity; PostgreSQL accessible only via Azure private networking and explicit firewall rules

B.4. Audit and Integrity

MeasureDetail
Audit loggingAll platform events recorded with SHA-256 hash chaining (tamper-evident)
WORM immutabilityPublished audit outputs written to WORM-protected storage: SOFT WORM for UK/SG/MY; HARD LOCK for AU/US
Change trackingGit-based version control for all platform code; CI/CD pipeline with automated testing

B.5. Availability and Resilience

MeasureDetail
ComputeAzure App Service with 2 Gunicorn workers × 4 threads = 8 concurrent requests
DeploymentAutomated CI/CD pipeline with health check retry loops (10 × 30 seconds), rollback capability
MonitoringMicrosoft Application Insights for performance monitoring and error diagnostics
BackupAzure-managed PostgreSQL backups; blob storage geo-redundancy per Azure region policy

B.6. Incident Response

MeasureDetail
Breach detectionApplication-level logging; Azure security alerts
Notification timeline72-hour notification to affected Controller
ResponseDocumented incident response procedure; designated DPO contact

Annex C — List of Sub-processors

Sub-processorProcessing ActivityData CategoriesLocation
Microsoft Corporation (Azure) Cloud infrastructure: compute (App Service), database (PostgreSQL Flexible Server), storage (Blob Storage), identity (Entra ID), key management (Key Vault), monitoring (Application Insights) All categories of Personal Data and Tenant Data Per-jurisdiction Azure regions (see Privacy Policy Section 7)
Anthropic PBC (Claude API) AI-powered compliance analysis: document classification, natural language processing, compliance scoring. Anthropic’s API Terms of Service prohibit using API inputs for model training. Building compliance document content (may contain personal data of engineers, certifiers, project stakeholders) United States
Stripe Inc. Payment processing: subscription billing, invoice generation, payment card processing. LuxGov does not receive or store payment card details. Billing data: customer name, email, subscription plan, payment history United States

Current as of: 5 June 2026

The Processor will notify the Controller at least thirty (30) days before adding or replacing any Sub-processor.

§ Execution

This DPA is executed by the authorised representatives of each party.

Data Controller

Name

Title

Organisation

Date

Signature

Data Processor

Name

Title

Organisation: Luxemss Resources

Date

Signature