Practical Guide to Privacy & Security for Retailers

Retailers are facing risks as more and more of their operations is moving online.  These risks are legal, reputational, operational, investment, and data breaches. In this report you will learn about:

  1. Boards, Executives, and Privacy Compliance Obligations
  2. What You as a Director Can Do
  3. FTC and Canadian Privacy Obligations
  4. The report will provide you with an Implementation Checklist
  5. Detailed Recommendations on :
    1. New Technologies and Consumer Data Protection
    2. In-store tracking
    3. Internet of Things
    4. Mobile Apps
    5. Behavioural Advertising
    6. Hacking and Phishing Threats
  6. In addition to HR issues on : Legal Privacy Obligations, Relevant Federal Law, Anti-discrimination, Background Checks,Workplace Monitoring, Post-employment Access Issues
  7. Relevant State and Provincial Law, Tort Law, Contract Law requirements

Download this guide to learn more about how to prevent a potential attack on Retail Data. In recent years, news of massive data breaches has become almost commonplace. Major retailers such as Target and Home Depot have been targeted; so too have hospitals, universities, and both the US Internal Revenue Service and Canada Revenue Agency. We are witnessing an unprecedented increase in cyber attacks. Privacy and information security have never been more important, yet it is clear that many companies are struggling to keep up with new technological issues and legal requirements.

For retailers, compliance is a vital aspect of corporate governance. Traditionally, “security” has meant securing store locations and computers. Now, it also means securing personal data online. Corporate compliance – meeting regulatory requirements for privacy and security – is an equally important aspect of corporate governance.

Audience:

This report is for ideal for CISOs, security, compliance and risk management officers, IT administrators and other professionals concerned with information security, this guide is for IT decision-makers that need to implement strong authentication security, as well as those evaluating two-factor authentication solutions for organizations in the retail industry.

Download our  guide today for a detailed overview of the retail industry’s current state of security, and recommendations on safeguarding customer financial information.

Data Protection in Design

Time for a New Vision

Up until now, we have viewed privacy and security on the same sliding scale, through which it appears to be impossible to have one without hurting the other. Envisioning a country where privacy is prioritized over security and surveillance seems absurd. However, it is time that we disrupt this traditional way of thinking.

How? Through Data Protection in Design. By developing and building data protection into the design of private, public, and political systems, citizens would have the ability to express their desires, change the system, and influence government, all the while minimizing the risk to national or public safety. Instead of pitting the forces for privacy and the forces for security against one another, the two forces should be integrated in order to reap the benefits of both.

It is no longer a balance between privacy freedoms and security, but rather about achieving both outcomes in an effective way

Agile Privacy for Modern Software Development

 With the increasing popularity of agile IT, privacy officers responsible for assessing new software programs are finding it difficult to keep track of changes and ensure that proper checks are in place. We propose an agile approach to privacy assessment that can reduce confusion, increase compliance, and improve relationships between privacy and IT.

Privacy Impact Assessments (PIAs), which are required for government initiatives involving the use of citizens’ personal information, aim to identify, measure, and mitigate privacy risks. PIAs evaluate an initiative’s management of privacy by analyzing policies and processes for the collection, retention, use, and disclosure of information. This type of systematic, end-to-end analysis is most effective when it is integrated into the planning of a new initiative. A PIA during the design phase of a project can identify risks before they arise and enable the seamless integration of privacy best practices into design.

In an information technology (IT) context, a comprehensive PIA fits well into the traditional, waterfall method of software development. This method’s four stages, analysis, design, implementation, and testing, form a systematic and gated approach which allows for thorough quality assurance before software is launched. A PIA during the design phase forms part of this process.

However, the waterfall method has become less popular. Largely because of its deliberate and thorough process, projects usually end upbehind schedule and over budget.The newer model of software development is the agile method: rather than designing, testing, and launching software packages as a whole, developers create a program prototype, set up the software interface, and develop and release features one at a time. Users start with a simple version of the software and add features as they are released. Each feature is developed in a development “sprint” of about two weeks. This flexibility not only allows for quicker release, but also makes it easier to refresh programs by simply adding or replacing specific features rather than reworking the whole program.

Privacy officers have made efforts to adapt PIAs to an agile IT environment. Often, a generic PIA is conducted based on the software’s conceptual system design. The PIA is then typically refreshed with each major redesign or new feature, often at considerable expense. However, smaller changes or features are usually released without any evaluation from a privacy standpoint. These changes can nonetheless pose significant privacy risks, especially when numerous small changes togethersubstantially alter the operation of a program. Because of the constantly evolving program design, privacy officers find it difficult to keep track of new developments and to discern what needs to be re-assessed from a privacy perspective. This challenge very often resultsin tensionsbetween software developers racing to release a new feature and privacy officers arguing for checkpoints for compliance evaluation.

These difficulties can largely be addressed by an approach to privacy assessment that mirrors the distinct activities making up the agile IT development process. Three natural points of contact between privacy and agile software development are:

1. Development Process

One of the major difficulties in conducting privacy assessments during the software development process is that communication between privacy staff and IT staff can be fragmented and unproductive. A simple communication system can cut across confusion and inefficiency: when coding features, software developers tag each data variable in the program code that corresponds to data collection (entering data), retention (saving or storing data), use (processing, editing, managing, or linking data) and disclosure (sending data). Privacy staffthen assesses the compliance of the actions represented by the tagged variables. When a feature is altered, privacy staff will only need to re-examine tagged variables which have been changed.

2. Application

Changes in user experience(software interface) are often overlooked from a privacy perspective. However, interface changes can make certain features easier or more difficult to access or change, which can affect privacy. For instance, an interface redesign that allows predictive name typing based on user input (i.e. once a few letters of a name have been entered, the interface suggests names beginning with these letters) is a major privacy risk.  If the data management process has not changed, but the interface has been altered, privacy officers can refresh their assessment of the interface only without re-examining the process.

3. Release Management

Before new features or updates are released, privacy staff does a high level review, checking that appropriate tests have been done, licensing is in place, and any design changes have been approved from a privacy standpoint. These due diligence checks constitute a final gate before release, ensuring that privacy staff has access to the most recent information when they refresh the privacy assessment.

The processes of agile IT and privacy assessment have often been at odds with each other, but this does not have to be the case. A modular approach to privacy assessment that mirrors the agile IT process can greatly improve communication between IT and privacy staff, leading to increased compliance and saving time, resources, and frustration. By clearly separating program areas that have and have not been assessed, an agile privacy assessment process eliminates both assessment gaps and duplication of work. In contrast to established PIA models better suited to a waterfall development process, an agile PIA model fits smoothly into an agile IT process of continuous change, turning privacy from a roadblock into an unobtrusive safety check.

IAM Maturity Model

Identity and Access Management (IAM) has two seemingly opposed purposes: to enable user access to information, and to block user access to restricted information. In fact, strong security and user-friendly access are by no means mutually exclusive: a mature IAM solution provides both. Read a summary of my IAM Maturity Model.

Governance Analysis Method – PhD Thesis Waël Hassan

Governance Analysis is a logic-based, computer assisted framework for validating legal compliance of enterprise governance models. This framework is intended to help check whether governance systems are consistent with the law. My approach to Governance Analysis includes legal and enterprise models, a governance analysis method (GAM), a governance analysis language (GAL), and an implemented governance analysis tool (GAT) (see Publications). GAM consists in extracting legal requirements and translating them into GAL statements by using patterns and translating them into a logic model for consistency checking.

The GAM, GAL, and GAT evolved as a result of their application to governance laws related to privacy and financial management. The method’s main processes were validated through application to Canadian and US laws (mainly PIPEDA and Sarbanes-Oxley) combined with various examples taken from enterprise systems.

Governance Analysis begins with an extraction process, which uses patterns to match legal and enterprise requirements. Next, the representation process maps extracted requirements to GAL statements. The generation process takes as input GAL statements to generate a logic model, and the Alloy logic analyser is used to check legal consistency. Three legal compliance validation techniques can then be applied: model, ontology, and scenario checks (see What are the Methods for Validating Legal Compliance?). Model checks validate the combined legal and enterprise requirements for logical consistency; ontology checks validate the enterprise structure and process; and scenario checks validate enterprise scenarios.

These Governance Analysis techniques have proven to be useful not only for identifying conflicts between laws and enterprise governance models, but for identifying the specific scenarios in the enterprise which threaten legal compliance.

De-Identification Maturity Model

Recently I have been working on a formal framework for evaluating the maturity of de-identification services within an organization. The framework gauges the level of an organization’s readiness and experience with respect to de-identification, in terms of people, processes, technologies and consistent measurement practices.
The De-Identification Maturity Model (DMM) is used as a measurement tool and enables the enterprise to implement an empirically-based improvement strategy.

The DMM was published under the auspices of Privacy Analytics, a leader in de-identification technology solution delivery.  Alternatively, the article can be downloaded from DMM Khaled El-Emam & Wael Hassan. Or download a one-page DMM Summary.

 

 

What is Legal Compliance?

 

A set of enterprise requirements is considered compliant with the law if the requirements are legally consistent and compliant with respect to the law.

 

 

Legal Compliance is about Legal Consistency & Completness
Legal Compliance

 

 

The figure above shows the proposed methods for consistency and completeness checking. The square boxes represent the methods, which we have partially presented in the previous post: model consistency check, scenario check, ontology check, and coverage check.

How to withdraw and control my private health information in Ontario?

Consent Management in Ontario

Depending on the type of personal health information (PHI) involved, Ontarians can withdraw consent to the use and disclosure of their PHI by various health information networks.

  1. Calling Service Ontario allows you to:
    Block access to all personal health information used in Ontario labs
  2. Calling Service Ontario – Ministry of Health Info-line, you can ask to:
    Block access to the use of all personal health information:

    1. In the drugs database
    2. Related to a specific drug in the database
  3. Visiting an Ontario lab, you can ask to:
    Block access to the use of all personal health information used:

    1. In Ontario labs
    2. In a specific lab order
  4. Sending a fax to the Drug Programs Branch allows you to:
    Block access to all personal health information:

    1. In the Drugs Database
    2. Related to a particular prescription
    3. Related to a particular drug
  5. Any hospital, clinic, or independent healthcare practitioner should be able to give you a form that you can send to the Service Ontario Ministry of Health info-line.