Chapter 7 · ProjectVIEW ERP Master SaaS Framework Chapter 7 sets the data-protection obligations for personal data processed in ProjectVIEW ERP under a dual-jurisdiction model: the EU GDPR (Regulation 2016/679) and the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021). It allocates controller and processor roles and defines the Data Processing Agreement, sub-processor management, technical and organisational measures, data-subject rights, breach notification and AI-specific safeguards. GDPREU Regulation 2016/679 UAE PDPLFederal Decree-Law No. 45/2021 ≤ 24 hcritical breach: Provider → Controller 7.1 Overview & Purpose This chapter defines the data-protection and privacy obligations that govern the processing of Personal Data within and by the ProjectVIEW ERP Platform throughout the Subscription Term. It establishes the regulatory baseline, allocates Controller and Processor responsibilities, sets out the technical and organisational safeguards applied to Personal Data, and specifies the breach-notification and data-subject-rights procedures that both Parties shall follow. The Provider operates under a dual-jurisdiction compliance model, maintaining concurrent alignment with: (a) the European Union’s General Data Protection Regulation (EU) 2016/679 (“GDPR”), including all adopted opinions and guidelines of the European Data Protection Board (EDPB); and (b) (ii) the United Arab Emirates’ Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (“UAE PDPL”) and its implementing regulations. Where a Customer operates in additional jurisdictions, supplementary data-processing addenda may be executed pursuant to §7.14. DANAOS Projects Software Solutions LLC has established as a major objective the adoption of data-protection principles and the permeation of all daily business operations with an acute data-protection mentality. The Provider has consistently achieved compliance with the existing legal framework regarding data protection and has undertaken the actions derived from the repealing of Directive 95/46/EC, the establishment of GDPR (EU) 2016/679, and the enactment of the UAE PDPL. This chapter, together with the Data Processing Agreement (“DPA”) annexed to this Framework (§7.5), constitutes the binding contractual framework required under GDPR Article 28 and UAE PDPL Article 29 for the lawful processing of Personal Data by a Data Processor on behalf of a Data Controller. 7.2 Scope This chapter applies to all Personal Data processed by the Provider in connection with the delivery of the Platform and related services, including but not limited to: (a) Customer Employee Data: Personnel records, payroll data, timesheets, attendance, labour-productivity records, and identity information processed within modules PV_07 (HRMS– Payroll) and PV_A (Site Operations & Labour Productivity). (b) Customer Contacts & Counterparties: Names, email addresses, telephone numbers, and commercial correspondence of subcontractors, suppliers, clients, and other third parties managed within modules PV_03, PV_04, PV_09, and PV_10. (c) End-User Credentials & Activity Logs: User-account credentials, authentication tokens, session logs, IP addresses, browser fingerprints, and audit-trail data generated by the Platform’s Users & Roles Management module (STY). (d) Support & Communication Data: Personal Data contained within support tickets, WhatsApp Business group messages, training recordings, AI-transcribed session content, and any other communication exchanged through the Provider’s omnichannel support model (§4.2). (e) Project & Financial Data: Where project records, procurement data, accounting entries, or cost-control records contain identifiable natural-person information (e.g., named workers, consultant invoices), such data falls within scope. (f) Configuration & Master Data: Master-data elements that reference identifiable individuals, including personnel registers, organisational hierarchies, approval matrices, and signatory authorities. 7.3 Regulatory Framework The Provider’s data-protection programme is built on the following regulatory instruments, standards, and guidance: Ref Instrument / Standard Relevance RF-01 GDPR (EU) 2016/679 Primary regulation for EEA-origin Personal Data; defines Controller/Processor obligations, data-subject rights, breach notification, and cross-border transfer rules. RF-02 UAE Federal Decree-Law No. 45 of 2021 (PDPL) Primary regulation for UAE-resident Personal Data; mirrors GDPR in substance with UAE-specific provisions on data localisation, Emirati data sovereignty, and UAE Data Office oversight. RF-03 EDPB Guidelines & Adopted Opinions Interpretive guidance on GDPR application, including SCCs, data transfers, legitimate interest, and DPIA methodology. RF-04 EU Standard Contractual Clauses (SCCs) — Commission Implementing Decision (EU) 2021/914 Approved mechanism for Controller-to-Processor and Controller-to-Controller cross-border transfers of Personal Data outside the EEA. RF-05 ISO/IEC 27701:2019 Extension to ISO 27001 establishing a Privacy Information Management System (PIMS); used as the organisational baseline for Processor privacy controls. RF-06 ISO/IEC 27001:2022 Information Security Management System standard; foundational for the technical and organisational measures described in §7.8. RF-07 NIST Privacy Framework 1.0 Voluntary framework used to align privacy risk assessment with enterprise risk management (§7.10). RF-08 EU AI Act — Regulation (EU) 2024/1689 Regulates AI systems; relevant to the Provider’s use of AI-assisted transcription, AIOps, and contextual in-app guidance (§5.3, §6.2). RF-09 NIST AI Risk Management Framework (AI RMF 1.0) Voluntary framework for identifying and mitigating risks in AI systems; applied alongside the EU AI Act for governance of AI components. GDPR Full Text — EUR-Lex UAE PDPL — Federal Decree-Law No. 45 of 2021 EU Standard Contractual Clauses (2021/914) ISO/IEC 27701:2019 — PIMS EU AI Act — Regulation (EU) 2024/1689 7.4 Roles & Responsibilities 7.4.1 Controller–Processor Allocation By nature of its business operations, the Provider’s role under applicable data-protection law is determined as follows: (a) Data Processor: The Provider acts as a Data Processor regarding any Personal Data processing activity conducted on behalf of the Customer within the Platform. The Customer, as Data Controller, determines the purposes and means of processing; the Provider processes Personal Data solely on the Controller’s documented instructions (§7.5). (b) Data Controller (limited scope): The Provider acts as an independent Data Controller regarding processing activities conducted on its own employees’ Personal Data (e.g., Provider staff assigned to the Customer’s account), business-contact data for commercial relationship management, and anonymised/aggregated analytics that cannot be re-identified to any natural person. (c) Sub-Processor engagement: The Provider shall not engage any Sub-Processor to process Personal Data without the prior specific or general written authorisation of the Controller. Where general authorisation is given, the Provider shall notify the Controller of any intended additions or replacements of Sub-Processors, giving the Controller the opportunity to object (§7.6). 7.4.2 Data Protection Officer The Provider has designated a Data Protection Officer (DPO) in accordance with GDPR Articles 37–39 and UAE PDPL Article 10. The DPO is responsible for: (i) monitoring compliance with applicable data-protection legislation; (ii) advising on Data Protection Impact Assessments (§7.10); (iii) serving as the contact point for supervisory authorities; and (iv) handling data-subject inquiries. Data subjects and Customer contacts may reach the DPO at: admin@danaos-projects.com DANAOS employees may contact the DPO for any clarification regarding data-protection principles and request guidelines to perform data processing optimally and avoid potential infringement of the legislation. 7.4.3 RACI Matrix — Data Protection Activity Provider DPO Provider Ops Customer DPO / Privacy Lead Customer PM Champion Supervisory Authority Define processing purposes & lawful basis C I A/R I I I Maintain Record of Processing Activities (RoPA) A/R C R I I I Conduct Data Protection Impact Assessment A/R C R C I I Implement technical & organisational measures C A/R I I I I Respond to Data Subject Access Requests C R A/R I I I Detect & classify Personal Data breach C A/R I I I I Notify Controller of breach (≤72 hrs) A/R R I I I I Notify Supervisory Authority (≤72 hrs) C I A/R I I R Notify affected Data Subjects C I A/R C C I Approve Sub-Processor engagements C R A I I I Annual privacy audit & compliance review A/R C R I I I Cross-border transfer impact assessment A/R C R I I I Legend: R = Responsible (does the work) │ A = Accountable (owns the outcome) │ C = Consulted │ I = Informed 7.5 Data Processing Agreement (DPA) The Parties might execute a Data Processing Agreement (“DPA”) which constitutes the Article 28 contract required under GDPR and the equivalent processor agreement required under UAE PDPL Article 29. The DPA shall, at a minimum, specify: (a) Subject matter & duration: The DPA covers all Personal Data processing performed by the Provider in delivering the Platform throughout the Subscription Term plus any post-termination data-retention or return period (§7.13). (b) Nature & purpose of processing: Hosting, storing, transmitting, backing-up, and computing Personal Data within the Customer’s dedicated private sovereign environment for the purpose of enabling the Customer’s construction project management, financial management, human-resources management, and procurement operations. (c) Categories of Data Subjects: Customer employees, subcontractor personnel, supplier contacts, client contacts, site workers, and any other natural persons whose data the Customer inputs into the Platform. (d) Types of Personal Data: Identification data (names, national IDs, passport numbers), contact data (email, phone, address), employment data (role, salary, attendance, leave), financial data (bank details for payroll), project-assignment data, access credentials, and audit-trail metadata. (e) Documented instructions: The Provider shall process Personal Data only on documented instructions from the Controller, including with regard to transfers to third countries, unless required to do so by Union or Member State law to which the Provider is subject (GDPR Art. 28(3)(a)). (f) Confidentiality: All Provider personnel authorised to process Personal Data have committed to confidentiality or are under an appropriate statutory obligation of confidentiality (GDPR Art. 28(3)(b)). (g) Deletion or return: Upon termination, the Provider shall, at the Controller’s election, delete or return all Personal Data and delete existing copies unless Union or Member State law requires storage (§7.13). (h) Audit rights: The Provider shall make available to the Controller all information necessary to demonstrate compliance, and shall allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller (§7.11). 7.6 Sub-Processor Management The Provider engages a limited number of Sub-Processors to deliver components of the Platform and associated services. The following Sub-Processor governance applies: (a) Authorisation model: The Customer grants general authorisation for Sub-Processor engagement subject to the Provider’s obligation to: (i) maintain a current register of Sub-Processors; (ii) notify the Customer of any intended additions or replacements no fewer than thirty (30) calendar days before the new Sub-Processor commences processing; and (iii) provide sufficient information to enable the Customer to exercise its right of objection. (b) Right of objection: If the Customer reasonably objects to a new Sub-Processor on legitimate data-protection grounds, the Provider shall either: (i) refrain from engaging the Sub-Processor and offer an alternative; or (ii) if no alternative is feasible, either Party may terminate the affected services without penalty, subject to a reasonable wind-down period. (c) Flow-down obligations: The Provider shall impose on each Sub-Processor, by way of contract, the same data-protection obligations as set out in the DPA (§7.5), in particular providing sufficient guarantees to implement appropriate technical and organisational measures such that the processing meets GDPR and UAE PDPL requirements. (d) Liability: The Provider remains fully liable to the Customer for the performance of the Sub-Processor’s obligations under the DPA. Where a Sub-Processor fails to fulfil its data-protection obligations, the Provider shall be liable for the acts and omissions of the Sub-Processor as if they were the Provider’s own acts or omissions. 7.6.1 Sub-Processor Register The following table lists the Sub-Processors engaged by the Provider as at the Effective Date. The register is maintained and updated pursuant to §7.6(a). Sub-Processor Processing Activity Location Safeguard Microsoft Azure IaaS hosting of Customer’s dedicated private sovereign environment (compute, storage, networking) Region selected per Customer DPA (default: UAE North / West Europe) EU SCCs + Microsoft DPA Microsoft 365 Email communication, collaboration tools used by Provider operations team EEA / UAE (per licence configuration) EU SCCs + Microsoft DPA WhatsApp (Meta Platforms) Expedient informal communication via shared WhatsApp Business groups (§4.2) EEA (Meta Ireland) EU SCCs + Meta DPA AI Transcription Service Processing of recorded training-session audio for AI-generated transcripts (§6.2) EEA / UAE (per Provider configuration) EU SCCs + Provider-assessed DPA Note: The Customer’s Platform data resides in a dedicated private sovereign environment; no customer data is co-mingled across tenants. The hosting region is selected per the Customer’s DPA and may be restricted to a specific Azure region to satisfy data-localisation requirements under the UAE PDPL or other applicable law. 7.7 Data Protection Principles Any Personal Data processing activity conducted by the Provider, either as Data Controller or Data Processor, shall be characterised by the following principles, aligned with GDPR Article 5 and UAE PDPL Article 4: Principle GDPR Art. UAE PDPL Art. Provider Implementation Lawfulness, fairness & transparency 5(1)(a) 4(1) Processing is based on at least one lawful basis (Art. 6); data subjects are informed in a concise, transparent, intelligible manner via the Customer’s privacy notices; Provider assists Customer in maintaining transparency. Purpose limitation 5(1)(b) 4(2) Personal Data is processed exclusively for the documented purposes specified in the DPA (§7.5). The Provider does not process Customer data for its own purposes (e.g., analytics, marketing, profiling) unless explicitly authorised in writing. Data minimisation 5(1)(c) 4(3) The Platform’s module design collects only data elements required for the activated business functions. Master-data checklists (§6.4.3) define the minimum viable dataset per module. Accuracy 5(1)(d) 4(4) The Platform provides data-validation rules, duplicate-detection, and referential-integrity checks. The Customer retains responsibility for the accuracy of input data; the Provider provides tools to maintain it. Storage limitation 5(1)(e) 4(5) Data-retention policies (§7.12) ensure Personal Data is deleted or anonymised when no longer necessary. Automated retention-period enforcement is configurable per Customer. Integrity & confidentiality 5(1)(f) 4(6) Technical and organisational measures (§7.8) ensure Personal Data is protected against unauthorised or unlawful processing, accidental loss, destruction, or damage. Accountability 5(2) 4(7) The Provider maintains Records of Processing Activities (RoPA), conducts DPIAs where required, and makes compliance evidence available for audit (§7.11). 7.8 Technical & Organisational Measures (TOMs) The Provider implements and maintains the following technical and organisational measures to ensure a level of security appropriate to the risk, in accordance with GDPR Article 32 and UAE PDPL Article 28. These measures are aligned with ISO/IEC 27001:2022 and ISO/IEC 27701:2019 control objectives. The Provider’s Information Security Management System (ISMS) is maintained by the IT Department. 7.8.1 Access Control & Authentication (a) Password complexity: Minimum length, character-class requirements, and prohibition of common/breached passwords enforced at the application layer. (b) Password expiration: Configurable password-rotation policy; default rotation period aligned with NIST SP 800-63B guidance. (c) Failed-authentication lockout: Account lockout after a configurable number of consecutive failed attempts; lockout duration escalates with repeated violations. (d) Password history: The system prevents reuse of the last N passwords (configurable per Customer policy). (e) Multi-factor authentication (MFA): Second-factor authentication is supported and recommended for all administrative and privileged accounts. MFA methods include TOTP (time-based one-time password), push notification, and FIDO2 hardware keys. (f) Single Sign-On (SSO): The Platform supports integration with enterprise identity providers via SAML 2.0 and OpenID Connect, enabling centralised credential management and reducing the attack surface associated with password proliferation. (g) Session management: Away-from-keyboard auto-lock mechanism; configurable idle-session timeout; session invalidation on password change or account suspension. (h) Role-based access control (RBAC): The Users & Roles Management module (STY) enforces granular, role-based access control at the module, function, field, and record level. Segregation of duties is enforced through conflicting-role detection. (i) Restricted remote access: Remote administrative access to the Provider’s infrastructure is restricted to authorised personnel via encrypted VPN tunnels with MFA; all remote sessions are logged and auditable. 7.8.2 Encryption (a) Data in transit: All client–server communication is encrypted using TLS 1.2 or higher. End-to-end data-transmission encryption is enforced across all Platform interfaces, APIs, and integration endpoints. (b) Data at rest: Transparent Data Encryption (TDE) is applied to all database instances. Database backups are encrypted using AES-256 encryption. Encryption keys are managed through the cloud provider’s Key Management Service with customer-managed key (CMK) options available. (c) Key management: Encryption keys are rotated according to a defined schedule. Key-management procedures follow ISO 27001 Annex A.10 controls. Hardware Security Modules (HSMs) are used for root key protection where available. 7.8.3 Database Security (a) Database connections: Connections to database instances are controlled, monitored, and restricted to authorised application-layer services and designated DBA personnel only. (b) Default accounts: Default system accounts are secured by the DBA; all default passwords are changed immediately upon provisioning; unnecessary default accounts are disabled. (c) Minimum privilege: Database user accounts are provisioned with minimum permissions and roles necessary for their function. System privileges are removed unless explicitly required and approved. (d) Audit logging: Database audit logging captures all DDL operations, privileged-user activity, failed authentication attempts, and data-export operations. Logs are retained for a minimum of twelve (12) months and are tamper-evident. (e) DBA remote access: Remote database administration is restricted to named individuals via encrypted channels with multi-factor authentication. All DBA sessions are logged with full command-level audit trail. 7.8.4 Network Security (a) Perimeter defence: Next-generation firewalls, Web Application Firewalls (WAF), and DDoS-protection services guard the platform perimeter. Network segmentation isolates the Customer’s private sovereign environment from other Provider infrastructure. (b) Intrusion detection & monitoring: Cloud-native SIEM and network-monitoring tools provide real-time alerting on anomalous traffic patterns, port-scan attempts, and lateral-movement indicators. (c) Vulnerability management: Regular vulnerability scans and annual penetration tests are conducted. Critical and high-severity vulnerabilities are remediated within the timeframes specified in §3.5 (Incident Priority Classification). 7.8.5 Organisational Measures (a) Confidentiality agreements: All Provider personnel authorised to process Personal Data have signed confidentiality/non-disclosure agreements and are under an appropriate statutory obligation of confidentiality. (b) Training & awareness: Provider personnel receive annual data-protection training covering GDPR, UAE PDPL, breach reporting, social engineering, and secure-coding practices. (c) Clean desk & clear screen: Clean-desk and clear-screen policies are enforced in all Provider facilities to prevent inadvertent exposure of Personal Data. (d) Asset-use policy: All hardware and software assets are used exclusively for business purposes and the implementation of tasks respective to each employee’s job description. 7.9 Data Subject Rights The Provider recognises the rights of Data Subjects as defined in GDPR Chapter III (Articles 12–23) and UAE PDPL Articles 12–18, and shall assist the Customer in fulfilling its obligation to respond to Data Subject requests in accordance with GDPR Article 28(3)(e) and UAE PDPL Article 29. The Provider shall: (a) Promptly notify the Customer upon receipt of a Data Subject request related to Customer data, without responding to the Data Subject directly unless instructed by the Customer. (b) Provide the Customer with the technical capability to extract, rectify, restrict, port, or delete Personal Data through Platform functionality or, where not available through the UI, through Provider-executed database operations within the timeframes required by law. (c) Maintain audit trails of all Data Subject request fulfilment actions for a minimum of twenty-four (24) months. 7.9.1 Rights Fulfilment Matrix Right GDPR Art. UAE PDPL Art. Platform Capability Response SLA Right of access 15 13 Data-export function generates structured report of all Personal Data associated with a Data Subject’s identity ≤30 calendar days Right to rectification 16 14 In-app record editing with full audit trail; batch-correction support for bulk updates ≤30 calendar days Right to erasure (‘right to be forgotten’) 17 15 Erasure workflow anonymises or deletes all instances of a Data Subject’s Personal Data across modules, backups, and logs (subject to legal-hold exceptions) ≤30 calendar days Right to restriction of processing 18 16 Record-level processing-restriction flag; restricted data remains stored but is excluded from active processing, reporting, and API responses ≤72 hours (flag) Right to data portability 20 17 Machine-readable export in CSV, JSON, and XML formats; API-based extraction available ≤30 calendar days Right to object 21 18 Processing-objection flag triggers review; Provider ceases processing pending assessment of compelling legitimate grounds ≤72 hours (flag) Legal-hold override: Where erasure or restriction conflicts with a legal obligation (e.g., statutory record-retention, pending litigation, regulatory investigation), the Provider shall inform the Customer and the Data Subject of the legal basis for continued processing, and shall restrict processing to the minimum necessary for compliance. 7.10 Data Protection Impact Assessment (DPIA) Where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons, the Customer (as Controller) shall carry out a Data Protection Impact Assessment in accordance with GDPR Article 35 and UAE PDPL Article 23. The Provider shall: (a) Provide the Customer with all information necessary to conduct the DPIA, including documentation of the Platform’s data flows, retention policies, access-control model, and cross-border transfer mechanisms. (b) Assist the Customer in conducting the DPIA where requested, including by providing a pre-completed DPIA template covering the standard processing operations performed by the Platform. (c) Notify the Customer if, in the Provider’s opinion, a new feature, module activation, integration, or change in processing operations triggers the need for a new or updated DPIA. (d) AI-specific DPIA: Where the Platform’s AI components (e.g., AI-assisted transcription, AIOps anomaly detection, contextual in-app guidance) process Personal Data, a supplementary AI-specific DPIA shall be conducted addressing algorithmic bias, automated decision-making transparency, data-minimisation in training sets, and the rights of Data Subjects under GDPR Article 22 (automated individual decision-making). This assessment shall also consider obligations under the EU AI Act (Regulation (EU) 2024/1689) and the NIST AI Risk Management Framework. 7.11 Audit & Compliance 7.11.1 Provider Obligations The Provider shall: (d) Maintain a Record of Processing Activities (RoPA) in accordance with GDPR Article 30, covering all processing operations performed on behalf of the Customer. (e) Make available to the Customer all information necessary to demonstrate compliance with the obligations laid down in GDPR Article 28 and UAE PDPL Article 29. (f) Allow for and contribute to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer, subject to: (i) reasonable advance notice of not less than thirty (30) calendar days; (ii) audit scope limited to the processing activities covered by the DPA; (iii) the auditor’s execution of a non-disclosure agreement acceptable to the Provider; and (iv) audits being conducted during normal business hours in a manner that minimises disruption. (g) Immediately inform the Customer if, in the Provider’s opinion, an instruction from the Customer infringes GDPR, UAE PDPL, or other applicable data-protection law (GDPR Art. 28(3)(h)). 7.11.2 Audit Frequency & Scope The following audit schedule applies: Audit Type Frequency Scope Output Provider self-assessment Quarterly RoPA completeness, TOM effectiveness, Sub-Processor compliance, incident log review Internal compliance report shared with Customer DPO Customer-initiated audit Annually (or upon material breach) Full DPA compliance, technical controls inspection, personnel-training records, breach-response drill Audit findings report with remediation timeline Third-party certification audit Annually ISO 27001:2022 / ISO 27701:2019 scope — ISMS and PIMS controls Certificate and Statement of Applicability Regulatory authority audit As required Full regulatory scope as directed by the supervisory authority Cooperation and documentation provision per GDPR Art. 58 7.12 Data Retention & Destruction Personal Data shall not be retained for longer than is necessary for the purposes for which it was collected. The following retention framework applies: (a) Active processing: Personal Data is actively processed for the duration of the Subscription Term and any post-termination wind-down period agreed under the DPA. (b) Retention periods: Where specific retention periods are mandated by applicable law (e.g., labour-law record retention, tax-authority requirements, regulatory preservation orders), the Provider shall retain the minimum necessary data for the prescribed period, clearly segregated and access-restricted. (c) Automated enforcement: The Platform supports configurable data-retention policies that automatically flag, archive, or purge records that exceed their defined retention period. The Customer defines the retention rules; the Provider implements the technical enforcement. (d) Secure destruction: When Personal Data is deleted, the Provider shall ensure secure destruction through: (i) cryptographic erasure for encrypted data (rendering the encryption key irrecoverable); (ii) multi-pass overwrite for unencrypted media; and (iii) deletion confirmation certificates provided to the Customer upon request. (e) Backup retention: Backup copies containing Personal Data are subject to the same retention and destruction policies. The Provider shall ensure that deleted Personal Data is purged from all backup cycles within ninety (90) calendar days of the deletion instruction, unless a shorter period is specified in the DPA. NIST SP 800-88 Rev. 1 — Guidelines for Media Sanitization 7.13 Data Return & Portability on Termination Upon termination or expiry of the Framework, the following data-return and portability provisions apply: (a) Data-return period: The Customer shall have a period of sixty (60) calendar days from the effective date of termination to request the return of all Personal Data and Customer Data in a structured, commonly used, machine-readable format (CSV, JSON, XML, or SQL dump). (b) Format options: The Provider shall offer data export in at least three machine-readable formats. The export shall include: (i) all transactional data across activated modules; (ii) master-data registers; (iii) document attachments; (iv) audit logs; and (v) configuration metadata sufficient to reconstruct the Customer’s operational setup in a successor system. (c) Deletion after return: Upon confirmation that the Customer has received and verified the exported data, or upon expiry of the sixty (60) day data-return period (whichever is earlier), the Provider shall securely delete all Personal Data from all systems, including production databases, staging environments, backups, and disaster-recovery replicas. (d) Deletion certificate: The Provider shall issue a written certificate of deletion within thirty (30) calendar days of completing the secure-destruction process, confirming that all Personal Data has been irreversibly destroyed from all Provider-controlled systems and media. (e) Residual obligations: Data-protection obligations under this chapter survive termination with respect to any Personal Data retained by the Provider pursuant to a legal obligation, until such data is securely destroyed. 7.14 Cross-Border Data Transfers Where the processing of Personal Data involves or may involve the transfer of Personal Data to a third country or international organisation, the following provisions apply: (a) EEA-origin data: Transfers of Personal Data originating from the European Economic Area to countries not covered by an adequacy decision under GDPR Article 45 shall be governed by the EU Standard Contractual Clauses (SCCs) adopted under Commission Implementing Decision (EU) 2021/914, supplemented by a Transfer Impact Assessment (TIA) where required by EDPB Recommendations 01/2020. (b) UAE-origin data: Transfers of Personal Data originating from the UAE to countries outside the UAE shall comply with UAE PDPL Article 22 (cross-border transfer provisions), including any data-localisation requirements imposed by the UAE Data Office or sector-specific regulators. (c) Data-localisation options: The Provider’s dedicated private sovereign environment model enables the Customer to select the geographic region (Azure Region) in which all Customer Data resides and is processed. Where the Customer requires data to remain within a specific jurisdiction (e.g., UAE for government contracts, EEA for EU-regulated entities), the Provider shall ensure that no data leaves the designated region, including for backup and disaster-recovery purposes. (d) Transfer Impact Assessment: Prior to initiating any new cross-border transfer mechanism, the Provider shall conduct and document a Transfer Impact Assessment evaluating: (i) the legal framework of the recipient country; (ii) the supplementary measures in place; and (iii) the practical enforceability of Data Subject rights in the recipient jurisdiction. 7.15 Personal Data Breach Management 7.15.1 Breach Detection & Classification The Provider has established procedures, governed by the IT Department, to detect, classify, and respond to Personal Data breaches. The Provider’s SIEM and AIOps tooling provides automated anomaly detection; all alerts classified as potential Personal Data breaches are immediately escalated to the DPO. Breaches are classified by severity: Severity Criteria Notification Timeline Example Critical High risk to rights and freedoms of Data Subjects; large-scale breach; sensitive data categories affected Provider → Controller: ≤24 hrs Controller → Authority: ≤72 hrs Controller → Data Subjects: without undue delay Database exfiltration; ransomware encrypting HR/payroll data; credential compromise of admin accounts High Material risk to rights and freedoms; limited-scale breach; standard Personal Data categories Provider → Controller: ≤48 hrs Controller → Authority: ≤72 hrs Unauthorised access to project-contact data; email misdirection containing Personal Data Medium Low risk; containment achieved quickly; limited data exposure Provider → Controller: ≤72 hrs Controller → Authority: at Controller’s discretion Failed brute-force attempt contained by lockout; exposure of non-sensitive metadata Low Negligible risk; no actual exposure of Personal Data Provider → Controller: monthly summary report Anomalous login pattern with no data access; policy-violation alert triggered by false positive 7.15.2 Breach Notification Procedure The Provider shall notify the Customer (as Controller) of any confirmed or suspected Personal Data breach as follows: (a) Initial notification: Within the timeframes specified in §7.15.1, the Provider shall notify the Customer’s designated DPO/privacy lead via the primary communication channel (email to designated address, followed by telephone confirmation for Critical and High severity breaches). The initial notification shall include: (i) nature of the breach; (ii) categories and approximate number of Data Subjects affected; (iii) categories and approximate number of records concerned; (iv) likely consequences; and (v) measures taken or proposed to mitigate adverse effects. (b) Follow-up reporting: Where the full details are not available at the time of the initial notification, the Provider shall provide information in phases without undue delay as it becomes available (GDPR Art. 33(4)). (c) Root-cause analysis: The Provider shall deliver a full root-cause analysis report to the Customer within fifteen (15) business days of breach containment, including: timeline of events, affected systems and data, root cause, containment actions, remediation measures, and recommendations to prevent recurrence. (d) Regulatory cooperation: The Provider shall assist the Customer in: (i) notifying the competent supervisory authority (GDPR Art. 33, UAE PDPL Art. 28); and (ii) communicating the breach to affected Data Subjects where required (GDPR Art. 34). The Provider shall not communicate directly with the supervisory authority or Data Subjects regarding Customer data without the Customer’s prior written consent, unless required by law. 7.15.3 Breach Response Drill The Provider and Customer shall conduct a joint Personal Data breach-response drill at least annually, simulating a Critical-severity breach scenario. The drill shall test: (i) detection-to-notification timelines; (ii) communication-channel effectiveness; (iii) containment-procedure execution; and (iv) regulatory-notification readiness. Findings from each drill shall be documented and incorporated into process improvements. 7.16 AI-Specific Data Protection The Provider’s use of artificial-intelligence components within the Platform (including AI-assisted transcription, AIOps, predictive analytics, and contextual in-app guidance) is subject to the following data-protection controls, aligned with the EU AI Act (Regulation (EU) 2024/1689) and the NIST AI RMF: (a) No cross-tenant training: Customer data is never used to train AI models that serve other customers or improve the Provider’s general-purpose AI capabilities. Each Customer’s AI-generated outputs (e.g., transcription models, predictive analytics) are trained and scoped exclusively to that Customer’s data within their dedicated sovereign environment. (b) Data minimisation in AI: AI components process the minimum Personal Data necessary to deliver their function. Where possible, data is pseudonymised or anonymised before AI processing. (c) Automated decision-making: The Platform does not make decisions based solely on automated processing that produce legal effects or similarly significant effects on Data Subjects (GDPR Art. 22) unless: (i) the Customer explicitly configures such processing; (ii) the Customer ensures a lawful basis (consent, contract necessity, or Member State law); and (iii) human review is available. (d) AI transparency: The Provider documents the purpose, data inputs, logic, and output scope of each AI component in the Platform’s technical documentation. This documentation is available to the Customer for DPIA purposes (§7.10) and regulatory inspection. (e) Bias monitoring: Where AI components process Personal Data that includes special categories (e.g., ethnicity, nationality in HRMS modules), the Provider implements bias-monitoring checks and reports findings to the Customer as part of the quarterly self-assessment (§7.11.2). 7.17 Process Register The following table enumerates the contractual and operational processes governed by this chapter. Each process is assigned a unique identifier, trigger condition, responsible handler, approver, expected outcome, and cross-reference to the governing section. Proc-ID Process Name Trigger Handler Approver Outcome Section P-7.01 DPA Execution Agreement signing or renewal Provider DPO Customer DPO Signed DPA annexing Art. 28 obligations §7.5 P-7.02 Sub-Processor Notification New or replacement Sub-Processor identified Provider Ops Customer DPO 30-day advance notice with objection window §7.6 P-7.03 Sub-Processor Objection Resolution Customer objects to Sub-Processor Provider DPO Both Parties Alternative Sub-Processor or service termination option §7.6(b) P-7.04 Data Subject Access Request (DSAR) Data Subject submits request to Controller Customer DPO Customer DPO Structured report delivered within 30 days §7.9 P-7.05 Data Subject Erasure Request Data Subject exercises right to erasure Provider Ops + Customer DPO Customer DPO Anonymisation/deletion with legal-hold check §7.9 P-7.06 DPIA Initiation New module, feature, or processing change triggers high-risk threshold Provider DPO Customer DPO Completed DPIA with risk register §7.10 P-7.07 AI-Specific DPIA AI component processes Personal Data Provider DPO Customer DPO AI DPIA covering bias, transparency, Art. 22 §7.10 P-7.08 Breach Detection SIEM/AIOps alert or manual detection of suspected breach Provider Ops Provider DPO Classified breach record; containment initiated §7.15.1 P-7.09 Breach Notification (Controller) Confirmed/susp ected breach classified ≥ Medium Provider DPO Provider DPO Notification to Customer within SLA timeline §7.15.2 P-7.10 Breach Notification (Authority) Controller determines authority notification required Customer DPO Customer DPO ≤72-hour notification to supervisory authority §7.15.2 P-7.11 Root-Cause Analysis Breach containment completed Provider Ops Provider DPO + Customer DPO RCA report within 15 business days §7.15.2(c ) P-7.12 Breach Response Drill Annual schedule or ad-hoc trigger Provider DPO + Customer DPO Both Parties Drill report with improvement actions §7.15.3 P-7.13 Data Return on Termination Agreement termination/expi ry Provider Ops Customer PM Data exported in machine-readable format within 60 days §7.13 P-7.14 Secure Data Destruction Data-return period expires or deletion requested Provider Ops Provider DPO Deletion certificate issued within 30 days §7.12 P-7.15 Cross-Border Transfer Assessment New transfer mechanism or destination identified Provider DPO Customer DPO Documented TIA with supplementary measures §7.14 P-7.16 Privacy Audit (Internal) Quarterly schedule Provider DPO Provider DPO Compliance report shared with Customer §7.11.2 P-7.17 Privacy Audit (Customer) Annual schedule or material breach trigger Customer Auditor Customer DPO Findings report with remediation timeline §7.11.2 P-7.18 Retention Policy Review Annual schedule or regulatory change Provider DPO + Customer DPO Customer DPO Updated retention schedule and automated enforcement rules §7.12 7.18 Process-Flow Schematic The following diagram illustrates the data-protection lifecycle from DPA execution through ongoing compliance monitoring, breach response, and data return on termination. ① DPA Execution & Lawful Basis → ② RoPA & Privacy-by-Design → ③ TOM Implementation ▼ ④ DPIA (incl. AI DPIA) → ⑤ Ongoing Processing & Monitoring → ⑥ Data Subject Rights Fulfilment ▼ ⑦ Breach Detection & Response → ⑧ Audit & Compliance Review → ⑨ Data Return / Destruction Feedback loop: Stage ⑨ (Data Return/Destruction) feeds back into Stage ② (RoPA) for record-keeping of destruction activities and Stage ⑧ (Audit) for post-termination compliance verification. Stages ④–⑦ operate continuously throughout the Subscription Term with quarterly self-assessment checkpoints (§7.11.2). ← PreviousTraining & Knowledge TransferNext →Information Security & Confidentiality See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →
Chapter 7 · ProjectVIEW ERP Master SaaS Framework Chapter 7 sets the data-protection obligations for personal data processed in ProjectVIEW ERP under a dual-jurisdiction model: the EU GDPR (Regulation 2016/679) and the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021). It allocates controller and processor roles and defines the Data Processing Agreement, sub-processor management, technical and organisational measures, data-subject rights, breach notification and AI-specific safeguards. GDPREU Regulation 2016/679 UAE PDPLFederal Decree-Law No. 45/2021 ≤ 24 hcritical breach: Provider → Controller 7.1 Overview & Purpose This chapter defines the data-protection and privacy obligations that govern the processing of Personal Data within and by the ProjectVIEW ERP Platform throughout the Subscription Term. It establishes the regulatory baseline, allocates Controller and Processor responsibilities, sets out the technical and organisational safeguards applied to Personal Data, and specifies the breach-notification and data-subject-rights procedures that both Parties shall follow. The Provider operates under a dual-jurisdiction compliance model, maintaining concurrent alignment with: (a) the European Union’s General Data Protection Regulation (EU) 2016/679 (“GDPR”), including all adopted opinions and guidelines of the European Data Protection Board (EDPB); and (b) (ii) the United Arab Emirates’ Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (“UAE PDPL”) and its implementing regulations. Where a Customer operates in additional jurisdictions, supplementary data-processing addenda may be executed pursuant to §7.14. DANAOS Projects Software Solutions LLC has established as a major objective the adoption of data-protection principles and the permeation of all daily business operations with an acute data-protection mentality. The Provider has consistently achieved compliance with the existing legal framework regarding data protection and has undertaken the actions derived from the repealing of Directive 95/46/EC, the establishment of GDPR (EU) 2016/679, and the enactment of the UAE PDPL. This chapter, together with the Data Processing Agreement (“DPA”) annexed to this Framework (§7.5), constitutes the binding contractual framework required under GDPR Article 28 and UAE PDPL Article 29 for the lawful processing of Personal Data by a Data Processor on behalf of a Data Controller. 7.2 Scope This chapter applies to all Personal Data processed by the Provider in connection with the delivery of the Platform and related services, including but not limited to: (a) Customer Employee Data: Personnel records, payroll data, timesheets, attendance, labour-productivity records, and identity information processed within modules PV_07 (HRMS– Payroll) and PV_A (Site Operations & Labour Productivity). (b) Customer Contacts & Counterparties: Names, email addresses, telephone numbers, and commercial correspondence of subcontractors, suppliers, clients, and other third parties managed within modules PV_03, PV_04, PV_09, and PV_10. (c) End-User Credentials & Activity Logs: User-account credentials, authentication tokens, session logs, IP addresses, browser fingerprints, and audit-trail data generated by the Platform’s Users & Roles Management module (STY). (d) Support & Communication Data: Personal Data contained within support tickets, WhatsApp Business group messages, training recordings, AI-transcribed session content, and any other communication exchanged through the Provider’s omnichannel support model (§4.2). (e) Project & Financial Data: Where project records, procurement data, accounting entries, or cost-control records contain identifiable natural-person information (e.g., named workers, consultant invoices), such data falls within scope. (f) Configuration & Master Data: Master-data elements that reference identifiable individuals, including personnel registers, organisational hierarchies, approval matrices, and signatory authorities. 7.3 Regulatory Framework The Provider’s data-protection programme is built on the following regulatory instruments, standards, and guidance: Ref Instrument / Standard Relevance RF-01 GDPR (EU) 2016/679 Primary regulation for EEA-origin Personal Data; defines Controller/Processor obligations, data-subject rights, breach notification, and cross-border transfer rules. RF-02 UAE Federal Decree-Law No. 45 of 2021 (PDPL) Primary regulation for UAE-resident Personal Data; mirrors GDPR in substance with UAE-specific provisions on data localisation, Emirati data sovereignty, and UAE Data Office oversight. RF-03 EDPB Guidelines & Adopted Opinions Interpretive guidance on GDPR application, including SCCs, data transfers, legitimate interest, and DPIA methodology. RF-04 EU Standard Contractual Clauses (SCCs) — Commission Implementing Decision (EU) 2021/914 Approved mechanism for Controller-to-Processor and Controller-to-Controller cross-border transfers of Personal Data outside the EEA. RF-05 ISO/IEC 27701:2019 Extension to ISO 27001 establishing a Privacy Information Management System (PIMS); used as the organisational baseline for Processor privacy controls. RF-06 ISO/IEC 27001:2022 Information Security Management System standard; foundational for the technical and organisational measures described in §7.8. RF-07 NIST Privacy Framework 1.0 Voluntary framework used to align privacy risk assessment with enterprise risk management (§7.10). RF-08 EU AI Act — Regulation (EU) 2024/1689 Regulates AI systems; relevant to the Provider’s use of AI-assisted transcription, AIOps, and contextual in-app guidance (§5.3, §6.2). RF-09 NIST AI Risk Management Framework (AI RMF 1.0) Voluntary framework for identifying and mitigating risks in AI systems; applied alongside the EU AI Act for governance of AI components. GDPR Full Text — EUR-Lex UAE PDPL — Federal Decree-Law No. 45 of 2021 EU Standard Contractual Clauses (2021/914) ISO/IEC 27701:2019 — PIMS EU AI Act — Regulation (EU) 2024/1689 7.4 Roles & Responsibilities 7.4.1 Controller–Processor Allocation By nature of its business operations, the Provider’s role under applicable data-protection law is determined as follows: (a) Data Processor: The Provider acts as a Data Processor regarding any Personal Data processing activity conducted on behalf of the Customer within the Platform. The Customer, as Data Controller, determines the purposes and means of processing; the Provider processes Personal Data solely on the Controller’s documented instructions (§7.5). (b) Data Controller (limited scope): The Provider acts as an independent Data Controller regarding processing activities conducted on its own employees’ Personal Data (e.g., Provider staff assigned to the Customer’s account), business-contact data for commercial relationship management, and anonymised/aggregated analytics that cannot be re-identified to any natural person. (c) Sub-Processor engagement: The Provider shall not engage any Sub-Processor to process Personal Data without the prior specific or general written authorisation of the Controller. Where general authorisation is given, the Provider shall notify the Controller of any intended additions or replacements of Sub-Processors, giving the Controller the opportunity to object (§7.6). 7.4.2 Data Protection Officer The Provider has designated a Data Protection Officer (DPO) in accordance with GDPR Articles 37–39 and UAE PDPL Article 10. The DPO is responsible for: (i) monitoring compliance with applicable data-protection legislation; (ii) advising on Data Protection Impact Assessments (§7.10); (iii) serving as the contact point for supervisory authorities; and (iv) handling data-subject inquiries. Data subjects and Customer contacts may reach the DPO at: admin@danaos-projects.com DANAOS employees may contact the DPO for any clarification regarding data-protection principles and request guidelines to perform data processing optimally and avoid potential infringement of the legislation. 7.4.3 RACI Matrix — Data Protection Activity Provider DPO Provider Ops Customer DPO / Privacy Lead Customer PM Champion Supervisory Authority Define processing purposes & lawful basis C I A/R I I I Maintain Record of Processing Activities (RoPA) A/R C R I I I Conduct Data Protection Impact Assessment A/R C R C I I Implement technical & organisational measures C A/R I I I I Respond to Data Subject Access Requests C R A/R I I I Detect & classify Personal Data breach C A/R I I I I Notify Controller of breach (≤72 hrs) A/R R I I I I Notify Supervisory Authority (≤72 hrs) C I A/R I I R Notify affected Data Subjects C I A/R C C I Approve Sub-Processor engagements C R A I I I Annual privacy audit & compliance review A/R C R I I I Cross-border transfer impact assessment A/R C R I I I Legend: R = Responsible (does the work) │ A = Accountable (owns the outcome) │ C = Consulted │ I = Informed 7.5 Data Processing Agreement (DPA) The Parties might execute a Data Processing Agreement (“DPA”) which constitutes the Article 28 contract required under GDPR and the equivalent processor agreement required under UAE PDPL Article 29. The DPA shall, at a minimum, specify: (a) Subject matter & duration: The DPA covers all Personal Data processing performed by the Provider in delivering the Platform throughout the Subscription Term plus any post-termination data-retention or return period (§7.13). (b) Nature & purpose of processing: Hosting, storing, transmitting, backing-up, and computing Personal Data within the Customer’s dedicated private sovereign environment for the purpose of enabling the Customer’s construction project management, financial management, human-resources management, and procurement operations. (c) Categories of Data Subjects: Customer employees, subcontractor personnel, supplier contacts, client contacts, site workers, and any other natural persons whose data the Customer inputs into the Platform. (d) Types of Personal Data: Identification data (names, national IDs, passport numbers), contact data (email, phone, address), employment data (role, salary, attendance, leave), financial data (bank details for payroll), project-assignment data, access credentials, and audit-trail metadata. (e) Documented instructions: The Provider shall process Personal Data only on documented instructions from the Controller, including with regard to transfers to third countries, unless required to do so by Union or Member State law to which the Provider is subject (GDPR Art. 28(3)(a)). (f) Confidentiality: All Provider personnel authorised to process Personal Data have committed to confidentiality or are under an appropriate statutory obligation of confidentiality (GDPR Art. 28(3)(b)). (g) Deletion or return: Upon termination, the Provider shall, at the Controller’s election, delete or return all Personal Data and delete existing copies unless Union or Member State law requires storage (§7.13). (h) Audit rights: The Provider shall make available to the Controller all information necessary to demonstrate compliance, and shall allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller (§7.11). 7.6 Sub-Processor Management The Provider engages a limited number of Sub-Processors to deliver components of the Platform and associated services. The following Sub-Processor governance applies: (a) Authorisation model: The Customer grants general authorisation for Sub-Processor engagement subject to the Provider’s obligation to: (i) maintain a current register of Sub-Processors; (ii) notify the Customer of any intended additions or replacements no fewer than thirty (30) calendar days before the new Sub-Processor commences processing; and (iii) provide sufficient information to enable the Customer to exercise its right of objection. (b) Right of objection: If the Customer reasonably objects to a new Sub-Processor on legitimate data-protection grounds, the Provider shall either: (i) refrain from engaging the Sub-Processor and offer an alternative; or (ii) if no alternative is feasible, either Party may terminate the affected services without penalty, subject to a reasonable wind-down period. (c) Flow-down obligations: The Provider shall impose on each Sub-Processor, by way of contract, the same data-protection obligations as set out in the DPA (§7.5), in particular providing sufficient guarantees to implement appropriate technical and organisational measures such that the processing meets GDPR and UAE PDPL requirements. (d) Liability: The Provider remains fully liable to the Customer for the performance of the Sub-Processor’s obligations under the DPA. Where a Sub-Processor fails to fulfil its data-protection obligations, the Provider shall be liable for the acts and omissions of the Sub-Processor as if they were the Provider’s own acts or omissions. 7.6.1 Sub-Processor Register The following table lists the Sub-Processors engaged by the Provider as at the Effective Date. The register is maintained and updated pursuant to §7.6(a). Sub-Processor Processing Activity Location Safeguard Microsoft Azure IaaS hosting of Customer’s dedicated private sovereign environment (compute, storage, networking) Region selected per Customer DPA (default: UAE North / West Europe) EU SCCs + Microsoft DPA Microsoft 365 Email communication, collaboration tools used by Provider operations team EEA / UAE (per licence configuration) EU SCCs + Microsoft DPA WhatsApp (Meta Platforms) Expedient informal communication via shared WhatsApp Business groups (§4.2) EEA (Meta Ireland) EU SCCs + Meta DPA AI Transcription Service Processing of recorded training-session audio for AI-generated transcripts (§6.2) EEA / UAE (per Provider configuration) EU SCCs + Provider-assessed DPA Note: The Customer’s Platform data resides in a dedicated private sovereign environment; no customer data is co-mingled across tenants. The hosting region is selected per the Customer’s DPA and may be restricted to a specific Azure region to satisfy data-localisation requirements under the UAE PDPL or other applicable law. 7.7 Data Protection Principles Any Personal Data processing activity conducted by the Provider, either as Data Controller or Data Processor, shall be characterised by the following principles, aligned with GDPR Article 5 and UAE PDPL Article 4: Principle GDPR Art. UAE PDPL Art. Provider Implementation Lawfulness, fairness & transparency 5(1)(a) 4(1) Processing is based on at least one lawful basis (Art. 6); data subjects are informed in a concise, transparent, intelligible manner via the Customer’s privacy notices; Provider assists Customer in maintaining transparency. Purpose limitation 5(1)(b) 4(2) Personal Data is processed exclusively for the documented purposes specified in the DPA (§7.5). The Provider does not process Customer data for its own purposes (e.g., analytics, marketing, profiling) unless explicitly authorised in writing. Data minimisation 5(1)(c) 4(3) The Platform’s module design collects only data elements required for the activated business functions. Master-data checklists (§6.4.3) define the minimum viable dataset per module. Accuracy 5(1)(d) 4(4) The Platform provides data-validation rules, duplicate-detection, and referential-integrity checks. The Customer retains responsibility for the accuracy of input data; the Provider provides tools to maintain it. Storage limitation 5(1)(e) 4(5) Data-retention policies (§7.12) ensure Personal Data is deleted or anonymised when no longer necessary. Automated retention-period enforcement is configurable per Customer. Integrity & confidentiality 5(1)(f) 4(6) Technical and organisational measures (§7.8) ensure Personal Data is protected against unauthorised or unlawful processing, accidental loss, destruction, or damage. Accountability 5(2) 4(7) The Provider maintains Records of Processing Activities (RoPA), conducts DPIAs where required, and makes compliance evidence available for audit (§7.11). 7.8 Technical & Organisational Measures (TOMs) The Provider implements and maintains the following technical and organisational measures to ensure a level of security appropriate to the risk, in accordance with GDPR Article 32 and UAE PDPL Article 28. These measures are aligned with ISO/IEC 27001:2022 and ISO/IEC 27701:2019 control objectives. The Provider’s Information Security Management System (ISMS) is maintained by the IT Department. 7.8.1 Access Control & Authentication (a) Password complexity: Minimum length, character-class requirements, and prohibition of common/breached passwords enforced at the application layer. (b) Password expiration: Configurable password-rotation policy; default rotation period aligned with NIST SP 800-63B guidance. (c) Failed-authentication lockout: Account lockout after a configurable number of consecutive failed attempts; lockout duration escalates with repeated violations. (d) Password history: The system prevents reuse of the last N passwords (configurable per Customer policy). (e) Multi-factor authentication (MFA): Second-factor authentication is supported and recommended for all administrative and privileged accounts. MFA methods include TOTP (time-based one-time password), push notification, and FIDO2 hardware keys. (f) Single Sign-On (SSO): The Platform supports integration with enterprise identity providers via SAML 2.0 and OpenID Connect, enabling centralised credential management and reducing the attack surface associated with password proliferation. (g) Session management: Away-from-keyboard auto-lock mechanism; configurable idle-session timeout; session invalidation on password change or account suspension. (h) Role-based access control (RBAC): The Users & Roles Management module (STY) enforces granular, role-based access control at the module, function, field, and record level. Segregation of duties is enforced through conflicting-role detection. (i) Restricted remote access: Remote administrative access to the Provider’s infrastructure is restricted to authorised personnel via encrypted VPN tunnels with MFA; all remote sessions are logged and auditable. 7.8.2 Encryption (a) Data in transit: All client–server communication is encrypted using TLS 1.2 or higher. End-to-end data-transmission encryption is enforced across all Platform interfaces, APIs, and integration endpoints. (b) Data at rest: Transparent Data Encryption (TDE) is applied to all database instances. Database backups are encrypted using AES-256 encryption. Encryption keys are managed through the cloud provider’s Key Management Service with customer-managed key (CMK) options available. (c) Key management: Encryption keys are rotated according to a defined schedule. Key-management procedures follow ISO 27001 Annex A.10 controls. Hardware Security Modules (HSMs) are used for root key protection where available. 7.8.3 Database Security (a) Database connections: Connections to database instances are controlled, monitored, and restricted to authorised application-layer services and designated DBA personnel only. (b) Default accounts: Default system accounts are secured by the DBA; all default passwords are changed immediately upon provisioning; unnecessary default accounts are disabled. (c) Minimum privilege: Database user accounts are provisioned with minimum permissions and roles necessary for their function. System privileges are removed unless explicitly required and approved. (d) Audit logging: Database audit logging captures all DDL operations, privileged-user activity, failed authentication attempts, and data-export operations. Logs are retained for a minimum of twelve (12) months and are tamper-evident. (e) DBA remote access: Remote database administration is restricted to named individuals via encrypted channels with multi-factor authentication. All DBA sessions are logged with full command-level audit trail. 7.8.4 Network Security (a) Perimeter defence: Next-generation firewalls, Web Application Firewalls (WAF), and DDoS-protection services guard the platform perimeter. Network segmentation isolates the Customer’s private sovereign environment from other Provider infrastructure. (b) Intrusion detection & monitoring: Cloud-native SIEM and network-monitoring tools provide real-time alerting on anomalous traffic patterns, port-scan attempts, and lateral-movement indicators. (c) Vulnerability management: Regular vulnerability scans and annual penetration tests are conducted. Critical and high-severity vulnerabilities are remediated within the timeframes specified in §3.5 (Incident Priority Classification). 7.8.5 Organisational Measures (a) Confidentiality agreements: All Provider personnel authorised to process Personal Data have signed confidentiality/non-disclosure agreements and are under an appropriate statutory obligation of confidentiality. (b) Training & awareness: Provider personnel receive annual data-protection training covering GDPR, UAE PDPL, breach reporting, social engineering, and secure-coding practices. (c) Clean desk & clear screen: Clean-desk and clear-screen policies are enforced in all Provider facilities to prevent inadvertent exposure of Personal Data. (d) Asset-use policy: All hardware and software assets are used exclusively for business purposes and the implementation of tasks respective to each employee’s job description. 7.9 Data Subject Rights The Provider recognises the rights of Data Subjects as defined in GDPR Chapter III (Articles 12–23) and UAE PDPL Articles 12–18, and shall assist the Customer in fulfilling its obligation to respond to Data Subject requests in accordance with GDPR Article 28(3)(e) and UAE PDPL Article 29. The Provider shall: (a) Promptly notify the Customer upon receipt of a Data Subject request related to Customer data, without responding to the Data Subject directly unless instructed by the Customer. (b) Provide the Customer with the technical capability to extract, rectify, restrict, port, or delete Personal Data through Platform functionality or, where not available through the UI, through Provider-executed database operations within the timeframes required by law. (c) Maintain audit trails of all Data Subject request fulfilment actions for a minimum of twenty-four (24) months. 7.9.1 Rights Fulfilment Matrix Right GDPR Art. UAE PDPL Art. Platform Capability Response SLA Right of access 15 13 Data-export function generates structured report of all Personal Data associated with a Data Subject’s identity ≤30 calendar days Right to rectification 16 14 In-app record editing with full audit trail; batch-correction support for bulk updates ≤30 calendar days Right to erasure (‘right to be forgotten’) 17 15 Erasure workflow anonymises or deletes all instances of a Data Subject’s Personal Data across modules, backups, and logs (subject to legal-hold exceptions) ≤30 calendar days Right to restriction of processing 18 16 Record-level processing-restriction flag; restricted data remains stored but is excluded from active processing, reporting, and API responses ≤72 hours (flag) Right to data portability 20 17 Machine-readable export in CSV, JSON, and XML formats; API-based extraction available ≤30 calendar days Right to object 21 18 Processing-objection flag triggers review; Provider ceases processing pending assessment of compelling legitimate grounds ≤72 hours (flag) Legal-hold override: Where erasure or restriction conflicts with a legal obligation (e.g., statutory record-retention, pending litigation, regulatory investigation), the Provider shall inform the Customer and the Data Subject of the legal basis for continued processing, and shall restrict processing to the minimum necessary for compliance. 7.10 Data Protection Impact Assessment (DPIA) Where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons, the Customer (as Controller) shall carry out a Data Protection Impact Assessment in accordance with GDPR Article 35 and UAE PDPL Article 23. The Provider shall: (a) Provide the Customer with all information necessary to conduct the DPIA, including documentation of the Platform’s data flows, retention policies, access-control model, and cross-border transfer mechanisms. (b) Assist the Customer in conducting the DPIA where requested, including by providing a pre-completed DPIA template covering the standard processing operations performed by the Platform. (c) Notify the Customer if, in the Provider’s opinion, a new feature, module activation, integration, or change in processing operations triggers the need for a new or updated DPIA. (d) AI-specific DPIA: Where the Platform’s AI components (e.g., AI-assisted transcription, AIOps anomaly detection, contextual in-app guidance) process Personal Data, a supplementary AI-specific DPIA shall be conducted addressing algorithmic bias, automated decision-making transparency, data-minimisation in training sets, and the rights of Data Subjects under GDPR Article 22 (automated individual decision-making). This assessment shall also consider obligations under the EU AI Act (Regulation (EU) 2024/1689) and the NIST AI Risk Management Framework. 7.11 Audit & Compliance 7.11.1 Provider Obligations The Provider shall: (d) Maintain a Record of Processing Activities (RoPA) in accordance with GDPR Article 30, covering all processing operations performed on behalf of the Customer. (e) Make available to the Customer all information necessary to demonstrate compliance with the obligations laid down in GDPR Article 28 and UAE PDPL Article 29. (f) Allow for and contribute to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer, subject to: (i) reasonable advance notice of not less than thirty (30) calendar days; (ii) audit scope limited to the processing activities covered by the DPA; (iii) the auditor’s execution of a non-disclosure agreement acceptable to the Provider; and (iv) audits being conducted during normal business hours in a manner that minimises disruption. (g) Immediately inform the Customer if, in the Provider’s opinion, an instruction from the Customer infringes GDPR, UAE PDPL, or other applicable data-protection law (GDPR Art. 28(3)(h)). 7.11.2 Audit Frequency & Scope The following audit schedule applies: Audit Type Frequency Scope Output Provider self-assessment Quarterly RoPA completeness, TOM effectiveness, Sub-Processor compliance, incident log review Internal compliance report shared with Customer DPO Customer-initiated audit Annually (or upon material breach) Full DPA compliance, technical controls inspection, personnel-training records, breach-response drill Audit findings report with remediation timeline Third-party certification audit Annually ISO 27001:2022 / ISO 27701:2019 scope — ISMS and PIMS controls Certificate and Statement of Applicability Regulatory authority audit As required Full regulatory scope as directed by the supervisory authority Cooperation and documentation provision per GDPR Art. 58 7.12 Data Retention & Destruction Personal Data shall not be retained for longer than is necessary for the purposes for which it was collected. The following retention framework applies: (a) Active processing: Personal Data is actively processed for the duration of the Subscription Term and any post-termination wind-down period agreed under the DPA. (b) Retention periods: Where specific retention periods are mandated by applicable law (e.g., labour-law record retention, tax-authority requirements, regulatory preservation orders), the Provider shall retain the minimum necessary data for the prescribed period, clearly segregated and access-restricted. (c) Automated enforcement: The Platform supports configurable data-retention policies that automatically flag, archive, or purge records that exceed their defined retention period. The Customer defines the retention rules; the Provider implements the technical enforcement. (d) Secure destruction: When Personal Data is deleted, the Provider shall ensure secure destruction through: (i) cryptographic erasure for encrypted data (rendering the encryption key irrecoverable); (ii) multi-pass overwrite for unencrypted media; and (iii) deletion confirmation certificates provided to the Customer upon request. (e) Backup retention: Backup copies containing Personal Data are subject to the same retention and destruction policies. The Provider shall ensure that deleted Personal Data is purged from all backup cycles within ninety (90) calendar days of the deletion instruction, unless a shorter period is specified in the DPA. NIST SP 800-88 Rev. 1 — Guidelines for Media Sanitization 7.13 Data Return & Portability on Termination Upon termination or expiry of the Framework, the following data-return and portability provisions apply: (a) Data-return period: The Customer shall have a period of sixty (60) calendar days from the effective date of termination to request the return of all Personal Data and Customer Data in a structured, commonly used, machine-readable format (CSV, JSON, XML, or SQL dump). (b) Format options: The Provider shall offer data export in at least three machine-readable formats. The export shall include: (i) all transactional data across activated modules; (ii) master-data registers; (iii) document attachments; (iv) audit logs; and (v) configuration metadata sufficient to reconstruct the Customer’s operational setup in a successor system. (c) Deletion after return: Upon confirmation that the Customer has received and verified the exported data, or upon expiry of the sixty (60) day data-return period (whichever is earlier), the Provider shall securely delete all Personal Data from all systems, including production databases, staging environments, backups, and disaster-recovery replicas. (d) Deletion certificate: The Provider shall issue a written certificate of deletion within thirty (30) calendar days of completing the secure-destruction process, confirming that all Personal Data has been irreversibly destroyed from all Provider-controlled systems and media. (e) Residual obligations: Data-protection obligations under this chapter survive termination with respect to any Personal Data retained by the Provider pursuant to a legal obligation, until such data is securely destroyed. 7.14 Cross-Border Data Transfers Where the processing of Personal Data involves or may involve the transfer of Personal Data to a third country or international organisation, the following provisions apply: (a) EEA-origin data: Transfers of Personal Data originating from the European Economic Area to countries not covered by an adequacy decision under GDPR Article 45 shall be governed by the EU Standard Contractual Clauses (SCCs) adopted under Commission Implementing Decision (EU) 2021/914, supplemented by a Transfer Impact Assessment (TIA) where required by EDPB Recommendations 01/2020. (b) UAE-origin data: Transfers of Personal Data originating from the UAE to countries outside the UAE shall comply with UAE PDPL Article 22 (cross-border transfer provisions), including any data-localisation requirements imposed by the UAE Data Office or sector-specific regulators. (c) Data-localisation options: The Provider’s dedicated private sovereign environment model enables the Customer to select the geographic region (Azure Region) in which all Customer Data resides and is processed. Where the Customer requires data to remain within a specific jurisdiction (e.g., UAE for government contracts, EEA for EU-regulated entities), the Provider shall ensure that no data leaves the designated region, including for backup and disaster-recovery purposes. (d) Transfer Impact Assessment: Prior to initiating any new cross-border transfer mechanism, the Provider shall conduct and document a Transfer Impact Assessment evaluating: (i) the legal framework of the recipient country; (ii) the supplementary measures in place; and (iii) the practical enforceability of Data Subject rights in the recipient jurisdiction. 7.15 Personal Data Breach Management 7.15.1 Breach Detection & Classification The Provider has established procedures, governed by the IT Department, to detect, classify, and respond to Personal Data breaches. The Provider’s SIEM and AIOps tooling provides automated anomaly detection; all alerts classified as potential Personal Data breaches are immediately escalated to the DPO. Breaches are classified by severity: Severity Criteria Notification Timeline Example Critical High risk to rights and freedoms of Data Subjects; large-scale breach; sensitive data categories affected Provider → Controller: ≤24 hrs Controller → Authority: ≤72 hrs Controller → Data Subjects: without undue delay Database exfiltration; ransomware encrypting HR/payroll data; credential compromise of admin accounts High Material risk to rights and freedoms; limited-scale breach; standard Personal Data categories Provider → Controller: ≤48 hrs Controller → Authority: ≤72 hrs Unauthorised access to project-contact data; email misdirection containing Personal Data Medium Low risk; containment achieved quickly; limited data exposure Provider → Controller: ≤72 hrs Controller → Authority: at Controller’s discretion Failed brute-force attempt contained by lockout; exposure of non-sensitive metadata Low Negligible risk; no actual exposure of Personal Data Provider → Controller: monthly summary report Anomalous login pattern with no data access; policy-violation alert triggered by false positive 7.15.2 Breach Notification Procedure The Provider shall notify the Customer (as Controller) of any confirmed or suspected Personal Data breach as follows: (a) Initial notification: Within the timeframes specified in §7.15.1, the Provider shall notify the Customer’s designated DPO/privacy lead via the primary communication channel (email to designated address, followed by telephone confirmation for Critical and High severity breaches). The initial notification shall include: (i) nature of the breach; (ii) categories and approximate number of Data Subjects affected; (iii) categories and approximate number of records concerned; (iv) likely consequences; and (v) measures taken or proposed to mitigate adverse effects. (b) Follow-up reporting: Where the full details are not available at the time of the initial notification, the Provider shall provide information in phases without undue delay as it becomes available (GDPR Art. 33(4)). (c) Root-cause analysis: The Provider shall deliver a full root-cause analysis report to the Customer within fifteen (15) business days of breach containment, including: timeline of events, affected systems and data, root cause, containment actions, remediation measures, and recommendations to prevent recurrence. (d) Regulatory cooperation: The Provider shall assist the Customer in: (i) notifying the competent supervisory authority (GDPR Art. 33, UAE PDPL Art. 28); and (ii) communicating the breach to affected Data Subjects where required (GDPR Art. 34). The Provider shall not communicate directly with the supervisory authority or Data Subjects regarding Customer data without the Customer’s prior written consent, unless required by law. 7.15.3 Breach Response Drill The Provider and Customer shall conduct a joint Personal Data breach-response drill at least annually, simulating a Critical-severity breach scenario. The drill shall test: (i) detection-to-notification timelines; (ii) communication-channel effectiveness; (iii) containment-procedure execution; and (iv) regulatory-notification readiness. Findings from each drill shall be documented and incorporated into process improvements. 7.16 AI-Specific Data Protection The Provider’s use of artificial-intelligence components within the Platform (including AI-assisted transcription, AIOps, predictive analytics, and contextual in-app guidance) is subject to the following data-protection controls, aligned with the EU AI Act (Regulation (EU) 2024/1689) and the NIST AI RMF: (a) No cross-tenant training: Customer data is never used to train AI models that serve other customers or improve the Provider’s general-purpose AI capabilities. Each Customer’s AI-generated outputs (e.g., transcription models, predictive analytics) are trained and scoped exclusively to that Customer’s data within their dedicated sovereign environment. (b) Data minimisation in AI: AI components process the minimum Personal Data necessary to deliver their function. Where possible, data is pseudonymised or anonymised before AI processing. (c) Automated decision-making: The Platform does not make decisions based solely on automated processing that produce legal effects or similarly significant effects on Data Subjects (GDPR Art. 22) unless: (i) the Customer explicitly configures such processing; (ii) the Customer ensures a lawful basis (consent, contract necessity, or Member State law); and (iii) human review is available. (d) AI transparency: The Provider documents the purpose, data inputs, logic, and output scope of each AI component in the Platform’s technical documentation. This documentation is available to the Customer for DPIA purposes (§7.10) and regulatory inspection. (e) Bias monitoring: Where AI components process Personal Data that includes special categories (e.g., ethnicity, nationality in HRMS modules), the Provider implements bias-monitoring checks and reports findings to the Customer as part of the quarterly self-assessment (§7.11.2). 7.17 Process Register The following table enumerates the contractual and operational processes governed by this chapter. Each process is assigned a unique identifier, trigger condition, responsible handler, approver, expected outcome, and cross-reference to the governing section. Proc-ID Process Name Trigger Handler Approver Outcome Section P-7.01 DPA Execution Agreement signing or renewal Provider DPO Customer DPO Signed DPA annexing Art. 28 obligations §7.5 P-7.02 Sub-Processor Notification New or replacement Sub-Processor identified Provider Ops Customer DPO 30-day advance notice with objection window §7.6 P-7.03 Sub-Processor Objection Resolution Customer objects to Sub-Processor Provider DPO Both Parties Alternative Sub-Processor or service termination option §7.6(b) P-7.04 Data Subject Access Request (DSAR) Data Subject submits request to Controller Customer DPO Customer DPO Structured report delivered within 30 days §7.9 P-7.05 Data Subject Erasure Request Data Subject exercises right to erasure Provider Ops + Customer DPO Customer DPO Anonymisation/deletion with legal-hold check §7.9 P-7.06 DPIA Initiation New module, feature, or processing change triggers high-risk threshold Provider DPO Customer DPO Completed DPIA with risk register §7.10 P-7.07 AI-Specific DPIA AI component processes Personal Data Provider DPO Customer DPO AI DPIA covering bias, transparency, Art. 22 §7.10 P-7.08 Breach Detection SIEM/AIOps alert or manual detection of suspected breach Provider Ops Provider DPO Classified breach record; containment initiated §7.15.1 P-7.09 Breach Notification (Controller) Confirmed/susp ected breach classified ≥ Medium Provider DPO Provider DPO Notification to Customer within SLA timeline §7.15.2 P-7.10 Breach Notification (Authority) Controller determines authority notification required Customer DPO Customer DPO ≤72-hour notification to supervisory authority §7.15.2 P-7.11 Root-Cause Analysis Breach containment completed Provider Ops Provider DPO + Customer DPO RCA report within 15 business days §7.15.2(c ) P-7.12 Breach Response Drill Annual schedule or ad-hoc trigger Provider DPO + Customer DPO Both Parties Drill report with improvement actions §7.15.3 P-7.13 Data Return on Termination Agreement termination/expi ry Provider Ops Customer PM Data exported in machine-readable format within 60 days §7.13 P-7.14 Secure Data Destruction Data-return period expires or deletion requested Provider Ops Provider DPO Deletion certificate issued within 30 days §7.12 P-7.15 Cross-Border Transfer Assessment New transfer mechanism or destination identified Provider DPO Customer DPO Documented TIA with supplementary measures §7.14 P-7.16 Privacy Audit (Internal) Quarterly schedule Provider DPO Provider DPO Compliance report shared with Customer §7.11.2 P-7.17 Privacy Audit (Customer) Annual schedule or material breach trigger Customer Auditor Customer DPO Findings report with remediation timeline §7.11.2 P-7.18 Retention Policy Review Annual schedule or regulatory change Provider DPO + Customer DPO Customer DPO Updated retention schedule and automated enforcement rules §7.12 7.18 Process-Flow Schematic The following diagram illustrates the data-protection lifecycle from DPA execution through ongoing compliance monitoring, breach response, and data return on termination. ① DPA Execution & Lawful Basis → ② RoPA & Privacy-by-Design → ③ TOM Implementation ▼ ④ DPIA (incl. AI DPIA) → ⑤ Ongoing Processing & Monitoring → ⑥ Data Subject Rights Fulfilment ▼ ⑦ Breach Detection & Response → ⑧ Audit & Compliance Review → ⑨ Data Return / Destruction Feedback loop: Stage ⑨ (Data Return/Destruction) feeds back into Stage ② (RoPA) for record-keeping of destruction activities and Stage ⑧ (Audit) for post-termination compliance verification. Stages ④–⑦ operate continuously throughout the Subscription Term with quarterly self-assessment checkpoints (§7.11.2). ← PreviousTraining & Knowledge TransferNext →Information Security & Confidentiality See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →