Security Policy

1. Scope and status

This Policy covers cloudhub.lk and products and services operated, developed, configured or supported by Cloud Partners that expressly link to it. It includes web applications, APIs, mobile applications, procurement systems, Muster, Cloudyy, custom implementations and our role in third-party cloud subscriptions.

This public statement describes our security approach. It does not certify that every control is present in every product, environment or customer implementation. Specific controls, service levels, recovery objectives and audit rights apply where documented in the applicable agreement. Future products must undergo a review of their actual controls before publishing product-specific claims.

2. Shared responsibilities

Cloud infrastructure providers operate the underlying services and physical facilities within their contractual scope. Cloud Partners is responsible for the application, configuration, access design, integration and support activities we undertake under the customer agreement. Provider protections do not eliminate application or configuration risk.

Customers manage authorised users, permissions, endpoint devices, data quality, lawful use and their own internal governance. They should enable available protective authentication controls, review administrator access, protect integrations and arrange business continuity appropriate to their needs. Each party remains responsible for the obligations that apply directly to it.

3. Identity access and customer separation

Access should be limited to authorised identities and the permissions needed for the task. Reviewed products use authentication and role or scope checks; the controls and their coverage depend on the product. Server-side authorisation must protect records independently of what a screen displays.

Administrative and support access should use strong authentication and multi-factor authentication where supported and appropriate to the risk. No statement here guarantees MFA on every existing portal. Access changes, account deactivation and reviews must follow the applicable operational process; a universal quarterly review or one-hour revocation commitment is not established by this Policy.

Applications serving multiple organisations require separation of customer records and permission checks at access boundaries. Customers should review roles, API credentials, exports and external sharing. Single sign-on verifies identity but does not alone authorise organisational access.

4. Data and credential protection

Production connections should use encrypted HTTPS or the applicable secure transport. Reviewed products include HTTPS-oriented access and credential-protection controls. Exact TLS versions, storage encryption and key-management arrangements must be confirmed for each deployed component rather than assumed across all systems.

Passwords, tokens, API credentials and configuration secrets require appropriate protection and restricted access. Customers must not share credentials through public support forms or expose keys in browser code or documents. Where needed, revoke compromised keys and contact support promptly.

Customer content, generated documents, attachments, payroll and location records require access restrictions appropriate to their sensitivity. Retention, deletion, logs and backup copies follow the agreed arrangements and applicable law, as explained in the Privacy Policy.

5. Development integrations and vulnerability management

Security review should address authentication, authorisation, input validation, uploads, external content, dependency risks, secrets and environment configuration. Features that render submitted HTML, call external URLs or integrate third-party systems require particular attention to untrusted content and access boundaries.

Patches and corrective changes are prioritised according to severity, exposure and operational impact. Automated checks, code reviews and technical testing can support this work. Independent penetration testing, its scope and frequency must be evidenced or agreed; this Policy does not promise annual independent VAPT or continuous review of every codebase.

Development and testing data should be limited and protected. Production data must not be used for testing without appropriate authorisation and safeguards. New integrations and providers require assessment of their access, data use, retention and contractual role.

6. Logging monitoring and personnel

Relevant products maintain records of selected authentication, administrative, approval, usage and data-change events. Event coverage and retention differ by product. Audit records support troubleshooting and accountability; we do not claim that every log is immutable or that all systems have continuous staffed monitoring.

Personnel and contractors should receive access appropriate to their work, protect confidential information and report suspected incidents. Staff training, confidentiality agreements, screening, endpoint management and offboarding arrangements must be confirmed for the actual operational process; this Policy does not establish that all personnel have undergone background screening or that every device can be remotely wiped.

7. Availability backups and recovery

Availability depends on application design, configuration, providers, networks and devices. Customers should agree their backup, restoration, export and recovery requirements for the selected service and maintain any additional records needed for critical operations.

Backup frequency, retention, restoration testing and recovery capabilities must be documented for the actual environment. Recovery point and recovery time objectives apply only when explicitly agreed and supported by the relevant architecture and tests. There is no universal promise of less than one hour of data loss or restoration within four hours, and no guarantee of uninterrupted availability.

An exported record is not a complete system backup. A backup is not proof of a tested restoration. Provider service credits and restoration commitments are limited to the applicable provider and customer agreements.

8. Incident handling and notification

Report suspected unauthorised access, lost credentials or exposed data to hello@cloudpartners.biz and, for an organisation account, to your administrator. Include the affected product, time, account or organisation and a factual description. Do not include unnecessary personal data or publish credentials.

Incident handling includes assessment, proportionate containment, preservation of relevant evidence, investigation, recovery and corrective action. Immediate isolation of every affected component is not always appropriate; actions depend on the incident and risks.

Where we act as a processor, we notify the affected customer without undue delay after becoming aware of a personal data breach and provide available information to support its response, as required by law and the applicable agreement. Where we act as controller, we assess any duty to notify authorities and individuals and meet the applicable legal thresholds and deadlines. Information may be supplied in stages as facts are confirmed.

A 72-hour deadline is not universal across Sri Lankan incidents, client notifications or CERT reports. GDPR establishes specific notification duties when it applies; other laws and contractual duties can differ. Statutory and contractual obligations take priority over this general description.

9. Provider assurance and applicable law

Cloud Partners' own security or compliance certification must be supported by a current certificate and a defined scope. A provider's ISO certificate, SOC report or other assurance does not certify Cloud Partners, its applications or a customer.

For Google Cloud and Zoho services, consult the provider's current compliance documentation and verify that the specific service, region and contract are covered. A statement about one service does not establish assurance for every product sold by that provider.

Relevant obligations include Sri Lanka's Personal Data Protection Act No. 9 of 2022, as amended and commenced, the Computer Crimes Act No. 24 of 2007, and the Electronic Transactions Act No. 19 of 2006, as amended. International duties apply where their legal scope is met. A criminal law or an online safety law is not itself a general security certification.

10. Responsible vulnerability reporting

Send a confidential vulnerability report to hello@cloudpartners.biz with the subject "Security report", the affected service, a concise description, minimal reproduction steps and the potential impact. Redact secrets and personal data; share additional sensitive evidence only through an agreed protected channel.

Use only accounts and systems you are authorised to test. Do not access other users' data, disrupt availability, use social engineering, extract records or continue once unintended access is demonstrated. This Policy is not permission to test production systems and does not promise legal safe harbour or a bounty.

We ask reporters to coordinate disclosure and allow reasonable time for assessment and remediation. This does not prevent legally required reporting. We do not publish a guaranteed response or remediation time under this Policy.

11. Updates and contact

We may update this Policy as services, controls and legal requirements change. The published revision date identifies the version. Material changes to contractual commitments are governed by the applicable agreement and law.