Security Measures Schedule

1. Scope and assurance boundary

This schedule describes the security control objectives Bibeno must meet for the production service and forms part of the Data Processing Agreement. It covers Bibeno-managed application, Backoffice, POS integration, support, database, object-storage, billing-integration, email, monitoring, backup, and administrative boundaries.

2. Governance and risk management

• Assign accountable owners for security, privacy, incidents, providers, access, backups, change, vulnerability remediation, retention, and business continuity.
• Identify reasonably foreseeable internal and external risks to confidentiality, integrity, availability, authenticity, accountability, and tenant isolation.
• Record treatment, residual risk, approval, due date, evidence, exception expiry, and review cadence for material risks.
• Review safeguards after material product, provider, territory, threat, legal, or architecture changes and after a security incident or failed control test.
• Maintain policies, training, tests, runbooks, supplier records, and immutable operational evidence proportionate to risk.

3. Identity, authentication, and access

• Use individually attributable accounts, purpose-scoped permissions, least privilege, separation of duties, and branch and tenant boundaries.
• Protect owner, administrator, Support, production, provider, and other privileged access with strong authentication and multi-factor controls appropriate to risk.
• Use purpose-scoped, expiring invitation, recovery, approval, session, device, API, and offline credentials rather than shared permanent secrets.
• Issue merchant-website API credentials with only the catalogue, configuration, or order scopes required; bind them to the correct tenant and store; compare stored hashes safely; and support expiry and revocation.
• Rate-limit and monitor authentication, recovery, pairing, approval, and sensitive mutation routes; invalidate sessions and credentials after relevant security events.
• Review privileged, dormant, former-personnel, device, integration, and service-account access regularly and revoke it promptly when no longer required.

4. Tenant, branch, and record isolation

Authorisation is enforced on the server and in persistence queries rather than relying on hidden client controls. Tenant ownership, active branch, record relationship, capability, and action-specific permission are checked at each material boundary.

• Prevent horizontal and vertical access across tenants, branches, employees, devices, support cases, exports, objects, and financial records.
• Bind mutation and replay evidence to the correct user, tenant, branch, device, request, transaction, and legal-feature state.
• Use restrictive relationships and validated ownership transitions for sensitive and append-only evidence.
• Test representative cross-tenant, cross-branch, role-escalation, direct-object, and stale-session scenarios.

5. Devices, offline operation, and local data

• Pair and approve devices through authenticated, expiring, revocable workflows and expose only the minimum configuration and legal-feature snapshot required.
• Sign or otherwise authenticate supported offline authority and mutation records, prevent replay, preserve stable idempotency, and re-evaluate current server gates during sync.
• Limit locally cached credentials and information, protect device storage and logs, and provide secure revocation, recovery, replacement, and decommissioning procedures.
• Reconcile offline sales, payments, cash, inventory, gift-card, loyalty, workforce, and day-end effects and place uncertain outcomes into review rather than silently duplicating or discarding them.
• Require the customer to secure physical devices, operating-system access, networks, printers, terminals, exports, and recovery material.

6. Encryption, secrets, and data movement

• Protect supported network traffic with current transport security and prevent insecure downgrade at production boundaries.
• Use managed encryption or equivalent storage protection appropriate to the database, object, backup, device, secret, and export risk.
• Keep credentials, signing material, provider keys, tokens, and recovery secrets out of source code, tickets, chat, analytics, client bundles, and ordinary logs.
• Encrypt supported merchant payment-provider secrets before database storage, expose only public keys to the storefront, verify webhook signatures with the merchant's configured secret, and rotate or revoke credentials after suspected compromise.
• Use a hosted or provider-controlled payment page for card entry. Bibeno does not intentionally collect or store full card numbers or CVV values in the Digital Ordering Suite.
• Separate production from development and test credentials and data; use synthetic or appropriately de-identified data where production information is unnecessary.
• Control export and download links, expiry, authorisation, object names, recipient, audit trail, and deletion; do not create public access by default.

7. Secure development and change management

• Review security and privacy impact during design for authentication, permissions, payments, exports, marketing, workforce, devices, offline operation, retention, and new provider use.
• Use peer review, automated validation, controlled dependencies, schema and migration review, secret scanning, and environment-specific deployment controls proportionate to change risk.
• Test authentication, authorisation, tenant isolation, input validation, injection resistance, unsafe file handling, replay, idempotency, transaction integrity, error disclosure, and fail-closed legal gates.
• Require traceable release and deployment identifiers, change approval, rollback or remediation readiness, and post-deployment checks for material changes.
• Do not publish a legal, security, provider, tax, or compliance claim solely because a development test passes.

8. Vulnerability and dependency management

Bibeno inventories supported application and infrastructure components, monitors credible vulnerability and dependency information, triages findings by exploitability and impact, assigns remediation owners and deadlines, tests fixes, and records accepted residual risk and exception expiry.

Independent testing or review is performed at a cadence and scope justified by risk and after material architectural change. Customer-facing assurance states the actual scope and date and does not imply that an assessment covers untested providers, devices, customer networks, or future releases.

9. Logging, monitoring, and evidence

• Log security-relevant authentication, authorisation, recovery, device, support, export, provider, billing, privacy, incident, legal-acceptance, retention, and high-risk mutation events at an appropriate level.
• Bind online quotes, orders, acceptance state, payments, refunds, customer cancellations, provider webhooks, and notifications to stable tenant, branch, publication, policy, order, and idempotency identifiers.
• Minimise personal information and exclude passwords, full payment-card data, CVV values, private keys, provider secrets, and unnecessary request bodies from logs.
• Protect material evidence from ordinary alteration or deletion through append-only records, hashes, restrictive permissions, durable provider references, or equivalent controls.
• Monitor actionable failure, denial, anomaly, dead-letter, outbox, malware-scan, export, access, and readiness signals and route them to accountable responders.
• Synchronise time sufficiently for incident and transaction reconstruction and record release, deployment, actor, tenant, branch, device, and correlation identifiers where relevant.

10. Files, uploads, and malware controls

• Validate supported file type, size, structure, naming, ownership, destination, and business purpose at the server boundary.
• Quarantine or reject unsafe and unsupported content and use the approved malware-scanning boundary where required.
• Prevent executable interpretation, path traversal, public object exposure, formula injection, unsafe archive expansion, and cross-tenant object access.
• Restrict access to support attachments, imports, exports, receipts, evidence, and identity-related documents and preserve custody and deletion evidence appropriate to risk.

11. Availability, backup, and recovery

Bibeno uses resilience, health, graceful-shutdown, backup, restore, queue, retry, reconciliation, and recovery controls proportionate to the production architecture. The Support Policy or signed service level schedule states any customer-facing availability or recovery commitment; this security schedule does not invent one.

• Back up approved systems and data at a frequency based on business and legal requirements.
• Restrict and monitor backup access and protect backups from ordinary production-account compromise where practicable.
• Test restoration and verify application, relationship, transaction, and evidence integrity rather than assuming file recovery is sufficient.
• Document dependencies, degraded operation, offline boundaries, recovery priorities, communication, and reconciliation.
• Apply valid deletion and legal-hold instructions to restored data before returning it to ordinary processing.

12. Security incident and compromise response

Bibeno maintains a tested workflow for detection, triage, containment, evidence preservation, assessment, recovery, regulator and customer coordination, data-subject notification, remediation, and lessons learned. The workflow distinguishes an operational security event from a POPIA security compromise without using a risk threshold to avoid a notification that section 22 requires.

A relevant operator compromise is reported immediately to the responsible customer. A compromise affecting information for which Bibeno is the responsible party is notified to the Information Regulator and identifiable affected data subjects as soon as reasonably possible, subject only to a lawful delay.

13. Personnel and physical security

• Screen personnel lawfully and proportionately for the role and bind them to confidentiality, acceptable-use, access, incident-reporting, and return-of-property duties.
• Train personnel on phishing, credentials, personal information, payment data, exports, support access, secure development, incidents, and customer confidentiality.
• Use managed, patched, access-controlled work devices and appropriate workspace, screen, media, disposal, and visitor safeguards.
• Revoke logical and physical access, recover assets, rotate exposed secrets, preserve required evidence, and confirm continuing confidentiality when a role ends.

14. Providers and supply chain

Before enabling a provider, Bibeno verifies the legal entity, service, role, data and data subjects, processing and support regions, onward providers, transfer safeguard, security evidence, retention, incident duty, contract or DPA, business continuity, and exit plan. The controlled vendor register prevents an enabled provider category from being omitted.

Bibeno reviews providers and evidence on change and at the approved cadence, restricts access to the required purpose, monitors material service and security events, and disables or replaces a provider that cannot meet the approved boundary. Customer-selected providers require a separate customer responsibility and integration boundary.

15. Retention, deletion, and legal holds

Retention and deletion are controlled by record class, purpose, trigger, period, legal basis, hold rule, backup treatment, action, and accountable owner. Destructive operations support review or dry-run, authorisation, item-level outcomes, failure handling, and immutable completion evidence.

Legal holds are scoped, authorised, recorded, reviewed, and released. Deletion removes ordinary access first where appropriate, then propagates through live records, objects, derived records, queues, and backups according to the approved schedule without destroying evidence required to prove the deletion.

16. Customer security responsibilities

• Assign suitable administrators, use strong authentication, review roles and branches, and remove former personnel and lost devices promptly.
• Secure customer networks, endpoints, browsers, email, payment terminals, printers, exported files, backups, and customer-selected integrations.
• Provide accurate configuration and lawful instructions, use supported software and hardware, reconnect and reconcile offline devices, and investigate warnings.
• Do not share credentials, upload prohibited high-risk information, bypass legal or safety gates, or expose exports through personal or public channels.
• Notify Bibeno promptly of suspected compromise, unauthorised access, incorrect permission, lost device, or material data-integrity issue.

17. Evidence, changes, and contact

Bibeno provides proportionate current assurance evidence under the Data Processing Agreement. Evidence may be redacted to protect other customers, security, provider confidentiality, privilege, and secrets, but a redaction may not be used to conceal a material deficiency.

A material reduction in the security baseline, provider assurance, processing location, or incident duty follows the legal change process and requires notice, risk acceptance, and any customer re-acceptance or termination right required by contract or law.

Security questions and reports may be sent to the verified security or support contact. Urgent compromise reports should identify the affected account, time, system or device, observed behaviour, and safe callback details without including passwords, private keys, full card data, or unnecessary personal information.