Sumalytics Public Security Policy

Security Policy

Public security statement for Sumalytics and DaaFlow

Last updated: 30 September 2026

Purpose: This public policy explains Sumalytics’ security approach at a high level. It is not a technical architecture specification, warranty, service-level agreement or certification statement.

1. Scope

This Security Policy applies to the public Sumalytics website, Sumalytics-managed online services and, where stated, the security approach used for DaaFlow. Customer-specific security obligations may also be set out in a signed service agreement, Data Processing Agreement, security schedule or other written contract. If there is a conflict, mandatory law and the signed contract govern.

2. Security principles

Sumalytics uses a risk-based approach intended to protect the confidentiality, integrity and availability of systems and data. Our security programme is guided by Ghanaian law, generally accepted information-security practices and the sensitivity of the information being processed.

least-privilege access and separation of responsibilities;

authentication and authorisation appropriate to the service and user role;

organisation and tenant isolation for multi-tenant application data;

secure transmission of data over public networks;

controlled handling of credentials, tokens and secrets;

logging, auditability and monitoring of important technical or business events;

backup, recovery and continuity planning proportionate to business risk;

timely remediation of material security weaknesses; and

security awareness, confidentiality and access discipline for staff and contractors.

Legal framework

This policy is intended to support compliance with applicable Ghanaian law, including the following, as amended or replaced from time to time:

the Constitution of the Republic of Ghana, 1992, including the constitutional right to privacy;

the Data Protection Act, 2012 (Act 843), including its data protection principles, registration, security, processor-contract, breach-notification and data-subject-rights requirements;

the Electronic Transactions Act, 2008 (Act 772), as amended, including requirements relevant to electronic transactions, privacy/security disclosures and unsolicited electronic commercial communications; and

the Cybersecurity Act, 2020 (Act 1038) and applicable directives, regulations or guidance issued by the Cyber Security Authority where relevant.

If another law, binding contract, regulatory requirement or customer-specific data processing agreement imposes a higher standard, Sumalytics will apply that requirement to the extent applicable.

3. Access control

Access to Sumalytics systems should be limited to authorised persons with a legitimate business need. Depending on the system, access controls may include strong authentication, multi-factor authentication for privileged accounts where supported, role-based permissions, organisation membership checks, operational scope restrictions and revocation when access is no longer required.

DaaFlow is designed so that customer access is not determined only by what the user interface displays. Server-side controls are intended to check the user’s organisation membership, permissions and relevant workflow or operational scope before protected actions are performed.

4. Customer organisation separation

DaaFlow is designed as a multi-tenant platform in which business records are associated with the relevant customer organisation. An organisation administrator is not, merely by being a customer administrator, a Sumalytics platform administrator and should not gain access to other customer organisations or Sumalytics platform-level controls.

Where additional database-level controls such as PostgreSQL Row Level Security are used, their presence or scope should be described accurately in customer-specific technical documentation. This public Policy does not represent that any particular defence-in-depth mechanism is universal unless it has been verified.

5. Encryption, communications and secrets

Public website and application traffic should use HTTPS/TLS where supported. Production credentials, database secrets and privileged service tokens should be held in server-side or managed secret stores and should not be deliberately exposed to ordinary browser or mobile clients. We do not claim proprietary or “unbreakable” cryptography.

6. Data protection and confidentiality

Security controls are implemented alongside the Data Protection Act, 2012 (Act 843). Personnel and service providers who are authorised to process personal or confidential data are expected to do so only for authorised purposes and to preserve confidentiality. Third-party processors should be subject to written contractual security and confidentiality obligations where required.

7. Secure development and change management

For software we develop and operate, our security objective is to use controlled source code, documented changes, testing and review proportionate to the risk of the change. Development, staging and production environments should be separated where practicable, and production customer data should not be copied into non-production environments except where there is a lawful, authorised and appropriately protected reason.

Database changes should be made through controlled migrations or equivalent change procedures rather than untracked manual changes where practicable.

8. Logging and audit

We distinguish technical logs from business audit records:

Type

Purpose

Example

Technical / system logs

Help operate, diagnose and protect systems.

Failed login, API error, service restart, security event.

DaaFlow business audit trail

Help authorised organisations reconstruct important operational actions.

Who created a Float, posted a Warehouse Receipt, changed access, reversed a Dispatch or retired a record.

Important business audit records should be append-oriented where practical, so that corrections and reversals create additional evidence rather than silently rewriting history. This does not mean that DaaFlow uses blockchain, WORM storage or a legally certified immutable ledger unless expressly stated in a signed agreement.

9. Backups, recovery and availability

We aim to use backup and recovery controls appropriate to the service, including managed backup capabilities and restoration testing. The existence of a backup file is not treated as equivalent to a successful restore. Recovery objectives communicated during pilots or proposals are targets unless expressly incorporated into a signed service-level agreement.

For DaaFlow pilot planning, any stated recovery point objective (RPO) or recovery time objective (RTO) remains a target until the relevant production environment and restore procedures have been tested and documented.

10. Mobile and offline security

Where DaaFlow mobile/offline features are provided, offline operation should not bypass authorisation. The security design should limit locally available information according to the user’s authorised scope, protect authentication tokens and sensitive local data using platform-appropriate controls, and re-authorise queued operations when they synchronise with the server. We do not claim remote device wipe unless that capability is actually implemented.

11. Third-party cloud and service providers

Sumalytics may use established hosting, database, authentication, communications, source-control, monitoring, storage or other technology providers. We assess providers and configurations in light of the data and service involved. A provider’s ISO, SOC or other certification applies to that provider and its certified controls; it does not automatically make Sumalytics or DaaFlow certified.

Where a customer or programme requires a specific hosting region, including Ghana, the European Union or Germany, the agreed region must be expressly documented and technically verified before Sumalytics represents that the requirement has been met.

12. Vulnerability management and security testing

We seek to identify and remediate material vulnerabilities through a combination of secure engineering practices, dependency and configuration review, testing, monitoring and, where appropriate, independent assessment. We will state the exact status of penetration testing, certifications and independent assessments when asked and will not represent planned work as already completed.

13. Reporting a security concern

If you believe you have identified a security issue affecting a Sumalytics website or DaaFlow, report it promptly to info@sumalytics.com with the subject “Security Report”. Please include enough information for us to understand and reproduce the issue, but do not include unnecessary personal data or customer information.

If a dedicated security mailbox is later configured, this Policy should be updated to use that address.

14. Responsible security research and prohibited activity

A public website does not grant permission to perform intrusive security testing. Unless you have prior written authorisation from Sumalytics, you must not:

access, attempt to access or retain data that does not belong to you;

bypass authentication, authorisation, tenant boundaries, rate limits or security controls;

perform denial-of-service, load, destructive or availability-impacting testing;

deploy malware, ransomware, persistence mechanisms or destructive payloads;

conduct social engineering, phishing or impersonation of Sumalytics staff, customers or partners;

scan or exploit third-party infrastructure merely because it is used by Sumalytics;

alter, delete, download or disclose customer data; or

publish a vulnerability before Sumalytics has had a reasonable opportunity to investigate and remediate it.

If, despite reasonable care, you encounter personal or customer data while investigating an issue, stop, avoid further access, do not copy or disclose the data, and notify us. Nothing in this Policy authorises conduct prohibited by Ghanaian law or other applicable law.

15. Security incidents

Sumalytics maintains or develops incident-handling procedures appropriate to the service and severity of an event. A response may include containment, preservation of evidence, investigation, remediation, credential rotation, recovery, customer communication and regulatory notification where required. Personal-data compromises are handled in accordance with the Data Protection Act, including notification obligations where applicable.

16. Employee and contractor security

Access granted to employees and contractors should be limited to the work they are authorised to perform. Sumalytics may use confidentiality obligations, access reviews, training, device/account controls and prompt revocation of access when a role ends or changes. Staff should not disclose passwords, one-time passcodes, recovery codes or privileged secrets to customers or third parties.

Anti-impersonation notice: Sumalytics personnel should never ask a customer to send a password, one-time passcode or account-recovery secret by email, phone, social media or WhatsApp. If someone claims to be Sumalytics and requests such information, do not provide it; contact us through an address published on our official website.

17. Certifications and compliance statements

Unless expressly stated on our official website or in a signed agreement, Sumalytics and DaaFlow should not be understood to hold ISO 27001, SOC 2 or similar certification. We may rely on infrastructure providers that hold independent certifications, but those certifications do not transfer to Sumalytics or DaaFlow.

Similarly, use of servers located in Ghana, Germany or the European Union does not by itself establish compliance with the Data Protection Act, GDPR or any other privacy law.

18. No absolute security guarantee

No internet-connected system can be guaranteed to be free from every vulnerability, outage or attack. We use reasonable controls and risk management, but we do not warrant that the website, DaaFlow or any connected service will be completely secure, continuously available or immune from malicious activity. Specific contractual security commitments or service levels apply only where they are expressly agreed in writing.

19. Corporate responsibility and no personal undertaking

Security commitments made under this Policy are commitments of the responsible Sumalytics legal entity. Routine statements, demonstrations, emails or support communications by founders, directors, employees or contractors do not create a personal guarantee or personal assumption of company liabilities. Nothing in this section excludes personal responsibility where Ghanaian law expressly imposes it, or excludes liability that cannot lawfully be excluded.

20. Changes to this Policy

We may update this Policy to reflect changes in technology, law, threat conditions, infrastructure or business operations. The current version will be published with its update date. Customer-specific contractual security terms are not changed merely by publishing an updated public policy unless the contract expressly says otherwise.

21. Contact

Security questions and vulnerability reports: info@sumalytics.com (subject: “Security Report”). General contact: +233 (0) 55 253 7904. Business location: Kanvili, Tamale, Northern Region, Ghana.