Operator Addendum

1. What this addendum is, and how it applies

This Operator Addendum forms part of the Terms of Service for the digital business cards service. Where anything in those Terms conflicts with this addendum on the processing of personal information, this addendum applies.

It applies from the moment your company accepts its Order Form, which is what opens the account, and needs no separate signature. The Terms are accepted by accepting an Order Form or a quote, activating a card or paying an invoice, and this addendum is accepted with them. We do not ask you to click through it separately, and we do not record a separate acceptance for it — saying so is more honest than implying a signature ceremony that does not happen.

If your own procurement process requires a countersigned agreement, write to legal@xinnace.co.za and we will sign this document as it stands.

2. Definitions

POPIA — the Protection of Personal Information Act 4 of 2013, and any regulation made under it.

Client Data — personal information you or your people submit to the service, or that the service generates about them, in the course of issuing and running cards.

Data subject — the person the information is about: normally one of your employees.

Responsible party and operator — as defined in POPIA. The responsible party decides why and how information is processed; the operator processes it for them, on their instruction.

Security compromise — the unauthorised destruction, loss, alteration, access to or acquisition of Client Data.

Sub-operator — a third party we engage that processes Client Data in order to provide part of the service.

3. Roles of the parties

You are the responsible party for Client Data. Xinnace (Pty) Ltd, registration number 2025/316516/07, of 22 Umhlanga Boulevard, Umhlanga, KwaZulu-Natal, 4321, South Africa ("XINNACE", "we"), is your operator.

The distinction decides who answers for what, so it is worth being plain about it. Your employees' names, job titles, photographs and telephone numbers are yours. You decided to put them on a card, you decide what each card says, and if an employee objects to being on one, that is a conversation with you and not with us. We hold that information and run the software that shows it, on your instruction, and for no purpose of our own.

You remain responsible for having a lawful basis, for meeting the conditions for lawful processing, for issuing the notice section 18 requires to the people on the cards, and for the accuracy of the instructions you give us.

Two things sit outside this addendum because we are the responsible party for them rather than your operator: the account and billing records of the people who administer your account, and the anonymous engagement counts described in clause 4. Both are covered by our privacy notice.

4. Subject matter of the processing

Purpose. Hosting and operating a digital business card for each person you issue one to: publishing the card at its own web address, building the contact file a visitor saves to their phone, letting the person sign in and edit the parts of their card you allow them to edit, letting them add their card to their own phone's home screen as My Card — which keeps a copy of their card on that phone so it opens without signal — asking them whether their card may be listed in the directory when you request a listing, and billing you for the cards that are active.

Duration. While the account is active, plus the deletion period in clause 12.

Data subjects. Your employees, former employees whose details are still within the retention window you set, and anybody else you issue a card to.

Categories. Name; job title; department; work telephone and mobile numbers; work email address; a photograph if one is uploaded; a short biography if one is written; the card's web address; social and website links you choose to publish; and the email address and password hash of the account each person signs in with.

Special personal information. None is asked for, and the service has no field for any of it. A photograph of a person's face is not special personal information under POPIA, but it is personal information that most people recognise on sight, which is why the person on the card can decline to be listed in the directory even where you have agreed to it.

Children's information. The service is not designed for it and has no purpose that would need it. Do not issue a card to a child.

What is deliberately not processed. We do not record the IP address of anybody who opens one of your cards, and we do not set a cookie on them. The engagement figures on your analytics screen are counts against a daily rotating hash: honest for a day and deliberately not comparable across days, because a figure that can follow one person from Monday to Tuesday is a figure that identifies them. Those counts are anonymous, are ours rather than yours, and are the reason for the exclusion in clause 3.

A card is a public page. That is the product, and it is the one thing about this processing that has no equivalent in an HR system. Anybody with the address can open a card and read what is on it. Deciding what goes on a card is therefore a publication decision, and it is yours.

5. Our obligations as operator

• We process Client Data only on your documented instructions. Your instructions are the actions you take on the platform — what a card says, which fields an employee may change, who is added, who is removed, how long removed people are kept, and whether a card is listed anywhere — together with support requests you send us.
• We treat Client Data as confidential. We do not sell it, do not use it to advertise to anybody, and do not use it to train anything.
• We maintain the security safeguards in clause 6, as section 19 requires.
• We notify you of a security compromise as clause 8 and section 21(3) require.
• We process Client Data as the law requires where it does, and will tell you when we are compelled to unless we are prohibited from telling you.
• We limit access to the people who need it to run the service and support you, and everyone with access is under a written duty of confidentiality that survives their employment.
• If we believe an instruction would put us in breach of POPIA, we will say so before carrying it out rather than afterwards.
• We do not add, remove or edit an employee's card on your behalf except at your request.

One of our administrators can sign in as your administrator in order to see what you are seeing, which is the only way to answer some support questions honestly. When it happens, the session is marked as impersonation throughout, every action taken in it is recorded against the real person and not against yours, and it cannot be used to change a password or take over an account.

6. Security safeguards

Section 21(1)(b) requires that this contract oblige us to establish and maintain the security measures in section 19. It does, and the measures are these. They are stated specifically rather than as "appropriate technical and organisational measures", because that phrase tells your compliance officer nothing they can check.

• Tenant separation. One database, with every query scoped to the company it belongs to and the scope applied at the point of the query rather than filtered afterwards. This is a weaker separation than a database per customer, which is what the HRMS platform uses, and it is named here as what it is rather than described in a way that would flatter it.
• Encryption in transit. HTTPS with TLS throughout, with HTTP Strict Transport Security set for a year, so a browser that has been here once will not try plain HTTP again.
• Credential protection. Passwords are stored as bcrypt hashes and cannot be read back — not by us either. A forgotten password is replaced, never recovered. Changing a password ends every other session for that account immediately.
• Access control. Every route carries the role it requires, checked on the server on every request. An employee may edit only the fields you have allowed, and a hand-crafted request naming a locked field is ignored rather than obeyed.
• Brute-force and session protection. Sign-in is rate limited per address and per account. Session cookies are HTTP-only, Secure and SameSite, and the session identifier is regenerated on sign-in.
• Injection defence. Every database statement is parameterised, with prepared statements not emulated, so a value somebody typed cannot become part of a query. The content security policy on the application and on your cards allows scripts only from this origin and permits no inline script at all. The one exception is a hand-built Custom Card page, which holds no Client Data and runs under a separate, stricter policy: its own inline script, and no request to any other origin. Both are enforced by tests that read every file on every build rather than by convention.
• Uploads. Images are decoded and re-encoded before being stored, so the bytes we serve are the ones our software wrote. Only JPEG, PNG and WebP are accepted.
• Audit logging. Every change made by a person is recorded with the action, who did it, which company it was done to, and when — including changes made by us while supporting you, which are recorded as ours and not as yours.
• Backups. Server-level backups by Afrihost.

Not yet implemented. Naming these is more useful to your compliance officer than a page that avoids the question, and each is a thing we would have to build rather than a thing we have decided against: multi-factor authentication; independent penetration testing; scheduled vulnerability scanning; a published patch cadence; tested restore times; and any certification, including ISO 27001. The security page is the authoritative current description and is updated as these change.

We review these measures as the service changes, and we will not weaken them during the life of this addendum without telling you.

7. Sub-operators

You authorise us to engage sub-operators, bound by obligations no less protective than those in this addendum. We remain responsible to you for what a sub-operator does with Client Data as though we had done it ourselves.

Current sub-operators:

• Afrihost — hosts the application, the database and uploaded images on a South African server, and holds the backups.
• Google (email delivery) — transmits the email the platform sends: invitations, password links, order forms and their confirmations, plan-change notices, invoices, reminders and directory listing requests. The content of those messages and the recipients' addresses are processed outside South Africa.

We will give you reasonable notice before adding or replacing a sub-operator. You may object on data protection grounds, and we will look for an alternative. If there is none, you may end the affected service without penalty and clause 12 applies.

8. Security compromises

As section 21(3) requires, we will notify you immediately on having reasonable grounds to believe that Client Data has been accessed or acquired by an unauthorised person. Immediately means when we believe it, not when we have finished investigating — the later moment is not the one at which you can still make your own decisions.

The notification goes to your account administrator and tells you what happened, when, which categories of information are affected, an estimate of how many records, what we have done about it and what we suggest you do. We keep telling you as the investigation changes the answer.

Section 22 puts the duty to notify the Information Regulator and the affected people on the responsible party, which is you. We will not notify your employees ourselves unless you ask us to in writing or the law requires it of us, and we will give you what you need in order to do it.

To report a compromise to us, or anything that looks like one, write to security@xinnace.co.za with Security in the subject line. We aim to acknowledge within one business day.

9. Data subject requests

A request from one of your people to see, correct, object to or delete their information is directed to you, because you are the responsible party and the record is yours. If one comes to us directly we will not answer it substantively; we will refer them to you and tell you they made contact.

Most of these you can answer without us. Everything held about a person is on their own screen and they can export it themselves; you can correct any of it from the employees screen; and Erase now deletes it immediately rather than at the end of the retention window. Where you need something we hold and you cannot reach, ask and we will help.

One limit is worth stating in advance. A card that has been public has been public, and neither of us can retrieve a contact file somebody already saved to their own phone. Deleting a card stops it resolving, stops its QR codes working and removes the record; it does not reach into anybody's address book.

10. Your obligations

• Give lawful instructions, and process Client Data through the service only where POPIA permits you to.
• Issue the section 18 notice to the people whose cards you create, and obtain any consent your own circumstances require. Publishing somebody's photograph and telephone number on a page anybody can open is a decision they are entitled to hear about from you first.
• Manage your users: give each person the least access they need, remove people promptly when they leave, and keep the administrator's contact details current — that address is where a compromise notification would go.
• Do not send Client Data to us through insecure channels, and keep personal information out of support and security reports. A company slug and a card address identify what you are asking about without sending us anything.
• Tell us if your own account is compromised — a stolen administrator password is our problem as much as yours.

11. Cross-border transfers

Client Data is hosted in South Africa and is not transferred out of it for storage.

Two things cross the border in the ordinary course and are named here because section 72 asks for honesty about them rather than silence. Email delivery, described in clause 7, is processed outside the Republic. And a card is a public web page: when somebody outside the country opens one, what is on that card is sent to them, because that is what the card is for.

Further detail on request to security@xinnace.co.za.

12. Retention, return and deletion

Client Data is retained while your account is active. A person you remove is erased automatically after the retention window you set — up to 90 days, which is also the default, and as little as 7 — and Erase now does it immediately.

When the account ends you may elect return or deletion. You do not have to ask us for the return: Download a copy on your welcome pack produces everything held about your company and its people as a file you keep, at any time while the account is live, and each person can separately export everything held about them from their own screen. Take it before you close the account — afterwards there is a window and then there is not.

Deletion timeline. Within 90 days of termination or expiry, unless you ask for it sooner or we agree a longer period in writing, we delete your cards, your designs and your people's records, including uploaded images. Routine backup copies are overwritten in the ordinary cycle. A Custom Card filed under your account is not part of this: it was sold to its holder under clause 5 of the Terms, is not processed on your instruction, and ends with its own term rather than with your account.

An account cancelled from its Billing screen closes at the end of the calendar month in which it was cancelled, as clause 16 of the Terms sets out. Closing the account is what starts that clock, and it is recorded with the date so the ninety days are counted from something rather than remembered. When the deletion runs, that is recorded too — a promise to delete within ninety days is one somebody may ask us to evidence, and the evidence is a timestamp.

What is kept afterwards, and this is stated in detail rather than as "the minimum the law requires", because one part of it is more than a customer would assume from that phrase.

Invoices and their line items are kept for seven years, as the Tax Administration Act requires, and each line keeps the name and email address of the person it billed for, along with their card address, the days it was active and the rate. That is personal information and it outlives the deletion above. It has to: an invoice that cannot show what was charged and for whom is not a tax record, and an audit — ours or yours — has to be able to follow a line back to the thing it was for. The same exception is stated in our privacy notice, which is where the people on the cards are told about it.

Also kept, and for the same seven years: the billing record an invoice can be checked against — the rate that applied and the dates it applied between, and the days each card was actually active. An invoice whose arithmetic cannot be re-derived is one you would have to take on trust, which is not what a tax record is for, and it is the first thing an audit asks to see.

And your company's billing identity — its name, registered and VAT numbers, billing address and billing email — because a historical invoice is rendered from it and would otherwise become a document with no customer on it. Plus the audit trail of what was done to the account, for 3 years, which records that actions happened rather than what they contained.

Nothing kept afterwards holds a photograph, a biography, a telephone number or a password.

13. Audit and information

On reasonable written notice, and no more than once a year unless there has been a compromise or the Information Regulator requires it, we will provide information reasonably necessary to demonstrate compliance with this addendum and answer a reasonable security questionnaire.

We do not permit on-site inspection of the hosting environment or testing against the live platform. Where a question can be answered by showing you the system we would rather do that than write a document about it, and we will arrange a demonstration of any control that matters to you.

Technical and vendor-assessment questions go to security@xinnace.co.za.

14. Liability

The limitations and exclusions in the Terms of Service apply to this addendum, and liability under it counts towards the aggregate cap in those Terms rather than sitting on top of it.

Nothing here limits liability that cannot be limited in law, including liability for wilful misconduct and liability under POPIA to a data subject or to the Information Regulator.

15. Duration and changes

This addendum takes effect when your company accepts its Order Form, or on first use of the service after the effective date above, and continues for as long as we process Client Data. Clauses 8, 12 and 14 survive it.

We will notify your account administrator by email before a change takes effect. Where a change materially reduces the protection given to Client Data, you may end the affected service without penalty within 30 days of that notice.

16. Contact

Data protection and the Information Officer: privacy@xinnace.co.za.
Security reports and vendor assessments: security@xinnace.co.za.
Legal and contractual: legal@xinnace.co.za.
Invoices and everything else: support@xinnace.co.za.

They are separate addresses on purpose. A privacy request must not sit in a billing queue, and a compromise report must not wait behind a question about an invoice.

You and your people also have the right to complain to the Information Regulator; the privacy notice gives its details.