Security Policy

Digitel Africa Pty Ltd operates digital infrastructure that our customers depend on every day, including business email, DNS, hosting, our cloud and application platform, managed PostgreSQL databases, domains, SSL, and VPN. Security is not a feature we bolt on afterwards. It is a design constraint that runs through how we build, operate, and support each of these services.

This policy describes the practices we use to protect your data and our systems, and sets out how security researchers can report a vulnerability responsibly. It is written to be honest and specific: where a control is a goal or work in progress, we say so rather than overstate it. For how we handle personal information, see our Privacy Policy.

Our security programme rests on a few principles:

• Defence in depth — no single control is a single point of failure.
• Least privilege — people and systems get only the access they need.
• Encrypt everywhere — data is protected in transit and at rest.
• Assume breach — we monitor, log, and rehearse our response so we can act quickly.
• Transparency — we tell customers and, where required, the Information Regulator when it matters.

We encrypt customer data both while it moves across networks and while it is stored on disk. The table below summarises how each layer is protected.

Our infrastructure is designed so that a problem in one area is contained rather than allowed to spread.

• Network segmentation — production, staging, and management networks are isolated, and databases sit in private networks with no direct public exposure.
• Firewalls & security groups — default-deny rules restrict traffic to only the ports and sources each service requires.
• DDoS protection — volumetric and protocol attacks are absorbed at the network edge before they reach origin systems.
• Hardened images — servers and containers are built from minimal, hardened base images with unnecessary services removed.
• Patch management — operating systems and platform components are patched on a regular cadence, with expedited patching for high-severity vulnerabilities.
• Infrastructure as code — infrastructure is defined in version-controlled code so changes are reviewed, repeatable, and auditable.

Access to systems that hold customer data is tightly controlled and continuously reviewed.

• Least privilege — access is granted per role and per system, and is limited to what each person or service genuinely needs.
• Multi-factor authentication (MFA) — required for staff access to administrative systems and production environments.
• Audit logging — administrative and privileged actions are logged to support investigation and accountability.
• Key & secret management — SSH keys, API credentials, and service secrets are issued, rotated, and revoked through central tooling rather than shared informally.
• Joiner/mover/leaver process — access is provisioned on a documented basis and promptly revoked when someone changes role or leaves.
• Periodic access reviews — privileged access is reviewed on a recurring basis to remove entitlements that are no longer needed.

Security is part of how we write and ship software, not a final gate before release.

Secure development lifecycle

• Code review — changes are peer-reviewed before they reach production.
• Dependency scanning — third-party libraries are automatically scanned for known vulnerabilities, and updates are prioritised by severity.
• Static analysis — automated checks run in our CI pipeline to catch common security defects early.
• Secrets management — credentials are kept out of source code and injected at runtime from a secrets manager; commits are scanned to prevent secrets from being committed.
• Separation of environments — development, staging, and production are separated, and production data is not used casually in lower environments.

We follow widely recognised guidance such as the OWASP Top 10 when designing and testing web-facing applications and APIs.

We run continuous monitoring across our platform so that we can detect and respond to problems quickly. Monitoring and security are also services we offer to customers.

• 24/7 monitoring — availability, performance, and security signals are monitored continuously with automated alerting.
• Centralised logging — logs from applications, infrastructure, and network layers are aggregated for detection and investigation.
• Defined incident response — we have documented procedures for triaging, containing, eradicating, and recovering from security incidents, followed by a post-incident review.
• Escalation — incidents are escalated to the appropriate on-call and management contacts based on severity.

We plan for failure so that customer data and services can be recovered.

• Regular backups — customer data, including managed PostgreSQL databases, is backed up on a regular schedule with encrypted storage.
• Restore testing — backups are periodically tested so that a restore works when it is actually needed.
• Redundancy & multi-region — critical services are designed with redundancy, and we make use of multiple regions and availability zones to reduce the impact of localised failures.
• Point-in-time recovery — supported for managed databases, subject to plan and configuration.

We set internal recovery time objectives (RTO) and recovery point objectives (RPO) for our services. We treat these as operational targets that we work to meet and improve, rather than contractual guarantees; specific commitments, where offered, are set out in the applicable service agreement or SLA.

We build our security programme around established frameworks so that our practices are structured, measurable, and comparable to industry norms.

• POPIA — as a South African provider, we operate in accordance with the Protection of Personal Information Act. See our Privacy Policy for details on how we process personal information.
• ISO/IEC 27001 — we align our information-security management practices with the ISO 27001 framework. Formal certification is a goal we are working towards; we do not currently claim an issued certificate.
• SOC 2 — we design our controls with the SOC 2 Trust Services Criteria (security, availability, and confidentiality) in mind as we mature our reporting.
• Vendor & sub-processor management — we assess the security posture of the providers and sub-processors we rely on.

We welcome reports from security researchers and the wider community. If you believe you have found a security vulnerability in any Digitel Africa product or system, please tell us so we can fix it.

What to include in your report

• A clear description of the vulnerability and the affected product, domain, or endpoint.
• Step-by-step instructions to reproduce the issue.
• A proof of concept (script, request, or screenshots) where possible.
• The potential impact as you understand it.
• Any relevant configuration, browser, or environment details.
• How you would like to be credited, if you would like acknowledgement.

Our response targets

We treat the timelines below as service targets. They may vary with complexity, but we aim to keep you informed throughout.

Scope

In scope are Digitel Africa's own products and services on the digitel.africa domain and its subdomains, including our email, DNS, hosting, cloud platform, managed database, domain, SSL, and VPN services. If you are unsure whether something is in scope, ask us before testing.

Out of scope

The following are generally not eligible and should not be reported unless you can demonstrate a concrete, exploitable security impact:

• Volumetric or protocol denial-of-service (DDoS) attacks, or any testing that degrades service for others.
• Social engineering, phishing, or physical attacks against our staff, users, or offices.
• Reports produced solely by automated scanners without a working proof of concept.
• Missing best-practice HTTP headers, cookie flags, or TLS configuration with no demonstrated impact.
• Self-XSS, or issues that require a fully compromised or rooted device to exploit.
• Missing rate limiting or lack of CAPTCHA without a demonstrated security impact.
• SPF, DKIM, or DMARC configuration weaknesses on domains not used for email, absent real-world impact.
• Vulnerabilities in third-party services or software we do not control (please report those to the relevant vendor).
• Outdated software versions without a demonstrated, exploitable vulnerability.
• Clickjacking on pages with no sensitive state-changing actions.

Please act in good faith: only test against your own accounts or data, do not access, modify, or delete other customers' data, do not run automated attacks that degrade our services, and give us a reasonable opportunity to remediate before any public disclosure. We ask that you keep the details of any vulnerability confidential until we confirm it has been resolved.

For anything relating to the security of our products, or to report a vulnerability, contact our security team.

Security team

[email protected] — vulnerability reports, security questions, and PGP key requests.

Entity

Digitel Africa Pty Ltd, registered in South Africa.

Privacy

For how we handle personal information under POPIA, see our Privacy Policy.

This Security Policy is version 1.2, effective 1 August 2026 and last updated 24 August 2026. We review and update it as our services and practices evolve.