Preparing for the General Data Protection Regulation (GDPR)

12 steps to take now towards GDPR compliance

The General Data Protection Regulation (GDPR) was on track to come into force in the UK on 25 May 2018 but the result of the June 2016 referendum on membership of the EU now means that the Government needs to consider the impact on the GDPR.

When implemented in the EU, the GDPR will be relevant for many organisations in the UK especially those operating internationally. The GDPR has several new features – such as breach notification and data portability.

With so many businesses and services operating across borders, international consistency around data protection laws and rights is crucial both to businesses and organisations and to consumers and citizens.

1. Awareness

You should make sure that decision makers and key people in your organisation are aware that the law is changing to the GDPR. They need to appreciate the impact this is likely to have and find areas that could cause compliance problems under the GDPR. It would be useful to start by looking at your organisation’s risk register, if you have one.

Implementing the GDPR could have significant resource implications, especially for larger and more complex organisations. You should particularly use the first part of the GDPR’s two-year lead-in period to raise awareness of the changes that are coming. You may find compliance difficult if you leave your preparations until the last minute.

2. Information you hold

You should document what personal data you hold, where it came from and who you share it with. You may need to organise an information audit, across the organisation, or within particular business areas.

The GDPR updates rights for a networked world. For example, if you have inaccurate personal data and have shared this with another organisation, you will have to tell the other organisation about the inaccuracy so it can correct its own records. You won’t be able to do this unless you know what personal data you hold, where it came from and who you share it with. You should document this. Doing this will also help you to follow the GDPR’s accountability principle, which requires organisations to be able to show how they comply with the data protection principles, such as by having effective policies and rules in place.

3. Communicating privacy information

You should check your current privacy notices and put a plan in place for making any necessary changes in time for GDPR implementation. When you collect personal data you now have to give people certain information, such as your identity and how you intend to use their information. This is usually done through a privacy notice. Under the GDPR there are some extra things you will have to tell people. For example, you will need to explain your legal basis for processing the data, your data retention periods and that people have a right to complain to the Information Commissioner’s Office if they think there is a problem with the way you are handling their data. Note that the GDPR requires the information to be provided in concise, easy to understand and clear language.

4. Individuals’ rights

You should check your procedures to make sure they cover all the rights people have, including how you would delete personal data or give data electronically and in a commonly used format.

The main rights for people under the GDPR will be:

  • subject access,
  • to have inaccuracies corrected,
  • to have information erased,
  • to prevent direct marketing,
  • to prevent automated decision-making and profiling, and
  • data portability.

The rights people will enjoy under the GDPR are the same as those under the DPA but with some significant enhancements. If you are geared up to give people their rights now, then the transition to the GDPR should be relatively easy. This is a good time to check your procedures and to work out how you would react if someone asks to have their personal data deleted, such as – Would your systems help you to find and delete the data? Who will make the decisions about deletion?

The right to data portability is new. This is an enhanced form of subject access where you have to give the data electronically and in a commonly used format. Many organisations will already offer the data in this way, but if you use paper print-outs or an unusual electronic format, now is a good time to revise your procedures and make any necessary changes.

5. Subject access requests

You should update your procedures and plan how you will handle requests within the new timescales and give any more information.

The rules for dealing with subject access requests will change under the GDPR. In most cases you will not be able to charge for complying with a request and normally you will have just a month to comply, rather than the current 40 days. There will be different grounds for refusing to comply with subject access request – manifestly unfounded or excessive requests can be charged for or refused. If you want to refuse a request, you will need to have policies and procedures in place to demonstrate why the request meets these criteria.

You will also need to provide some additional information to people making requests, such as your data retention periods and the right to have inaccurate data corrected. If your organisation handles a large number of access requests, the impact of the changes could be considerable so the logistical implications of having to deal with requests more quickly and provide additional information will need thinking through carefully. It could ultimately save your organisation a great deal of administrative cost if you can develop systems that allow people to access their information easily online. Organisations should consider conducting a cost/benefit analysis of providing online access.

6. Legal basis for processing personal data

You should look at the various types of data processing you carry out, identify your legal basis for carrying it out and document it.

Many organisations will not have thought about their legal basis for processing personal data. Under the current law this does not have many practical implications. However, this will be different under the GDPR because some individuals’ rights will be modified depending on your legal basis for processing their personal data. The most obvious example is that people will have a stronger right to have their data deleted where you use consent as your legal basis for processing.

You will also have to explain your legal basis for processing personal data in your privacy notice and when you answer a subject access request. The
legal bases in the GDPR are broadly the same as those in the DPA so it should be possible to look at the various types of data processing you carry out and to identify your legal basis for doing so. Again, you should document this in order to help you comply with the GDPR’s ‘accountability’ requirements.

7. Consent

You should review how you are seeking, obtaining and recording consent and whether you need to make any changes.

Like the The Data Protection Act 1998 (DPA), the GDPR has references to both ‘consent’ and ‘explicit consent’. The difference between the two is not clear given that both forms of consent have to be freely given, specific, informed and unambiguous. Consent also has to be a positive indication of agreement to personal data being processed – it cannot be inferred from silence, pre-ticked boxes or inactivity. If you rely on individuals’ consent to process their data, make sure it will meet the standards required by the GDPR. If not, alter your consent mechanisms or find an alternative to consent.
Note that consent has to be verifiable and that individuals generally have stronger rights where you rely on consent to process their data.

The GDPR is clear that controllers must be able to demonstrate that consent was given. You should therefore review the systems you have for recording consent to ensure you have an effective audit trail.

8. Children

You should start thinking now about putting systems in place to verify individuals’ ages and to gather parental or guardian consent for the data
processing activity.

For the first time, the GDPR will bring in special protection for children’s personal data, particularly in the context of commercial internet services
such as social networking. In short, if your organisation collects information about children – in the UK this will probably be defined as anyone under 13 – then you will need a parent or guardian’s consent in order to process their personal data lawfully. This could have significant implications if your organisation aims services at children and collects their personal data. Remember that consent has to be verifiable and that when collecting children’s data your privacy notice must be written in language that children will understand.

9. Data breaches

You should make sure you have the right procedures in place to detect, report and investigate a personal data breach.

Some organisations are already required to notify the ICO (and possibly some other bodies) when they suffer a personal data breach. However, the GDPR will bring in a breach notification duty across the board. This will be new to many organisations. Not all breaches will have to be notified to the ICO – only ones where the individual is likely to suffer some form of damage, such as through identity theft or a confidentiality breach.

You should start now to make sure you have the right procedures in place to detect, report and investigate a personal data breach. This could involve assessing the types of data you hold and documenting which ones would fall within the notification requirement if there was a breach. In some cases you will have to notify the individuals whose data has been subject to the breach directly, for example where the breach might leave them open to financial loss. Larger organisations will need to develop policies and procedures for managing data breaches – whether at a central or local level. Note that a failure to report a breach when required to do so could result in a fine, as well as a fine for the breach itself.

10. Data Protection by Design and Data Protection Impact Assessments

Data Privacy Impact Assessments (DPIAs) are a tool which can help organisations identify the most effective way to comply with their data protection obligations and meet individuals’ expectations of privacy. An effective DPIA will allow organisations to identify and fix problems at an early stage, reducing the associated costs and damage to reputation which might otherwise occur. DPIAs are an integral part of taking a privacy by design approach.

DPIAs can link to other organisational processes such as risk management and project management. You should start to assess the situations where it
will be necessary to conduct a DPIA. Who will do it? Who else needs to be involved? Will the process be run centrally or locally?

It has always been good practice to adopt a privacy by design approach and to carry out a privacy impact assessment as part of this. A privacy by
design and data minimisation approach has always been an implicit requirement of the data protection principles. However, the GDPR will
make this an express legal requirement.

You do not always have to carry out a DPIA but it is required in high-risk situations, for example where a new technology is being deployed or where a profiling operation is likely to significantly affect individuals. Where a DPIA indicates high risk data processing, you will be required to consult the ICO to seek its opinion as to whether the processing operation complies with the GDPR.

11. Data Protection Officers

You should designate a Data Protection Officer, if required, or someone to take responsibility for data protection compliance and assess where this
role will sit within your organisation’s structure and governance arrangements.

The GDPR will require some organisations to designate a Data Protection Officer (DPO), for example public authorities or ones whose activities involve the regular and systematic monitoring of data subjects on a large scale. The important thing is to make sure that someone in your
organisation, or an external data protection advisor, takes proper responsibility for your data protection compliance and has the knowledge, support and authority to do so effectively. Therefore you should consider now whether you will be required to designate a DPO and, if so, to assess
whether your current approach to data protection compliance will meet the GDPR’s requirements.

12. International

If your organisation operates internationally, you should determine which data protection supervisory authority you come under.

The GDPR contains quite complex arrangements for working out which data protection supervisory authority takes the lead when investigating a complaint with an international aspect, for example where a data processing operation affects people in a number of Member States. Put simply, the lead authority is determined according to where your organisation has its main administration or where decisions about data processing are made. In a traditional headquarters (branches model), this is easy to determine. It is more difficult for complex, multi-site companies where decisions about different processing activities are taken in different places. In case of uncertainty over which supervisory authority is the lead for your organisation, it would be helpful for you to map out where your organisation makes its most significant decisions about data processing. This will help to determine your ‘main establishment’ and therefore your lead supervisory authority.

IOT Security

IoT Attack Surface Areas

IoT Attack Surface Areas
Attack Surface Vulnerability
Ecosystem (general)
  • Interoperability standards
  • Data governance
  • System wide failure
  • Individual stakeholder risks
Ecosystem Access Control
  • Implicit trust between components
  • Enrolment security
  • Decommissioning system
  • Lost access procedures
Device Memory
  • Cleartext usernames
  • Cleartext passwords
  • Third-party credentials
  • Encryption keys
Device Physical Interfaces
  • Firmware extraction
  • User CLI
  • Admin CLI
  • Privilege escalation
  • Reset to insecure state
  • Removal of storage media
  • Tamper resistance
  • Debug port
  • Device ID/Serial number exposure
Device Web Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
Device Firmware
  • Hardcoded credentials
  • Sensitive information disclosure
  • Sensitive URL disclosure
  • Encryption keys
  • Encryption (Symmetric, Asymmetric)
  • Firmware version display and/or last update date
  • Backdoor accounts
  • Vulnerable services (web, ssh, tftp, etc.)
  • Security related function API exposure
  • Firmware downgrade
Device Network Services
  • Information disclosure
  • User CLI
  • Administrative CLI
  • Injection
  • Denial of Service
  • Unencrypted Services
  • Poorly implemented encryption
  • Test/Development Services
  • Buffer Overflow
  • UPnP
  • Vulnerable UDP Services
  • DoS
  • Device Firmware OTA update block
  • Replay attack
  • Lack of payload verification
  • Lack of message integrity check
Administrative Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
  • Security/encryption options
  • Logging options
  • Two-factor authentication
  • Inability to wipe device
Local Data Storage
  • Unencrypted data
  • Data encrypted with discovered keys
  • Lack of data integrity checks
  • Use of static same enc/dec key
Cloud Web Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
  • Transport encryption
  • Insecure password recovery mechanism
  • Two-factor authentication
Third-party Backend APIs
  • Unencrypted PII sent
  • Encrypted PII sent
  • Device information leaked
  • Location leaked
Update Mechanism
  • Update sent without encryption
  • Updates not signed
  • Update location writable
  • Update verification
  • Update authentication
  • Malicious update
  • Missing update mechanism
  • No manual update mechanism
Mobile Application
  • Implicitly trusted by device or cloud
  • Username enumeration
  • Account lockout
  • Known default credentials
  • Weak passwords
  • Insecure data storage
  • Transport encryption
  • Insecure password recovery mechanism
  • Two-factor authentication
Vendor Backend APIs
  • Inherent trust of cloud or mobile application
  • Weak authentication
  • Weak access controls
  • Injection attacks
  • Hidden services
Ecosystem Communication
  • Health checks
  • Heartbeats
  • Ecosystem commands
  • Deprovisioning
  • Pushing updates
Network Traffic
  • LAN
  • LAN to Internet
  • Short range
  • Non-standard
  • Wireless (WiFi, Z-wave, Zigbee, Bluetooth)
  • Protocol fuzzing
Authentication/Authorization
  • Authentication/Authorization related values (session key, token, cookie, etc.) disclosure
  • Reusing of session key, token, etc.
  • Device to device authentication
  • Device to mobile Application authentication
  • Device to cloud system authentication
  • Mobile application to cloud system authentication
  • Web application to cloud system authentication
  • Lack of dynamic authentication
Privacy
  • User data disclosure
  • User/device location disclosure
  • Differential privacy
Hardware (Sensors)
  • Sensing Environment Manipulation
  • Tampering (Physically)
  • Damaging (Physically)

What’s DDoS?

How to 301 Redirect All Requests on Google App Engine

We need two files to set this up:

app.yaml is the configuration file for the app.
main.py is a redirect script.

app.yaml

application: your-app-name
version: 1
runtime: python27
api_version: 1
threadsafe: no

handlers:
– url: /.*
script: main.app

main.py

import webapp2

class MainPage(webapp2.RequestHandler):
def get(self):
self.redirect(“https://yourwebsite.com”, permanent=True)

app = webapp2.WSGIApplication([
(‘/.*’, MainPage),
], debug=True)

SEO Security

SEO Security