Chapter 8 · ProjectVIEW ERP Master SaaS Framework The Provider’s Information Security Management System is aligned with ISO/IEC 27001:2022 and enforces security at every tier — browser, application server and database — inside each customer’s dedicated Azure environment. Chapter 8 covers application, infrastructure and database security, vulnerability management, security monitoring and incident response, the secure development lifecycle, source-code protection and confidentiality. ISO/IEC 27001:2022ISMS alignment 3 tiersweb, application and database security SDLCsecure development lifecycle 8.1 Overview & Purpose This chapter defines the information-security and confidentiality obligations governing the Provider’s delivery of the ProjectVIEW ERP Platform. It establishes the security architecture, authentication controls, encryption standards, network defences, vulnerability management procedures, and confidentiality provisions that protect Customer Data, Platform integrity, and the Provider’s proprietary intellectual property throughout the Subscription Term. The Provider’s Information Security Management System (ISMS) is maintained by the IT Department and is aligned with ISO/IEC 27001:2022. This chapter addresses the technical security controls that complement the privacy-specific measures described in Chapter 7 (Data Protection & Privacy) and the operational-support security measures described in Chapter 4 (Service Support & Operations). DANAOS Web Enterprise incorporates security mechanisms at every layer of the application stack — from the presentation tier (web browser) through the application tier (application server) to the data tier (database server) — ensuring that confidentiality, integrity, and availability (the C.I.A. triad) are enforced end-to-end within each Customer’s dedicated private sovereign environment. 8.2 Scope This chapter covers: (a) Platform application security: Authentication, authorisation, session management, input validation, and secure-coding practices embedded within the DANAOS Web Framework. (b) Infrastructure security: Network segmentation, firewall configuration, intrusion detection, DDoS protection, and Web Application Firewall (WAF) controls applied to each Customer’s Azure-hosted sovereign environment. (c) Database security: Access control, encryption (at rest and in transit), audit logging, privilege management, and connection monitoring for SQL Server database instances. (d) Operational security: Vulnerability management, penetration testing, patch management, change-tracking, and security-incident response (non-personal-data incidents; Personal Data breaches are governed by §7.15). (e) Source-code security: Intellectual-property protection, secure-development lifecycle, Git-based version control, and code-review practices governing the Provider’s proprietary codebase. (f) Confidentiality obligations: Mutual confidentiality undertakings, information classification, disclosure restrictions, and survival provisions. 8.3 Security Standards & Frameworks The Provider’s security programme is built on the following standards, frameworks, and guidance: Ref Standard / Framework Application SF-01 ISO/IEC 27001:2022 Foundation for the ISMS; defines the management system, risk assessment methodology, Statement of Applicability (SoA), and continuous improvement cycle. SF-02 ISO/IEC 27002:2022 Reference control set; provides implementation guidance for the Annex A controls selected in the SoA. SF-03 NIST Cybersecurity Framework (CSF) 2.0 Used to structure the Provider’s security functions: Identify, Protect, Detect, Respond, Recover, and Govern. SF-04 OWASP Top 10 (2021) Baseline for web-application security; integrated into the Provider’s secure-development lifecycle and penetration-testing scope. SF-05 OWASP Application Security Verification Standard (ASVS) 4.0 Used for Level 2 verification of authentication, session management, access control, and input-validation controls. SF-06 CIS Microsoft Azure Foundations Benchmark v2.1 Hardening baseline for Azure infrastructure; applied to NSGs, storage accounts, key vaults, and identity configuration. SF-07 CIS Microsoft SQL Server 2022 Benchmark Hardening baseline for SQL Server database instances; applied to authentication, authorisation, auditing, and encryption settings. SF-08 NIST SP 800-63B Digital identity guideline for authentication assurance levels; informs password-policy and MFA requirements. SF-09 Microsoft Azure Well-Architected Framework — Security Pillar Cloud-native security design principles: zero-trust, defence-in-depth, and least-privilege. ISO/IEC 27001:2022 NIST CSF 2.0 OWASP Top 10 (2021) CIS Azure Foundations Benchmark NIST SP 800-63B Azure Well-Architected Framework 8.4 Application Security DANAOS ProjectVIEW ERP platform incorporates the following security mechanisms at the application layer to ensure system confidentiality and integrity. These controls are enforced for every Customer instance and are configurable by the Customer’s system administrators through the STY (Users & Roles Management) module. 8.4.1 Authentication Controls Control Description Configurable Reference Password complexity Inherits Microsoft LDAP authentication password-value requirements. Enforces minimum character-class diversity (uppercase, lowercase, numeric, special characters) and prohibits common/breached passwords. Yes — complexity rules defined by Customer admin NIST SP 800-63B §5.1.1 Password expiration System administrators define a mandatory rotation period after which users must alter their password. Default: 90 days; configurable per Customer policy. Yes — rotation period in days ISO 27002 §8.5 Failed-authentication lockout System administrators define the maximum number of consecutive failed login attempts per account, after which the account is locked for a configurable duration. Yes — attempt threshold + lockout duration OWASP ASVS 2.2.1 Password history Prevents users from reusing any password value used in the past. System administrators configure the number of historical passwords retained. Yes — history depth (N passwords) NIST SP 800-63B Minimum password length System administrators define the minimum length of the password value users may utilise. Yes — minimum characters NIST SP 800-63B §5.1.1 Idle-session lock System administrators define the number of minutes of inactivity after which the application demands re-authentication (away-from-keyboard lock screen). Yes — timeout in minutes ISO 27002 §8.1 Multi-factor authentication (MFA) Incorporated Google Authenticator OTP (TOTP) authentication mandated when login requests originate outside the intranet. System administrators define network/IP ranges considered ‘external’ that trigger MFA. Yes — network/IP ranges, MFA method NIST SP 800-63B AAL2 Single Sign-On (SSO) Supports SSO via Active Directory (SAML 2.0, OpenID Connect). Enables centralised credential management and reduces password proliferation. Yes — IdP integration configuration ISO 27002 §8.5 8.4.2 Authorisation & Access Control The Platform’s Users & Roles Management module (STY) enforces granular, role-based access control (RBAC) at multiple levels: (a) Module level: Users are granted or denied access to entire modules (e.g., PV_07 HRMS– Payroll, PV_08 Accounting) based on their role assignment. (b) Function level: Within a module, individual functions (e.g., create purchase order, approve invoice, view salary) are independently permissioned. (c) Field level: Sensitive fields within a record (e.g., salary amount, bank account, national ID) can be hidden or read-only for specific roles. (d) Record level: Row-level security restricts visibility based on organisational hierarchy (e.g., project managers see only their assigned projects; regional managers see their region). (e) Segregation of duties: Conflicting-role detection prevents a single user from holding roles that create separation-of-duties conflicts (e.g., requisition creator and approval authority). The STY module alerts administrators to detected conflicts and enforces policy-based restrictions. (f) Unique user IDs: Every user account is assigned a unique identifier. Shared/generic accounts are prohibited. All actions are traceable to an individual user through the audit trail. (g) Restricted remote access: System administrators control remote access per user via the administrator console; access can be allowed or revoked at any time. 8.4.3 Session Security (a) Session tokens: Cryptographically random session tokens are generated upon authentication. Tokens are bound to the user’s IP address and user-agent string to prevent session hijacking. (b) Session invalidation: Sessions are invalidated upon: password change, account suspension, explicit logout, or idle-timeout expiry. (c) Concurrent-session control: Configurable limits on concurrent active sessions per user account. Default: single active session per user (last-login-wins policy). 8.4.4 Input Validation & Output Encoding (a) Server-side validation: All user-supplied input is validated on the server side using whitelist-based validation. Client-side validation is treated as a usability enhancement only, never as a security control. (b) Parameterised queries: All database interactions use parameterised queries (prepared statements) to prevent SQL injection. Dynamic SQL construction from user input is prohibited by the Provider’s secure-coding standard. (c) Output encoding: All data rendered to the browser is contextually encoded (HTML, JavaScript, URL, CSS encoding as appropriate) to prevent cross-site scripting (XSS). (d) Content Security Policy (CSP): HTTP response headers include a strict Content Security Policy to mitigate XSS and data-injection attacks. 8.5 Infrastructure Security Each Customer’s ProjectVIEW ERP instance is deployed within a dedicated private sovereign environment on Microsoft Azure. The infrastructure security controls described below are applied per-tenant and are aligned with the CIS Azure Foundations Benchmark and the Azure Well-Architected Security Pillar. 8.5.1 Network Security (a) Network Security Groups (NSGs): Each virtual machine is protected by NSGs that provide stateful firewall functionality with explicit allow/deny rules. Default policy: deny-all inbound; allow only required service ports. (b) Web Application Firewall (WAF): Azure WAF is deployed in front of the application tier to protect against OWASP Top 10 threats, including SQL injection, XSS, CSRF, and request-smuggling attacks. (c) DDoS Protection: Azure DDoS Protection Standard is enabled for all Customer environments, providing volumetric, protocol, and application-layer attack mitigation with automatic detection and inline remediation. (d) Network segmentation: The data tier, application tier, and management tier are deployed in separate subnets with inter-tier traffic controlled by NSG rules. The database subnet is not directly accessible from the internet. (e) VPN & private connectivity: Where the Customer requires site-to-site connectivity (e.g., integration with on-premises Active Directory), Azure VPN Gateway or ExpressRoute is provisioned with IPSec/IKEv2 encryption. (f) DNS security: Azure Private DNS zones are used to prevent DNS-based data exfiltration. Public DNS records are protected with DNSSEC where supported by the registrar. 8.5.2 Compute Security (a) Operating system hardening: All virtual machines run Microsoft Windows Server 2022, hardened per CIS Windows Server 2022 Benchmark. Unnecessary services, ports, and features are disabled. (b) Patch management: Security patches are applied within: (i) seventy-two (72) hours for Critical/High CVEs; (ii) thirty (30) calendar days for Medium CVEs; (iii) next maintenance window for Low CVEs. Patches are tested in the Staging Environment before production deployment. (c) Anti-malware: Cloud-native endpoint protection (Microsoft Defender for Cloud) is enabled on all virtual machines with real-time scanning, behavioural analysis, and automatic remediation. (d) Host-based intrusion detection: Azure Security Centre monitors file-integrity, suspicious process execution, and anomalous system calls on all VMs. 8.5.3 Identity & Secrets Management (a) Azure Key Vault: All cryptographic keys, certificates, connection strings, and service credentials are stored in Azure Key Vault with access controlled by Azure RBAC and Key Vault access policies. (b) Managed identities: Azure Managed Identities are used for service-to-service authentication where possible, eliminating the need for stored credentials in application configuration. (c) Secret rotation: Automated secret-rotation policies are enforced for all service-account credentials and API keys. Maximum rotation period: ninety (90) calendar days. 8.6 Database Security The Platform’s data tier runs on Microsoft SQL Server 2022 (Standard or Enterprise Edition) deployed on Microsoft Windows Server 2022. The following database-specific security controls are applied, aligned with the CIS SQL Server 2022 Benchmark: 8.6.1 Access & Authentication (a) Database authentication: SQL Server uses Windows Authentication mode (integrated with Active Directory) as the primary authentication method. Mixed-mode authentication is disabled unless explicitly required and approved by the Customer. (b) Application passwords: Application-level database credentials use strong passwords compliant with the password-composition policy and are rotated per the secret-rotation schedule (§8.5.3). (c) Default accounts: All default system accounts (e.g., ‘sa’) are properly secured by the DBA: default passwords are changed immediately upon provisioning; unnecessary default accounts are disabled or dropped. (d) Connection control: Connections to the database instances are controlled and monitored. Only authorised application-layer services and designated DBA personnel may establish connections. Connection strings are stored in Azure Key Vault (§8.5.3). (e) Ability to connect: Network-level controls restrict database connectivity to the application-tier subnet and authorised management endpoints only. Direct internet connectivity to the database is prohibited. 8.6.2 Privilege Management (a) Minimum permissions & roles: Database user accounts are provisioned with the minimum permissions and roles necessary for their function. The principle of least privilege is enforced and periodically reviewed. (b) System privileges: All ‘system’ privileges are removed from user accounts unless explicitly required and approved. Privileged operations require a separate, dedicated DBA account with MFA. (c) Segregation of duties: Database administration privileges are segregated from application-development privileges. Developers do not have production database access. (d) Privilege review: Quarterly review of database privilege assignments; unused or excessive privileges are revoked. Review results are documented and available for audit (§7.11). 8.6.3 Encryption (a) Transparent Data Encryption (TDE): TDE is enabled on all production and staging database instances, encrypting data files, log files, and tempdb using AES-256 encryption. TDE certificates are backed up and stored in Azure Key Vault. (b) Backup encryption: All database backups (full, differential, and transaction-log) are encrypted using AES-256 with Customer-specific encryption keys managed through Azure Key Vault. (c) Column-level encryption: Where required by the Customer’s data-classification policy, column-level encryption (Always Encrypted) is available for highly sensitive fields (e.g., national IDs, bank account numbers). 8.6.4 Auditing & Logging (a) Audit logging: SQL Server Audit captures: (i) all DDL operations (schema changes); (ii) privileged-user activity; (iii) failed authentication attempts; (iv) data-export and bulk-copy operations; (v) permission changes. Audit logs are written to a tamper-evident store. (b) Logging retention: Database audit logs are retained for a minimum of twelve (12) months online and twenty-four (24) months in archival storage. Retention meets regulatory requirements under GDPR, UAE PDPL, and applicable industry standards. (c) Change tracking: SQL Server Change Tracking and Change Data Capture (CDC) are enabled to provide a complete inventory of data modifications for compliance and audit purposes. (d) 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.3). 8.7 Vulnerability Management The Provider operates a continuous vulnerability management programme aligned with NIST CSF Identify (ID.RA) and Protect (PR.IP) functions: 8.7.1 Assessment Schedule Assessment Type Frequency Scope Standard / Tool Automated vulnerability scan (infrastructure) Weekly All Azure VMs, NSGs, storage accounts, Key Vaults Microsoft Defender for Cloud + third-party scanner Automated vulnerability scan (application) Weekly (on every build) DANAOS Web Framework codebase; OWASP Top 10 + SANS CWE 25 SAST + DAST integrated into CI/CD pipeline Dependency / supply-chain scan On every build + daily Third-party libraries, NuGet/npm packages, container images Software Composition Analysis (SCA) tool Penetration test (external) Annually Public-facing attack surface; authentication bypass, privilege escalation, data exfiltration Certified third-party penetration-testing firm Penetration test (internal / red team) Annually Lateral movement, privilege escalation, insider-threat scenarios Provider security team or certified third party Configuration compliance scan Monthly CIS Benchmark compliance for Azure, Windows Server, SQL Server CIS-CAT Pro or equivalent 8.7.2 Remediation Timelines CVSS Severity Score Range Remediation SLA Escalation Critical 9.0–10.0 ≤72 hours Immediate escalation to CISO; Customer notification within 24 hours if Customer-facing High 7.0–8.9 ≤30 calendar days Escalation to security lead; included in next patch cycle Medium 4.0–6.9 ≤90 calendar days Tracked in vulnerability register; scheduled remediation Low 0.1–3.9 Next major release Documented; remediated as part of ongoing hardening Zero-day vulnerabilities: For actively exploited zero-day vulnerabilities affecting the Platform’s technology stack, the Provider shall apply emergency mitigation measures (e.g., WAF rules, network isolation, virtual patching) within twenty-four (24) hours, with a permanent patch following the Critical remediation SLA. 8.8 Security Monitoring & Incident Response 8.8.1 Monitoring The Provider operates a 24/7 security-monitoring capability using the following components: (a) SIEM: Cloud-native Security Information and Event Management (Microsoft Sentinel) aggregates logs from all infrastructure, application, and database layers. Correlation rules and machine-learning detections identify anomalous patterns. (b) AIOps: AI-driven operations tooling provides predictive anomaly detection on performance metrics, authentication patterns, and data-access volumes, enabling early identification of security-relevant deviations before they escalate to incidents. (c) Threat intelligence: SIEM integrates real-time threat-intelligence feeds (Microsoft Threat Intelligence, industry-specific IOCs) to detect known attack signatures and indicators of compromise. (d) User and Entity Behaviour Analytics (UEBA): Baseline behaviour profiles are established for users and service accounts. Deviations (e.g., anomalous login locations, unusual data-access patterns, privilege-escalation attempts) trigger automated alerts. 8.8.2 Security Incident Response Security incidents that do not involve Personal Data are managed under this section. Personal Data breaches are governed by §7.15. Where an incident is later classified as involving Personal Data, the §7.15 breach-notification procedures apply in addition to the measures below. Phase Activities Timeline Detection & Triage SIEM/AIOps alert triggered → SOC analyst validates → incident classified by severity → assigned to responder Real-time Containment Isolate affected systems; block IOCs at perimeter; revoke compromised credentials; preserve forensic evidence ≤60 minutes (Critical); ≤4 hours (High) Eradication Remove threat actor presence; patch exploited vulnerability; rebuild compromised components from known-good images Concurrent with containment Recovery Restore services from clean backups; validate integrity; re-enable network connectivity; confirm no residual indicators Per RTO targets (§3.4) Post-Incident Review Root-cause analysis; lessons-learned documentation; control improvements; Customer notification (if applicable) ≤15 business days post-containment 8.8.3 Customer Notification The Provider shall notify the Customer of security incidents that: (i) result in actual or suspected unauthorised access to Customer Data; (ii) materially affect Platform availability or integrity; or (iii) involve law-enforcement engagement related to the Customer’s environment. Notification shall occur within the timelines aligned with the incident severity and the breach-notification SLAs defined in §7.15.1. 8.9 Secure Development Lifecycle (SDLC) The Provider follows a secure SDLC aligned with OWASP’s Software Assurance Maturity Model (SAMM) and Microsoft’s Security Development Lifecycle (SDL): (a) Threat modelling: New features and significant changes undergo threat modelling during design. STRIDE methodology is used to identify threats; DREAD is used to prioritise risk. (b) Secure-coding standards: Developers follow the Provider’s secure-coding standard (based on OWASP Secure Coding Practices) covering input validation, output encoding, authentication, session management, error handling, and cryptography. (c) Static Application Security Testing (SAST): Automated SAST runs on every code commit. Findings of High/Critical severity block the build until resolved. (d) Dynamic Application Security Testing (DAST): DAST is executed against the Staging Environment before every production deployment. The scan targets the OWASP Top 10 and ASVS Level 2 controls. (e) Software Composition Analysis (SCA): All third-party dependencies are scanned for known vulnerabilities (CVEs) and licence compliance on every build. Components with unpatched Critical/High CVEs are blocked. (f) Code review: All production code changes require peer review and approval before merge to the Master branch. Security-sensitive changes (authentication, cryptography, access-control logic) require review by a designated security champion. (g) Version control: Git-based version control with Master/Client/Working branch model (§4.7). All commits are signed and traceable to individual developers. Force-push to Master is prohibited. 8.10 Source Code Protection The Provider’s source code constitutes proprietary intellectual property and is subject to the following protections: (a) Access restriction: Source code repositories are accessible only to authorised Provider development personnel. Customer personnel do not have access to source code unless a separate source-code escrow agreement is executed. (b) Source-code escrow: Upon Customer request, the Provider shall enter into a source-code escrow agreement with a reputable third-party escrow agent. Release conditions typically include: Provider insolvency, material breach of this Framework, or discontinuation of the Platform without an adequate successor product. (c) Thin-client architecture: The Platform operates as a thin-client web application. No proprietary source code, compiled binaries, or application logic is distributed to Client devices. All application processing occurs server-side within the Customer’s sovereign environment. (d) Obfuscation: Client-side JavaScript and CSS delivered to the browser are minified and obfuscated. Source maps are not exposed in production deployments. (e) No open-source obligation: The Provider ensures that the use of open-source components does not create an obligation to disclose proprietary source code (e.g., copyleft licence contamination). All open-source components are vetted for licence compatibility before adoption. 8.11 Confidentiality Obligations 8.11.1 Information Classification All information exchanged between the Parties is classified according to the following scheme: Classification Definition Handling Requirements STRICTLY CONFIDENTIAL Customer Data, source code, security configurations, encryption keys, penetration-test reports, vulnerability reports Encrypted at rest and in transit; access restricted to named individuals on a need-to-know basis; no disclosure to third parties without written consent; deletion/return on termination (§7.13) CONFIDENTIAL Commercial terms, pricing, project plans, architectural diagrams, process documentation, training materials Protected from unauthorised disclosure; shared only with authorised personnel; marked ‘CONFIDENTIAL’ when distributed; encrypted in transit INTERNAL Provider internal procedures, non-sensitive operational documentation Not shared externally; standard access controls; no public disclosure PUBLIC Marketing materials, published product documentation, publicly available certifications No handling restrictions; may be freely distributed 8.11.2 Mutual Confidentiality Undertakings Each Party undertakes to the other that it shall: (a) Keep confidential all Confidential Information of the disclosing Party and not disclose it to any third party without the prior written consent of the disclosing Party. (b) Use the Confidential Information solely for the purpose of performing its obligations or exercising its rights under this Framework. (c) Restrict disclosure of Confidential Information to those of its employees, agents, or sub-processors who need to know the information for the purposes of this Framework and who are bound by confidentiality obligations no less restrictive than those contained herein. (d) Apply the same degree of care to protect the Confidential Information of the disclosing Party as it applies to its own confidential information, but in no event less than reasonable care. (e) Promptly notify the disclosing Party of any actual or suspected unauthorised disclosure or use of Confidential Information. 8.11.3 Exclusions The confidentiality obligations shall not apply to information that: (a) Is or becomes publicly available through no fault of the receiving Party. (b) Was already known to the receiving Party at the time of disclosure, as demonstrated by written records. (c) Is independently developed by the receiving Party without reference to the Confidential Information. (d) Is lawfully obtained from a third party without restriction on disclosure. (e) Is required to be disclosed by applicable law, regulation, or court order, provided that the receiving Party gives prompt written notice to the disclosing Party (to the extent legally permissible) and cooperates in any effort to obtain protective treatment. 8.11.4 Survival The confidentiality obligations set out in this section shall survive termination or expiry of this Framework for a period of five (5) years, except with respect to trade secrets, which shall be protected for as long as they remain trade secrets under applicable law. 8.12 Access Removal 8.12.1 Systems Access Removal When a Provider employee’s role changes or their employment terminates, all systems access is removed within: (a) Involuntary termination or security concern: Immediate revocation (within 1 hour) of all system credentials, VPN access, Key Vault permissions, and physical-facility access. (b) Planned departure: Access is revoked on the last working day. All Provider-owned devices are returned and wiped. (c) Role change: Access is adjusted within one (1) business day to reflect the new role’s privilege requirements. Excess privileges from the prior role are removed. 8.12.2 Application Access Removal When a Customer end-user’s role changes or they leave the Customer’s organisation: (a) Customer responsibility: The Customer’s system administrator (or Champion) is responsible for disabling or modifying user accounts within the STY module. (b) Provider support: Where the Customer requires Provider assistance (e.g., bulk-deactivation, emergency lockout), a P2 service request (§4.3) shall be raised and processed within the applicable SLA. (c) Dormant-account detection: The Platform flags accounts with no login activity for more than ninety (90) calendar days. Flagged accounts are reported to the Customer administrator for review and potential deactivation. 8.13 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-8.01 ISMS Risk Assessment Annual schedule or significant change Provider CISO / IT Dept Provider Management Updated risk register and SoA §8.3 P-8.02 Authenticati on Policy Update Regulatory change, security incident, or annual review Provider IT Dept Provider CISO Updated authentication controls in STY module §8.4.1 P-8.03 Access-Control Review Quarterly schedule Provider IT Dept + Customer Admin Customer PM Privilege reconciliation report; excess privileges revoked §8.4.2 P-8.04 NSG / Firewall Rule Change Change request or security incident Provider Cloud Ops Provider CISO Updated firewall rules; change-log entry; rollback capability §8.5.1 P-8.05 Patch Deployment Vendor patch release or zero-day disclosure Provider Cloud Ops Provider CISO Patched systems within remediation SLA; test evidence §8.5.2 P-8.06 Database Privilege Review Quarterly schedule Provider DBA Provider CISO Reviewed privilege assignments; revoked excess §8.6.2 P-8.07 Encryption Key Rotation Rotation schedule (max 90 days) or key compromise Provider Cloud Ops Provider CISO Rotated keys; updated Key Vault references §8.5.3 P-8.08 Vulnerability Scan (Infrastructu re) Weekly schedule Provider Cloud Ops Provider CISO Scan report; new findings triaged and prioritised §8.7.1 P-8.09 Vulnerability Scan (Application) Every build + weekly Provider Dev / Security Provider CISO SAST/DAST/SCA findings; Critical/High blocked §8.7.1 P-8.10 Penetration Test Annual schedule Third-party tester Provider CISO + Customer PM Pen-test report with findings and remediation plan §8.7.1 P-8.11 Vulnerability Remediation New finding classified ≥ Medium Provider Dev / Cloud Ops Provider CISO Remediation within CVSS-based SLA §8.7.2 P-8.12 Security Incident Response SIEM/AIOps alert or manual detection Provider SOC Provider CISO Incident contained; RCA delivered within 15 BDs §8.8.2 P-8.13 Threat-Model Review New feature or significant change Provider Security Champion Provider CISO Updated threat model; identified risks mitigated §8.9 P-8.14 Code Security Review Pull request targeting Master branch Peer reviewer + Security Champion Provider Dev Lead Approved merge; SAST findings resolved §8.9 P-8.15 Source-Code Escrow Update New major release or Customer request Provider Legal / Dev Customer PM Updated escrow deposit with current release §8.10 P-8.16 Information Classificatio n Review Annual schedule or new information type Provider DPO + CISO Provider Management Updated classification register §8.11.1 P-8.17 Provider Staff Access Removal Employment termination or role change Provider HR + IT Dept Provider CISO Access revoked within SLA; device wiped §8.12.1 P-8.18 Dormant Account Review 90-day inactivity flag Customer Admin / Champion Customer PM Account deactivated or exception documented §8.12.2 8.14 Process-Flow Schematic The following diagram illustrates the information-security lifecycle from risk assessment through continuous monitoring and incident response. ① ISMS Risk Assessment → ② Security Architecture & Controls → ③ Secure Development & Deployment ▼ ④ Vulnerability Management → ⑤ Continuous Monitoring (SIEM / AIOps) → ⑥ Access Control & Reviews ▼ ⑦ Incident Detection & Response → ⑧ Post-Incident Review & Improvement → ⑨ Compliance Audit & Certification Continuous loop: Stage ⑨ (Audit & Certification) feeds back into Stage ① (Risk Assessment) through the ISMS continuous improvement cycle (Plan–Do–Check–Act). Stages ④–⑦ operate continuously with weekly automated scans and real-time SIEM monitoring. Annual penetration tests and certification audits provide independent assurance. ← PreviousData Protection & PrivacyNext →Business Continuity & Disaster Recovery See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →
Chapter 8 · ProjectVIEW ERP Master SaaS Framework The Provider’s Information Security Management System is aligned with ISO/IEC 27001:2022 and enforces security at every tier — browser, application server and database — inside each customer’s dedicated Azure environment. Chapter 8 covers application, infrastructure and database security, vulnerability management, security monitoring and incident response, the secure development lifecycle, source-code protection and confidentiality. ISO/IEC 27001:2022ISMS alignment 3 tiersweb, application and database security SDLCsecure development lifecycle 8.1 Overview & Purpose This chapter defines the information-security and confidentiality obligations governing the Provider’s delivery of the ProjectVIEW ERP Platform. It establishes the security architecture, authentication controls, encryption standards, network defences, vulnerability management procedures, and confidentiality provisions that protect Customer Data, Platform integrity, and the Provider’s proprietary intellectual property throughout the Subscription Term. The Provider’s Information Security Management System (ISMS) is maintained by the IT Department and is aligned with ISO/IEC 27001:2022. This chapter addresses the technical security controls that complement the privacy-specific measures described in Chapter 7 (Data Protection & Privacy) and the operational-support security measures described in Chapter 4 (Service Support & Operations). DANAOS Web Enterprise incorporates security mechanisms at every layer of the application stack — from the presentation tier (web browser) through the application tier (application server) to the data tier (database server) — ensuring that confidentiality, integrity, and availability (the C.I.A. triad) are enforced end-to-end within each Customer’s dedicated private sovereign environment. 8.2 Scope This chapter covers: (a) Platform application security: Authentication, authorisation, session management, input validation, and secure-coding practices embedded within the DANAOS Web Framework. (b) Infrastructure security: Network segmentation, firewall configuration, intrusion detection, DDoS protection, and Web Application Firewall (WAF) controls applied to each Customer’s Azure-hosted sovereign environment. (c) Database security: Access control, encryption (at rest and in transit), audit logging, privilege management, and connection monitoring for SQL Server database instances. (d) Operational security: Vulnerability management, penetration testing, patch management, change-tracking, and security-incident response (non-personal-data incidents; Personal Data breaches are governed by §7.15). (e) Source-code security: Intellectual-property protection, secure-development lifecycle, Git-based version control, and code-review practices governing the Provider’s proprietary codebase. (f) Confidentiality obligations: Mutual confidentiality undertakings, information classification, disclosure restrictions, and survival provisions. 8.3 Security Standards & Frameworks The Provider’s security programme is built on the following standards, frameworks, and guidance: Ref Standard / Framework Application SF-01 ISO/IEC 27001:2022 Foundation for the ISMS; defines the management system, risk assessment methodology, Statement of Applicability (SoA), and continuous improvement cycle. SF-02 ISO/IEC 27002:2022 Reference control set; provides implementation guidance for the Annex A controls selected in the SoA. SF-03 NIST Cybersecurity Framework (CSF) 2.0 Used to structure the Provider’s security functions: Identify, Protect, Detect, Respond, Recover, and Govern. SF-04 OWASP Top 10 (2021) Baseline for web-application security; integrated into the Provider’s secure-development lifecycle and penetration-testing scope. SF-05 OWASP Application Security Verification Standard (ASVS) 4.0 Used for Level 2 verification of authentication, session management, access control, and input-validation controls. SF-06 CIS Microsoft Azure Foundations Benchmark v2.1 Hardening baseline for Azure infrastructure; applied to NSGs, storage accounts, key vaults, and identity configuration. SF-07 CIS Microsoft SQL Server 2022 Benchmark Hardening baseline for SQL Server database instances; applied to authentication, authorisation, auditing, and encryption settings. SF-08 NIST SP 800-63B Digital identity guideline for authentication assurance levels; informs password-policy and MFA requirements. SF-09 Microsoft Azure Well-Architected Framework — Security Pillar Cloud-native security design principles: zero-trust, defence-in-depth, and least-privilege. ISO/IEC 27001:2022 NIST CSF 2.0 OWASP Top 10 (2021) CIS Azure Foundations Benchmark NIST SP 800-63B Azure Well-Architected Framework 8.4 Application Security DANAOS ProjectVIEW ERP platform incorporates the following security mechanisms at the application layer to ensure system confidentiality and integrity. These controls are enforced for every Customer instance and are configurable by the Customer’s system administrators through the STY (Users & Roles Management) module. 8.4.1 Authentication Controls Control Description Configurable Reference Password complexity Inherits Microsoft LDAP authentication password-value requirements. Enforces minimum character-class diversity (uppercase, lowercase, numeric, special characters) and prohibits common/breached passwords. Yes — complexity rules defined by Customer admin NIST SP 800-63B §5.1.1 Password expiration System administrators define a mandatory rotation period after which users must alter their password. Default: 90 days; configurable per Customer policy. Yes — rotation period in days ISO 27002 §8.5 Failed-authentication lockout System administrators define the maximum number of consecutive failed login attempts per account, after which the account is locked for a configurable duration. Yes — attempt threshold + lockout duration OWASP ASVS 2.2.1 Password history Prevents users from reusing any password value used in the past. System administrators configure the number of historical passwords retained. Yes — history depth (N passwords) NIST SP 800-63B Minimum password length System administrators define the minimum length of the password value users may utilise. Yes — minimum characters NIST SP 800-63B §5.1.1 Idle-session lock System administrators define the number of minutes of inactivity after which the application demands re-authentication (away-from-keyboard lock screen). Yes — timeout in minutes ISO 27002 §8.1 Multi-factor authentication (MFA) Incorporated Google Authenticator OTP (TOTP) authentication mandated when login requests originate outside the intranet. System administrators define network/IP ranges considered ‘external’ that trigger MFA. Yes — network/IP ranges, MFA method NIST SP 800-63B AAL2 Single Sign-On (SSO) Supports SSO via Active Directory (SAML 2.0, OpenID Connect). Enables centralised credential management and reduces password proliferation. Yes — IdP integration configuration ISO 27002 §8.5 8.4.2 Authorisation & Access Control The Platform’s Users & Roles Management module (STY) enforces granular, role-based access control (RBAC) at multiple levels: (a) Module level: Users are granted or denied access to entire modules (e.g., PV_07 HRMS– Payroll, PV_08 Accounting) based on their role assignment. (b) Function level: Within a module, individual functions (e.g., create purchase order, approve invoice, view salary) are independently permissioned. (c) Field level: Sensitive fields within a record (e.g., salary amount, bank account, national ID) can be hidden or read-only for specific roles. (d) Record level: Row-level security restricts visibility based on organisational hierarchy (e.g., project managers see only their assigned projects; regional managers see their region). (e) Segregation of duties: Conflicting-role detection prevents a single user from holding roles that create separation-of-duties conflicts (e.g., requisition creator and approval authority). The STY module alerts administrators to detected conflicts and enforces policy-based restrictions. (f) Unique user IDs: Every user account is assigned a unique identifier. Shared/generic accounts are prohibited. All actions are traceable to an individual user through the audit trail. (g) Restricted remote access: System administrators control remote access per user via the administrator console; access can be allowed or revoked at any time. 8.4.3 Session Security (a) Session tokens: Cryptographically random session tokens are generated upon authentication. Tokens are bound to the user’s IP address and user-agent string to prevent session hijacking. (b) Session invalidation: Sessions are invalidated upon: password change, account suspension, explicit logout, or idle-timeout expiry. (c) Concurrent-session control: Configurable limits on concurrent active sessions per user account. Default: single active session per user (last-login-wins policy). 8.4.4 Input Validation & Output Encoding (a) Server-side validation: All user-supplied input is validated on the server side using whitelist-based validation. Client-side validation is treated as a usability enhancement only, never as a security control. (b) Parameterised queries: All database interactions use parameterised queries (prepared statements) to prevent SQL injection. Dynamic SQL construction from user input is prohibited by the Provider’s secure-coding standard. (c) Output encoding: All data rendered to the browser is contextually encoded (HTML, JavaScript, URL, CSS encoding as appropriate) to prevent cross-site scripting (XSS). (d) Content Security Policy (CSP): HTTP response headers include a strict Content Security Policy to mitigate XSS and data-injection attacks. 8.5 Infrastructure Security Each Customer’s ProjectVIEW ERP instance is deployed within a dedicated private sovereign environment on Microsoft Azure. The infrastructure security controls described below are applied per-tenant and are aligned with the CIS Azure Foundations Benchmark and the Azure Well-Architected Security Pillar. 8.5.1 Network Security (a) Network Security Groups (NSGs): Each virtual machine is protected by NSGs that provide stateful firewall functionality with explicit allow/deny rules. Default policy: deny-all inbound; allow only required service ports. (b) Web Application Firewall (WAF): Azure WAF is deployed in front of the application tier to protect against OWASP Top 10 threats, including SQL injection, XSS, CSRF, and request-smuggling attacks. (c) DDoS Protection: Azure DDoS Protection Standard is enabled for all Customer environments, providing volumetric, protocol, and application-layer attack mitigation with automatic detection and inline remediation. (d) Network segmentation: The data tier, application tier, and management tier are deployed in separate subnets with inter-tier traffic controlled by NSG rules. The database subnet is not directly accessible from the internet. (e) VPN & private connectivity: Where the Customer requires site-to-site connectivity (e.g., integration with on-premises Active Directory), Azure VPN Gateway or ExpressRoute is provisioned with IPSec/IKEv2 encryption. (f) DNS security: Azure Private DNS zones are used to prevent DNS-based data exfiltration. Public DNS records are protected with DNSSEC where supported by the registrar. 8.5.2 Compute Security (a) Operating system hardening: All virtual machines run Microsoft Windows Server 2022, hardened per CIS Windows Server 2022 Benchmark. Unnecessary services, ports, and features are disabled. (b) Patch management: Security patches are applied within: (i) seventy-two (72) hours for Critical/High CVEs; (ii) thirty (30) calendar days for Medium CVEs; (iii) next maintenance window for Low CVEs. Patches are tested in the Staging Environment before production deployment. (c) Anti-malware: Cloud-native endpoint protection (Microsoft Defender for Cloud) is enabled on all virtual machines with real-time scanning, behavioural analysis, and automatic remediation. (d) Host-based intrusion detection: Azure Security Centre monitors file-integrity, suspicious process execution, and anomalous system calls on all VMs. 8.5.3 Identity & Secrets Management (a) Azure Key Vault: All cryptographic keys, certificates, connection strings, and service credentials are stored in Azure Key Vault with access controlled by Azure RBAC and Key Vault access policies. (b) Managed identities: Azure Managed Identities are used for service-to-service authentication where possible, eliminating the need for stored credentials in application configuration. (c) Secret rotation: Automated secret-rotation policies are enforced for all service-account credentials and API keys. Maximum rotation period: ninety (90) calendar days. 8.6 Database Security The Platform’s data tier runs on Microsoft SQL Server 2022 (Standard or Enterprise Edition) deployed on Microsoft Windows Server 2022. The following database-specific security controls are applied, aligned with the CIS SQL Server 2022 Benchmark: 8.6.1 Access & Authentication (a) Database authentication: SQL Server uses Windows Authentication mode (integrated with Active Directory) as the primary authentication method. Mixed-mode authentication is disabled unless explicitly required and approved by the Customer. (b) Application passwords: Application-level database credentials use strong passwords compliant with the password-composition policy and are rotated per the secret-rotation schedule (§8.5.3). (c) Default accounts: All default system accounts (e.g., ‘sa’) are properly secured by the DBA: default passwords are changed immediately upon provisioning; unnecessary default accounts are disabled or dropped. (d) Connection control: Connections to the database instances are controlled and monitored. Only authorised application-layer services and designated DBA personnel may establish connections. Connection strings are stored in Azure Key Vault (§8.5.3). (e) Ability to connect: Network-level controls restrict database connectivity to the application-tier subnet and authorised management endpoints only. Direct internet connectivity to the database is prohibited. 8.6.2 Privilege Management (a) Minimum permissions & roles: Database user accounts are provisioned with the minimum permissions and roles necessary for their function. The principle of least privilege is enforced and periodically reviewed. (b) System privileges: All ‘system’ privileges are removed from user accounts unless explicitly required and approved. Privileged operations require a separate, dedicated DBA account with MFA. (c) Segregation of duties: Database administration privileges are segregated from application-development privileges. Developers do not have production database access. (d) Privilege review: Quarterly review of database privilege assignments; unused or excessive privileges are revoked. Review results are documented and available for audit (§7.11). 8.6.3 Encryption (a) Transparent Data Encryption (TDE): TDE is enabled on all production and staging database instances, encrypting data files, log files, and tempdb using AES-256 encryption. TDE certificates are backed up and stored in Azure Key Vault. (b) Backup encryption: All database backups (full, differential, and transaction-log) are encrypted using AES-256 with Customer-specific encryption keys managed through Azure Key Vault. (c) Column-level encryption: Where required by the Customer’s data-classification policy, column-level encryption (Always Encrypted) is available for highly sensitive fields (e.g., national IDs, bank account numbers). 8.6.4 Auditing & Logging (a) Audit logging: SQL Server Audit captures: (i) all DDL operations (schema changes); (ii) privileged-user activity; (iii) failed authentication attempts; (iv) data-export and bulk-copy operations; (v) permission changes. Audit logs are written to a tamper-evident store. (b) Logging retention: Database audit logs are retained for a minimum of twelve (12) months online and twenty-four (24) months in archival storage. Retention meets regulatory requirements under GDPR, UAE PDPL, and applicable industry standards. (c) Change tracking: SQL Server Change Tracking and Change Data Capture (CDC) are enabled to provide a complete inventory of data modifications for compliance and audit purposes. (d) 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.3). 8.7 Vulnerability Management The Provider operates a continuous vulnerability management programme aligned with NIST CSF Identify (ID.RA) and Protect (PR.IP) functions: 8.7.1 Assessment Schedule Assessment Type Frequency Scope Standard / Tool Automated vulnerability scan (infrastructure) Weekly All Azure VMs, NSGs, storage accounts, Key Vaults Microsoft Defender for Cloud + third-party scanner Automated vulnerability scan (application) Weekly (on every build) DANAOS Web Framework codebase; OWASP Top 10 + SANS CWE 25 SAST + DAST integrated into CI/CD pipeline Dependency / supply-chain scan On every build + daily Third-party libraries, NuGet/npm packages, container images Software Composition Analysis (SCA) tool Penetration test (external) Annually Public-facing attack surface; authentication bypass, privilege escalation, data exfiltration Certified third-party penetration-testing firm Penetration test (internal / red team) Annually Lateral movement, privilege escalation, insider-threat scenarios Provider security team or certified third party Configuration compliance scan Monthly CIS Benchmark compliance for Azure, Windows Server, SQL Server CIS-CAT Pro or equivalent 8.7.2 Remediation Timelines CVSS Severity Score Range Remediation SLA Escalation Critical 9.0–10.0 ≤72 hours Immediate escalation to CISO; Customer notification within 24 hours if Customer-facing High 7.0–8.9 ≤30 calendar days Escalation to security lead; included in next patch cycle Medium 4.0–6.9 ≤90 calendar days Tracked in vulnerability register; scheduled remediation Low 0.1–3.9 Next major release Documented; remediated as part of ongoing hardening Zero-day vulnerabilities: For actively exploited zero-day vulnerabilities affecting the Platform’s technology stack, the Provider shall apply emergency mitigation measures (e.g., WAF rules, network isolation, virtual patching) within twenty-four (24) hours, with a permanent patch following the Critical remediation SLA. 8.8 Security Monitoring & Incident Response 8.8.1 Monitoring The Provider operates a 24/7 security-monitoring capability using the following components: (a) SIEM: Cloud-native Security Information and Event Management (Microsoft Sentinel) aggregates logs from all infrastructure, application, and database layers. Correlation rules and machine-learning detections identify anomalous patterns. (b) AIOps: AI-driven operations tooling provides predictive anomaly detection on performance metrics, authentication patterns, and data-access volumes, enabling early identification of security-relevant deviations before they escalate to incidents. (c) Threat intelligence: SIEM integrates real-time threat-intelligence feeds (Microsoft Threat Intelligence, industry-specific IOCs) to detect known attack signatures and indicators of compromise. (d) User and Entity Behaviour Analytics (UEBA): Baseline behaviour profiles are established for users and service accounts. Deviations (e.g., anomalous login locations, unusual data-access patterns, privilege-escalation attempts) trigger automated alerts. 8.8.2 Security Incident Response Security incidents that do not involve Personal Data are managed under this section. Personal Data breaches are governed by §7.15. Where an incident is later classified as involving Personal Data, the §7.15 breach-notification procedures apply in addition to the measures below. Phase Activities Timeline Detection & Triage SIEM/AIOps alert triggered → SOC analyst validates → incident classified by severity → assigned to responder Real-time Containment Isolate affected systems; block IOCs at perimeter; revoke compromised credentials; preserve forensic evidence ≤60 minutes (Critical); ≤4 hours (High) Eradication Remove threat actor presence; patch exploited vulnerability; rebuild compromised components from known-good images Concurrent with containment Recovery Restore services from clean backups; validate integrity; re-enable network connectivity; confirm no residual indicators Per RTO targets (§3.4) Post-Incident Review Root-cause analysis; lessons-learned documentation; control improvements; Customer notification (if applicable) ≤15 business days post-containment 8.8.3 Customer Notification The Provider shall notify the Customer of security incidents that: (i) result in actual or suspected unauthorised access to Customer Data; (ii) materially affect Platform availability or integrity; or (iii) involve law-enforcement engagement related to the Customer’s environment. Notification shall occur within the timelines aligned with the incident severity and the breach-notification SLAs defined in §7.15.1. 8.9 Secure Development Lifecycle (SDLC) The Provider follows a secure SDLC aligned with OWASP’s Software Assurance Maturity Model (SAMM) and Microsoft’s Security Development Lifecycle (SDL): (a) Threat modelling: New features and significant changes undergo threat modelling during design. STRIDE methodology is used to identify threats; DREAD is used to prioritise risk. (b) Secure-coding standards: Developers follow the Provider’s secure-coding standard (based on OWASP Secure Coding Practices) covering input validation, output encoding, authentication, session management, error handling, and cryptography. (c) Static Application Security Testing (SAST): Automated SAST runs on every code commit. Findings of High/Critical severity block the build until resolved. (d) Dynamic Application Security Testing (DAST): DAST is executed against the Staging Environment before every production deployment. The scan targets the OWASP Top 10 and ASVS Level 2 controls. (e) Software Composition Analysis (SCA): All third-party dependencies are scanned for known vulnerabilities (CVEs) and licence compliance on every build. Components with unpatched Critical/High CVEs are blocked. (f) Code review: All production code changes require peer review and approval before merge to the Master branch. Security-sensitive changes (authentication, cryptography, access-control logic) require review by a designated security champion. (g) Version control: Git-based version control with Master/Client/Working branch model (§4.7). All commits are signed and traceable to individual developers. Force-push to Master is prohibited. 8.10 Source Code Protection The Provider’s source code constitutes proprietary intellectual property and is subject to the following protections: (a) Access restriction: Source code repositories are accessible only to authorised Provider development personnel. Customer personnel do not have access to source code unless a separate source-code escrow agreement is executed. (b) Source-code escrow: Upon Customer request, the Provider shall enter into a source-code escrow agreement with a reputable third-party escrow agent. Release conditions typically include: Provider insolvency, material breach of this Framework, or discontinuation of the Platform without an adequate successor product. (c) Thin-client architecture: The Platform operates as a thin-client web application. No proprietary source code, compiled binaries, or application logic is distributed to Client devices. All application processing occurs server-side within the Customer’s sovereign environment. (d) Obfuscation: Client-side JavaScript and CSS delivered to the browser are minified and obfuscated. Source maps are not exposed in production deployments. (e) No open-source obligation: The Provider ensures that the use of open-source components does not create an obligation to disclose proprietary source code (e.g., copyleft licence contamination). All open-source components are vetted for licence compatibility before adoption. 8.11 Confidentiality Obligations 8.11.1 Information Classification All information exchanged between the Parties is classified according to the following scheme: Classification Definition Handling Requirements STRICTLY CONFIDENTIAL Customer Data, source code, security configurations, encryption keys, penetration-test reports, vulnerability reports Encrypted at rest and in transit; access restricted to named individuals on a need-to-know basis; no disclosure to third parties without written consent; deletion/return on termination (§7.13) CONFIDENTIAL Commercial terms, pricing, project plans, architectural diagrams, process documentation, training materials Protected from unauthorised disclosure; shared only with authorised personnel; marked ‘CONFIDENTIAL’ when distributed; encrypted in transit INTERNAL Provider internal procedures, non-sensitive operational documentation Not shared externally; standard access controls; no public disclosure PUBLIC Marketing materials, published product documentation, publicly available certifications No handling restrictions; may be freely distributed 8.11.2 Mutual Confidentiality Undertakings Each Party undertakes to the other that it shall: (a) Keep confidential all Confidential Information of the disclosing Party and not disclose it to any third party without the prior written consent of the disclosing Party. (b) Use the Confidential Information solely for the purpose of performing its obligations or exercising its rights under this Framework. (c) Restrict disclosure of Confidential Information to those of its employees, agents, or sub-processors who need to know the information for the purposes of this Framework and who are bound by confidentiality obligations no less restrictive than those contained herein. (d) Apply the same degree of care to protect the Confidential Information of the disclosing Party as it applies to its own confidential information, but in no event less than reasonable care. (e) Promptly notify the disclosing Party of any actual or suspected unauthorised disclosure or use of Confidential Information. 8.11.3 Exclusions The confidentiality obligations shall not apply to information that: (a) Is or becomes publicly available through no fault of the receiving Party. (b) Was already known to the receiving Party at the time of disclosure, as demonstrated by written records. (c) Is independently developed by the receiving Party without reference to the Confidential Information. (d) Is lawfully obtained from a third party without restriction on disclosure. (e) Is required to be disclosed by applicable law, regulation, or court order, provided that the receiving Party gives prompt written notice to the disclosing Party (to the extent legally permissible) and cooperates in any effort to obtain protective treatment. 8.11.4 Survival The confidentiality obligations set out in this section shall survive termination or expiry of this Framework for a period of five (5) years, except with respect to trade secrets, which shall be protected for as long as they remain trade secrets under applicable law. 8.12 Access Removal 8.12.1 Systems Access Removal When a Provider employee’s role changes or their employment terminates, all systems access is removed within: (a) Involuntary termination or security concern: Immediate revocation (within 1 hour) of all system credentials, VPN access, Key Vault permissions, and physical-facility access. (b) Planned departure: Access is revoked on the last working day. All Provider-owned devices are returned and wiped. (c) Role change: Access is adjusted within one (1) business day to reflect the new role’s privilege requirements. Excess privileges from the prior role are removed. 8.12.2 Application Access Removal When a Customer end-user’s role changes or they leave the Customer’s organisation: (a) Customer responsibility: The Customer’s system administrator (or Champion) is responsible for disabling or modifying user accounts within the STY module. (b) Provider support: Where the Customer requires Provider assistance (e.g., bulk-deactivation, emergency lockout), a P2 service request (§4.3) shall be raised and processed within the applicable SLA. (c) Dormant-account detection: The Platform flags accounts with no login activity for more than ninety (90) calendar days. Flagged accounts are reported to the Customer administrator for review and potential deactivation. 8.13 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-8.01 ISMS Risk Assessment Annual schedule or significant change Provider CISO / IT Dept Provider Management Updated risk register and SoA §8.3 P-8.02 Authenticati on Policy Update Regulatory change, security incident, or annual review Provider IT Dept Provider CISO Updated authentication controls in STY module §8.4.1 P-8.03 Access-Control Review Quarterly schedule Provider IT Dept + Customer Admin Customer PM Privilege reconciliation report; excess privileges revoked §8.4.2 P-8.04 NSG / Firewall Rule Change Change request or security incident Provider Cloud Ops Provider CISO Updated firewall rules; change-log entry; rollback capability §8.5.1 P-8.05 Patch Deployment Vendor patch release or zero-day disclosure Provider Cloud Ops Provider CISO Patched systems within remediation SLA; test evidence §8.5.2 P-8.06 Database Privilege Review Quarterly schedule Provider DBA Provider CISO Reviewed privilege assignments; revoked excess §8.6.2 P-8.07 Encryption Key Rotation Rotation schedule (max 90 days) or key compromise Provider Cloud Ops Provider CISO Rotated keys; updated Key Vault references §8.5.3 P-8.08 Vulnerability Scan (Infrastructu re) Weekly schedule Provider Cloud Ops Provider CISO Scan report; new findings triaged and prioritised §8.7.1 P-8.09 Vulnerability Scan (Application) Every build + weekly Provider Dev / Security Provider CISO SAST/DAST/SCA findings; Critical/High blocked §8.7.1 P-8.10 Penetration Test Annual schedule Third-party tester Provider CISO + Customer PM Pen-test report with findings and remediation plan §8.7.1 P-8.11 Vulnerability Remediation New finding classified ≥ Medium Provider Dev / Cloud Ops Provider CISO Remediation within CVSS-based SLA §8.7.2 P-8.12 Security Incident Response SIEM/AIOps alert or manual detection Provider SOC Provider CISO Incident contained; RCA delivered within 15 BDs §8.8.2 P-8.13 Threat-Model Review New feature or significant change Provider Security Champion Provider CISO Updated threat model; identified risks mitigated §8.9 P-8.14 Code Security Review Pull request targeting Master branch Peer reviewer + Security Champion Provider Dev Lead Approved merge; SAST findings resolved §8.9 P-8.15 Source-Code Escrow Update New major release or Customer request Provider Legal / Dev Customer PM Updated escrow deposit with current release §8.10 P-8.16 Information Classificatio n Review Annual schedule or new information type Provider DPO + CISO Provider Management Updated classification register §8.11.1 P-8.17 Provider Staff Access Removal Employment termination or role change Provider HR + IT Dept Provider CISO Access revoked within SLA; device wiped §8.12.1 P-8.18 Dormant Account Review 90-day inactivity flag Customer Admin / Champion Customer PM Account deactivated or exception documented §8.12.2 8.14 Process-Flow Schematic The following diagram illustrates the information-security lifecycle from risk assessment through continuous monitoring and incident response. ① ISMS Risk Assessment → ② Security Architecture & Controls → ③ Secure Development & Deployment ▼ ④ Vulnerability Management → ⑤ Continuous Monitoring (SIEM / AIOps) → ⑥ Access Control & Reviews ▼ ⑦ Incident Detection & Response → ⑧ Post-Incident Review & Improvement → ⑨ Compliance Audit & Certification Continuous loop: Stage ⑨ (Audit & Certification) feeds back into Stage ① (Risk Assessment) through the ISMS continuous improvement cycle (Plan–Do–Check–Act). Stages ④–⑦ operate continuously with weekly automated scans and real-time SIEM monitoring. Annual penetration tests and certification audits provide independent assurance. ← PreviousData Protection & PrivacyNext →Business Continuity & Disaster Recovery See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →