POPIA Compliance: What It Requires and How Motadata Supports It

If your organization handles the personal information of people in South Africa, POPIA compliance is not optional.

The Protection of Personal Information Act has been fully enforceable since 1 July 2021, and the Information Regulator now backs it with administrative fines of up to ZAR 10 million.

The requirement your IT and security teams own most directly is security safeguards under Section 19, and it is the first place a regulator looks after a breach.

This guide explains what POPIA compliance requires, how your duties as a responsible party differ from an operator's, and how Motadata supports the technical and reporting side as an operator that follows POPIA.

By the end, you will know what POPIA requires, how it splits duties between you and your vendors, what the 2025 amendments changed, and how to turn your existing monitoring and service management into evidence you can show the Regulator.

What is POPIA?

POPIA is South Africa's data protection law, the Protection of Personal Information Act 4 of 2013.

It governs how organizations collect, store, and process the personal information of people in South Africa, and it sets out the rights those individuals hold over their own data.

The Act became fully enforceable on 1 July 2021 and is administered by the Information Regulator, which also enforces the Promotion of Access to Information Act.

POPIA sits close to the European GDPR, so teams that have already done GDPR work will recognize most of the principles. The difference is in the detail, and the detail is where compliance is won or lost.

What Counts as Personal Information Under POPIA?

Personal information under POPIA is any detail that relates to an identifiable, living person, and in some cases to an existing organization. That covers far more than a name and an ID number. It includes:

• Contact details such as email addresses, phone numbers, and physical addresses.

• Financial records, medical history, and employment information.

• Online identifiers such as IP addresses and cookies.

• Biometric data, from fingerprints to facial scans.

• A person's opinions, preferences, and confidential correspondence.

For an IT team, the practical point is uncomfortable. Personal information is not locked in one database. It is scattered across your ticketing system, asset records, log files, and email, which means your compliance scope is wider than most people assume when they start mapping it.

Who Needs to Comply with POPIA?

POPIA applies to any organization that processes personal information in South Africa. That includes local businesses, government bodies, and non-profits, and it reaches companies based outside the country when they process the data of people inside it.

The Act also has a wider scope than some of its peers, because it covers the personal information of juristic persons, meaning other companies, not only individuals.

If you hold customer, employee, or supplier data tied to South Africa, you are in scope. Size and sector do not exempt you.

What are the Eight Conditions for Lawful Processing?

POPIA sets out eight conditions in Chapter 3, sections 8 to 25, that every responsible party has to meet when processing personal information.

Section 8 makes you answerable for all of them, from the moment you decide why and how you will process data and for as long as the processing continues. They work as a system, not a checklist, so a gap in one condition usually shows up as a failure in another.

1. Accountability (Section 8)

Accountability is the first condition, and the other seven hang from it. You have to ensure every condition, and the measures that give effect to them, are met when you set the purpose and means of processing and throughout the processing itself.

In practice that means appointing and registering an Information Officer with the Information Regulator, documenting your governance, and staying answerable even when you pass data to an operator.

2. Processing Limitation (Sections 9 to 12)

Personal information has to be processed lawfully and in a way that does not infringe on the data subject's privacy. You collect only what is adequate, relevant, and not excessive for the purpose, which rules out gathering data you do not need.

POPIA sets a general duty to obtain consent, alongside defined justifications where consent is not required, and it expects you to collect directly from the data subject in most cases.

A data subject can object to certain processing on reasonable grounds, and once they do, you have to stop.

3. Purpose Specification (Sections 13 and 14)

You collect personal information for a specific, explicitly defined, and lawful purpose, and you make the data subject aware of that purpose.

This condition also governs retention. You do not keep records longer than the purpose needs, unless the law requires it or the data subject consents, after which the information should be deleted or de-identified.

4. Further Processing Limitation (Section 15)

Any use of the data beyond the original purpose has to be compatible with why you collected it in the first place.

Where it is not compatible, you need consent or another lawful basis, such as information already in a public record. You cannot quietly turn data a person gave you for one reason into something they never agreed to.

5. Information Quality (Section 16)

You take reasonably practicable steps to keep the personal information you hold complete, accurate, not misleading, and up to date, weighed against the purpose you collected it for.

Acting on stale or wrong data is both a compliance failure and an operational one, because every decision made from it carries the error forward.

6. Openness (Sections 17 and 18)

Openness has two parts. You document your processing operations, and when you collect personal information you tell the data subject who is collecting it and why.

That notification also covers whether supplying the data is voluntary or mandatory and the consequences of not supplying it.

7. Security Safeguards (Sections 19 to 22)

You secure the integrity and confidentiality of personal information with appropriate, reasonable technical and organizational measures, and that duty extends to any operator processing data on your behalf under a written contract.

It also carries the breach obligation: if personal information is accessed or acquired without authorization, you notify the Information Regulator and affected data subjects as soon as reasonably possible.

This is the condition your IT and security teams carry, and it is covered in detail further down.

8. Data Subject Participation (Sections 23 to 25)

Once they have confirmed their identity, people have the right to ask whether you hold information about them and to receive a copy or description of it.

They can also request that you correct or delete information that is inaccurate, irrelevant, excessive, out of date, incomplete, or held without authority. You have to act on those requests in the manner the Act sets out.

What is the Difference Between a Responsible Party and an Operator?

POPIA splits responsibility between two roles, and knowing which one you are changes what you are on the hook for. A responsible party decides why and how personal information gets processed, the controller in GDPR terms.

An operator processes that data on the responsible party's behalf and on its instructions, the processor equivalent. A bank that collects customer data is a responsible party. The software platform it runs that data through is an operator.

The accountability does not transfer with the data. Even when you pass personal information to an operator, you stay answerable for it as the responsible party.

Section 21 of POPIA requires you to put a written contract in place with every operator and to satisfy yourself that the operator maintains the security measures the Act demands.

That is why a vendor's certifications and security posture feed directly into your own compliance. A security questionnaire and an operator agreement belong in your procurement process, not as an afterthought once the data is already flowing.

What Does POPIA Require for Data Security?

Section 19 is the security backbone of POPIA, and it is where most IT teams spend their compliance effort.

It requires you to secure the integrity and confidentiality of personal information by taking appropriate and reasonable technical and organizational measures. In practice it breaks into four ongoing duties:

• Identify the reasonably foreseeable internal and external risks to the data you hold.

• Establish and maintain safeguards against those risks.

• Verify that the safeguards actually work.

• Update them as new risks appear.

The word that matters there is ongoing. Section 19 is not a control you switch on once and forget. Regulators expect access control, encryption, patching, monitoring, and testing to be live and reviewed, with evidence that you checked them.

A layered approach of access control, encryption, regular patching, and continuous monitoring is what a defensible Section 19 program looks like in practice.

What are the POPIA Breach Notification Rules?

When personal information is accessed or acquired by someone without authorization, Section 22 of POPIA requires you to notify the Information Regulator and the affected data subjects as soon as reasonably possible.

There is no fixed seventy-two-hour clock like the GDPR sets, but the expectation is prompt action once you are reasonably sure a compromise has happened, not after a full investigation has wrapped up.

Since April 2025, that notification runs through the Regulator's online portal rather than by email.

This is where detection speed and a clean record matter most. You cannot report what you never saw, and you cannot prove your timeline without a log of when the compromise was detected and what you did next. A proper root cause analysis depends on that same record.

Most teams discover their gap here only after an incident, when they go looking for a timeline that was never recorded.

If you want a fuller view of how to structure that response before you need it, our guide to incident management best practices walks through it.

How Motadata Follows POPIA Compliance

POPIA puts the legal duty on you as the responsible party, but the operator you hand personal information to has to carry its own weight.

Motadata processes that data as an operator that follows POPIA, and it lists POPIA alongside GDPR, CIS, SOC 1 Type 2, SOC 2 Type 2, and SOC 3 among the standards it meets.

Here is what sits behind that.

1. Certifications and Operator Commitments

Motadata holds SOC 1 Type 2, SOC 2 Type 2, and SOC 3 attestations. A Type 2 report tests whether security controls operated effectively across a period, not just on the day of the audit, which is the evidence an Information Officer needs when assessing an operator under Section 19.

Motadata also aligns to CIS benchmarks, holds ITIL certification through PeopleCert, and supports GDPR, the framework POPIA most closely mirrors.

2. Security Safeguards Built Into the Platform

Personal information inside ServiceOps is encrypted, and the platform keeps audit logs of who did what. ObserveOps watches the same environment for the unusual access patterns that point to a compromise.

These are the technical measures Section 19 asks for, applied to the systems where ticket data, asset records, and user details actually live.

3. Access Control and Audit Trails

ServiceOps and ObserveOps both run on role-based access control, so a technician reaches only the records their role permits. Every change is tracked.

ServiceOps records change history and policy enforcement, and ObserveOps keeps a dedicated audit trail of user actions, which gives you the openness and accountability POPIA expects you to demonstrate.

4. Data Residency and Deployment Options

You can run Motadata on-premises or in a private cloud, which keeps personal information inside your own infrastructure rather than a shared multi-tenant service.

For organizations weighing cross-border transfer rules under POPIA, that control over where data physically sits is often the deciding factor. A SaaS option exists for teams that prefer it.

How Does Motadata Help You Meet POPIA's Security Safeguards?

Section 19 is the condition your IT team owns. It asks you to identify risks, put safeguards in place, check they work, and keep them current, then detect and act when something slips through. Here is where Motadata does the work.

1. Detecting Unauthorized Access With ObserveOps

ObserveOps brings logs, metrics, flows, and traces into one place and runs anomaly detection on them around the clock. Its log monitoring surfaces patterns that point to a problem, and its AI policies flag activity that breaks from the normal baseline without weeks of manual tuning first.

When access to a system holding personal data looks wrong, the platform raises a classified alert instead of leaving it buried in a console.

2. Closing the Loop on Breach Response

This is where Motadata goes past a monitoring tool. An ObserveOps alert can open a ServiceOps incident on its own, so the moment a possible compromise is detected, a ticket exists with a timestamp.

Your team works it through incident and problem management, and the record it leaves is what Section 22 asks for when you notify the Regulator as soon as reasonably possible.

3. Evidence and Compliance Reporting

POPIA does not stop at having controls. You have to show they work.

Motadata's Network Configuration and Compliance Management checks device configurations against policy and flags drift, ServiceOps patch management closes known vulnerabilities across Windows, macOS, and Linux, and both products produce the reports and audit trails that become your proof during an assessment or investigation.

4. Accountability and Openness Through ServiceOps

Accountability under POPIA means someone owns compliance and can demonstrate it.

ServiceOps gives that owner a shared CMDB, a full request and change history, and dashboards that show what happened across the estate.

When the Information Officer has to answer for a processing activity, the trail is already there.

What Changed in the 2025 POPIA Amendments?

The 2025 updates to the POPIA Regulations tightened several practical points:

• Data subjects can now send requests, including objections, corrections, and deletions, by email, SMS, and WhatsApp, not only on a written form, so your intake process has to accept those channels.

• Organizations are expected to keep a Compliance Register that links each obligation to its controls and owners.

• Breach notifications to the Regulator now run through the online eServices portal.

The direction is clear. There is less tolerance for paper-based, once-a-year compliance and more expectation of live, documented controls that you can produce on demand.

POPIA Compliance Checklist for IT Teams

Use this as a starting point for the work your team owns directly.

• Appoint and register your Information Officer with the Information Regulator, and assign deputies for a larger organization.

• Map where personal information actually lives across your tickets, assets, logs, and email.

• Put a written operator agreement and a security questionnaire in place for every vendor that processes your data.

• Harden your Section 19 controls with role-based access, encryption, patching, monitoring, and regular testing.

• Document a breach response procedure that can file through the Regulator's portal as soon as reasonably possible.

• Keep audit trails and reports that show your controls are working, not just present.

• Review your cross-border transfers and retention periods at least once a quarter.

Make POPIA Compliance Something You Can Prove

POPIA compliance is not something you buy. It is something you have to demonstrate.

The Act puts the accountability on you as the responsible party, and the eight conditions stand or fall on whether you can show the controls behind them when the Regulator asks.

No platform changes that. The Information Officer, the operator agreements, the policies, and the staff training are yours to run, and a tool will not write them for you.

What the right platform does is carry the technical and reporting weight, so that when the Regulator asks what you saw and what you did, the answer is already recorded.

Motadata supports that side as an operator that follows POPIA, with the security safeguards, detection, and audit trails Section 19 and Section 22 expect.

If you want to see how that holds up against your own environment, you can book a demo with Motadata sale's representative. Get an understanding of how Motadata products meet your requirements in observability and ITSM requirements.

FAQs