PAIA & POPIA Compliance Manual

1. Purpose, scope and status

This manual records how [LEGAL ENTITY NAME] ("SMJobs", "we") complies with the Protection of Personal Information Act 4 of 2013 ("POPIA") and the Promotion of Access to Information Act 2 of 2000 ("PAIA"). It is the operating document behind the Privacy Notice, the Cookie Policy and the Terms & Conditions.

It covers the SMJobs platform at smjobs.co.za — the job board, the seeker and employer accounts, the application process, the talent directory, the administrative back office, the newsletter and the cookies the site sets. It does not cover recruitment agencies or employers who use the platform as a candidate source under their own lawful basis, or third-party sites we link to.

It is a controlled document. The Information Officer owns it, reviews it at least annually, and records every change in the change log at Annexure C. Where this manual and the published notices disagree, the published notices are the public commitment and this manual must be corrected; where this manual and the code disagree, the code must be corrected, because the code is what actually happens to a data subject's information.

2. Roles and accountability

POPIA places the duty on the responsible party. We are the responsible party for the personal information described in the processing register.

• Responsible party / Operator — [LEGAL ENTITY NAME], registration number [CIPC REGISTRATION NUMBER], of [REGISTERED STREET ADDRESS] (VAT number [VAT NUMBER]). The operator decides what is processed and why, and is accountable for this manual.
• Information Officer — [INFORMATION OFFICER NAME AND ROLE]. Responsible for the public-facing notices, the processing register, this manual, the handling of data subject requests, and the liaison with the Information Regulator. Reachable at info@smjobs.co.za or on +27 788 770 744.
• Service providers and operators — the web host, the email delivery provider and the analytics provider (if one is engaged). They process on our instructions under a written operator agreement, are bound to our security requirements, and are not permitted to use the information for their own purposes.
• Internal users — administrative staff with access to the back office. Their access is limited to what their role requires, is individually attributable, and is logged.

A single breach of this manual by a staff member is a disciplinary matter. Any suspected breach of personal information is also a security compromise under section 22 and must be reported to the Information Officer immediately, whatever else it turns out to be.

3. Legal framework

This manual is written against, and should be read with:

• POPIA — the Protection of Personal Information Act 4 of 2013. Section 9 requires personal information to be processed lawfully and in a reasonable manner that does not infringe the data subject's privacy, and section 11 sets out the grounds on which it may be processed, together with consent, withdrawal of consent and objection. Section 13 requires collection for a specific, explicitly defined and lawful purpose; section 14 limits retention; section 17 requires processing to be documented; section 18 requires the data subject to be notified when information is collected. Section 19 sets the security safeguards and section 22 requires the Regulator and the data subject to be notified of a security compromise. Section 5 lists the data subject rights, and sections 23, 24 and 25 give the detail on access, on correction, destruction and deletion, and on the manner of access. Section 26 prohibits processing special personal information, and section 34 governs the personal information of children. Section 69 deals with direct marketing by unsolicited electronic communications, section 71 with automated decision-making, and section 72 with transfers of personal information outside the Republic.
• PAIA — the Promotion of Access to Information Act 2 of 2000. It applies to records held by public bodies. SMJobs is a private entity, so PAIA access requests are not a general entitlement against us; where a request is made we route it to the Information Officer, who responds in writing and explains the position, including the sections of PAIA that protect third-party privacy and the commercial information exemptions. Where a request concerns the personal information of the requester, POPIA rights apply instead and are dealt with under section 6.
• Consumer Protection Act 68 of 2008 — for the quality, accuracy and fairness of the marketing we send and the terms on which we contract.
• Electronic Communications and Transactions Act 25 of 2002 — for the validity of electronic consents and records, and for the unsubscribe requirement in direct marketing.
• Protection of Personal Information Act regulations and directives issued by the Information Regulator from time to time.

4. The processing register

POPIA section 17 requires a responsible party to document all processing operations under its responsibility, and section 18 requires the data subject to be told, when information is collected, what it is collected for. This register is the operational form of that documentation. It is maintained by the Information Officer. Each row is a processing activity, not a table, because the lawful basis and the retention period attach to the purpose, not to the column.

5. Consent management

Where we rely on consent, it must be freely given, specific, informed and unambiguous, and it must be a positive act (POPIA section 11). The platform implements this as follows.

5.1 The consent ledger

Every consent decision is written to the consents table at the moment it is made, with the visitor id, the account id where the person is signed in, the email address where one was given, the consent type, the categories, the policy version that was on display, the source, the IP address, the user agent, and the timestamp. A withdrawal is recorded as a new row with granted = 0 and a withdrawn_at timestamp, so the history is never rewritten — we can always show what was agreed to and when, which is what POPIA and the Regulator expect to be able to see. The responsible party bears the burden of proof of consent, so this ledger is how we discharge it.

5.2 The consent categories

• essential — required for the site to work. The session cookie, the consent cookie itself, the visitor id, and the saved-jobs cookie. No consent is required for these because the site cannot operate without them, and POPIA permits processing that is necessary for the transfer or service to be delivered.
• functional — remembers job-search filters so a returning visitor does not have to set them again. Optional, and off until accepted.
• analytics — reserved for a measurement tool. No analytics or tracking code is currently running on the platform, and the banner says so rather than implying that a consent is doing something it is not.

5.3 How consent is obtained

• Cookies — the banner offers "Accept all", "Essential only" and "Cookie settings". Choosing "Essential only" is recorded as a refusal of the optional categories. A visitor who has not chosen either way is treated as essential-only, and optional cookies are not set.
• Talent directory — a switch in the account area, off by default. Switching it on records a consent; switching it off withdraws it and hides the profile at once.
• Job applications — a tick box next to the "Apply" button, unticked by default, stating that the CV and covering letter will be processed for that application. The application is refused server-side if the box is not ticked; the browser check is a convenience, not the control.
• Registration — a tick box for the Terms and the Privacy Notice. A registration without it is refused.
• Google sign-in — no separate tick box. The button is accompanied by the notice "By continuing with Google you agree to our Terms of Service and Privacy Policy", and continuing is the positive act. The consent is recorded when the account is created.
• Newsletter — a tick box on the subscribe form. A subscription without it is refused, and the refusal is recorded.

5.4 Withdrawing consent

Withdrawal is as easy as giving it. The "Cookie settings" link in the footer of every page reopens the preference panel, and the talent directory switch is in the account area. A request to withdraw by email is actioned by the Information Officer within the ordinary rights timescale, and the withdrawal is recorded in the ledger.

6. Data subject rights

POPIA section 5 lists the rights a data subject has: to be notified that information is being collected or has been accessed by an unauthorised person; to establish whether we hold their information and to get access to it; to have it corrected, destroyed or deleted; to object to processing on reasonable grounds, and to object to direct marketing at any time; to withdraw consent; not to be subject to a decision based solely on automated processing; to complain to the Regulator; and to institute civil proceedings. Requests are free. We do not charge for a request, and we do not ask for identity documents beyond what is needed to confirm that the requester is who they say they are.

6.1 How a request is handled, step by step

1. The request is logged on receipt, with the date, the channel, and the identity of the person who received it.
2. Identity is confirmed. For a signed-in account the session is the confirmation. For an email request we confirm the address the request came from, or ask for one non-sensitive detail already on the account, such as the company name or the headline. We never ask for a password, an ID number or a CV as proof of identity.
3. If the request is on behalf of someone else — for example a guardian, or a person acting under a power of attorney — the authority to act must be established before we disclose anything.
4. The request is assessed against the register, to identify every row that holds the requester's information and every recipient it has already been sent to.
5. The Information Officer decides whether any of the processing must stop immediately pending the outcome, which is the normal treatment of an objection under s.11(3).
6. The response is prepared, signed off by the Information Officer, and sent within the timeframe above. Where a request is refused, the refusal is in writing and states the reason.
7. The outcome is recorded in the rights request log, and the log is reviewed at each compliance review.

7. Special personal information

POPIA section 26 prohibits processing special personal information — health, biometric, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic information, and the personal information of children — unless an exception in s.27(1) applies.

SMJobs does not ask for special personal information, and the platform has no field for it. We do not ask for it on registration, on the profile, on the application form or on the job posting form.

We recognise that a CV or a covering letter may contain special personal information that the data subject chose to include, and that a job seeker may mention a disability, a pregnancy, a religious observance, or a union membership in the course of explaining why they are a good fit. That is the data subject's own free expression, provided to the employer, and we neither profile on it nor treat it as a reason to refuse a listing. We do not read applications to infer special personal information, and we do not ask employers to send it to us through the platform.

If a data subject asks us to stop processing special personal information that they have included in a CV or covering letter, we treat that as an objection and a correction under sections 11(3) and 24, and we remove it from the stored file where we are able to.

We do not knowingly allow the Platform to be used to recruit on the basis of race, colour, religion, gender, sexual orientation, pregnancy or HIV status. Section 9 of the Terms makes that a breach of the contract, and the moderation queue exists partly to catch it.

8. Security safeguards

POPIA section 19 requires safeguards appropriate to the sensitivity of the data and the risk of harm, and section 19(2) requires the measures in Schedule 2 to be adhered to. These are the measures in place, and what each one is for.

9. Security compromise and breach management

POPIA section 22 requires a responsible party to notify the Information Regulator — and, subject to the one exception in section 22(3), the affected data subjects — where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by any unauthorised person. The test is a reasonable belief that unauthorised access or acquisition has happened, not a finding that serious harm is likely: if the threshold in section 22 is met, we notify.

Section 22(2) requires the notification to be made as soon as reasonably possible after the discovery of the compromise, taking into account the legitimate needs of law enforcement and any measures reasonably necessary to determine the scope of the compromise and to restore the integrity of our information systems. Section 22(4) requires the notification to a data subject to be in writing, delivered by one of the listed routes — mail to the last known physical or postal address, email to the last known email address, a prominent notice on our website, publication in the news media, or as the Regulator directs. Section 22(5) requires the notification to contain enough information for the data subject to take protective measures: the possible consequences, the measures we have taken or intend to take, a recommendation on what the data subject should do, and the identity of the unauthorised person if we know it. The Regulator may also direct us to publicise a compromise (section 22(6)).

9.1 What counts as a security compromise

Not only a hacker. A security compromise includes, for us:

• unauthorised access to the database, a backup, or a credential;
• a CV or a set of CVs accessed by someone who should not have had them — for example a URL guess that returns a file it should not;
• an account takeover, including one achieved through a reset token that was intercepted or reused;
• loss or theft of a device that was not encrypted;
• an email sent to the wrong recipient that contained personal information;
• an administrative action that exposed data it should not have — for example a moderation view returning more than it should;
• an error in a deletion routine that left personal information behind;
• the loss or compromise of a credential held by a service provider, which is a compromise for us too.

9.2 The procedure

1. Detect and report — as soon as anyone suspects a compromise, they report it to the Information Officer, immediately and directly. They do not investigate it alone, and they do not wait to be sure.
2. Contain — the Information Officer decides how to stop it: revoke the session or the credential, remove the access path, disable the endpoint, or take the service down while the fix is applied. Containment comes before understanding.
3. Preserve evidence — logs, the affected records, the time it happened, the systems involved. Do not wipe, reformat or clean up before the evidence is captured.
4. Assess — determine what information was involved, how many data subjects are affected, what the information is, whether the data was encrypted, and whether it has been published. This assessment is what decides whether the section 22 threshold is met, and it also tells us who to notify and what to tell them.
5. Notify the Regulator — where there are reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person, notify the Information Regulator as soon as reasonably possible after discovery, in the form the Regulator prescribes and with the information section 22 requires.
6. Notify the data subjects — notify the affected persons in writing, unless their identity cannot be established or a criminal investigation is impeded. The notice must say what the possible consequences are, what we have done about it, what the data subject should do to protect themselves, and the identity of the unauthorised person if we know it.
7. Remediate — fix the cause, not just the symptom. Re-issue credentials, close the access path, and add a control that stops the same thing happening again.
8. Learn — write it up in the breach register at Annexure B, and bring the lesson into the next compliance review.

10. Direct marketing

POPIA section 11(3)(b) gives a data subject the right to object, at any time, to the processing of their personal information for direct marketing, and section 69 governs direct marketing by means of unsolicited electronic communications — the communications that count as "unsolicited" are listed in section 69(1) and the corresponding right to object is in section 69(3)(c). The ECTA requires an unsubscribe mechanism that is simple, immediate and effective.

• Every marketing email carries a working unsubscribe link, and unsubscribing takes effect without requiring a reason, a phone call or a login.
• Unsubscribe removes the address from the newsletter list and records the withdrawal in the consent ledger. It is not a soft opt-out and it does not require the person to re-confirm.
• Job alerts and application notifications are service messages about a transaction the person asked for, and are not marketing. The distinction is recorded in the register at R-09.
• We do not buy, rent or trade mailing lists, and we do not accept third-party data about job seekers from anyone. The Terms prohibit it, and the moderation queue exists to catch it.
• Every piece of direct marketing identifies us, gives a postal address, and gives a way to reach the Information Officer.

11. Cross-border processing

The Platform is hosted with a service provider outside South Africa, and the email delivery provider processes messages outside South Africa. The regulatory consequence is that information is processed outside the Republic, and POPIA section 72 governs transfers of personal information outside the Republic: a transfer may only take place if the conditions in section 72 are met, which in turn require the level of protection to be no less than the level of protection in South Africa.

What we do about it:

• service providers are bound by operator agreements that carry our security requirements across the border;
• the transfer is limited to what the service requires — a hosting provider receives the data in the application, and an email provider receives the address and the message body and nothing else;
• the risk is recorded in the register at R-01, R-04 and R-09, and is reconsidered if a new provider is engaged;
• if a transfer to a country without an adequate level of protection became necessary, we would put in place a binding undertaking from the recipient, or seek the Regulator's authorisation, before it happens.

12. Retention and disposal schedule

POPIA section 14 requires a responsible party to keep personal information only for as long as it is needed for the purpose for which it was collected, and section 24(1)(b) gives a data subject the right to have a record destroyed or deleted where the responsible party is no longer authorised to retain it. The schedule below is the one the platform enforces automatically where it can, so that retention does not depend on anybody remembering.

12.1 What "delete my account" removes

The account-deletion routine runs in a single transaction and removes, in one pass:

• the account row itself;
• the seeker or employer profile row;
• every application the person submitted, by account id and by email address, including applications they submitted as a guest;
• every application made to a vacancy the person posted as an employer, together with the applicant's CV files attached to them;
• the CV file on the profile, and any other CV file the person uploaded;
• the saved-jobs rows, by account id and by vacancy id;
• the consent records tied to the person, by account id and by email address;
• the password reset rows;
• any vacancies the employer posted, and the submissions attached to them;
• the name and email address in the audit log, replaced with "[redacted]", so the log keeps its evidential value without keeping the personal information;
• the session and the session cookie.

What is deliberately kept: a single audit entry recording that the account was deleted, the account id, and the date. It holds no name, no email address and no content. The consent records are deleted along with everything else, because a data subject's request to have their information deleted under section 24(1)(b) overrides the five-year evidential retention described at R-07; what we keep in its place is the redacted audit entry, which is enough to show that a deletion was requested and carried out, and by whom.

13. Compliance calendar

The Information Officer keeps this schedule. Each item is a task, an owner and a date, and the review is evidenced by a signed entry in the register kept for that purpose.

14. Annexures

Annexure A — Open items

These are the outstanding actions. Each must be closed before the first compliance review.

Annexure B — Breach register template

One row per incident, whether or not it turned out to be reportable. The fact that an entry exists is not an admission of breach; the fact that an entry is missing where one was needed is a problem.

Annexure C — Change log

Every change to this manual, to the three public notices, to the processing register, or to a technical control in section 8 is recorded here before it takes effect.

Annexure D — Related documents

• Privacy Notice — what we tell the public, in plain language.
• Cookie Policy — the cookies and local storage we use, and how to change your mind.
• Terms & Conditions — the contract between you and SMJobs, including the employer obligations and the enforcement process.
• Processing register — maintained by the Information Officer, held with this manual in the compliance file.
• Rights request log — maintained by the Information Officer.
• Breach register — maintained by the Information Officer, using the template in Annexure B.
• Operator agreements with the hosting and email service providers — held with this manual in the compliance file.