The California Consumer Privacy Act of 2018 still doesn’t have either the public awareness nor the multi-year time to prepare as the EU’s GDPR.
Nonetheless, it will have a similarly huge significant impact on organizations that do business in the state of California.

Why should you care? Well California is the world’s fifth-largest economy, so that means it affects pretty much everyone.
Businesses – including yours- have less than two years until the January 2020 compliant deadline

Organizations are constantly at risk of paying a hefty penalty for not complying with rules and regulations that dictate how they should operate and do business.
A recent research by the Ponemon Institute and GlobalScape entitled, “The True Cost of Compliance with Data Protection Regulations” concluded that the average cost of non-compliance is now $14.82 million annually (a 45 percent increase from 2011) and is 2.71 times higher than the cost of compliance.

This means organizations are better off making the necessary investments on people, process and technology to comply with Data Protection regulations than incurring the cost of non-compliance. It’s clear that the topic of compliance is broader than just Data Protection regulations and covers other global and regional regulations, industry-specific mandates and trading partner specific contracts.

The worry is conflicting standards and how to stay abreast of everything. Colorado is also bringing out similar legislation. The UAE has also signalled that it may follow GDPR. This major implications for companies in areas of contract, insurance of liability, training, master data management, software security, encyrption, back up, policies, administration …… and a lot more cost. This not going away and it easier to start now – a plan t0 shut the stable door only after the horse has bolted is not a strategy,

An even stricter privacy law, known as ePrivacy Regulation, is currently pending abroad. The law, was approved in the last quarter of 2017 by the European Parliament and is currently under review by the Council of the European Union. While the policymakers had hoped that the ePrivacy Regulation would enter into force on GDPR Day, this obviously didn’t happened. In a nutshell, the ePrivacy Regulation is lex specialis to the General Data Protection Regulation (“GDPR”). While the GDPR applies to all categories of personal data—hard copy and electronic—the ePrivacy Regulation will typically only apply to electronic communications data, a subset. The Regulation, if adopted, would cover not only traditional telecommunications operators and providers of electronic communication services but also “over-the-top” communications services

It requires explicit consent from users for all messaging services—things like Apple’s iMessage, Facebook’s WhatsApp, and Microsoft’s Skype—before companies can place tracking codes on their devices or collect data about their electronic communications. In other words, a company could only collect data or metadata about users’ communications online when they get their explicit consent to use it for a specific purpose. When someone declines to share their data, companies will be required to provide them with the same service as someone who consents. The law was scheduled to go into effect this year, but has been held up by negotiations. https://iapp.org/resources/article/eprivacy-regulation-may-2018-draft/

The ePrivacy regulation is an update to the standing ePrivacy Directive, which was originally put into place to guarantee “right to privacy in the electronic communication sector,” according to the directive. The directive originally focused mainly on email and SMS messages, but the proposed regulation would also address data privacy in services like WhatsApp, Facebook Messenger, and Skype, along with Internet of Things (IoT) devices.
Additionally, the ePrivacy regulation will also protect metadata associated with electronic communications .

ePrivacy includes non-personal data. GDPR is laser-focused on the protection of personal data, but the ePrivacy regulation is focused more broadly on the confidentiality of communications, “which may also contain non-personal data and data related to a legal person,” the proposal states. The original ePrivacy Directive is often referred to as the “cookie law” because it imposed the need for informed consent before a firm could track an internet user with cookies. The regulation will add new clarifications and simplifications for the consent rule, along with other new tools for protecting against unwanted communication tracking and more.

Both GDPR and the proposed ePrivacy regulation reflect similar aspects of privacy, but they do so from the perspective of different legal charters. The basis for the ePrivacy regulation are Article 16 and Article 114 of the Treaty on the Functioning of the European Union. However, it also reflects part of Article 7 of the Charter of Fundamental Rights: “Everyone has the right to respect for his or her private and family life, home and communications.” GDPR, on the other hand, is based on Article 8 of the European Charter of Human Rights, which states: “Everyone has the right to respect for his private and family life, his home and his correspondence.” However, for ePrivacy, the proposal notes that the meaning and scope of Article 7 of the Charter of Fundamental Rights shall be regarded in the same way as Article 8 from the European Charter of Human Rights

Consent is just one of six lawful grounds for processing data under GDPR. If one of the other five grounds applies, consent might not be required.

The other five legal grounds are:
•Processing being required to fulfil a contract with a data subject.
•Having a legal obligation, the fulfilment of which requires you to process user data.
•Needing to process data to protect someone’s life.
•Processing being required to carry out a task in the public interest.
•Requiring data processing in order to protect your legitimate interests, or those of a third party (unless those interests clash with a good reason to protect user data).

If none of these other grounds applies then, clear consent must be given to process personal data for each specific purpose.

How you ask for consent forms a big part of the regulation. It must be presented with these features:
• Unbundled: No lumping consent for one usage of data in with another. This is particularly relevant to collecting data for marketing.
• Active opt-in: No pre-ticked boxes, with binary in/out options given the same prominence.
• Granular: Each type of data usage needs to be consented to separately.
• Named: All organisations involved in handling the data being collected must be listed by name, especially third-parties.
• Easy to withdraw: Withdrawing consent needs to be at least as easy as giving it.

British Airways disclosed on Sept. 7 that it was the victim of a data breach that exposed details on 380,000 customers. The breach involved data from British Airways’ mobile application and website at ba.com. The airline noted in its advisory that stolen data did not include customers’ passport information or travel details. However, hackers stole names, addresses and payment card details of customers who used the British Airways website or mobile app between Aug. 21 and Sept. 5. To its credit BA respond promptly and apologized.

“We are investigating, as a matter of urgency, the theft of customer data from our website and our mobile app, The airline has guaranteed that financial losses suffered by customers directly because of the theft of this data from British Airways will be reimbursed, and is recommending that customers contact their bank or card provider if they made a booking or change to their booking between 22:58 BST August 21 2018 and 21:45 BST September 5 2018.” British Airways wrote in an advisory post.

The British Airways breach is the second in as many weeks that has involved a major international airline. On Aug. 29, Air Canada reported that its mobile app was breached, potentially exposing 1.7 million accounts to risk. Air Canada, however, estimated that information on only 20,000 customers accounts was stolen in the breach, which is thought to have taken place between Aug. 22-24.

The British Airways breach is potentially the first major test for the European Union’s General Data Protection Regulation (GDPR), which has strict requirements on disclosure of breaches, and non-compliance that could result in costly financial penalties.

RiskIQ detected the use of a script associated with a “threat group” RiskIQ calls Magecart. the same set of actors believed to be behind a recent credit card breach at Ticketmaster UK. The Ticketmaster UK breach was the result of JavaScript injected through a third-party service used by the Ticketmaster website, but the British Airways breach was actually the result of a compromise of BA’s own Web server, according to the RiskIQ analysis.
This skimmer is attuned to how British Airways’ payment page is set up, which tells us that the attackers carefully considered how to target this site in particular.
The suspect scripts were detected based on a daily crawl of websites conducted by RiskIQ, which gathers data on more than two billion pages a day. Focusing on how the scripts on the BA site changed over time, the RiskIQ researchers found a modified script within the BA site. Code added to a JavaScript library utilized by the BA site called an API on a malicious Web server at baways.com—a virtual private server hosted by a provider in Lithuania, using a TS certificate registered through Comodo (apparently to raise its appearance of legitimacy) on August 15.

The 22 lines of code are targeted to export the data entered in the BA website’s payment form to the malicious server when the “submit” button was clicked by a customer, with the data being sent as a JSON object. As a result, the transaction would go through for the customer without any errors, while the attackers received a full copy of the customer’s payment information despite the payment apparently being over a secure session. The attackers also added a “touchend” callback to the script, which made the attack functional for users of BA’s mobile app—which called the same, modified script.

While the modified script file’s timestamp matches with the beginning of the attack reported by British Airways, the registration date for the malicious site’s certificate, indicates that the attacker] likely had access to the British Airways site before the reported start date of the attack on August 21st—possibly long before. Without visibility into its Internet-facing web assets, British Airways were not able to detect this compromise before it was too late.

British Airways did not comment on the RiskIQ report, as a criminal investigation is still underway.