Approaches for GDPR Compliance
Info: 15322 words (61 pages) Dissertation
Published: 17th Dec 2019
Tagged: Business
- Abstract
As organizations prepare for the new European Union (EU) General Data Protection Regulation (GDPR) by considering changes in processes, people, and technology, this project looks at approach for data security for compliance with the EU-GDPR.
This project concentrates mainly on security requirements of the GDPR, best practise and good set of approach.
An evaluation and analysis proposal of the current data policy and the requirements of the EU-GDPR.
The GDPR mandates many different data protection and governance principles and requirements, this report mainly covers the key requirements of GDPR and data security principles.
Contents
2 Introduction
3 Aim
4 Background
5 Literature Review
5.2 Regulation Security Requirements
5.2.1 GDPR Definition of Participants
5.2.2 What any organization need to have in place
5.3 Privacy Impact Assessments (PIA)
5.4 Prevention of Attacks
5.4.1 Privileged Users Review, Assessment and Control
5.4.2 Database Security and Threats
5.4.3 Encryption
5.4.4 Anonymization and Pseudonymization
5.4.5 Access Control-Defined Purpose Only
5.5 Monitoring
5.6 Protection
5.6.1 Data Security by Design
5.6.2 Centralized Management and Comprehensive Security
5.6.3 Data Loss Prevention – DLP
5.7 Attack Methods and Testing
5.8 DPA Vs GDPR
6 Conclusion
7 Bibliography
8 Appendices
2 Introduction
This research is an approach to data security of personal data to ensure the compliance with the new European Union General Data Protection Regulation.
An approach that can be adapted to any environment to ensure that performance, availability and integrity are maintained.
The General Data Protection Regulation (GDPR) is designed to enable individuals to have greater control of their personal data.
The GDPR was concluded in middle of 2016 and became law, which requires member states to comply and will be enforceable by May 2018.
Complying with the new regulations requires operating to high standards of data security and protection. Any data breach that puts the rights and freedoms of individuals at risk, organizations must notify the people affected and the data protection authority (Information Commissioner’s Office (ICO) in the UK) within 72 hours of becoming aware of it.
Any organizations and businesses who are involved in a data breach, are far more liable under new GDPR than they were under the Data Protection Act, so data breaches comes with heavier financial punishment and consequences of inadequate security.
An organization must demonstrate that they have complied and below are what is required:
- Implement appropriate technical and organisational measures that will ensure and prove that you comply, this will and may involve internal data protection policies i.e. staff training, internal and regular audits of processing activities, regular reviews.
- Maintain appropriate documentation on processing activities.
- Possibly appointment of a data protection officer.
- Design and Implement measures that meet the criteria of data protection by design and data protection:
Data Encryption,
Pseudonymisation
Transparency
Data Minimisation
Appropriate Security controls, protection and monitoring.
PIA where appropriate
The approach to compliance is further broken down in detail in the main body section of this report.
3 Aim
The EU-GDPR has mandated that Controllers perform Data Protection Impact Assessments when certain types of processing of Personal Data are likely to present a high risk to the data subject.
So, the aim of this research is an approach to Privacy Impact Assessment in compliance with EU-GDPR.
4 Background
GDPR is a new regulation that will be enforceable in May 2018, as such this is an important and interesting area to research in and around the information security and in order to come up with a transparent approach to fulfil the EU-GDPR requirements and critical review.
Since the regulation is wider and broader, the research will look how information can be secured, encryption, processes and the technology changes that will be required to comply, so this report is the ideal topic that encapsulate all the topics covered in the master’s degree program in the last 2 years. All of the modules completed are adequately relevant and applicable to GDPR security approach discussed in this report; Information Governance and Security, Information Assurance and Risk Management, Network Security, Ethical Hacking and Project management.
From a security perspective, the EU General Data Protection Regulation (GDPR) is more important in terms of potential actions that needs to be taken.
The regulation will require every organization that offers products or services to EU citizens, as well as those handling data of EU citizens, to comply with a strict set of data privacy and security controls.
5 Literature Review
The rationale behind data protection regulation seems to lay emphasis on consumer interests and rights to control personal data, it appears as an inadequate tool for preventing or trying to stop the current problems involved with big and ever growing Data.
So do the proposed EU-GDPR would really protect individual rights? It would certainly increase the interest in data security which is what this research paper clearly provides an approach due to the heavy fines with certain type of privacy breach in the new regulation.
Extensive search carried out to identity similar academic papers for literature review were insufficient, most papers are mainly on the PIA and various sections of the regulation which discusses the security aspect of the GDPR requirements.
Mandatory pseudonymisation
“Obligatory pseudonymisation (data enabling identification of specific data subjects being kept separately from the other information) might be seen as a small and reasonable concession, but if strictly interpreted the consequences for epidemiological research may be detrimental. In the present LIBE amendment, personal data is defined as data that contains a unique personal identifier (direct identification) or data that can be attributed to a person without the presence of an identifier because of the richness of the available information. The combination of a few key variables (e.g., age, sex, date of diagnosis, geographic region, and diagnosis code) in a contingency table often results in some cells with just a single observation, providing a possibility for indirect identification of at least some subjects. If indirect identification is to be counted as ‘‘data enabling attribution of information to a data subject’’, then research databases must be stripped of considerable amounts of information in order to adhere to the requirement of pseudonymisation, possibly rendering many—if not most of them—useless for epidemiological research.” (Olof Nyre´n, 2014)
This was a valid statement, which highlights the fundamental flaws in pseudonymisation, but software and database developers have come up with solutions to the problem where by an attribute on a table column representing a data subject can be redacted or a table with multiple attributes which can link to the original data subject can be secured in such a way that it is not possible to join thereby reducing the link of the dataset with the data subject but can still be used for the flaws quoted in Olof ‘s paper above.
A literature review on Biro project provided an insight into what is to be expected in a PIA assessment when dealing with various regions so it can help in developing a PIA for GDPR, Biro project started back in 2005 to develop a sustainable platform for quality improvement in the treatment of diabetes by linking regional registers and creating benchmarks across various healthcare
Systems.
The BIRO method of privacy impact assessment (PIA)
“Specific questions related to privacy, confidentiality and security cannot be answered by technicians independently. What is the minimum aggregation level for data exchange (individual, provider, region, state)? What security measures must be applied? How should the communication process be activated?” (C T Di Iorio, 2009)
This paper strengthens the approach to support a good data security which this paper will further provide in section 5.1, slightly different methodological approach but this research papers provides an updated one considering the technology available now.
Bert-Jaap Koops wrote “In 2010, the total amount of information processed globally was estimated to be 1.2 zettabytes (that is 1,200,000,000,000,000,000,000 bytes) and growing at a rate of 60% per year; 31 of course, much of that is not personal data, but with increasing technological capacities to combine and interpret data, personal data will show up ever more frequently in the zettabytes of 21st-century information flows. The Data Protection Directive has done little to prevent the development of massive databases or the advent of the Big Data era, and it is folly to think that the GDPR will fare better in preventing ‘unnecessary’ data processing.32 who in his right mind can look at the world out there and claim that a principle of data minimisation exists?
The second problem is that the response to the regulatory disconnection between data protection law and data processing practice is more law, and specifically more-of-the-same law. Not only does the law triple in size and create more obligations (see fallacy 2), it also expands its scope.” (Koops, 2014)
Above literature review paper analyses the problem with the proposed GDPR and if it can actually achieve its purpose, deeper research into the challenges of the legal framework.
The paper is badly constructed and lacked a good theoretical approach but useful in understand the problem with new EU-GDPR.
Michael wrote “In light of this we show the exploration of privacy by design as a design philosophy which can be made to map legal requirements, particularly those of the GDPR, into software engineering. We make this more concrete through the use of privacy patterns (a kind of software design pattern), a less abstracted design medium. We connect this through privacy design strategies, which help link privacy by design to the GDPR [3].” (Michael Colesky, 2015)
Above literature paper aims to contribute a critical analysis to translate legal requirements into privacy design implementation and evidence through a strategic approach, very good analysis.
Many researchers and data protection commissioners have produced guidelines on how privacy by design can be understood but many system developers are struggling with the privacy principles and technology to adequately implement the design.
- Report and Methodological Approach
This section will focus and concentrate on the requirements and then discuss the plans to map methods and approaches deemed appropriate to satisfy the requirements.
Survey carried to gain insight regarding the awareness and preparation of organizations for full compliance with the General Data Protection Regulation.
The survey contains a series of question to assess most organization’s readiness for GDPR and generally to assess how they currently protect data which can give an indication of how secured they are and controls in place. The assessment and analysis results indicates that most micro to medium size organizations are not fully prepared while large businesses are 90-95% compliant.
Below is a chart of three questions analyzed from 8 organizations per size, Micro less than 10 employees, Small 10 to 49 employees, Medium 50 to 249 employees and Large are organizations greater than 250. Refer to survey questionnaire in Appendix A.
Figure 1: GDPR Readiness Survey Chart.
5.2 Regulation Security Requirements
The fundamental GDPR data security requirements can simply be classified into three categories: Assessment, Prevention, and Monitoring/Detection. The GDPR also requires compliance with the data protection principles to enhance the quality and protection of the data. This section summarizes key data security requirements discussed in the GDPR.
So, the core changes giving rise to the security requirements are and as stated that Personal Data must be;
- Processed fairly & lawfully and in a transparent manner
- Collected for specific, explicit and legitimate purposes
- Adequate, relevant and limited to what is necessary to meet the purpose
- Accurate and up to date
- Must not be kept for no longer than is necessary
- Kept secure to maintain its integrity, confidentiality and availability
7. Processed by controllers and processors able to demonstrate compliance
5.2.1 GDPR Definition of Participants
Personal data:
“Personal data means any information relating to an identified or identifiable natural person (“data subject”). An identifiable natural person is one who can be identified, directly or indirectly, by reference to an identifier such as a name, an identification number, location data, and an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. This definition of personal data is important to information security professionals because it implicates data that may not seem, at first glance, to qualify as personal. IP addresses, application user IDs, Global Positioning System (GPS) data, cookies, media access control (MAC) addresses, unique mobile device identifiers (UDID), and International Mobile Equipment IDs (IMEI) are some examples.” (Gary, July 11th, 2016)
Data Subject
A person who can be identified directly or indirectly by means of an identifier. For example, an identifier can be a national identifier, IP address, a credit card number, a username, or a cookie.
Personal Data
Personal information, including sensitive personal information, relating to a Data Subject e.g., address, date of birth, name, location and nationality.
Controller
A natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data. For example, a controller can be an organization or CIO.
Data Protection Officer
An individual working for a Controller or a Processor with extensive knowledge of the data privacy laws and standards. The Data Protection Officer (DPO) shall advice the controller or the processor of their obligations according to the GDPR and shall monitor its implementation. The DPO acts as a liaison between the controller/processor and the supervisory authority. A DPO for example can be a Chief Security Officer (CSO) or a Security Administrator.
Processor
A natural or legal person, agency or any other body which processes Personal Data on behalf of the Controller. For example, a developer, a tester, or an analyst. A Processor can also be a cloud service provider or an outsourcing company.
Recipient
A natural or legal person, agency or any other body to whom the personal data is disclosed. For example, an individual, a tax consultant, an insurance agent, or an agency.
Enterprise
Any natural or legal person engaged in an economic activity. This essentially includes all organizations whether in the public or private sector, whether in the EU or outside of the EU.
Third party
Any natural or legal person, agency or any other body other than the Data Subject, the Controller, the Processor and the persons who, under the direct authority of the Controller or the Processor, are authorized to process the data. For example, partners or subcontractors.
Supervisory Authority
An independent public authority established by a Member State (known as the National Data Protection Authority under the current EU Data Protection Directive), or auditing agency.
5.2.2 What any organization need to have in place
Staff Data
Rights
Information Security
Policies
Incidents MGT Process
3rd Parties & Transfers
Data Protection Officer
DP by Design
Risk & Assurance
Risk Profiling
Data Inventory
Figure 2: People, Process and Technology
From above GDPR requirements we can summarize the plan of actions and what is required in order to comply.
“Effective security is a key requirement for good governance” (Trinder, 2008)
“An Information Security Management System is the key set of processes that are required to support effective information security throughout an organization. Key components of the ISMS include; a high level Security Policy that states the organization’s objectives for information security, a Risk Assessment of the critical information assets and a ‘Statement of Applicability’, which documents how compliance is achieved against the Standard’s controls.
The implementation of the ISMS follows the concept of the Plan, Do, Check Act cycle – (See Figure 3) common in other management systems, such as ISO 9001 and ISO 14001 ” (Trinder, 2008)
Figure 3: Plan, Do, Check, and Act lifecycle of an ISMS
- Identify Indicators of compromises: Malware; Exploits; Signatures; Vulnerabilities; Logs; IP Addresses; File Errors etc.
- Identify and implement security systems to protect from security attacks
- Document or Update & Implement data integrity security
- Monitor privileged users activities
- Identify and monitor unusual activities and logged/reported instantly.
- Ensure data integrity
- Define Personal Information: Employees must know what constitute a personal information: Employee number, Customer number, GPS, Email Address, IP address, Photos, Videos Social Security ID, Tattoo etc.
- Perform Data Inventory – Usually available in CMD for large organizations: File, Web and Storage servers; Endpoints-Laptop; Tablets; Smartphones; Fax Machines; Archive and Backup Tapes etc.
- Perform a data flow mapping or diagram.
- Document Method of Transmissions: SFTP, FTP, FAX, Email, Web HTTP/HTTPS, Direction Connection, Portable Media, Hard Copy delivery etc.
- Document Data Security Methods: Encrypted, 2-Factor Authentication, Wi-Fi Security type, Access Controls, Physical Controls etc.
- Review and Document Automated workflow and Processes within your organization
- Encrypt databases with strong encryption method
- Enforce Password Complexity Rules
- Gain certification ISO/IEEE not mandatory but useful.(Ideal for Vendors)
- Implement Firewall and Networking Segmentation
- Enforce Security close to the data when possible
Recommended approach for organization to comply or best achieve security controls is Assessment, Prevention and Detection.
Figure 4: Assessment, Preventive and Detective.
5.3 Privacy Impact Assessments (PIA)
Article 33 paragraph 1 of the proposed new regulation states that “Where processing operations present specific risks to the rights and freedoms of data subjects by virtue of their nature, their scope or their purposes, the controller or the processor acting on the controller’s behalf shall carry out an assessment of the impact of the envisaged processing operations on the protection of personal data.”
The regulation further states that ‘risky’ data is sensitive personal data, which means as an organization and intent on processing sensitive personal data then there is an obligation to complete a PIA.
The Regulation also states that in some instances, the data controller or in data processor shall obtain an authorization from the supervisory authority where the risk is significant. This means that prior approval may be needed from the commissioner in the event of risky processing.
Article 35 of the new proposed GDPR would suggest that data protection impact assessments (also known as Privacy Impact Assessment) mandatory.
“1. Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. A single assessment may address a set of similar processing operations that present similar high risks.
2. The controller shall seek the advice of the data protection officer, where designated, when carrying out a data protection impact assessment.
3. A data protection impact assessment referred to in paragraph 1 shall in particular be required in the case of: (a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person; (b) processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10; or (c) a systematic monitoring of a publicly accessible area on a large scale.
4. The supervisory authority shall establish and make public a list of the kind of processing operations which are subject to the requirement for a data protection impact assessment pursuant to paragraph 1. The supervisory authority shall communicate those lists to the Board referred to in Article 68.
5. The supervisory authority may also establish and make public a list of the kind of processing operations for which no data protection impact assessment is required. The supervisory authority shall communicate those lists to the Board.
6. Prior to the adoption of the lists referred to in paragraphs 4 and 5, the competent supervisory authority shall apply the consistency mechanism referred to in Article 63 where such lists involve processing activities which are related to the offering of goods or services to data subjects or to the monitoring of their behavior in several Member States, or may substantially affect the free movement of personal data within the Union.
7.The assessment shall contain at least: (a) a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller; (b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes; (c) an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1; and (d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.
8.Compliance with approved codes of conduct referred to in Article 40 by the relevant controllers or processors shall be taken into due account in assessing the impact of the processing operations performed by such controllers or processors, in particular for the purposes of a data protection impact assessment.
9.Where appropriate, the controller shall seek the views of data subjects or their representatives on the intended processing, without prejudice to the protection of commercial or public interests or the security of processing operations.
10.Where processing pursuant to point (c) or (e) of Article 6(1) has a legal basis in Union law or in the law of the Member State to which the controller is subject, that law regulates the specific processing operation or set of operations in question, and a data protection impact assessment has already been carried out as part of a general impact assessment in the context of the adoption of that legal basis, paragraphs 1 to 7 shall not apply unless Member States deem it to be necessary to carry out such an assessment prior to processing activities.
11 Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations.” (Union, 2016)
Risk Assessments Vs PIA
Risk can be mitigated by placing controls which will lessen either the likelihood or consequence of a privacy breach.
PIA should be a flexible process and a way in which systematic activity to assess the impacts or potential effects that an activity or proposal may have on individual privacy and the ways in which the effects may be mitigated.
Risks are generally categorized into the following: People, Technology and Process.
For GDPR, risks should be identified by association, Privacy and Security.
Privacy risks are areas such as information collection (As defined in above section 6), use, disclosure, retention, access, accuracy and governance.
Security risks cover areas such as Confidentiality, Integrity and Availability.
•Confidentiality: Ensure information is released only through intentional channels.
•Integrity: Ensures modifications are not made to the data either by authorized or unauthorized personnel or processes.
•Availability: Ensures reliable and timely access to data or computing resources by appropriate personnel. Guarantee systems are up when needed and security applications are running when needed.
Figure 5: CIA Triad
Below identified risks grouped into 6 tables from Alberta Medical Association – Privacy Impact Assessment Amendment Template
• Privacy/security not well understood; • information accidentally or otherwise disclosed to unauthorized individuals; • inappropriate network access/usage; • an act of sabotage (disgruntled current or former staff member); • unauthorized internal access (staff see information they are not authorized to see); • access is not limited; • information accidentally or otherwise disclosed to unauthorized individuals (terminated employee whose access to information systems was not removed); • Unauthorized use of information by an authorized user (vendor staff); • Unauthorized access (user shares his login and password with another user). |
• unauthorized access by a contractor; • loss of information availability / information control (data held by contracted service provider – data Centre); • contracted service provider breaches confidentiality; • access to information by contracted third parties; • disclosure of information (risk of loss / theft of data from contracted service provider); • excessive collection of information by vendor when providing contracted services • physical damage / theft (fire, flood, malicious action, equipment failure); • Unauthorized/unintended loss of data by vendors; • Unauthorized external access due to lack of Implementation of planned administrative, technical and physical controls. |
|
|
|
|
The PIA Process
This is an approach to PIA process designed to identify and address all Data protection risks within a new developing or procuring any new or modifications to any existing program, policy, procedure, service, technology or system that handles or collects information relating to all individuals or system which significantly change how information is managed.
It is an iterative process which maps the lifecycle of personal data to determine:
(A)The source of the data, (B) how will the data be processed;
(C)Who and where the data are sent to; (D) is the data still required/deleted or anonymised.
For the purpose of GDPR region should be included in the PIA process and when carrying out the Risk Assessments.
The following 6 steps suggested below should be followed
Figure 6: 6 Steps PIA Process
Below are sample of PIA Template from Information Governance Alliance.
(IGA, 2015)
Step 1: Background Details
Project Name | |
Organisation | |
Assessment Completed By | |
Job Title | |
Date completed | |
Phone | |
Project/Change Outline – What is it that is being planned? If you have already produced this as part of the project’s Project Initiation Document or Business Case etc. you may make reference to this, however a brief description of the project/process being assessed is still required. | |
Purpose / Objectives – Why is it being undertaken? This could be the objective of the process or the purpose of the system being implemented as part of the project. | |
What is the purpose of collecting the information within the system? For example patient treatment, patient administration, research, audit, reporting, staff administration etc. | |
What are the potential privacy impacts of this proposal – how will this change impact upon the data subject? Provide a brief summary of what you feel these could be, it could be that specific information is being held that hasn’t previously or that the level of information about an individual is increasing. | |
Provide details of any previous Privacy Impact Assessment or other form of personal data compliance assessment done on this initiative. If this is a change to an existing system, a PIA may have been undertaken during the project implementation | |
Stakeholders – who is involved in this project/change? Please list stakeholders, including internal, external, organisations (public/private/third) and groups that may be affected by this system/change. | |
Step 2: Identify Data Involved
What data is being collected, shared or used? | |||
Data Type | Justifications – there must be justification for collecting the particular items and these must be specified here – consider which data items you could remove, without compromising the needs of the project? | ||
Information that identifies the individual and their personal characteristics | Name | ☐ | |
Address | ☐ | ||
Postcode | ☐ | ||
Dob | ☐ | ||
Age | ☐ | ||
Sex | ☐ | ||
Gender | ☐ | ||
Racial/ethnic origin | ☐ | ||
Tel no. | ☐ | ||
Physical description | ☐ | ||
NHS no. | ☐ | ||
Mobile/home phone no. | ☐ | ||
Email address | ☐ |
Step 3: Screening Questions
Ys | N/A | Justification | |||||
Information relating to the individual’s physical or mental health or condition | ☐ | ☐ | |||||
Information relating to the individual’s sexual life | ☐ | ☐ | |||||
Information relating to the family of the individual and the individuals lifestyle and social circumstances | ☐ | ☐ | |||||
Information relating to any offences committed or alleged to be committed by the individual | ☐ | ☐ | |||||
Information relating to criminal proceedings, outcomes and sentences regarding the individual | ☐ | ☐ | |||||
Information which relates to the education and any professional training of the individual | ☐ | ☐ | |||||
Employment and career history | ☐ | ☐ | |||||
Information relating to the financial affairs of the individual | ☐ | ☐ | |||||
Information relating to the individual’s religion or other beliefs | ☐ | ☐ | |||||
Information relating to the individual’s membership of a trade union | ☐ | ☐ |
Step 4: Assessment Questions
Question | Response | Required Action | |
Legal compliance – is it fair and lawful? |
|
||
b – Have you identified the social need and aims of the initiative and are the planned actions a proportionate response to the social need? |
|||
|
|||
|
|||
Purpose |
|
||
|
|||
Adequacy |
|
||
Accurate and up to date |
|
||
|
|||
Retention |
|
||
|
|||
|
|||
Rights of the individual |
|
||
Appropriate technical and organisational measures |
|
||
|
|||
|
|||
|
|||
Transfers both internal and external including outside of the EEA |
|
||
|
|||
Consultation |
|
||
|
|||
Guidance used |
|
Major challenges while performing risk assessment is to determine what to evaluate, because some database applications would typically contain several entry points, and have Personal Data in multiple columns and tables with undefined access control.
Organization should seek a good database security technology and products that can help address this challenge, a tool to evaluate multiple aspects of application’s data:
- A tool with ability to discover tables and columns containing Personal Data.
- Ability to determine if databases configurations are adequately secured with a good overall security profile.
- Provides analysis of database roles and privileges to determine how and who can access personal data.
Approach to Identify Privacy issues and the Risk Assessment
While there are differences in approach or methodologies to PIA, they are all basically concerned with identifying risks to privacy and finding ways of overcoming those risks via mitigation or acceptance.
Below table is the methodology approach used by this research paper of assessing the data protection impact assessments when certain types of processing of personal Data are likely to present a “high risk” to the data subject, the assessment is not only limited to personal data but inclusive of areas that could lead to the breach when adequate security is lacking. The assessment also includes a systematic and extensive evaluation of organization’s processes, profiles, and how the technology tools and systems recommended in this research paper can protect the personal data.
The Risk AssessmentTableincluded in this research paper covers risks linked or related with privacy and security. Privacy risks cover areas such as personal information, use, disclosure, retention, access, accuracy and governance. Security risks cover areas such as confidentiality, integrity and availability.
The first thing is to identify the information assets that can lead to privacy issues, breach and security risks then apply the RAG matrix rating system for assessing risk.
This is normal when performing risk assessment, RAG means red, amber and green scored with the impact against Confidentiality, Integrity and Availability.
No | Information Asset | Confidentiality | Integrity | Availability | Impact |
1 | File Servers | 5 | 5 | 5 | Very High |
2 | Client/Customer Personal Information | 5 | 5 | 5 | Very High |
3 | Identifiable Details | 5 | 5 | 5 | Very High |
4 | Network Peripherals | 4 | 4 | 4 | High |
5 | Financial Information | 4 | 4 | 4 | High |
6 | Desktop/PDA/Mobile Phones | 4 | 4 | 4 | High |
7 | Staff | 4 | 4 | 4 | High |
8 | Controller/Processor/Third Party | 4 | 4 | 4 | High |
9 | Systems Application | 4 | 4 | 4 | High |
10 | Management | 3 | 3 | 4 | Medium |
11 | 3rd party (SLA) | 2 | 4 | 3 | Medium |
12 | Documents | 2 | 3 | 2 | Medium |
13 | Phone | 2 | 2 | 1 | Low |
14 | Printers | 2 | 2 | 1 | Low |
15 | Faxes | 2 | 1 | 1 | Very Low |
Figure 7: Information Asset Table
Risk Assessment Framework Approach
The assessment is an example of a systematic approach to an evaluation for any organization’s processes, technology tools and people that can safeguard or protect the personal Data.
Inherent Assessment | Residual Assessment | |||||||
Ref No | Risk Area | Risk Type | Impact | Likelihood | Mitigation | Impact | Likelihood | Treatment Plans |
R123 | People | Individuals not aware that their data is being processed | High
Breach that can lead to huge fine |
Medium | Communication plan to be developed to ensure compliance with GDPR | Medium | Low | Continuous development plan to ensure compliance. |
R124 | Technology/People | Unauthorised access or disclosure to external third party. | Medium | Low | Policies and procedures in place that prohibit information being retained after no longer required.
Technical Controls to secure information in transit and or the monitoring, detection, analysis, and process to correct intrusions. Mitigated by both Controller and processor maintaining an ongoing program of reviewing developing risk and threat vectors and scenarios regularly. |
Low | Low | Continuous Monitoring and looking at newer technology tools to ensure improvement in monitoring and adhering to good security standards.
Updating security and safety measures. |
Inherent Assessment | Residual Assessment | |||||||
Ref No | Risk Area | Risk Type | Impact | Likelihood | Mitigation | Impact | Likelihood | Treatment Plans |
R125 | Organization | Compliance to GDPR | High
This risk type not directly linked to incidents but highly important. |
Medium | Gain Compliance | Low | Low | Requires improvement on information security controls, access, encryption etc. | |
R126 | People/Technology | Risk of unauthorized modification of Client information,
Risk of data modification after email messages are sent or within systems applications. |
Medium | Low | User accounts and audit logs in place.
Users can only delete, archive to folders, or reply to messages. Protection against Man in the middle attack in place so contents cannot be modify in transit. All data via application in the database can only be modified by the database software itself or via app, process to monitor or prevent or log sql queries. |
Low | Low | Continuous improvement in technology and standards | |
R127 | Process/Technology |
|
Medium | Medium | Mitigating measures to ensure retention of the overall system configuration.
Onsite and offsite data backups with a stipulated retention period and discarded there after the expiry of retention period. |
Low | Low | Continuous improvement in the process technology. | |
R128 | Process | User access review | Low | Low | Regular review of user access to be performed and results documented | Low | Low | Requires quarterly review. | |
R129 | Technology | Breach of Network Peripheral | Medium | Medium | All network routers, gateway, cables secured | Low | Low | Continually updating and technology standards. | |
R130 | Technology | Threats and breach to Desktop/PDA/File server | Medium | Medium | Provide adequate security and encryption where possible | Low | Low | Regular review and documents to kept. |
Inherent Assessment | Residual Assessment | |||||||
Ref No | Risk Area | Risk Type | Impact | Likelihood | Mitigation | Impact | Likelihood | Treatment Plans |
R131 | Technology | Unavailability of Data and System failure or unauthorized destruction | Medium | Medium | Backup of data and systems is made and tested regularly. | Low | Low | Mirrored and Backup servers to be readily available |
R132 | Privacy and protection | Privacy and protection of personal information | High | Medium | Where personal information is involved should be protected to ensure compliance with applicable GDPR and contractual clauses | Low | Low | Continuously reviewed and improved. |
R133 | People/Technology | Privacy and security is not well understood by Staff | Medium | Low | Initial training in regards GDPR, appropriate use of the system, online training and a user handbook that contains privacy and basic security training. | Low | Low | Annual training program and other programs to educate staff. |
R132 | Technology | No ownership of assets | Low | Low | All data and systems to have designated ownership | Low | Low | Information to be kept in CMDB |
R134 | Technology | Database breach validation and checks | High | Low | Security and encryption of databases in place. Controls to be in place to validate and test backups. | Low | Low | Continual Monitory and improvement. |
R135 | Process/Technology | Static data creation & maintenance, risk of inappropriate access to systems | Low | Low | Unique logon and Complex passwords.
Regular password changes every month. |
Low | Low | Continual review of policy and comply with standards |
R136 | Technology | Technology security risk,
Data and messages. |
Medium | Low | Alteration, message duplication, replay, misrouting, Monitoring and Alert in operation. | Low | Low | Regularly reviewed and monitoring and alert to continually improve. |
R137 | Technology | Data exchange risk | Medium | Low | Policies and controls are in place to protect information exchanges between interconnected Systems. | Low | Low | Currently not an |
R138 | Technology | Privileged access and activity | Medium | Low | Process to log and monitor privileged and administrative system access | Low | Low | Real-time Alert required not just activity monitoring |
PIA Summary
In the table of above approach is the method used by this paper for assessing the impacts on privacy, the inherent impact and likelihood is before the mitigation and the residual impact and likelihood is the assessment after the mitigation with a further remedial actions as necessary in order to avoid or continuous effort to minimise negative impacts.
5.4 Prevention of Attacks
The GDPR stipulates the importance of preventing security breaches and recommends several techniques to prevent a successful attack, so this section is mainly at ways, processes and technology tools available to prevent attacks.
5.4.1 Privileged Users Review, Assessment and Control
The GDPR has indicated that privileged users access should be controlled, users with access to the Personal Data in order to prevent attacks from insiders.
As soon as personal data has been marked and identified, it is compulsory and important to then identify users within the organization, Data Subjects, Third Parties, Supervisory Authorities, and Recipients, including the administrators, privileged users who can not only access but also have ability to process the personal data.
Perform a user access review and document permissions, ensure that only privileges are granted access to perform their roles, sensitive and personal data should be hidden if not required to perform daily duties.
Review and Assessment should be done regularly, ideally quarterly or purchase a tool which can automate the process, there are tools in the market like The RSA Aveksa Identity Access Management and Governance tool, which can help big organizations to efficiently cope with the security and GDPR requirements, it is an automated tool and can provide evidence of compliance and also reduce access-related risk.
Privilege user accounts is the easiest and common ways to gain access to systems, applications and databases in order to get access to sensitive information. It is a good practice to regularly review and identify users with many privileges and those that don’t actually require or use their privileges, always review when last used, the process can indicate whether user’s access rights are correctly defined, remove excessive and replaced with required rights for users to perform their job.
Most hackers often use access rights to mimic users in order to gain access to sensitive information. So by reducing excessive rights can protect against malware attacks.
Organization should regularly carry out user access review rights to determine the appropriateness. “T-Mobile (2009) Sales staff were caught selling customer records to brokers who used the information to market them as their contracts were coming to an end. It was never clear how many records were involved in this murky insider trade but it was believed to run from half a million to millions. Initially the ICO refused to name the firm but was forced to after rival networks said they were not involved, leaving only one name.”(Dunn, 2017)
By performing user rights review could have reduced the risk by making sure that access privileges are granted on a need-to-know basis. The sales staff should not have had access to sensitive personal data if segregation of duty had been implemented.
5.4.2 Database Security and Threats
One of the most important asset of an organization is the database, and it is the most compromised assets, so it is critical to protect these crucial assets since they store personal and confidential data.
Hackers and malicious insiders are always looking to gain access to sensitive information, which they can use to damage your operations, steal and sell valuable data or inflict serious damage to your organization.
With the new GDPR, breaches almost certainly will result in heavy fines and legal fees.
Below are the most common security threats to databases:
- Excessive and Unused Privileges
- Misconfigured Databases – Exploitation
- Unmanaged Sensitive Data
- Input or SQL Injection
- Malware
- Privilege Abuse
- Weak Audit Trail
- Storage Media Exposure
- Lack of Security Expertise and Knowledge
- Denial of Service
Majority of databases come with many configuration parameters to suit a variety of security requirements. It is essential to ensure that your database configurations are secured and has not changed over time, so monitoring and alert should be mandatory when configurations are accessed which must be logged and reviewed regularly, best to adopt and enforces good set of best practices. Organizations should carry out automated regular checks for default account passwords, account status, and account profiles, if found they should be immediately changed as this are the easiest way to penetrate your databases.
Best practise for Database Security solutions are:
- Regular assessment and review to identify database vulnerabilities and critical data reside.
- Regular User rights management, identify excessive user rights for sensitive data.
- Real-time monitoring and blocking to protect databases from attacks and unauthorized access. Use firewall and isolate connection to permitted servers only.
- Regular auditing to demonstrate compliance with GDPR.
- Data protection to ensure data integrity and confidentiality.
- Understanding and regularly scan for vulnerabilities that are likely to expose databases to SQL injection.
- Patch your databases regularly as soon as it is released but adequate testing should be done before applying to your production databases.
- Avoid weak authentication rules that can enable an application-layer DoS attack.
- Purchase vulnerability assessment tools to detect security misconfigurations, vulnerabilities, and missing patches.
- Virtual patching can protect the database from exploit attempts until when patch is deployed in situations where the official patch has not been released for a detected high-risk vulnerabilities that can enable a Denial of Service or SQL injection attacks. “The Register can reveal the UK’s largest sports retail business was the subject of a digital break-in during September, when an attacker exploited public vulnerabilities affecting the unpatched version of the DNN platform that Sports Direct was using to run a staff portal.” (Martin, 2017)
- Use analytical tools to understand database risks.
- Review database discovery and classification results to determine which databases are used for storing sensitive data should be monitored.
- Once you have constructed a catalog of databases, it is critical to understand which databases contain sensitive data. Scan the objects, rows, and columns of databases to identify sensitive data.
To conclude on database security threats and best practice to protect from attacks or breaches, it is also a good approach to use data classification solutions that are aware of personal or identifiable information types such as credit cards, national identity numbers and email addresses.
By automatically identifying sensitive data and personally identifiable information should reduce the scope of GDPR security and compliance efforts.
Databases encryption: Sensitive data across different database environments should be encrypted. It provides organization ability to secure production and backup copies of databases, monitor the activities and control access to sensitive data from users who access databases at the operating system and storage level by utilizing SIEM tools like Splunk, database monitoring, auditing and alerting coupled with encryption can provide organizations with needed controls and security to monitor users both inside and outside of the database environment.
5.4.3 Encryption
Encryption is one of the core techniques to render data unintelligible to any person or group who are not authorized to access the personal data, so GDPR considers encryption as vital requirement in order to comply with the regulation.
The GDPR provides that in the event of a data breach, the Controller need not to notify data subjects if data is encrypted and rendered unintelligible to any person accessing it, thereby removing notification costs to the organizations.
TalkTalk received a record fine over data breach that led to data theft of 157,000 customers, the personal data of 156,959 customers including names, addresses, dates of birth, phone numbers and bank accounts were stolen.
“The cyber-attack in October last year exposed the latest security failure for the company, which was forced to admit it had not encrypted some personal details of customers.
The Information Commissioner’s Office (ICO) said the attack could have been prevented if TalkTalk had taken basic steps to protect customers’ information.” (Independent News)
“In order to maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected. In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed which may in particular lead to physical, material or non-material damage.” (Regulation, 27 April 2016)
Above statement should be a result of the PIA process carried out in earlier section 6.3.
In order to comply with the requirements of Article 32 of the GDPR for protecting personal data when transmitted, Implementation of strong database and network encryption such as AES and Transport Layer Security(TLS), provides security for organizations and controllers by prevent data loss, packet sniffing, replay and man-in-the-middle attacks.
5.4.4 Anonymization and Pseudonymization
Anonymization and pseudonymization are ways or techniques used by means of hiding the identity of a person and personal data or attributes that cannot be revealed or traced.
Anonymization is a way to prevent personal data being exposed in less secured or protected environments, such as removing client’s personal information before refreshing your test systems with production data or before shipping a copy of your data to an external party.“Kiddicare (2016) online child products retailer Kiddicare was forced to admit it had exposed real customer data when testing a new website in 2015. In this case, the mistake was only noticed when customers started receiving suspicious SMS text messages asking them to take an online survey and an investigation eventually uncovered to error. As with many UK breaches, the company played down the fact it had let names, addresses and contact details of up to 800,000 people fall into malevolent hands with the excuse that no credit card data had been compromised (which would have been its liability had it done so)” (Dunn, 2017)
The fact that sensitive personal data had been exposed here and this would have been considered as a serious breach and huge fine under the new GDPR, this is why the new regulation would streamline organizations like Kiddicare.
Pseudonymization is a procedure used by means of identifying data with algorithm, replaced by encrypted data know as pseudonym.
Article 32 of the GDPR recommends pseudonymization.
Pseudonymization can reduce attacks by preventing intentional or accidental exposure to sensitive information in systems. Major difficulties while implementing pseudonymization is the method or ways to link client or frontend systems queries to the database and transform the data back without affecting the front end systems or backend database.
Oracle came with a solution in their white paper
“Oracle Advanced Security – Data Redaction can help address this concern by providing selective, on-the-fly redaction of Personal Data in SQL query results before returning to the applications so that unauthorized users cannot view the data. It enables consistent redaction of database columns across application modules accessing the same database information. Oracle Data Redaction minimizes changes to applications because it does not alter actual data in internal database buffers, caches, or storage, while preserving the original data type and formatting when transformed data is returned to the application. Oracle Data Redaction has no impact on database operational activities such as backup and restore, upgrade and patch, and high availability clusters as no persistent data is changed. Unlike historical approaches that require making changes to applications or intercepting access to the database through a proxy, Oracle Data Redaction policies are enforced directly in the database kernel, resulting in tighter security and better performance. Oracle Data Redaction also allows the Controller to specify the conditions under which real data should be returned to the authorized Recipients. Oracle Database comes pre-installed with Data Redaction and can be easily enabled.”(RAJASEKHARAN, 2017)
5.4.5 Access Control-Defined Purpose Only
GDPR clearly indicated the need for controlling privileged users who have access to any Personal Data in order to prevent attacks from insiders and compromised user accounts.
This can be achieved by making sure that users are correctly assigned to the specific role and groups required within all applications and systems, with logging, monitoring and alerts enabled when personal data is being accessed, also Processor and any person who has access to personal data, shall not process those data except on instructions from the controller.
In addition to privileged user control, the GDPR recommends adopting a fine-grained access control methodology to ensure that the personal data is accessed selectively and only for a specific and designed reason, organizations should create a record, alerting and activity log with reasons and evidence of the need to access sensitive and personal data. This type of specific access control can help organizations minimize unauthorized access to personal data.
5.5 Monitoring
Traditional perimeter firewalls play an important role in protecting data centers from unauthorized, external access, but attacks have grown increasingly sophisticated bypassing perimeter security, taking advantage of trusted middle tiers, and even masquerading as privileged insiders. Surveys of numerous security incidents have shown that timely examination of audit data could have helped detect unauthorized activity early and reduce the resulting financial impact.
“An investigation by the ICO found hackers gained access to the database of details which TalkTalk had from its takeover of rival firm Tiscali via vulnerable web pages which it had not spotted. TalkTalk also avoided “two warnings” prior to the hack which should have alerted the firm to the problems with its software and data” (Rodionova, 2016) this was due to is lack of adequate security and monitoring that should have been in place for a firm of this magnitude.
GDPR mandates that organizations must maintain a record of its processing activities and audit records, also to report breaches on time.
Organization should purchase comprehensive auditing collection and reporting tool or have a mechanism to meet the monitoring requirements of GDPR.
5.6 Protection
5.6.1 Data Security by Design
The GDPR has mandated data protection by design and data protection by default,
Privacy-Data protection by design is based on premises of incorporating privacy features from the beginning of the design process instead of attempting to adopt it at a later stage when the process and technology is at full blown.
Privacy-Data protection by default is the default setting, the user is already protected against privacy risks.
“In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default.” (Regulation, 27 April 2016) By taking security into account during the initial stage of your design in any technology life cycle and the entire engineering process will increase the security suitability of the system and ensures that technical security controls will function as expected,
Privacy and protection features in technology are generally ignored by developers and controllers, this is mainly due to lack of awareness and understanding of implementation techniques or inadequate tools according to research paper carried out by European Union Agency for Network and Information Security (enisa), so how can this problem be solved? With the new GDPR, this deficiency is bound to change as we are more likely to see controllers and system developers and providers paying more attention to data protection by design.
Further recommendations on how this can be improved by enisa (George Danezis, 2014).
- Policy makers need to support the development of new incentive mechanisms for privacy friendly services and need to promote them.
- The research community needs to further investigate in privacy engineering, especially with a multidisciplinary approach. This process should be supported by research funding agencies. The results of research need to be promoted by policy makers and media.
- Providers of software development tools and the research community need to offer tools that enable the intuitive implementation of privacy properties.
- Especially in publicly co-founded infrastructure projects, privacy-supporting components, such as key servers and anonymising relays, should be included.
- Data protection authorities should play an important role providing independent guidance and assessing modules and tools for privacy engineering.
- Legislators need to promote privacy and data protection in their norms.
- Standardisation bodies need to include privacy considerations in the standardisation process.
- Standards for interoperability of privacy features should be provided by standardization bodies
5.6.2 Centralized Management and Comprehensive Security
The GDPR has a preference for centralising administration, it is deemed effective to manage activities across various systems and applications and it can help by taking effective resolution during an attack or a breach. Encryption keys ideally should be managed centrally.
“The main establishment of a controller in the Union should be the place of its central administration in the Union, unless the decisions on the purposes and means of the processing of personal data are taken in another establishment of the controller in the Union, in which case that other establishment should be considered to be the main establishment.” (Regulation, 27 April 2016)
Organizations must be ready and have a comprehensive security in place to prevent threats and attacks from various sources and in every direction and method. The GDPR stipulates that protection of personal data at every stage of a data lifecycle such as data in motion or static, so data must be encrypted in motion and when stored in database or static.
In order to minimise attacks and threats to data, all sources to the data must be protected and also vital to enforce security as close to the data, therefore everything from the OS, Network, Cable, Routers, Switches, File Server, Application, Printer, and Wi-Fi must be secured.
5.6.3 Data Loss Prevention – DLP
DLP is a vital tool for any organisation looking to comply with the GDPR security requirements, tools such as Intrusion Detection System and Intrusion Protection System are for anything that can pose a threat to an organization but DLP is mainly concerned in identifying sensitive data. It searches for contents that are defined as critical to an organization.
Detective control would provide visibility, preventive control is a necessity to
reduce data leaks by accidentally or intentionally.
DLP is a technology and tool that can enforce these policies effectively.
So many cases of sensitive data loss, where employees have taken data when they change jobs or to sell; example is a case of former HP employee, who took copies of IBM sensitive and confidential documents to HP just before he joined them whilst he had been employed by IBM and had access to this sensitive information, this type of incident could have been prevented by proper implementation of DLP and data would have been marked as sensitive.
Other types of data breach are corporate email, FTP, web mail, printing and other removable drives e.g. CD’s and USB. DLP would have flagged this activity.
Below is an example DLP device in operation.
LAN Traffic Telnet, FTP, SFTP, Mail, IM etc.
DLP Device
Figure 8: DLP Device in Operation
All traffic from local area network LAN via routers are automatically mirrored and searched by DLP device.
This provides visibility into many violations, if a sensitive file was transferred using FTP, there are several things that this will bring to light. FTP, a protocol that uses clear text should be a concern in transmitting sensitive files, FTP by default does not provide any security, ideally FTP should be blocked and only SFTP protocols to be allowed in any organization seeking a secured environment or willing to comply with GDPR security requirements. In addition, this leads to the question if this type of file should be transferred out of the company, then it will be verified if the people involved are permitted to view and send data. All this does not only apply to a single type of file, but any communication protocol used to communicate externally outside the organization.
While DLP is good for data in motion it is also capable of searching data at rest, for anything that holds data such as file servers, databases, data storage etc. Most DLP’s have features for discovering sensitive data on data depositories by utilizing the existing defined policy to look for any sensitive data.
During data discovery scanning, DLP also has capability to move the data to a specified secured location, should data found to be located on a non-secured or protective area, an excellent feature that mitigates the risk by migrating the data to a specified protected share.
Discovery scanning can also be useful to fingerprint data to be used for identifying unstructured data.
To summarize, DLP is a security countermeasure used to constantly search data on network for defined sensitive information and it has capability to be used as both monitoring and preventative measure.
5.7 Attack Methods and Testing
Type of attacks and what encryption method to use to defend against this attacks,
Some tests carried out using dsniff for MITM attacks.
Brute force attack using John the Ripper
Rainbow-table attack using Rainbow Crack
SQL Injection
A brute force attack is one of the more common types of attack that malicious people use to try and gain access to your servers, applications and data. In theory, a brute-force attack can be used to attempt to decrypt any encrypted data (except for data encrypted in an information-theoretically secure manner).
Attacks are relatively easy and simple for attackers to implement and they can wreak havoc on your organization when successful. However, many IT security teams may not be aware that they are at risk from these attacks, or what to do about them.
Purchase tools and systems that can deliver a solution to this attacks e.g. Unified Security Management (USM) approach.
Organization need to be proactive in Detecting and investigate these types of attacks.
– How attackers can use brute force attacks to gain access to network
– Steps you can take BEFORE an attack to identify systems or applications that may be at greater risk
5.8 DPA Vs GDPR
GDPR provides greater protection for personal data in many ways than the Data Protection Act and has led to many organizations reviewing their current data security strategies, processes and technology. Too many breaches under the current DPA over the years and these are mainly due to lack of the security requirements that are now being addressed in the new GDPR.
Below are the most recent and past data breaches:
- Payday Loan Company: Wonga (2017) – Large data breach that possibly could have impacted 245,000 of its customer’s personal information including bank account details.
- Mobile Network Operator: Three (November 2016) – Database was accessed using a Three staff login credential, believed to be 133,827 customer personal information was compromised.
- Sportswear retailer: Sports Direct (September 2016) – Attacker gained access through an unpatched content management system running on the open source DNN platform.
- British Supermarket Giant: Tesco Bank (2016) – 40,000 accounts had been compromised and half had money stolen from them.
- Human Resources software firm: Sage (2016) – Access to UK customer information via an internal login.
- Telecommunications Company: TalkTalk (2015) – Up to three data breach affected the company in under a year.
- Online Greeting Cards Company: Moonpig (2015) – A researcher gained access to records of any Moonpig account holder via a software flaw in the firm’s Android app.
- Online Holiday Company: Think W3 Limited (2014) – A hacker stole 1,163,996 credit and debit card records by using an SQL injection attack to exploit a weakness on its website. Described by ICO as a “staggering lapse” and the company was fined£150,000.
- Parenting Website: Mumsnet (2014) – An insider attack, the attacker published details of 100,000 employees.
- Search Engine Company: Yahoo (2013, 2014) – Two data breaches between 2013 and 2014.
- PlayStation Network: Sony (2011) The largest data breach in history and affected people across various regions, records of 77 million people relating to its playStation network, including a small number revealing credit card numbers was stolen.
There are too many breaches under the current DPA, the tradition physical robbery and Petty crimes have now shifted to online and these are also the contributing factors leading to these breaches which the current DPA has not managed to control. Non-compliance of GDPR will result in serious consequences such as those in Article 83 where a minor Infringement fine could cost €10 million or up to 2% of the organisation’s annual turnover of the preceding financial year, while serious data breach can result in fines of up to €20 million or up to 4% of the organization total annual turnover for the previous financial year.
6 Conclusion
It is important to plan early on how your organization will comply with the GDPR’s requirements, organizations should start implementing the controls as quick as possible and develop ways to achieve and adopt majority of suggested tools and approach in order to maintain a strong security for sensitive personal data and critical business data.
Educate your staff on risk mitigation techniques and how to recognize common threats and attacks such as spear-phishing.
Organizations with best practices around email and internet usage including good password management are less likely to be prone to attacks and closer to compliance with the GDPR requirements.
Inability to enforce staff training and implementation of security conscious employee culture can lead to endless possibilities of security breaches.
Going by the survey carried out, academic and media review, reveals that GDPR has impacted big organizations considering the cost of non-compliance that could be extremely expensive and possibly damaging if a major security breach occurs.
7 Bibliography
Andy Taylor, D. A. (2015). Procedural and People Security Controls. In D. A. Andy Taylor, Information Security Management Principles, Second Edition (p. Page 87). London: BCS.
C T Di Iorio, F. C. (2009). Privacy impact assessment in the design of transnational public health information systems. The BIRO project.
Dunn, J. E. (2017, April 10). The UK’s 19 most infamous data breaches. Retrieved from TechWorld: http://www.techworld.com/security/uks-most-infamous-data-breaches-3604586/
Fisher, J. (2015). Top Ten Database Security Threats 2015. Top Ten Database Security Threats The Most Significant Risks of 2015 and How to Mitigate Them.
Gary, T. (July 11th, 2016). Four Reasons the EU General Data Protection Regulation is Important to Security.
George Danezis, J. D.-F.-H. (2014). Privacy and Data Protection by Design. from policy to engineering.
IGA. (2015). Privacy Impact Assesment Template.
Koops, B.-J. (2014). The Trouble with European. The Trouble with European.
Lomas E, N. U. (2014). Section 2: Practice. Part 2: Risk Management. Information governance, management and security.
Martin, A. J. (2017, February 8). Sports Direct hacked last year, and still hasn’t told its staff of data breach. Retrieved from TheARegister: https://www.theregister.co.uk/2017/02/08/sports_direct_fails_to_inform_staff_over_hack_and_data_breach/
Michael Colesky, J.-H. H. (2015). A Critical Analysis of Privacy Design Strategies. A Critical Analysis of Privacy Design Strategies.
Olof Nyre´n, M. S. (2014). The European Parliament proposal for the new EU GDPR Protection Regulation may restrict European epidemiological research. The European Parliament proposal for the new EU GDPR Protection Regulation may restrict European epidemiological research.
RAJASEKHARAN, D. (2017). Using Oracle Database Security Products. ACCELERATE YOUR RESPONSE TO THE EU GENERAL DATA PROTECTION REGULATION USING ORACLE DATABASE SECURITY PRODUCTS.
Regulation, G. D. (27 April 2016). Official Journal of the European Union. REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL, 53-54.
Rodionova, Z. (2016, October 5). TalkTalk given record fine over data breach that led to data theft of nearly 157,000 customers. Retrieved from Independent: http://www.independent.co.uk/news/business/news/talktalk-fine-data-breach-theft-customers-information-stolen-record-penalty-a7346316.html
Shams Zawoad, R. H. (26 Feb 2013). Cloud Forensics: A Meta-Study of Challenges, Approaches, and Open Problems .
Treasury, H. (2004). Management of Risk – Principles and Concepts. The Orange Book, 29.
Trinder, G. (2008, March 12). microsoft-standards-for-information-security-management. Retrieved December 14, 2015, from MSDN: http://blogs.msdn.com/b/apinedo/archive/2007/05/09/microsoft-and-the-as-7799-iso-17799-standards-for-information-security-management.aspx
Union, O. J. (2016). on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL.
8 Appendices
Appendix A
Cite This Work
To export a reference to this article please select a referencing stye below:
Related Services
View allRelated Content
All TagsContent relating to: "Business"
The term Business relates to commercial or industrial activities undertaken to realise a profit including producing or trading in products (goods or services). A general business studies degree could cover subjects such as accounting, finance, management and increasingly, entrepreneurship.
Related Articles
DMCA / Removal Request
If you are the original writer of this dissertation and no longer wish to have your work published on the UKDiss.com website then please: