xcrypt.co.za › Legal › Information Security Policy

Information Security Policy

Effective Date: June 2025  |  Last Reviewed: June 2025  |  Version: 1.2

This Information Security Policy ("Policy") describes the security principles, technical controls, organisational measures, and incident response procedures implemented by SkyL4rk (Pty) Ltd ("SkyL4rk") to protect the confidentiality, integrity, and availability of data processed across all platforms operated under the SkyL4rk umbrella, including xCrypt, Verilink, TermsCon, SkyVault, and SkyDome.

This Policy supports SkyL4rk's obligations under the Protection of Personal Information Act 4 of 2013 (POPIA), the General Data Protection Regulation (GDPR), and industry best practices for information security in SaaS and API-based platforms.

1. Purpose and Objectives

The objectives of this Policy are to:

2. Scope

This Policy applies to:

3. Information Classification

SkyL4rk classifies information into four tiers, each with corresponding handling requirements:

Classification Description Examples Handling Requirements
Restricted Highly sensitive. Unauthorised disclosure would cause serious harm. API keys, license key hashes, password hashes, biometric data, cryptographic secrets, payment data Encrypted at rest and in transit. Access limited to named individuals with documented business need. Never transmitted in plaintext. Never logged in full.
Confidential Sensitive business or personal data. Disclosure limited to authorised parties. Client personal information, Sub-Client records, billing details, internal audit logs, incident reports Encrypted in transit. Access controlled by RBAC. Not shared externally without DPA or NDA in place.
Internal Business information not intended for public disclosure but not inherently sensitive. Internal documentation, system architecture diagrams, deployment scripts, support ticket histories Access limited to SkyL4rk personnel. Not published publicly.
Public Information approved for public release. Legal documents, pricing pages, API documentation, marketing materials No special handling required beyond standard publication review.

4. Access Control

4.1 Principle of Least Privilege

Access to systems, databases, and data is granted on the basis of least privilege — personnel receive only the access necessary to perform their specific role. Access rights are reviewed when roles change and revoked immediately upon termination of employment or contract.

4.2 Role-Based Access Control (RBAC)

SkyL4rk implements RBAC across all platforms. Platform roles include administrator, developer, support, and read-only tiers, each with defined access scopes. Merchant-facing roles (admin, user, dev) are similarly scoped and enforced at the application layer.

4.3 Authentication Requirements

4.4 Geo-Fenced Administrative Access

Administrative access to production databases and server infrastructure is restricted by IP allowlist and geographic controls. Access from outside approved network ranges requires additional verification. This control is enforced at the infrastructure level, independent of application-layer authentication.

4.5 Third-Party Access

Third-party contractors or service providers are granted time-limited, scoped access only. All third-party access is logged and reviewed. Sub-processors are required to implement equivalent access controls under their data processing agreements with SkyL4rk.

5. Encryption

5.1 Data in Transit

All data transmitted between clients and SkyL4rk services — including API calls, dashboard sessions, and webhook deliveries — is encrypted using TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled across all endpoints. HTTP requests are redirected to HTTPS. Certificate validity is monitored with automated alerts for expiry.

5.2 Data at Rest

Sensitive data fields in the database, including credential-related fields and personal information, are encrypted at rest using AES-256. Full-disk or volume-level encryption is applied at the infrastructure layer for all persistent storage. Backup archives are encrypted prior to storage using AES-256.

5.3 Key Management

Cryptographic keys used for data encryption are stored separately from the data they protect, using environment-level secrets management. Keys are rotated periodically and immediately upon suspected compromise. Retired keys are securely destroyed.

5.4 Credential Handling

API keys issued to clients are generated using a cryptographically secure random number generator. License keys are generated using a hashing algorithm that prevents reconstruction from partial data. Neither credential type is stored in reversible form after issuance.

6. Network and Infrastructure Security

6.1 Cloud Infrastructure

SkyL4rk's production infrastructure is hosted on Google Cloud Platform (GCP), leveraging GCP's built-in security controls including network segmentation, DDoS mitigation, and physical security at data centre level. SkyL4rk's use of GCP is governed by Google's data processing terms and security commitments.

6.2 Network Segmentation

Production, staging, and development environments are segregated at the network level. Production databases are not directly accessible from the public internet — all database access is routed through application-layer controls with authenticated connections only.

6.3 Firewall and Perimeter Controls

Network firewall rules are configured to allow only necessary inbound and outbound traffic. All administrative ports (SSH, database ports) are blocked from public access and accessible only via allowlisted IP ranges or VPN. Firewall rules are reviewed quarterly.

6.4 DDoS and Rate Limiting

SkyL4rk implements API rate limiting at the application layer to prevent abuse and mitigate denial-of-service conditions. Rate limits are enforced per API key and per IP address. Excessive request volumes trigger automatic throttling with appropriate HTTP response codes.

6.5 Vulnerability Management

SkyL4rk maintains a process for identifying, assessing, and remediating security vulnerabilities in its systems:

7. Application Security

7.1 Secure Development Practices

Security is considered throughout the software development lifecycle. Key practices include:

7.2 API Security

The xCrypt API implements the following security controls:

7.3 Secrets Management

Application secrets, database credentials, and environment-specific configuration values are stored in environment variables and secrets management tooling — never hardcoded in source code or committed to version control repositories.

8. Data Backup and Recovery

8.1 Backup Schedule

Database backups are performed daily. Backups are encrypted using AES-256 before storage and are retained on a rolling 30-day basis. Backups are stored in a geographically separate location from live infrastructure.

8.2 Backup Integrity

Backup integrity is verified periodically through test restores. Any failure in the backup process triggers an automated alert for immediate investigation.

8.3 Recovery Objectives

SkyL4rk targets the following recovery objectives for data loss scenarios:

9. Physical Security

SkyL4rk's platforms are hosted in cloud infrastructure where physical security of data centres is managed by Google Cloud Platform under their own industry-certified security programme (ISO 27001, SOC 2 Type II). SkyL4rk's own physical premises (administrative offices) are secured with standard physical access controls. No production data is stored on physical media at administrative premises under normal operating conditions.

10. Personnel Security

10.1 Onboarding

All personnel with access to production systems or personal data are required to:

10.2 Access Provisioning and Revocation

Access to production systems is provisioned following the principle of least privilege. When a person's role changes or their engagement with SkyL4rk ends, all access credentials are revoked within 24 hours of notification. Shared credentials are not used — each individual has uniquely attributed access.

10.3 Security Awareness

Personnel are made aware of common security threats including phishing, social engineering, and credential mishandling. Security reminders are issued periodically and following any relevant security incident.

11. Incident Response

11.1 Incident Classification

Severity Definition Examples Initial Response Target
Critical Confirmed breach of personal data or system compromise with active impact Unauthorised database access, API key mass exposure, ransomware Immediate — within 1 hour of detection
High Suspected breach or significant vulnerability with potential for data exposure Suspicious authentication patterns, unpatched critical CVE, credential stuffing attack Within 4 hours of detection
Medium Security anomaly or policy violation without confirmed data exposure Failed brute force attempts, misconfigured access control, suspicious API usage patterns Within 24 hours of detection
Low Non-urgent security observations or improvement opportunities Expiring certificates, outdated library version, policy non-compliance Within 5 business days

11.2 Response Process

  1. Detection: Incident identified via automated monitoring, personnel report, or third-party notification
  2. Containment: Immediate steps taken to limit the scope and impact — isolating affected systems, revoking compromised credentials, blocking malicious traffic
  3. Investigation: Root cause analysis performed to determine the extent, origin, and impact of the incident
  4. Notification: Affected clients notified within 72 hours of a confirmed personal data breach, in accordance with POPIA and GDPR obligations. The Information Regulator is notified as required.
  5. Remediation: Affected systems patched, credentials rotated, access controls reviewed, and any exploited vulnerability addressed
  6. Post-Incident Review: A written post-incident report is completed within 5 business days of resolution, documenting root cause, impact, actions taken, and preventative measures

11.3 Incident Register

All security incidents are recorded in an internal incident register regardless of severity or whether notification to external parties is required. The register includes date of detection, nature of incident, systems affected, data categories involved, actions taken, and resolution date. The register is reviewed by the Information Officer quarterly.

11.4 Reporting a Security Concern

Merchants, researchers, or members of the public who identify a potential security vulnerability or incident affecting SkyL4rk platforms are encouraged to report it responsibly:

12. Third-Party and Sub-Processor Security

SkyL4rk evaluates the security posture of all third-party service providers and sub-processors before engagement. Requirements include:

Current approved sub-processors and their security certifications are listed in the Data Processing Agreement Schedule 2.

13. Compliance and Review

This Policy is reviewed at minimum annually, and following any significant security incident, material change to SkyL4rk's infrastructure, or relevant changes to applicable legislation. The Information Officer is responsible for maintaining this Policy and ensuring controls described herein are implemented and effective.

SkyL4rk aligns its security practices with the following frameworks and standards:

14. Contact