Privacy Notice

Thank you for choosing to be part of our community at AdvanceNet Pty Ltd, doing business as AdvanceNet ("AdvanceNet", "we", "us", "our"). We are committed to protecting your personal information and your right to privacy. If you have any questions or concerns about this privacy notice, or our practices with regards to your personal information, please contact us at info@advancenetgroup.com.

When you visit our website http://www.advancenetgroup.com (the "Website"), and more generally, use any of our services (the "Services", which include the Website), we appreciate that you are trusting us with your personal information. We take your privacy very seriously. In this privacy notice, we seek to explain to you in the clearest way possible what information we collect, how we use it and what rights you have in relation to it. We hope you take some time to read through it carefully, as it is important. If there are any terms in this privacy notice that you do not agree with, please discontinue use of our Services immediately.

This privacy notice applies to all information collected through our Services (which, as described above, includes our Website), as well as, any related services, sales, marketing or events.

Data Protection Policy

1. Introduction
   • At the AdvanceNet Group we respect the privacy of people and we protect the personal information we process. We balance our need to process personal information for our activities with the legal requirements to protect it.

2. Purpose
   • This policy describes the principles governing our processing of personal information. It also records our compliance strategy regarding personal information and our incident response policy should there be an information security compromise in our organization.

3. Scope
   • This policy applies to all personal information processed in the course of our business and to all persons employed or engaged by us who process personal information.

4. Data protection laws
   • We are committed to protecting and respecting the privacy of our data subjects in accordance with the local data protection laws applicable to the jurisdictions in which we operate. As such, we have chosen to adopt a global approach to data protection compliance. This involves an 80% focus on complying with those requirements that are common to most data protection laws globally and a 20% focus on complying with those that are specific to our relevant jurisdictions. The relevant local laws with which we will comply are:
     • General Data Protection Regulation 2016/679 (European Union).
     • Protection of Personal Information Act 4 of 2013 (South Africa).
   • In applying the relevant data protection laws, we will ensure that we:
     • Enable data subject rights.
     • Adhere to our data protection obligations as controller or processor.
     • Apply the data protection principles.
   • In terms of data subject rights, we will ensure that our data subjects can:
     • Know when and why we process their personal information.
     • Request access to their personal information that we process.
     • Rectify any personal information of theirs that is incorrect.
     • Erase their personal information from our systems, where required.
     • Restrict our processing of their personal information, where required.
     • Object to our processing of their personal information.
     • Transfer their personal information from us to another controller in a structured and accessible format.
     • Be protected from us making automated decisions about them.
   • In terms of our obligations as controller, we will ensure that we:
     • Implement appropriate and reasonable technical and organisational measures to protect personal information.
     • Control our processors through a written contract.
     • Keep records of our processing activities.
     • Cooperate with the relevant data protection authorities.
     • Conduct data protection impact assessments, where required.
     • Consult with the relevant data protection authorities, where required.
   • In terms of our obligations as processor, we will ensure that we:
     • Enter into a contract with the relevant controller.
     • Appoint sub-processors only with the controller’s written authorisation.
     • Process personal information only on the instructions of the controller.
     • Keep records of our processing activities done on behalf of the controller.
     • Inform the relevant data protection authorities of irregularities, where required.
   • In terms of the data protection principles, we will ensure that we process personal information:
     • Lawfully, fairly and transparently.
     • Only for a specific purpose that is explicit and legitimate.
     • Only as necessary for that purpose.
     • Accurately, keeping it up to date.
     • For no longer than necessary to achieve the purpose.
     • Securely.
5. Compliance strategy
   • Our compliance strategy is to do our best to comply absolutely with every aspect of the applicable data protection law.
   • We have identified the following areas as being key priorities in our compliance efforts:
     • Monitoring and applying our data protection activities consistently across our entities and jurisdictions.
     • Adopting privacy by design and by default at a Group level.
     • Managing our responsible party relationships efficiently.
     • Digitising our responsible party processing activities.
6. Governance of data protection
   • We will appoint and maintain one Information Officer for each of our entities. The Information Officer is responsible for:
     • Promoting compliance with data protection law within the entity.
     • Ensuring awareness of data protection law within the entity.
     • Managing and responding to data subject access requests.
     • Managing and responding to data breaches or incidents.
     • Assisting the relevant data protection authorities with their investigations.
     • Developing, implementing and monitoring the compliance framework within the entity
   • The Information Officer will report to the Group Managing Director.

7. Policy responsibility and administration
   • The Information Officer is responsible for overseeing data protection in our Group and is responsible for ensuring that the policy is effective and relevant. Their contact information is:

Name: Andy Irving

Email address: andy.irving@advancenetgroup.com

Telephone: +27 11 367 9000

Incident Response Policy

1. Introduction
   • This is our official incident response policy to handle information security compromises in our organisation. Information is a powerful tool that we rely on to run our business. But, it poses significant risks if it falls into the wrong hands because of a security compromise or related incident that lets an unauthorised person access or acquire personal information. We make every effort to guard against incidents and have extensive policies in place, provide training to our staff thereon and use technical tools to secure our information. But, incidents can potentially still occur. For this reason, we must understand and be ready to apply this incident response policy.

2. Purpose
   • The purpose of this policy is to set out the necessary steps to effectively and efficiently identify, report, escalate, respond to and evaluate whether we have resolved any security compromises or other related incidents that occur in our organisation. It is important because we must implement good incident management practices to deal with incidents that may harm us, our stakeholders, or the public in general.

3. Legislation
   • This policy gives effect to many of our responsibilities as a responsible party in terms of the Protection of Personal Information Act 4 of 2013 (POPIA) and as a controller in terms of the General Data Protection Regulation 2016/679 (GDPR) and should be read in conjunction with that legislation where applicable.

4. Audience
   • This policy is intended for our Information Officer or anyone delegated the responsibility of responding to security compromises and related incidents. This policy is important for our Information Officer, or someone that they have delegated appropriate authority to, because it could affect how they handle a security compromise or other related incident. They are also the only people in our organisation that should be authorised to speak on our behalf about security compromises or other related incidents.
   • Our Information Officer is responsible for responding to security compromises. This means that:
     • In general, all incidents must be reported to the Information Officer or the office of the Information Officer, as the case may be.
     • The Information Officer must authorise all notifications to the Regulator, the authorities, or data subjects in writing.
     • The Information Officer must approve all external communications about an incident.
     • The Information Officer must decide where and how to allocate resources to handle incidents.
     • The Information Officer must assemble a response team and instruct them on their specific responsibilities.

5. Incidents
   • An incident is a security compromise or any other related occurrence where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by any unauthorised person. This definition has three components:
     • Reasonable grounds to believe – an average person would have thought that there was a security compromise from the circumstances.
     • Personal information of a data subject – the security compromise concerned personal information belonging to a data subject.
     • Accessed or acquired by any unauthorised person – someone who wasn’t supposed to have accessed or acquired the personal information has done so.
   • Incidents will include anything that meets these criteria, which could include:
     • Loss or theft of data containing personal information or equipment on which data containing personal information is stored.
     • Hacking or any other deliberate attack on our systems to access data containing personal information.
     • Access control failure a failure of a password, firewall, or other access control system that allows unauthorised access to personal information.
     • Unauthorised use of personal information by a member of our personnel.
     • Equipment failure that exposes personal information to unauthorised access.
     • Human error that exposes personal information to unauthorised access.
     • Phishing or other ways of using persuasion or guile to obtain personal information without authorisation.
   • We must ensure that our response to an incident is proportional to its severity.
6. Categories
   • Once we have identified an incident, we must categorise it. A category is a class of incidents based on shared characteristics. This policy does not prescribe hard and fast categories into which incidents should be categorised, it merely suggests a few ways of categorising them. For example, we could categorise an incident based on:
     • The sensitivity of any information leaked during the incident.
     • How badly the incident threatens our reputation.
     • How difficult the incident will be to recover from.
     • The severity of the incident and the consequences to the data subjects involved in the incident.
     • What type of personal information is involved.
     • How protected the personal information is.
     • What happened to the personal information.
     • Who accessed or acquired the personal information without authorisation.
     • What the extent of the security compromise or related incident is.
     • Who the data subjects are whose personal information has been compromised.
     • What harm could come to those data subjects.
7. Report
   • We must obtain a report of the incident so that we can deal with it properly. If we don’t know about it, then we can’t do anything about it. We want anyone at any level of our organisation to be encouraged to report an incident to us. We also want them to report incidents in sufficient detail for us to formulate a meaningful response. The contact details of the Information Officer should be easily accessible when anyone wants to report an incident.
8. Duty
   • We must encourage employees, contractors (and customers, prospects and suppliers, where applicable) to bring any suspected incidents to our attention as quickly as possible. They must report them directly to our Information Officer so that we can handle them properly. It is very important that we encourage the reporting of all incidents as soon as is possible, because it is often required by law and delays in finding out about incidents can determine how effectively we are able to manage them.
9. Detail
   • It is important that we have any incident reported in sufficient detail to enable the Information Officer to process it effectively. Anyone reporting an incident should provide the Information Officer with all possible information. It is better to give the Information Officer too much information, as opposed to little.
10. Authorities
    • Only the Information Officer should decide whether or not to contact the Regulator, law enforcement, or other authorities about a particular incident as they are responsible for managing the incident response procedure.
11. Requests to cooperate
    • Our employees or contractors should be cautioned not to reply to any requests to cooperate with any investigations about incidents unless the requests come directly from our Information Officer. Hackers can use phishing techniques combined with the uncertainty of how to deal with an incident to obtain sensitive information from employees or contractors. These requests may appear to come from the Regulator, law enforcement, or other authorities. These requests should be sent to our Information Officer to decide whether they are legitimate or not.
12. Protection
    • We want to encourage employees and contractors to report incidents and will protect them as far as is legally possible to make sure that they are comfortable with reporting them. If an employee or contractor reports an incident in good faith, we should not threaten them with any recourse or discriminate against them in any way because of their involvement in the incident. We want them to report anything they suspect of being an incident to us and should incentivise them to do so. There should be no recourse against them even if we discover that there was no incident or that the incident did not pose as much of a risk to us as they led us to believe.
13. Optional anonymity
    • If an employee or contractor reports an incident, they may tell us whether or not they wish to remain anonymous. If they decide that they want to remain anonymous, then the Information Officer will not give their identifying information to anyone else unless absolutely necessary, for law enforcement for example.
14. Escalation
    • It is important to escalate incidents appropriately so that they can be dealt with by the appropriate people.
15. Escalation plan
    • We should follow an escalation plan and escalate various categories of incidents to specific people in our organisation when they occur, such as:

16. Response
    • We must actually respond to the incident, which is arguably the most important step of all. The cost of an incident is often determined by how well we respond to it.
17. Resources
    • The Information Officer needs to know what resources they have available to them, including what they have access to internally and what they need to get access to externally to deal with security compromises or related incidents.
18. Response team
    • The Information Officer should assemble and oversee a response team consisting of representatives from business areas likely to be affected by a security compromise or any other related incident and should consider including representatives from:
      • Legal.
      • Human resources.
      • Information technology.
      • Any other departments working with personal information.
      • External stakeholders or suppliers.
    • The Information Officer needs to decide whether or not to delegate responsibility to members of the response team. The Information Officer should clearly document and define the roles of the response team. Each person should be responsible for different tasks and they should understand that the Information Officer oversees them. The Information Officer should have a clear plan of communication within the team.
19. Containment and recovery
    • Any response to a security compromise or related incident should be backed up by a containment and recovery plan that seeks to limit the damage of the incident. The plan should specify which member of the response team will lead the containment and recovery process (usually the Information Officer) and establish what each other member of the response team will do in terms of containment and recovery.
20. Notification
    • The Information Officer needs to know who to notify in the case of a security compromise, whether it be the Regulator, relevant information regulator, data subjects, or law enforcement. There are legal requirements in terms of POPIA and the GDPR to notify certain parties about security compromises and related incidents that we must comply with when responding to an incident. However, there are also business reasons why we should notify these parties. The Information Officer should decide whether to notify third parties about a security compromise or related incident. This will give the notification a clear purpose, be it to comply with the law or for our business reasons.
21. Notification timeframe
    • Section 22(2) of POPIA and Article 33 of the GDPR require us to make notifications as soon as possible after an incident is discovered because:
      • Law enforcement needs time to respond.
      • We must take reasonable measures to determine the scope of the compromise.
      • We must restore the integrity of our information system.

However, the Information Officer must ensure that they do not compromise the steps set out in this policy by making a notification prematurely.

22. Processor breach notification
    • The processor must notify the controller after becoming aware of a personal information breach without undue delay.
23. Notifying authorities.
    • Section 22(1)(a) of POPIA and Article 33(1) of the GDPR require us to notify the relevant information regulator of a personal information breach without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the rights of the data subjects.
    • The purpose of the notification is to allow the appropriate regulatory bodies to perform their functions. It is important that we notify the correct regulatory body. When notifying the regulatory body, we should give details about what we are prepared to do to help them. We might also need to consider notifying other third parties like law enforcement bodies, insurers, professional bodies, bank or credit card companies, trade unions and anyone else who can assist in reducing the risk of financial loss to individuals. The Regulator may direct us in terms of section 22(6) of POPIA to publicise the fact that the integrity or confidentiality of our personal information has been compromised if they believe that the publicity would protect an affected data subject. It is important that we only notify the Regulator where there is a real security compromise or related incident.
24. Notification contents
    • The notification must contain at least:
      • A breach description, including:
        • Categories and approximate number of data subjects.
        • Categories and approximate number of personal information records concerned.
      • Information Officer (or other contact point) name and contact details.
      • Likely consequences of the data breach.
      • Measures taken or proposed to address the personal information breach and mitigate its possible adverse effects (where appropriate).
25. Phases exception
    • We may provide the information in phases without undue further delay where it is not possible to provide it all at the same time.
26. Documentation requirement
    • The controller must document any breaches, by recording:
      • The facts relating to the breach.
      • The effects of the data breach.
      • The remedial action taken.
27. Notifying data subjects
    • Section 22(1)(b) of POPIA and Article 34 of the GDPR require us to notify the data subjects affected by the incident unless their identity cannot be established. We may only delay notifying the data subjects in terms of section 22(3) of POPIA if a public body responsible for the prevention, detection, or investigation of offences or the Regulator determines that notification will impede their criminal investigation. We need not notify the data subject in terms of Article 34(3) of the GDPR if:
      • We have implemented appropriate technical and organisational measures and those measures were applied to the personal information affected by the data breach.
      • We have taken subsequent measures to ensure that high risk to the rights of the data subject is unlikely to materialise.
      • Unless it would involve disproportionate effort.
    • Section 22(4) of POPIA requires the notification to the data subject to be in writing and communicated in at least one of the following ways:
      • Physically delivered to the data subject’s last known physical or postal address.
      • Electronically delivered to the data subject’s last known e-mail address.
      • Placed in a prominent place on our website.
      • Published in the news media.
      • As the Regulator may direct.
    • Section 22(5) of POPIA requires that the notification contains enough information to allow the data subject to take steps against the consequences of the compromise, including:
      • A description of the possible consequences of the incident.
      • A description of the steps that we intend to take to handle the security compromise.
      • Suggestions of what the data subject could do to mitigate the consequences of the security compromise.
      • The identity of the unauthorised person who may have accessed or acquired the personal information if known to us.
    • Article 33(3) and 34(2) of the GDPR require that the communication to the data subject must be in clear and plain language and must:
      • Describe the nature of the personal information breach, including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal information records concerned.
      • Communicate the name and contact details of the Information Officer or other contact point where more information can be obtained.
      • Describe the likely consequences of the personal information breach.
      • Describe the measures taken or proposed to be taken by the controller to address the personal information breach, including, where appropriate, measures to mitigate its possible adverse effects.
    • For business reasons, the notification should allow affected individuals to protect themselves. It should also provide advice on how data subjects can mitigate the consequences of the incident and have a mechanism to deal with complaints.
28. Notifying data subjects (GDPR)
    • The controller must communicate the personal information breach to the data subject without undue delay when it is likely to result in a high risk to human beings’ rights and freedoms. The communication must:
      • Describe the nature of the personal information breach.
      • Be in clear and plain language.
    • The communication must also contain the required information and recommendations, namely:
      • Our Information Officer’s (or other contact point’s) name and contact details.
      • The likely consequences of the data breach.
      • The measures taken or proposed to address the personal information breach and mitigate its possible adverse effects where appropriate.
    • The controller need not communicate the personal information breach to the data subject under any of the following conditions:
      • They had implemented appropriate technical and organisational protection measures and applied them to the breached personal information, particularly encryption.
      • They have taken subsequent measures to make sure that the high risk is unlikely to materialize.
      • It would involve disproportionate effort, provided that they must use a public communication or similar equally effective measure.

The information regulator may consider the likelihood of the personal information breach resulting in a high risk where the controller has not already communicated the personal information breach to the data subject and:

• Require the controller to communicate the personal information breach to the data subject.
• Decide that one of the communication exceptions has been met and they need not communicate the data breach to the data subject.

29. Notification questions
    • It can help to decide when to notify and to what extent to notify the data subject if the Information Officer asks themselves questions, including:
      • Are we legally or contractually obliged to notify anyone about this incident?
      • Will the notification help the individual data subject?
      • What should we include in our notification to ensure that it is appropriate for the data subjects whose personal information has been breached?
      • What are the risks of not notifying the data subject?
      • What are the risks of “over notifying” the data subject? I.e. not every incident requires notification of all our stakeholders and often only the affected subset need be notified.

30. Manner
    • It is important that we frame and deliver our response in the correct manner, which includes:
      • Keeping the response simple – complexity means more room to make mistakes.
      • Delivering the response quickly – failing to respond quickly makes the problem worse and creates the impression that we are uninterested in the problem.
      • Delivering the response as a matter of urgency where the fallout is severe – the first 24 hours are crucial.
      • Making sure we have formulated our response properly – responding properly means including the relevant information and interacting with the relevant individuals.
      • Delivering the response on an appropriate forum – use appropriate platforms to maximise efficacy.
    • We will have successfully responded to an incident if:
      • Our leadership is accountable.
      • We are able to re-establish trust.
      • We provide transparency.
31. Acknowledgement
    • We must acknowledge the security compromise or other related incident, which means to recognise its importance. To recognise the importance of a security compromise or other related incident, we must collect the following information:
      • Who or what was affected by the incident?
      • Why did the incident occur?
      • When did the incident occur?
      • How did the incident occur?
      • To what extent did the incident pose a risk?
      • How did we find out about the incident?
32. Action
    • We must take action, which means working out what happened, preventing it from happening again and maintaining communication with our data subjects. The Information Officer should handle the security compromise by investigating the problem and identify short and long term solutions.
33. Other steps
    • Other steps we can take as and when needed to effectively respond to a security compromise or other related incident are to:
      • Get a media program, which is a set of press releases and other media content, that we can syndicate to the media to help them report on the incident.
      • Prepare and maintain a toolkit to help people in our organisation deal with an incident.
      • Develop templates the Information Officer may deploy in the case of an incident, such as letters to the Regulator or other authorities, or media statements.
34. Evaluate
    • A security compromise or other related incident is not over once we have responded to it. We must evaluate the outcome of that response, which means we need to form an idea of how well it worked. We need to know how well it worked so that we can decide whether an additional response is needed or whether the response we put out is sufficient.
35. Answers
    • Feedback is the food of champions. We should invite it whenever we can and be grateful for it when our data subjects decide to give it to us and make sure to respond to it where appropriate.
36. Aggregation
    • We should collect everything about the incident together in one place so that our data subjects can access it easily.
37. Update policy
    • We must update this policy from time to time based on how we’ve evaluated our responses to incidents.
38. Update information security
    • We need to update our information security systems based on the outcome of an incident and our response. Information security is a constantly changing landscape. Section 19(3) of POPIA and Article 32 of the GDPR require us to have due regard to generally accepted information security practices and procedures which may apply to us generally or be required in terms of our industry rules and regulations
39. Questions
    • Security compromises or other related incidents can be confusing to deal with and we hope this policy has helped to alleviate some of the confusion, however this policy cannot cover all issues when it comes to security compromises or other related incidents. There will always be issues that fall outside of it and we want people in our organisation to contact the Information Officer with questions when such incidents occur or if they have any questions arising out of this policy.