Operator Policy

Last updated 21 September 2026

When a client sends data to Xinnace Reports — by uploading it, by posting it from their own system, by letting us collect it from a folder of theirs, or by emailing it — that data often contains personal information — most commonly the names and performance figures of the client’s own staff. For that information, under South Africa’s Protection of Personal Information Act (POPIA), the client is the responsible party and Xinnace (Pty) Ltd is an operator: we process it on the client’s behalf and on the client’s instructions, and this policy records how.

It is also the agreement itself. Section 21 of POPIA requires a written contract between a responsible party and its operator, and this is that contract: it takes effect when the client’s administrator accepts it, and what each of us undertakes is set out below and summarised in section 11. It supplements the Terms of Service and the Privacy Policy.

1. What we process, and why

The personal information involved is whatever the client’s files contain — typically employee names or identifiers together with operational measures such as handle times, satisfaction scores, or survey responses. It is the same information however the file reaches us, and it goes through the same checks. We process it to do exactly four things:

• read a file — in our template, or in the client’s own export layout where we have set one up with them — and validate it against the columns its report type declares
• import it into that client’s own database
• build and version the client’s reports from it
• back it up

A report imports only the columns it uses. Anything else in a file — a comment, a customer’s details, a column the report never reads — is not imported, but it stays in the stored file for as long as that file is kept. So we ask clients to leave out of their uploads what their reports do not need, and in particular information about their own customers. Where a file is emailed to us, we keep the attachment and a record of the message — who sent it, its subject and what we did with it — but not the body of the message.

We do not use a client’s data for any purpose of our own — not for analytics across clients, not for training anything, not for marketing.

2. Only on instruction

Processing happens only as the service requires or as the client instructs — uploading a file, publishing a report, granting access, closing the account are the instructions. We do not process a client’s personal information otherwise, unless a law requires it, in which case we tell the client unless that law forbids it.

3. Separation

Each client’s data lives in its own database and its own storage area. Separation is enforced by the database engine, not by an application filter. No client can reach another’s data, and reports have no public URLs — they are served only through an authenticated page, to people the client has named.

4. Confidentiality and staff access

• Xinnace staff access a client’s data only to operate and support the service.
• When staff work inside a client’s account to assist, every action is recorded in the audit trail against the staff member who took it — not against the client’s user.
• Platform administrator accounts cannot be impersonated at all.

5. Security safeguards

As required by section 19 of POPIA, we maintain safeguards including:

• encryption of all traffic in transit
• one database per client, with report files held outside the web root
• hashed credentials, invitation-only accounts, and client-configurable IP restrictions
• an audit trail of sign-ins, failed attempts, permission changes, uploads and report views
• nightly backups, each kept for 14 days and copied to object storage in South Africa on separate infrastructure from the server, and a version history of the figures from every upload, from which any earlier version of a report can be rebuilt or exported
• each automatic connection reaches one report and nothing else, so a compromised system of the client’s cannot reach the rest of their data

Credentials of the client’s own systems

Where a client asks us to collect files from a server of theirs, we hold what is needed to sign in to it. That is a real trust and we treat it as one:

• we generate the key ourselves and give the client only the half that admits us, so the half that signs in has never been anywhere else — a client may supply their own key or a password instead, and we recommend against it
• credentials are encrypted at rest and are never displayed again once saved, to anyone, including us
• we record the server’s own fingerprint on the first connection and refuse any server afterwards that does not present it, so a changed DNS record cannot redirect us
• we connect only to the address we have checked, and never to an address on a private network
• when a connection is stopped, the credential is destroyed immediately — and we tell the client which line to remove from their server, because we cannot remove it ourselves
• we only ever read, and move a file within the client’s own folder where they have asked us to. We never delete anything on a client’s server, and there is no setting that would let us

A client should give us an account restricted to the folder the exports are in, rather than a general one. We say so in the guidance we give them.

A note on sending data by email

Where a client chooses to email their data, it travels as email does: over the public internet, through their mail provider and ours, encrypted between hops where both ends support it and not guaranteed to be. That is less protected than uploading it or having us collect it, and it is the client’s decision to make. We say so here rather than leave it to be assumed, and we recommend one of the other routes for anything sensitive.

We reduce what we can: each address is unguessable and reaches one report; a client may restrict which senders it accepts; and where they do, we verify that a message really came from the domain it claims before accepting it.

6. Sub-operators

We use three, and no others:

• Hosting — a dedicated server in South Africa, on which the platform and the databases reside.
• Amazon Web Services — object storage in their Cape Town region, holding the off-site copy of the nightly backups. The data does not leave South Africa.
• Google Workspace — for sending email notifications, which may involve processing outside South Africa under Google’s safeguards. Report data itself is not sent by email; notifications link to the platform.

If we engage a new sub-operator that would touch client data, we tell clients before it happens.

7. If there is a breach

If we have reasonable grounds to believe a client’s personal information has been accessed or acquired by an unauthorised person, we notify that client without undue delay, with what we know: what happened, what data was involved, and what we are doing. As the responsible party, the client decides on notification of data subjects; we assist, and we meet our own POPIA obligations to the Information Regulator.

8. Data subject requests

If someone whose information appears in a client’s data contacts us directly — to access, correct or delete it — we refer the request to the client and assist the client in answering it. The audit trail and view log exist partly for this: a client can always establish who saw a report containing someone’s information, and when.

9. Return and destruction

• While the account is open, the client’s administrator can, through the platform and at any time, open every report and any earlier version of it, export the figures of any version, and download the uploaded files still kept — the ten most recent for each report.
• On closure, everything is retained for 90 days, during which the client may request an export of every version of its data, the uploaded files still kept and its current reports, or reverse the closure.
• After 90 days the client’s database is permanently deleted and stored files are removed; copies in the nightly backups age out within 14 days after that, and the off-site copies they leave behind are permanently destroyed within a further 60 days. The destruction itself is recorded.

10. Demonstrating all this

The measures above are how the platform is built, not aspirations. On reasonable notice, we will answer a client’s written questions about our processing and provide the records that support them — audit entries, view logs, and the destruction record after a purge.

11. The agreement

Everything above is what we undertake to do and not do. This section says who has agreed it, from when, and for how long.

• The parties are the client organisation whose administrator accepted this policy, as the responsible party, and Xinnace (Pty) Ltd, registration 2025/316516/07, as the operator. The client is identified in the acceptance record described below; this page is published, so it names no single client.
• It is accepted in the welcome pack, shown to a client’s administrator when they sign in: each document is listed with the version being accepted, and the administrator ticks and submits. We record which documents were accepted, in which version, by whom, when and from what address, and will give the client a copy of that record on request.
• It takes effect on that acceptance, and covers all personal information we process for the client — including anything uploaded before it.
• It lasts as long as we hold that information. Sections 7, 9 and 10 — breach notification, return and destruction, and answering for what we did — continue to apply after the account is closed, until the destruction in section 9 is complete.
• If it changes, the date at the top of this page changes with it, clients are told of material changes before they take effect, and the client’s administrator is asked to accept the new version before using the platform again.
• If a separately negotiated agreement is signed between the client and Xinnace and differs from this policy, that agreement prevails.
• It is governed by the law of the Republic of South Africa.

Our information officer is Poobalan Soobramoney, Chief Executive Officer. A client may raise anything under this agreement with them.

Questions: accounts@xinnace.co.za.