PCI DSS & ISO Compliance Information

1. Purpose of This Page

This page explains Bwiser’s security and compliance posture in clear operational language. It is intended to help Drivers, Merchants/Stations, partners, and stakeholders understand how we protect data and what to expect from our security controls. It does not replace formal contractual security terms, an audit report, or a third-party certification.

2. PCI DSS Scope and Card Data Approach

Where card payments are used (for example, repayments or card authorisations for Autopay), Bwiser aims to minimise exposure to cardholder data by using integrated payment gateways and tokenised payment workflows. As a principle:

• We do not intentionally store full primary account numbers (PAN), CVV/CVC codes, or magnetic stripe data in application databases.
• We rely on payment processors to capture and store sensitive payment details, returning tokenised references and transaction outcomes.
• We store operational metadata needed for reconciliation and audit (for example, payment reference, status, timestamps), and tokenised payment identifiers where applicable.

PCI DSS scope depends on how payments are implemented and how users interact with the payment gateway. We continuously aim to reduce scope by keeping sensitive entry points within approved payment components and by limiting what our systems store and process.

PCI DSS is a broad standard covering network security, secure configuration, access control, monitoring, and regular testing. While the exact set of PCI DSS controls applicable to Bwiser depends on system design and the payment gateway integration, our design approach is to keep cardholder data out of our systems wherever possible and to focus on strong security controls around the application and infrastructure that support payment initiation and reconciliation.

Examples of PCI-aligned control areas we focus on include:

• Secure transmission: enforcing HTTPS/TLS for production web traffic.
• Least privilege: limiting who can access repayment and settlement tooling.
• Logging: recording payment initiation and outcome events for audit and reconciliation.
• Secure defaults: restricting administrative endpoints and hardening server configuration.
• Vendor due diligence: selecting payment providers that can support tokenisation and have appropriate security controls.

3. Security Governance (ISO-Aligned)

Bwiser’s security program is designed to align with information security management principles commonly associated with ISO/IEC 27001. This means we aim to apply a structured approach to identifying security risks, applying controls, and reviewing effectiveness. Key governance concepts include:

• Policies that define acceptable use, access control, data handling, and incident response.
• Risk assessment to identify threats to confidentiality, integrity, and availability.
• Control implementation across people, processes, and technology.
• Monitoring and continuous improvement as systems, threats, and legal requirements evolve.

4. Access Control and Authentication

Access controls are designed around least privilege. Users only receive the permissions required to perform their role. Typical controls include:

• Role-based access control (RBAC) separating Driver, Station/Merchant, and Admin permissions.
• Server-side session management and CSRF protection for web actions.
• Secure password storage using one-way hashing.
• Optional “Remember me” session behaviour using secure cookies for persistent login.
• Administrative actions protected by authentication and permission checks, with audit trails where applicable.

5. Data Protection and Encryption

Bwiser applies layered controls to protect data:

• Encryption in transit: web traffic is protected using TLS for production environments.
• Encryption and secure handling: sensitive fields may be encrypted at rest or stored as tokenised references depending on the nature of the data (for example, payment tokens).
• Key management: encryption keys and credentials should be stored in environment variables or secure secret stores, and rotated when necessary.
• Segregation: production secrets should not be committed to version control and should be restricted to authorised operators.

6. Application Security and Secure Development

We apply secure development practices to reduce vulnerabilities. Common measures include:

• Input validation and server-side enforcement of authorisation for sensitive actions.
• Framework-level protections against common web risks (for example, CSRF protections for forms).
• Security headers and cookie hardening to reduce exposure to browser-based attacks.
• Dependency management and patching of known vulnerabilities where practicable.
• Logging for security-relevant events and administrative actions.

While no software can be guaranteed to be free of vulnerabilities, the goal is to reduce risk and respond quickly when issues are identified.

7. Logging, Monitoring, and Audit Trails

The Platform maintains audit trails for key operational events to support accountability, dispute resolution, fraud investigations, and compliance readiness. Examples include:

• Voucher application, approval/decline, issuance, and redemption events.
• Repayment initiation, outcome, and failure events.
• Administrative changes affecting limits, station configurations, or user status.
• Security events such as login failures or unusual activity flags.

Monitoring may include automated alerts for unusual patterns (velocity, repeated failures, anomalous locations) and may be used to trigger manual review.

8. Infrastructure and Network Security

Security controls depend on the hosting environment and may include:

• Firewall rules allowing only necessary inbound traffic (for example, HTTPS and SSH for administration).
• Regular operating system and package updates where feasible.
• Separation of environments (development vs production) and access restrictions.
• Backups and disaster recovery practices appropriate to the risk and data sensitivity.

9. Vendor and Third-Party Risk Management

Bwiser may rely on third parties for hosting, payment processing, messaging, mapping, and analytics. We aim to manage third party risk by:

• Performing onboarding due diligence (security posture, availability history, and compliance claims).
• Using contractual controls, including confidentiality, security obligations, and breach notification expectations.
• Limiting data sharing to what is necessary for the service.
• Reviewing vendors periodically based on risk and performance.

10. Incident Response and Breach Notification

Bwiser maintains an incident response approach designed to detect, contain, investigate, and recover from security incidents. If a security compromise involves personal information, we aim to comply with applicable POPIA notification obligations and to communicate with affected parties where required.

Incident response generally includes triage, containment actions, forensic review where appropriate, corrective actions, and post-incident improvements.

11. Business Continuity and Availability (ISO 22301 Principles)

Operational continuity is important for real-time workflows (voucher issuance and redemption). Bwiser aims to apply continuity practices aligned with principles commonly associated with ISO 22301, including:

• Backups and restore testing appropriate to environment and risk.
• Monitoring for service health and alerting for critical failures.
• Change management to reduce deployment risk.
• Documented recovery steps for critical services.

12. What We Ask of Users

Security is shared. We ask users to:

• Use strong, unique passwords and keep credentials confidential.
• Sign out of shared devices and avoid using public computers for sensitive actions.
• Keep devices updated and protected with a passcode or biometric lock.
• Report suspicious activity promptly.

13. Compliance Statements and Limitations

References to PCI DSS and ISO standards on this page describe the security controls we aim to align with and the way we manage scope. They do not necessarily mean that Bwiser is currently certified under a specific standard, unless expressly stated in a signed document. Where formal compliance evidence is required (for example, an Attestation of Compliance from a payment processor), it should be requested through commercial and compliance channels.

14. Vulnerability Management

Bwiser aims to identify and address vulnerabilities across applications, dependencies, and infrastructure. Vulnerability management practices may include:

• Keeping critical dependencies up to date where practicable.
• Reviewing security advisories relevant to core frameworks and libraries.
• Applying patches for high-severity issues on a prioritised basis.
• Reviewing logs and alerts for indicators of compromise or unusual behaviour.

Remediation timelines depend on severity and exploitability. High-risk issues affecting authentication, payments, or voucher redemption are prioritised. Where a temporary mitigation is available (for example, disabling a feature, adding a server-side validation rule, or tightening permissions), we may apply mitigations immediately while a permanent fix is developed and tested. We also aim to avoid introducing new security risk while fixing issues, which can require staged releases.

If you believe you have discovered a security vulnerability, please report it responsibly to our support contact. Do not attempt to exploit vulnerabilities on production systems.

15. Data Minimisation and Classification

We aim to minimise the amount of sensitive data processed and stored. Where personal information is required, we classify data by sensitivity and apply safeguards appropriate to that classification. Examples include:

• Public: content intended for public viewing (policy pages and general product information).
• Internal: operational information used by staff and authorised station users.
• Confidential: personal information, KYC documents, repayment metadata, and security logs with restricted access.
• Highly sensitive: tokens, secrets, and security-critical configuration, handled through protected secret management practices.

16. Change Management and Release Safety

Because the Platform supports financial and operational workflows, changes are managed to reduce the risk of regressions and outages. Practices may include:

• Access-controlled deployments and separation of duties where feasible.
• Configuration management through environment variables and secure secret handling.
• Rollback and recovery procedures for critical services.
• Post-deployment validation and monitoring to catch errors early.

In addition to operational release controls, application-level secure coding practices are important. We aim to reduce common risks aligned with widely recognised threat categories (such as the OWASP Top 10), including injection risks, broken access control, insecure configuration, and sensitive data exposure. This is supported through framework protections, code review, and targeted testing for high-risk endpoints.

Backups and recovery are part of release safety: a deployment should not compromise the ability to restore service. Where possible, we test restoration procedures and ensure that backup retention is configured to balance operational needs with privacy principles and retention requirements.

17. Physical and Operational Security

Physical security controls depend on the hosting model used (cloud, data centre, or managed services). We aim to use hosting providers that implement appropriate physical security controls and access restrictions. Operational security also includes controlling access to administrative systems, keeping audit trails, and limiting administrative activities to authorised personnel.

18. Contact

For security enquiries, suspected vulnerabilities, or incident reporting, contact [email protected].

When reporting an issue, include as much detail as possible (page/feature, timestamps, screenshots where safe, and any reference IDs). Please do not send sensitive secrets or full payment card information. We will acknowledge reports and may request further information to validate and remediate.

If the issue relates to a suspected account compromise, we may recommend immediate password changes and may temporarily restrict account actions while we investigate.

We aim to prioritise reports that affect payments, voucher redemption, authentication, and personal information.

For general product support requests (not security issues), please use normal support channels so that security reports can be triaged quickly. If you are unsure whether something is a security issue, include that uncertainty in the report and we will route it appropriately.

We appreciate responsible disclosure.

Note: This page is provided for transparency and operational readiness and does not constitute legal advice or a formal certification statement.