Responsible information handling, verified for each implementation.

1. Scope and security commitments

This page applies to the public MUFK Integrated website and provides a general overview relevant to configured MUFK Integrated solutions. It is not a substitute for a solution-specific security schedule, data-processing agreement, architecture document or client policy.

Mupo Projex (Pty) Ltd, registration number 2019/545521/07, trading as MUFK Integrated, takes a risk-based approach to information handling. We aim to apply appropriate, reasonable technical and organisational measures having regard to the information, processing purpose, operational context, available controls and applicable legal and contractual requirements.

Exact controls can differ between the public website, demonstration environment, test environment and a client’s approved production implementation.

2. Roles and accountability

The responsible party determines why and how personal information is processed. An operator processes personal information for a responsible party under a contract or mandate without coming under the responsible party’s direct authority.

For our own website enquiries, business administration and employment activities, MUFK Integrated may act as the responsible party. For records processed in a client workspace, the client may be the responsible party and MUFK Integrated may act as an operator. The applicable agreement must confirm the roles, instructions and responsibilities for the specific processing.

When acting as an operator, we process personal information with the responsible party’s knowledge or authorisation and subject to the agreed confidentiality and security requirements. The responsible party retains its statutory responsibilities under POPIA.

3. Information that may be handled

Depending on the implemented modules and approved workflows, information may include:

• client, customer, policyholder, claimant and authorised-user information;
• claim, policy, incident, assessment, service and asset records;
• supplier, contractor and service-provider information;
• photographs, quotations, invoices, reports and supporting documents;
• workflow assignments, decisions, approvals, notes and communications;
• support requests and authorised attachments; and
• account, access, diagnostic, audit and security-event records where configured.

Clients should avoid configuring or collecting special personal information, children’s information, credentials or unnecessary identifiers unless the processing is authorised, necessary and supported by appropriate controls and legal grounds.

4. Data lifecycle and minimisation

Information handling should be considered across collection, validation, use, storage, sharing, support, retention and deletion. Forms, fields, permissions and integrations should be limited to what is reasonably necessary for the approved purpose.

During implementation, the parties should identify the record owner, permitted users, intended purpose, source, recipients, retention rule, required audit events and disposal method for relevant information categories.

5. Identity, authentication and authorised access

Access to a configured workspace is intended for approved users according to assigned roles and operational responsibilities. User approval, authentication methods, role design, privileged access, access reviews, account suspension and removal are confirmed for the implementation.

The public marketing website does not process client passwords. Where configured, the client-login page redirects authorised users to the approved authentication service.

Each user should have an individual account where supported, protect authentication factors, avoid credential sharing and use only the access necessary for authorised work.

6. Infrastructure and environment separation

Hosting model, infrastructure ownership, region, network controls, environment separation, administrative access and physical-security inheritance depend on the approved solution and providers. These details are confirmed during architecture and security review.

Production information should not be copied into development, demonstration or test environments unless the transfer is authorised, necessary and protected by controls appropriate to the information involved. Masked, synthetic or minimised data should be preferred where practical.

7. Data transmission and encryption

Approved methods should be used when personal, confidential or operational information is transmitted between users, systems, providers and integrations. The implemented transport protection, encryption at rest, key management and secure file-transfer configuration are confirmed for the relevant environment.

Users should not send passwords, one-time codes, private keys or unnecessary sensitive information through ordinary email, general enquiry forms or unapproved messaging channels.

8. Logging, audit records and monitoring

Operational, access, workflow and security events may be recorded where configured to support accountability, investigation, support, reporting and compliance. The events captured, log access, monitoring, alerting, retention and client visibility are defined for the approved implementation.

Logs may themselves contain personal or confidential information and should be protected, limited to authorised purposes and retained only as long as necessary.

9. Backups, recovery and continuity

Backup scope, frequency, storage, protection, restoration testing, retention, recovery time objectives, recovery point objectives and continuity arrangements depend on the contracted service and infrastructure. They must be confirmed in the relevant technical documentation or agreement.

No public statement on this page should be interpreted as a guaranteed backup frequency, recovery time, data-loss threshold or service level.

10. Change, vulnerability and security testing

Development, configuration and infrastructure changes should be assessed, approved, tested and released in a manner proportionate to their risk. Relevant dependencies and reported vulnerabilities should be evaluated and addressed according to the affected environment, exposure and operational impact.

Security testing, scanning, penetration testing, independent assurance, remediation targets and evidence-sharing arrangements are confirmed during due diligence and contracting. This page does not claim a certification or testing cadence unless expressly documented for the relevant service.

11. Service providers, operators and integrations

Approved hosting, communications, support, storage, authentication or integration providers may process or transmit information where required for the service. Their role, location, access, data categories and safeguards are assessed according to the implementation and applicable agreement.

Where an operator processes personal information for MUFK Integrated, we require written arrangements addressing authorisation, confidentiality and security safeguards. Where MUFK Integrated acts as an operator for a client, provider or subprocessor use is addressed according to the client agreement.

Integration credentials and service accounts should be limited, protected, rotated or revoked according to the approved design and provider capabilities.

12. Retention, deletion and return

Personal and operational information should be retained only for as long as required by an approved purpose, client instruction, contract, legal obligation, dispute, audit or security need. Retention rules may differ across website forms, support records, platform records, logs, files and backups.

At the appropriate time, information should be securely deleted, destroyed, returned or de-identified, subject to lawful holds, technical limitations and backup-expiry cycles. Client exit, export, return and deletion requirements should be agreed before service termination.

13. Security incidents and personal-information compromises

Suspected incidents should be reported promptly so that they can be assessed, contained, investigated, documented and remediated. The applicable response plan, escalation contacts, evidence preservation, client coordination and communication responsibilities are confirmed for the relevant service.

Where MUFK Integrated acts as an operator and has reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person, it must notify the responsible party immediately in accordance with POPIA and the applicable agreement.

Where MUFK Integrated is the responsible party, it will assess and make notifications to the Information Regulator and affected data subjects as required by section 22 of POPIA. Notification is made as soon as reasonably possible after discovery, subject to any lawful delay.

Do not disclose vulnerability details publicly. Do not post suspected vulnerabilities, exploit code, credentials or affected records on social media or in a public form. Use the contact process in section 16 and wait for a secure exchange method where sensitive detail is required.

14. Client, administrator and user responsibilities

Security is shared across MUFK Integrated, approved providers, client administrators and authorised users. Clients and users should:

• approve appropriate users and assign least-necessary roles;
• review access and remove or suspend it when responsibilities change;
• protect devices, networks, credentials and authentication factors;
• configure workflows, retention and integrations according to approved requirements;
• avoid unnecessary collection or disclosure of sensitive information;
• upload only records they are authorised to share;
• maintain accurate security and incident contacts; and
• report suspected unauthorised access, misuse or loss promptly.

15. Technical due diligence and assurance

Before relying on a control, clients should confirm the current evidence and contract relevant to their implementation.

Evidence may be subject to confidentiality, security and need-to-know restrictions. Detailed material can be shared through an approved due-diligence process where appropriate.

16. Report a security or data-handling concern

Use the following contact for an initial report. Include your name, organisation, affected service or URL, date and time observed, and a concise description. Do not include credentials, exploit code or unnecessary personal information in the initial message.

Existing clients should also follow the escalation and incident-reporting route in their approved service agreement.