POPI Checklist for the IT guy

I developed a standard and now my company is applying it to our very many systems and data sources. I took each processing condition and interpreted in a way that we could apply some set of controls or rules to the PI to make us compliant. This was done in conjunction with my technical team.

Suggest doing some formal training on POPI as this should give you an indication of what needs to be done.
 
There is no such thing as "POPI Compliant". There is, however, a set of clauses in an act that imply standards that have largely never been tested IRL, with virtually no enforcement capability by an information regulator that itself was subject to a data leak in it's 2nd week of operation and has thus far been incapable of processing the required POPI officer registrations, a year later. Bottom line, you will only be scrutinised and held responsible for all the things you should have done, after you get caught out in a high-profile data leak.
What you're saying here largely resonates with me. In a lot of audit type situations (and not just POPI) people come with a one-size-fits-all cookie cutter checklist of what you should do and includes everything that you would expect of a mature, well resourced large enterprise - much of these things are not feasible or applicable for and SME with small IT department or a single IT resource. Not to mention that POPI is a business responsibility as much as an IT one.

Security should be risk based and we should address, mitigate or accept the risks prioritised according to your threat model. One size fits all doesn't work very well. I suspect that even in many of the large, well resourced enterprises, they comply by ticking boxes rather than implementing effective controls which in turn contributes to some of the breaches in such organisations.
 
What you're saying here largely resonates with me. In a lot of audit type situations (and not just POPI) people come with a one-size-fits-all cookie cutter checklist of what you should do and includes everything that you would expect of a mature, well resourced large enterprise - much of these things are not feasible or applicable for and SME with small IT department or a single IT resource. Not to mention that POPI is a business responsibility as much as an IT one.

Security should be risk based and we should address, mitigate or accept the risks prioritised according to your threat model. One size fits all doesn't work very well. I suspect that even in many of the large, well resourced enterprises, they comply by ticking boxes rather than implementing effective controls which in turn contributes to some of the breaches in such organisations.
You underestimate my checklist-making abilities xD jk

I understand there is no one-size-fits-all list, but having something that outlines the basics can go a long way to helping the industry in general in SA operate more securely with PI.

I've encountered plenty of systems run by SMMEs that still give me nightmares. In general developers in SA are also fairly poorly trained in operating securely in an online environment. Things like public DB access, default root logins, not using SSL by default, etc, gives me nightmares - especially since there is NO WAY to know who possesses info about you.

At the very least something like this can end up protecting the data subject, but for that to happen any newbie on the internet need to be easily able to find such a thing
 
I developed a standard and now my company is applying it to our very many systems and data sources. I took each processing condition and interpreted in a way that we could apply some set of controls or rules to the PI to make us compliant. This was done in conjunction with my technical team.

Suggest doing some formal training on POPI as this should give you an indication of what needs to be done.
You don't mind sharing that standard with the class?
 
I'll give you my opinion as senior legal advisor of my company (and technically head of legal for SA since I'm the highest in legal):

Cover your ass.

It's a new thing with many grey areas, many different interpretations and there will be problems which will be fixed, it happens with every new regulations.

Usually I try to do as much as I can in house to avoid attorney and consultant costs (that's what justifies my salary).

On that one though, I said right away that it will be expensive but I'd rather not get us in trouble and we got everything done by our attorneys.
 
Top
Sign up to the MyBroadband newsletter
X