Search Results for: NS0-404 Schulungsunterlagen 🩱 NS0-404 Fragen&Antworten 🍕 NS0-404 Zertifikatsfragen 🚋 ➠ www.itzert.com 🠰 ist die beste Webseite um den kostenlosen Download von ⮆ NS0-404 ⮄ zu erhalten 🦗NS0-404 Fragen Antworten

Posted
By

Procurement says SAS70;
Finance says SSAE 16;
Audit says SOC 2;
IT says ISO27001;
Supplier says pay, pay, pay.
But there’s one fact That no one knows . . .

WHAT DOES THE SOX SAY?

Any negotiation for cloud and outsourced services undoubtedly ends up in a debate over what audits are appropriate, what are required, and who will pay for them. With numerous stakeholders, the business owner is often left with a cacophonous chorus of meaningless “gering-ding-dingeringeding” and “Joff-tchoff-tchoff.” So, from the lawyers perspective, let’s try to sort out what each of the audits are, which ones are required by or helpful for compliance with Sarbanes-Oxley and other laws, and where they might be appropriate.

As relevant here, the Sarbanes-Oxley Act of 2002 (SOX) relates to the accuracy of reporting of a company’s financials. Among other things, SOX requires the CEO to sign off on those financials. Because in most enterprises the CEO is not able to personally track the entire financial reporting process, companies have implemented controls that allowed the CEO and other executives to be confident in the financials (thereby also protecting the investing public). The Statement on Accounting Standards No. 70 (SAS-70) audit grew up against this backdrop as an audit to validate that sufficient controls are in place to enable accurate financial reporting.

SAS-70 audits came in two flavors: Type I, validating that controls are in place; and Type II, validating that those controls are actually applied.

As outsourcing (and later cloud) grew in parallel with this trend, customers were rightly focused on being sure that the functions outsourced to the supplier were governed by adequate controls. Thus, it became common practice to require that a supplier provide a SAS-70 for the outsourced services. Of course, everyone got so focused on requiring SAS-70s and arguing over who would pay, that the industry lost focus on the relatively narrow scope of the SAS-70. Soon, the SAS-70 became a proxy for a ensuring the quality of many areas of the service that had nothing to do with financial controls. Customers demanded SAS-70s without focus on what they were offering, and Suppliers trotted out SAS-70s to avoid the more robust conversations about other audits that might be appropriate.

In June, 2011, the American Institute of CPAs (AICPA) replaced the SAS-70 with a SOC (Service Organization Controls) 1 Audit (also known as an SSAE 16 audit), in part to conform to the requirements of the international standard covering the same financial controls–the ISAE 3402. Just like the SAS-70, the SOC 1 (SSAE 16) covers only financial controls. Similarly, the SOC 1 comes in the same Type I and Type II varieties. Where it was appropriate in the past to use a SAS-70, it is now appropriate to use a SOC 1. Where it was inappropriate to use the SAS-70, it is still inappropriate to use a SOC 1 (which has become the most common offering by the supplier community).

However, with the SOC 1, also came the SOC 2. The SOC 2 audit goes beyond financial controls and covers the following areas: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Sounds perfect for cloud and outsourcing agreements. Of course, these audits only cover the principles that are included within the scope of the audit–that is, you can have a SOC 2 that covers any or all of the foregoing areas. Also, SOC 2 audits can be burdensome to complete, and have a price tag that is often not borne readily by the supplier (although in some industries, a supplier may voluntarily undertake a SOC 2 so as to avoid custom audit requests from its customers). Like SOC 1, the SOC 2 also comes in Type I (controls are in place) and Type II (controls are being followed).

But that’s not all. The AICPA did not stop with 2 SOCs (which rhymes with, but should not be confused with, SOX). The SOC 3 is typically applicable in website context and can be applied as a seal on a website. Because this is less commonly implicated in cloud and outsourcing transactions, we will defer further discussion of the SOC 3.
Finally, in addition to all of the audits created by the auditors, there are also standards from the technology side. Most notably, the ISO 27001 provides standards (against which one can be audited) that include 11 standards relevant to IT (e.g., security policies, asset management).

When listening to multiple voices about what audit applies, typically the auditors voice may be controlling, but even then, the auditors need to be armed with the deal context that only the business can provide so that they give real and meaningful answers, rather than knee-jerk answers (that may tend toward over-inclusion with a cost implication).

With thanks to Ylvis for inspiring us with “What Does the Fox Say.”

Posted
By

As many who have struggled to find a clear way to comply will know, an important change to the EU E-Privacy Directive (implemented by many EU states late 2011/2012) meant that, in summary, websites which target/monitor/profile Europeans have been obliged to seek consent to use cookies via an opt in mechanism. However, given each member state was left to its own devices to implement this change at a national level and given some fierce lobbying by business to try to avoid strict “I agree” mechanisms, this has meant that a range of approaches have been taken to what precisely constitutes opt in consent, with some regulators (e.g. the Dutch) taking a more literal interpretation of the Directive, whilst others (e.g. the English) taking a much more liberal approach.

This patchwork approach across Europe has caused serious headaches for those conducting e-business in multiple EU countries., A compliance mechanism could be acceptable for one country, only to be slapped down (or worse, risk a fine) in another.

In an attempt to clear up some of the confusing and often contradictory views, the Article 29 Working Party, a body made up of the EU’s data protection regulators, released a new guidance note on 14th October 2013.

It recommends that all of the following elements should be included:

  1. Specific information should be provided in any cookie notice;
  2. Prior consent should be obtained before cookies are set;
  3. There should be an indication of wishes expressed by active behavior; and
  4. There should be an ability to choose freely.

The kicker here is the Working Group’s emphasis on the need for a user’s”positive action or other active behaviour“. In what sounds like the death knell for some existing techniques, the Working Party considers that an “immediately visible notice that cookies are being used or a notice that by further browsing on the website, the user agrees to the cookies being set“, although helpful, would be unlikely to constitute valid consent.

Those using cookies should, therefore: (1) not assume compliance because your site mirrors what other sites are doing (they may well be non-compliant) (2) note the compliance goalposts are shifting again and (3) urgently review their opt-in mechanisms and wording.

Posted
By

We previously reported on the Massachusetts computer services tax that became effective on July 31st after the legislature overturned Governor Deval Patrick’s veto of An Act Relative to Transportation Finance. Facing strong opposition from the state’s technology sector the Massachusetts legislature retroactively repealed the tax by passing An Act Repealing the Computer and Software Services Tax, which was signed into law on September 27th. Now, customers who paid the repealed tax should take steps to ensure they are promptly repaid or credited the appropriate amount by their vendors.

The Massachusetts Department of Revenue (DOR) has issued guidance to vendors regarding how to address the repeal. If a vendor collected but did not remit the taxes to the Massachusetts DOR, it is required to make reasonable efforts to return the taxes to the customers from whom they were collected. If a vendor collected and remitted the taxes to the Massachusetts DOR, the vendor may file an abatement application. Vendors should be keenly aware that abatement applications related to the repealed computer services tax are due by December 31, 2013. Furthermore, although Vendors may repay or credit customers prior to receiving an abatement, they must do so “within 30 days of receiving said abatement.” Although the Massachusetts DOR guidance is helpful, Vendors should consult their tax attorneys to determine their particular obligations.

Customers may consider reviewing applicable invoices for periods (a) from July 31, 2013 through September 27, 2013 to determine the repayment or credit amount they are owed, if any, and (b) after September 27th to ensure the vendors have updated their invoicing practices to account for the repeal. Customers should then contact their applicable vendors to ensure they are promptly repaid or credited the appropriate amount. If a vendor already remitted the taxes to the Massachusetts DOR, the customer should encourage the vendor to promptly file an abatement application. If the vendor resists, the customer may want to review the agreement between the parties to determine whether the vendor has a contractual duty to comply with the request. Last, customers should be aware that if (i) a vendor repays or credits a customer after filing an abatement application and (ii) the government’s refund to the vendor is delinquent, then the customer is entitled to any interest earned from the government.

Posted
By

October 1st marked the beginning of open enrollment for the federal and state health care exchanges (“Exchanges”) created to comply with the Affordable Care Act (“ACA”) of 2010, commonly referred to as Obamacare. The creation of the state and federal exchanges was and is a massive undertaking, involving the “unprecedented task of linking databases maintained by insurance companies, [and] states and federal agencies, including the Internal Revenue Service.” (“Obamacare Web sites see much interest, some glitches”, The Washington Post, October 2, 2013).

As anyone who has been involved in large scale IT projects knows, these types of projects invariably encounter glitches before they work smoothly, and the health insurance Exchanges are no exception. Many users of these Web sites encountered error messages or experienced significant delays when they tried to access the Exchanges to research their health insurance options.

Federal and state health officials initially blamed the delays on higher-than expected site traffic, and pointed out that any new technology is going to have errors at first that need to be corrected. But the Exchanges have been up and running for over three weeks now and issues remain, particularly with the federal exchange HealthCare.gov. Some specialists have suggested that extensive changes are required before the site will operate properly and that the repairs could take months. (“Contractors See Weeks of Work on Health Site“, The New York Times, October 20, 2013) The problems have created mounting pressure on the current administration, including plans for a congressional hearing later this month and calls for senior administration officials to lose their jobs. (“HealthCare.gov launched despite warning signs”, The Washington Post, October 22, 2013).

Indications at this point are that a number of missteps contributed to the problems with HealthCare.gov. During the 10 months prior to the October launch, the government changed the software and hardware requirements for the project at least seven times. (“Contractors See Weeks of Work on Health Site“, The New York Times, October 20, 2013) As of September, the government was still debating whether consumers should be required to register before shopping for insurance. (“From the Start, Signs of Trouble at Health Portal“, The New York Times, October 12, 2013) As late as September 26th, the system had not been tested from the end-to-end perspective of an individual trying to buy insurance on the site. (“HealthCare.gov launched despite warning signs”, The Washington Post, October 22, 2013). The federal government appears not to have followed a disciplined process in completing this project, which is a critical mistake that is all too common in these kinds of projects.

We outlined some of the elements of a more disciplined approach in our prior post [Obamacare: Meeting Implementation Challenges with Contracting Best Practices], including (1) a robust Implementation Project Plan to clarify the responsibilities of the parties engaged on the project, (2) the use of Critical Milestones to ensure that the contractor is delivering value during the course of the project and as a bright line test of whether the customer is entitled to exercise termination and other remedies, (3) requiring the contractor to pay Critical Milestone Credits as an incentive to stay on schedule, and (4) defining clear Acceptance Criteria to signify when a milestone has been met. For instance, if the federal government and its 55 contractors had adopted an Implementation Project Plan and strictly adhered to it, the government would have been forced to provide requirements earlier in the process, which would have permitted more time for developing and testing the code and may have mitigated some of the current issues.

The roll-out of HealthCare.gov is a good reminder of the types of things that can go wrong with large software development and integration projects. Although it is not clear whether contracting deficiencies contributed to the Exchange-related issues, below are some additional tools that a customer that is about to embark on such a project may use to prevent similar problems.

    • Clear Statement of Accountability – It’s critical that the contract accurately reflect the level of accountability that the customer expects from the supplier. In this type of transaction, this includes whether the supplier is being asked to be the system integrator for the project, responsible for making sure that all the parts of the system (some of which may have previously existed and others of which may have been developed by one or more suppliers) functions properly as a whole. Our experience is that many companies enter into contracts in which they erroneously believe that the supplier has taken on a broad level of responsibility (such as having overall accountability for a deliverable or system), when in reality the contract is not clear on this point. Customers should ensure that the contract reflects the level of accountability that they seek from their suppliers.
    • Testing – Complex integration projects require a robust testing regime, and this must be reflected in the contracts, project timelines and project resources. Testing will often occur in several stages, including unit testing, integration testing, system testing, acceptance testing, and performance testing. Although the details of testing plans and “use cases” can often be developed after contract execution, the types of testing to be performed should be set forth in the contract. The contract should also clearly define the testing responsibilities of each party at each stage of testing. The project plan should reflect the testing periods as well as time to correct deviations from the specifications (non-conformities) identified by the testing. Tying payment milestones to the successful completion of testing stages can help ensure that testing requirements are given proper attention.
    • Warranties – Customers should ensure that the contract contains a meaningful set of warranties so that the customer has recourse if problems arise. These warranties are part of documenting the desired level of supplier accountability discussed above. The warranties should include:
  • General Warranty – Software developers and contractors generally propose to warrant that the software system will operate in accordance with all material aspects of the requirements and specifications (or documentation). This is not sufficient. The warranty should state that the software system will operate in accordance with the requirements and specifications in all material respects. The difference is subtle yet important, as the software should meet all the requirements and specifications, not just those that are material. Presumably the customer believes all of the requirements and specifications are material, or they would not have included them in the first place.
  • Duration of the Warranty: Implementation and Post Production – It is important that the warranty be in effect not only after the implementation is complete, but during the implementation itself. This is because the customer will be expending valuable resources operating the software in development and test environments during implementation, so the software needs to operate properly during that time in order for the work to be productive. It is also important that the warranty be in effect for some period of time after commencement of production operations, so that the system is tested in “live” circumstances with actual loads, so that all problems will have a chance to surface and the customer have an opportunity to have them fixed under the warranty.
  • Scope of the Warranty – If a customer wants its supplier to take full accountability for the success of a project, the supplier must have control over the full implementation. That is, a warranty can only be as broad as the scope of responsibility that the supplier is given. This may require that the customer give up control over aspects of the project in order to obtain the warranty that the system will perform in accordance with its requirements and specifications.
  • Other warranties – The customer may also wish to include other warranties regarding the system, such as a warranty that the system is scalable to some level of users, or that, assuming a certain hardware and operating system configuration, the response time will not be greater than X.
  • Post Acceptance Obligations – It is important to note that the supplier’s obligations do not end with acceptance of the system by the customer. Although meeting the acceptance criteria may obligate the customer to accept the system and trigger payment obligations, such acceptance should not relieve the supplier of correcting any remaining non-conformities. For example, the acceptance criteria may require that the system be free of programming errors that create a Priority 1 or Priority 2 incident. At such time that the system satisfies such requirement, the customer may be obligated to accept the system, but the supplier should remain obligated to correct any Priority 3 and Priority 4 non-conformities. Typically these would be documented and a schedule created for the supplier to fix them. Or the minor issues may be left to be resolved in the next update of the software.

The issues arising in connection with the roll-out of HealthCare.gov demonstrate the need for companies to be careful when entering into contracts for large scale development and implementation projects, and the foregoing tools will help to provide the type of protection needed for these transactions.

Posted
By

Customers increasingly are taking advantage of Software as a Service (SAAS) and other cloud-based solutions available in the marketplace. There are of course many legal and commercial issues that customers should consider when evaluating contracts provided by suppliers of these solutions. This post focuses specifically on issues arising when SAAS or other cloud solutions will be provided from an offshore location. For example, data hosting, help desk/service desk, implementation, and disaster recovery services are often provided from India, the Philippines and other offshore locations in support of solutions that are delivered in North America and Europe.

  • Transfer of Customer Data Offshore. Customers should consider whether there must be restrictions on the transfer of data offshore (whether due to internal security policies, industry standards, obligations within downstream customer contracts, or applicable laws and regulations). If the data contains personally identifiable information (PII), protected health information (PHI) or similar types of data covered by data privacy laws, the data most likely should remain onshore. A customer may decide that other data may be transferred offshore, but only if additional safeguards, contract restrictions or liability provisions are added to the contract with its service provider.
  • Access to Customer Data or Systems from Offshore. This issue turns the item above on its head, a bit: even when customer data and systems remain onshore, customers should consider whether personnel from the SAAS or cloud service provider should have access to such data or systems from offshore. For example, offshore personnel who are accessing service desk records or performing break-fix services may request the ability to access a customer’s onshore systems. This may or may not be acceptable in any case, or it may be acceptable only if certain agreed-upon restrictions are followed.
  • Security Concerns. Customers should ensure that they understand the physical and logical security applicable to the offshore component of the SAAS or cloud solution that they are buying, and confirm that it complies with their overall network, application and data security standards. For example, customers may want to ensure that they can (i) inspect the service provider’s policies and procedures related to security and (ii) perform site audits of locations where offshore services are provided. They also may want to prohibit or restrict offshore employees from working from home.
  • Flash Drives/Printing. Customers should consider restricting the ability of offshore personnel from using computers that allow the customer’s data to be downloaded. Restrictions on the ability to print, prohibitions against the use of flash drives, and prohibitions against the use of both internal and external hard drives by offshore personnel are not uncommon.
  • Permissions of Offshore Governments. Customers should consider which party (the customer or the service provider) should be responsible for obtaining any government authorizations that are necessary to provide services from offshore, whether those are onshore or offshore governments. Related to who must take responsibility for obtaining any authorization is the issue of which party is responsible to pay any associated costs.
  • Encryption. If data is being sent offshore, customers may have certain encryption standards that they want their service providers to meet or particular encryption software that they want their service providers to use. It is important to note that the use of encryption technology is restricted with respect to the transmission of data to certain countries worldwide, so customers should coordinate with legal counsel to confirm that the use of encryption technology is in compliance with applicable law.
  • Personnel Matters. Customers should inquire as to how high the turnover rate is among the offshore workforces of their potential service providers. In some cases, customers may want to ensure that (i) there are turnover restrictions or service levels in place; (ii) incentives to avoid turnover are implemented; or (iii) at a minimum, the customer receives reports as to the turnover rates so that the customer will be aware if turnover becomes an issue. Additionally, customers will want to ensure that their contract makes clear that the service provider is responsible for compliance with applicable laws and customer policies relating to personnel. This may involve not only employment screening, reference checks and hiring issues, but also compliance with any applicable immigration laws (including visa status) and employee benefits requirements.

If SAAS or other cloud solutions will involve any offshore services, customers should carefully consider these issues and ensure that they have the necessary contract terms in place in order to protect themselves from potential risks related to the offshore services. Taking this a step further, we recommend that customers have a set of pre-prepared terms that they can include in contracts that will involve offshore services (these terms can be included in a stand-alone contract schedule or incorporated into the main body of the contract). If a customer is negotiating with a large service provider that offers a standard SAAS offering or other public cloud solution, the service provider may not be open to considering the customer’s standard offshore terms, but instead may have its own data security “fact sheet” or similar contract attachment. In that case, customers will want to review and attempt to supplement the service provider’s data security terms to make sure they adequately address the issues described above.

Posted
By and

The Transfer of Undertakings (Protection of Employment) Regulations 2006 (“TUPE”) is in the spotlight as part of the UK Government’s Employment Law Review.  Launched in 2011, the purpose of the review is to reform employment law in order to achieve a fair, effective and flexible labour market in the UK[1].  The Government says that these reforms will support better relationships between workers and employers and are aimed at making evolutionary improvements to the labour market which will retain flexibility and dynamism and benefit individuals, employers and the economy.

TUPE implements the EU Acquired Rights Directive (“ARD”) in the United Kingdom.  It protects employees’ terms and conditions of employment when a business is transferred from one owner to another.  Where TUPE applies, there is an automatic transfer – for the affected employees it is as if their employment contracts had originally been made with the new employer, with their continuity of service and, subject to a few exceptions, other employment rights all preserved.

In an outsourcing context, TUPE will often apply because of the service provision change (“SPC”) rules. A SPC will usually occur where there is a change of service providers or a contracting in or out of services.  TUPE is complex and is viewed by many as overly bureaucratic, leaving little room for new employers to make post-transfer changes to an employee’s contract or to dismiss them fairly.  Critics say the SPC provisions, which were introduced in 2006, went beyond the requirements of the ARD- so called “gold plating.”  Taken in the round, the impact of TUPE, in its current formulation, may constrain the incoming service provider’s ability to restructure the inherited work practices, thereby impeding innovation and cost reduction.  TUPE has also spawned complex indemnity and post-contract verification provisions in outsourcing agreements, reflecting the additional complexity associated with personnel transfers. 

In previous posts [TUPE: Service Provision Change – Do we need this provision?, The UK Government consults on proposed changes to the TUPE Regulations] we discussed the Government’s proposals to simplify TUPE.  One of the Government’s key proposals was to repeal the SPC rules entirely. This proposal was opposed by 67% of the respondents to the Government’s Consultation who believe the SPC rules brought much needed clarity on the application of TUPE and reduced the number of TUPE claims to the Employment Tribunal.  The Communication Workers’ Union[2] strongly opposed the proposed repeal.  In its response the Union said: “The government’s proposals are bad for business. They will lead to greater uncertainty. Many SPCs – the impact assessment estimates 65% based on 2006 analysis – will remain subject to TUPE following any repeal of the 2006 legislation; however, which transfers are subject to TUPE will become very unclear. This ambiguity will necessarily lead to more legal challenges, increasing the burden on business and workers. The government’s priority of reducing the burden on business will not be met; instead the burden will fall disproportionately on those embroiled in legal challenges over the application of TUPE.”

The Government also proposed to provide greater flexibility in making changes to terms and conditions of employment post transfer, which was welcome by employers who would like to harmonise terms and conditions of employment across their workforce.   

On 5 September 2013, the Government published its response to the Consultation (the “Response”) detailing its intended reforms, which do not go as far as originally planned.  Clearly, the Government is attempting to find the balance between competing interests.

 Changes of Substance:

1.     Dismissal on the grounds that there is a change of workplace location will fall within the scope of an economical, technical or organisational (“ETO”) reason entailing changes in the workforce. Under current law, terminations resulting from relocations of work are a dismissal for a reason connected with a transfer and will be automatically unfair unless there is an ETO reason justifying the dismissal. Relocation of work does not fall within the current ETO definition of “entailing changes in the workforce” because the relocation alone does not involve a reduction in the number of employees employed or changes to their job functions. This amendment to the ETO definition means that a dismissal due to a change of location would not be automatically unfair but will still be subject to the usual unfair dismissal rules.

2.     The transferee will be permitted to renegotiate terms in a collective agreement beginning one year after the transfer, provided that the new terms are no less favourable to the employee.

3.     Micro businesses (those with 10 or less employees) will be allowed to inform and consult directly with the employees where there is no recognised trade union or existing employee representatives.

4.     Collective consultation on redundancies can take place before the transfer provided that this is agreed by the transferor and transferee and the consultation is meaningful.

Other Changes of Note:

1.     Terms negotiated as part of a collective bargaining process after the relevant transfer will not be binding on the transferee unless the transferee is either a party to those subsequent collective agreements or participates in the bargaining process.  The effect of post transfer variations to collective agreements by the transferor becoming binding on the transferee has been subject to legal challenge in the UK with conflicting outcomes. This change effectively codifies the approach adopted by the Court of Justice of the European Union (CJEU) judgment in Parkwood Leisure v Alemo-Herron (C-426/11)[3]

2.     The obligations on the transferor service provider to provide Employee Liability Information will remain but this must now be provided to the transferee at least 28 days before the transfer rather than 14 days.  This is unlikely to have any significant impact as the commercial agreement will usually contain a timescale for disclosure of such information and in our experience the provision of such information is usually commercially required to be given at least 28 days before the transfer if not sooner.

3.     Regulation 4, which restricts changes to terms and conditions of employment and dismissing employees because of the transfer, will be amended to accord more closely with the wording of the Acquired Rights Directive so that changes made because of the “transfer itself” (as opposed to “connected with the transfer”) will be void. The new test is unlikely to make much difference in practice.

What has not changed?

1.     The Government has backtracked from its earlier proposal to repeal the SPC rules and has accepted that the rules provide much needed clarity on the application of TUPE in outsourcing/insourcing situations. The SPC provisions will remain but will be amended to reflect the current case law  which is that, for TUPE to apply to a SPC, the activities carried on after the change must be “fundamentally or essentially the same” as those carried on before it.  Therefore, if the services are provided in a different way post transfer, TUPE may not apply.  The proposed amendment to codify current case law is practical as the SPC rules have recently come under scrutiny by the Courts, as highlighted in our previous post [TUPE: Service Provision Change: Do we need this provision?], and there is now quite detailed guidance from the Courts on when a SPC falls within the scope of TUPE.   

2.     The Government has decided not to allow the transferor to rely on the transferee’s ETO reasons for pre-transfer dismissals. This means that any pre-transfer dismissals by the transferor related to the transfer will be automatically unfair unless the transferor has its own ETO reason.

3.     Harmonising terms and conditions of employment post-transfer are still prohibited. However, the Response indicates that the Government does recognise the business need for this and will engage with its European Partners on the issue.

Enactment

On the whole the changes as currently drafted are sensible and do benefit employers, particularly with regards to codifying current case law, permitting genuine place of work redundancies, reducing the impact of collective bargaining agreements and allowing for collective consultation to take place during a TUPE transfer. The retention of the SPC rules will be a welcome relief to many businesses.

The Government previously proposed to implement the TUPE reforms in October 2013. However, the amended TUPE Regulations are still being drafted and are expected to be laid before Parliament in December 2013 with the reforms expected to come into force in January 2014 subject to any transitional provisions.

[1] See Policy paper: Employment Law 2013: Progress on Reform (which Outlines the government’s vision for the UK labour market and Employment Law Review work to support an effective labour market) https://www.gov.uk/government/publications/employment-law-2013-progress-on-reform

[2] The Communication Workers’ Union (CWU) is the largest union in the communications sector in the UK, representing over 200,000 employees in the postal, telecommunications and financial and business services industries.

Posted
By

Google has figured out that I shop for a lot of children’s clothing online, as my two children grow like weeds. Every time I launch a search, my banner ads link to brands that I have bought previously or similar brands that other consumers may have purchased. That is Big Data at work, as it is being used to identify other brands that I might be interested in purchasing based on shoppers with similar consumer profiles to mine. But let’s say that the next banner ad I receive isn’t for children’s clothing, but is instead for an all-inclusive Caribbean vacation. Well, I have never searched for Caribbean vacations, why would this be turning up? Again, this is Big Data at work, because patterns in human behavior have informed Google that people with small children are likely good targets for a quick getaway vacation. This is an example of the value of Big Data in predicting individual consumer behavior based on the behavior of many.

“Big Data” is the somewhat uncreative but accurate term for the process of collecting, culling, and categorizing of data from diverse sources on a massive scale. Through the application of algorithms, companies are analyzing Big Data in order to see patterns in human behavior, and (most commonly) using it to develop targeted, individualized marketing. The primary goal of Big Data is to learn from a large body of information things that we could not comprehend when we used only smaller amounts. Recent trends point to an increase in the use of Big Data, but there are several cautionary points from a legal and privacy perspective to consider.

What are the uses of Big Data, and who uses it? The potential benefits are wide ranging, but can be categorized as follows:

How is this different than the statistical analysis that companies have been engaged in long before the advent of the Internet? Plenty of organizations have been handling and sifting through massive amounts of data for years. Why is the use of Big Data on the rise with no sign of slowing?

However, with the rise of Big Data, privacy and legal concerns have risen as well. Julie Brill, Commissioner of the Federal Trade Commission has voiced a number of concerns about privacy of consumers in the context of Big Data:

  • “De-Identifed” Information Can Be “Re-Identified”: Data collectors claim that the aggregated information has been “de-identified,” however, it is possible to re-associate “anonymous” data with specific individuals, especially since so much information is linked with smartphones.
  • Possible Deduction of Personally Identifiable Information: The non-personal data could be used to make predictions of a sensitive nature, like sexual orientation, financial status, and the like. FTC believes that collecting and using sensitive information requires more robust notice to the individual than non-personal information, which may not have been obtained as part of the initial consent.
  • Risk of Data Breach Is Increased: The higher concentration of data, the more appealing a target it makes for hackers, and the greater impact as a result of the breach. The notification requirements to individuals in the event of a breach vary from state to state, but it can very quickly add up to a substantial cost to an enterprise. As a result of this potential cost exposure, companies may need to invest in increased security and insurance to protect their data assets.
  • “Creepy” Factor: Consumers are often unnerved when they feel that companies know more about them than they are willing to volunteer. There is a sliding scale between tangible benefits that consumers appreciate (e.g., loyalty programs, rewards cards) and feeling that a company has stepped beyond personal boundaries (the anecdote of Target sending baby related coupons to a teenage girl before she had even told her immediate family members about her new bundle of joy still stands as the benchmark horror story of invasive marketing).
  • Big Brother or Big Data: Municipalities are using Big Data for predictive policing, and tracking potential terrorist activities. Concerns have been raised that such uses could become a slippery slope to using Big Data in a manner that infringes on individual rights, or could be used to deny consumers important benefits (such as housing or employment) in lieu of credit reports.

The general legal concerns about Big Data are just as complex as the privacy concerns. Naturally, determining which issues are of greatest concern to you or your clients is dependent on your role in the relationship – are you the data miner, analyzer, or licensee? As the laws and best practices still evolving, here are a few key issues to analyze and address when you or your clients are considering the use of Big Data:

  • What are your intellectual property rights in the data? Data analytics requires copying the data, so you will need to ensure that your ownership or license rights are sufficiently broad to cover the intended use with clear ownership rights in the data and any derivative work that is created from the data.
  • Who bears responsibility for inaccurate data? If a party relies on a pattern developed as a result of analyzing inaccurate Big Data, which party bears responsibility for the results? Since Big Data’s very nature relies on a massive volume, there is almost always going to be some degree of inaccurate information included.
  • Have you obtained the appropriate level of consent from the individual? Make sure that any consent that you have obtained from the individual to use data covers your intended purpose, including licensing that information to another party. As a best practice, advocate for full disclosure to the individual about your use of their data.

The legal risks engendered by using Big Data are also complicated by the myriad of state and Federal laws that are staking out regulatory territory with regard to privacy issues. While Congress mulls over a standard Federal law to address data breach notifications, there are a number of privacy related Federal laws that address the use of certain types of data and end users, such as HIPAA and the Children’s Online Privacy Protection Act. As noted above, the FTC has been vocal about its concerns with Big Data use, and has provided its own guidelines on data collection, including calling upon data brokers to provide consumers with more transparency on the use of their data. In addition, States are also weighing in with their own privacy laws (e.g., the California Online Privacy Protection Act). Finally, there are multi-country issues, as data privacy laws vary tremendously from country to country, with the EU imposing more onerous restrictions than the U.S. and higher burdens on companies in the event of a data breach.

Big Data can tell us many things, one of which is that perhaps we are not the mad cap, free spirits we might think ourselves to be. Our behavior in the aggregate is predictable. The benefits of deriving behavior patterns in Big Data are many, and there is the potential for even more as data analytics becomes more commercially available and commonplace. When considering the use of Big Data at your enterprise, advocate to 1) define clear ownership in the data with data collectors and individuals, 2) establish transparency to the individual with regard to the purpose and use of data, 3) tap into resources to monitor for State and Federal regulatory changes, and 4) avoid “creeping out” your customers.

Posted
By

In addition to the consumer hoopla over iOS 7, companies managing BYOD programs also have reason to rejoice. As reported on CIO.com, iOS 7 brings about a new level of control for companies through expanded app-level MDM Capabilities. MDM, or Mobile Device Management, is the technology that companies use to try to segregate the corporate and the personal realms on mobile devices.

Of course, the trick is not in having the coolest technology, but it how you use it. For app-level MDM to work, the company takes control over the app (including the ability to wipe the app and its data). For some apps that themselves share personal and corporate activities (e.g., the address book), the company’s use of MDM to protect its corporate assets will also sweep in personal assets. One can debate whether this is good or bad, but it does exacerbate challenges in balancing personal versus corporate interests. The tool makes it easier to protect the corporate assets, but exposes the personal assets to greater risk.

As we have outlined in prior posts, courts have striven to protect the individual’s interest in their personal data stored on mobile devices from over-reaching companies. Again, as we have previously discussed, the best way for the company to protect itself is by being very clear in its BYOD policies as to what it will and will not do. This requires the manager of the BYOD policy to understand clearly the technical implications of the new iOS 7 capabilities–including both the intended and unintended consequences of leveraging those capabilities–and to make those implications clear to company employees.

While companies cannot eliminate all risk, by being proactive and notifying their employees of the conditions of using BYOD devices (including through implementation of updated BYOD policies), they can take advantage of the new technical capabilities of iOS 7 MDM to protect their assets, while limiting exposure to claims by employees that do not understand the implications of BYOD.

Posted
By

As the U.S. moves toward full implementation of the Federal Affordable Care Act (ACA, also known as Obamacare), employers are seeing new challenges and opportunities in the provision of health coverage and other benefits to their employees.
Some predict that ACA will lead to cheaper, better, universal health care. Others predict a calamity. But most agree that the law will drive significant change in the way health care is delivered, paid for and insured in this country. Employers are left wondering how to plan for and manage those changes while containing costs and meeting their employees’ expectations.
Human resource consultants and product vendors are responding by aggressively promoting their services as an answer to the complexity and administrative headaches created by the legislation.  Outsourcing benefits administration functions to these specialists is one approach. Another approach is to engage one of several service providers that have launched private health insurance exchanges in the two years since the ACA legislation passed.
These exchanges promise to address two critical challenges facing employers -1) ensuring compliance with the ACA’s complex rules, in addition to any applicable state and local laws, and 2) securing appropriate coverage benefits for employees at an affordable cost.

What Are the New Private Health Exchange Options?
Individuals and small businesses may use public, government-run exchanges like Covered California to compare and purchase insurance plans.
Larger employers can continue to arrange their own health care programs. As an alternative, some will direct their employees to the public exchanges if the exchanges deliver better pricing, better service and greater options for their employees.  Sixteen states and the federal government will have such exchanges operating come January 2014. This constitutes a threat to existing payors, who may see their business migrating to commoditized public exchanges. Private exchanges recently launched by health insurers, brokers, and human resources and administration consultancies, including major players like Aon Hewitt, Mercer, and Towers Watson, offer individuals and businesses an alternative to the government-run exchanges and traditional payor health care plans. At a minimum, these exchanges generally offer:

· An online self-service portal for covered individuals

· Pre-packaged insurance products (medical, dental, vision, life, other)

· Standard benefits products 

In pitching their services to employers, private exchange operators are touting the prospective advantages of:

· Outsourced regulatory compliance

· Standardized benefits

· Simplified administration

· Reduced costs

 

Key Questions to Ask
What do companies need to know when they begin researching their options and negotiating with an exchange provider? Some key questions that employers need to consider include:

· What are the company’s objectives for the exchange and how will they be assured? 

· How will quality and costs be measured and benchmarked? 

· What levels of service does the company and its employees expect from a private exchange?  Just an online site where employees can research and select their insurance plans? A call center that can provide individualized advice? Or interactive integration with the company’s existing benefits administration infrastructure?

· What kind of contractual relationship should the company have with the exchange provider?  Some vendors are putting forward their “software as a service” (SaaS) contracts as the basis for the relationship, but such contracts are inadequate for a broader outsourcing relationship encompassing higher-level customer care and back office functions. Behind-the-scenes business processes are not part of a traditional SaaS deal and must be addressed through appropriate due diligence and contract terms.

· Who assumes fiduciary responsibility?  Service providers typically want to avoid any fiduciary duty. On the other hand, employers and other plan fiduciaries want to mitigate their ERISA fiduciary liability by engaging a co-fiduciary. Depending on the specifics of the arrangement, the service provider may be assuming a co-fiduciary role, particularly if the service provider will handle employee funds such as premium payments or reimbursement accounts.

· Which party is responsible for ensuring compliance with applicable laws as those laws change?  Allocating responsibility for complying with federal, state and local laws–particularly during a period of significant change like the ACA’s implementation–can be problematic.

No doubt there will be many turns in the road as the Affordable Care Act moves towards implementation.  Those companies that can’t afford to wait for the legislative dust to settle are being forced to plan in an environment of real uncertainty.   In this environment a clear strategic roadmap, supported by thoughtful contracting, is more important than ever.

By
Posted In: Industry Trends
Posted
Updated:

Posted
By

It has been said for some time that data is the new oil, but many global organizations continue to struggle to comply with regulatory requirements when it comes to the exploitation of this valuable resource.

A recent worldwide audit of over 2,000 websites, coordinated by the Global Privacy Enforcement Network (“GPEN”), has revealed “significant shortcomings” at many organizations. In particular, approximately half of the websites “swept” failed to display a complete, coherent and compliant privacy policy, or worse still, any policy at all.

The audit, the first of its kind, was conducted in May of this year by 19 different data protection authorities around the world, including the UK’s Information Commissioner’s Office (“ICO”).”The results reveal significant shortcomings” reports Adam Stevens, Intelligence Officer at the ICO, on 16 August, stating that 23% of the 250 websites it reviewed had no privacy policy at all and that a third of those that did have policies ” were considered to be difficult to read, and many weren’t sufficiently tailored to the actual website”.

These statistics are particularly significant given the audit’s focus on larger companies – companies one would expect to be ahead of the curve when it comes to providing information on their collection and handling of personal data. Presumably a more in depth survey of smaller companies with a web presence but a smaller compliance budget would produce even more alarming results.

The Canadian data protection authority also participated in the study, making similar observations to those of the ICO. Jennifer Stoddart, Privacy Commissioner of Canada, provided some non-compliant examples which were particularly eye-catching:
“A particularly disappointing example for my Office was a paternity testing website with a privacy statement so skimpy it would fit into a tweet. We also found a major fast food chain collecting personal information, such as photos, addresses and dates of birth, for various initiatives, and yet the privacy policy was just 110 words. At the other extreme, we saw long, legalistic policies that simply regurgitated – word for word in some cases – federal privacy legislation”.

Ms. Stoddart went on to say that “Neither approach is helpful to Canadians – nor necessary, as demonstrated by the many privacy policies we saw that were able to strike a balance between transparency and concision”.

Importantly, the various watchdogs have now committed to contacting those companies where significant concerns arose, leaving the door open to a potential wave of enforcement action off the back of the sweep in any number of jurisdictions.

The study is also likely to lead to further cooperation and collaboration among international authorities on an issue that crosses international borders. For example, the GPEN members have given some examples of best practices for companies to follow when drafting global privacy policies. These policies, along with already published guidance by regulators such as the ICO and Canadian data protection authority, are a good place to start when drafting privacy policies from scratch or for those companies in need of routine health check.